коммуникация, потому что успешные команды, уполномоченные компанией вести водопадную разработку, постоянно поддерживают контакт со своими пользователями, менеджерами и руководителями на протяжении всего проекта;
• хорошие методики, особенно такие как анализ кода и автоматизированное тестирование, которые направлены на поиск ошибок на раннем этапе. Обычно это называется «предотвращение дефектов» и необходимо команде, чтобы прежде всего понять, как эти ошибки попали в код;
• ящики, полные документации, которые редко открываются, потому что люди в команде понимают, что сам факт написания плана и вопросы, которые возникают во время планирования, – это важнее, чем слепое следование этому плану.
Есть еще одна сторона общей картины. Дэн начал свою карьеру после революционного переворота 1990-х годов в области инструментов разработки ПО и технологий, поэтому он трудился только в командах, которые использовали объектно-ориентированную разработку для создания лучших образцов программного обеспечения. Системы контроля версий, автоматическое тестирование, лучшие интегрированные среды разработки (integrated development environments, IDEs), которые включают в себя функции для автоматизации программирования, такие как рефакторинг и проектирование классов, и другие революционные средства, помогали Дэну сохранить контроль над кодом. У Брюса опыт взаимодействия с проектами гораздо длительнее, чем у Дэна, он наблюдал разные команды разработчиков, которые часто использовали программные средства для автоматизации рутинных и повторяющихся задач.
Брюс и Дэн знают по опыту собственных проектов, что наиболее успешные люди эффективно используют такие методы, инструменты и идеи. Это позволяет им выделять больше времени на контакты с пользователями и партнерами, а также думать о проблемах, которые приходилось решать вместо того, чтобы трудиться над кодом.
И оказалось, что водопадные проекты эффективны в тех случаях, когда их команды принимают многие ценности, принципы и практики, которые характерны для agile-проектов. Проекты, которые выполняются с использованием отдельных гибких методов и практик (а это нельзя считать настоящим следованием ценностям и принципам Agile), в итоге нередко сталкиваются с теми же проблемами, которые преследуют водопадные проекты.
К сожалению, Брюс, Дэн и Джоанна сумеют убедиться в этом лишь на собственном горьком опыте.
Водопадный подход требует от команды полного описания программного обеспечения в начале проекта, а затем точного создания того, что было описано.
Водопадный подход затрудняет возможность реагировать на изменения из-за сосредоточения внимания на документах, а не на сотрудничестве.
Серебряной пули, или практики, которая помогает создавать безупречные проекты, не существует.
Команды, использующие водопадный подход, делают это путем принятия эффективных методов и принципов создания ПО, особенно таких, которые улучшают коммуникацию.
Agile для спасения! (Правильно?)
Вы, наверное, знаете, на что похож водопадный подход, даже если впервые столкнулись с термином «водопад»[8]. Джоанна, Брюс и Дэн тоже знают. Прежде чем приступить к планированию музыкального автомата, они говорили о том, каким образом водопадные процессы вызывали проблемы у их команд в прошлом.
Над последним проектом вместе с Брюсом и Дэном работал Том, менеджер по работе с клиентами. Он провел много времени в разъездах, помогая заказчикам в торговых галереях, казино, барах и ресторанах устанавливать и использовать разработанное для них ПО. Втроем они потратили несколько недель на создание спецификации для нового игрового автомата.
Том провел в офисе лишь половину из того времени, которое отвели ему Брюс и Дэн, чтобы начать проектирование программного обеспечения и планирование архитектуры. Как только все трое согласовали требования, они назначили встречу с CEO и топ-менеджерами компании, чтобы ознакомить их с требованиями, внести необходимые изменения и получить разрешение на начало разработки.
К этому моменту Том вернулся к работе с клиентами, переложив ответственность за проект на Брюса и Дэна. Они разбили проект на задачи, разделили их между членами команды, и все начали писать программное обеспечение. Когда команда практически закончила создание ПО, Том собрал группу бизнес-пользователей, менеджеров проектов и руководителей, чтобы продемонстрировать им почти готовую программу для слот-машины «Боец по выходным».
Но все прошло не так гладко, как ожидалось.
Во время демонстрации программы состоялся неприятный разговор с CEO[9]. Он сказал: «Программа выглядит замечательно, но разве не предполагалось, что она будет иметь режим видеопокера?» Это было неожиданное заявление. Судя по всему, директор был уверен, что они работают над программным обеспечением, которое может быть развернуто на базе либо игрового автомата, либо оборудования для видеоигры в покер. Состоялся напряженный разговор между топ-менеджерами, советом директоров и двумя крупными заказчиками. Жаль, что никто не потрудился передать команде детали разговора.
Конечно, если бы Дэн узнал об этом раньше, было бы легко изменить направление работы над проектом. Но теперь придется вырывать огромные куски из кода, который они уже написали, и заменять их на модернизированные части кода для видеопокера. Они потратили недели на устранение фатальных ошибок, вызванных проблемами интеграции. Дэн провел много бессонных ночей, объясняя Брюсу, что все это было абсолютно предсказуемо, потому что так бывает всегда, когда код создается для одних целей, а потом его спешно переориентируют. Теперь же ему предстоит увязнуть в распутывании спагетти-кода. Будет трудно поддерживать существующий базовый код, кроме того, команда разочарована, потому что это явно ошибочный путь.
Но в сложной ситуации оказались не только Дэн и Брюс. Менеджер проекта, руководивший им, был настолько расстроен случившимся, что покинул компанию. Он доверял тому, как команда характеризовала текущее состояние дел, но они были полностью обесценены изменениями. Команда понятия не имела, что им придется столкнуться с неожиданной сменой оборудования, и это не сделало жизнь руководителя проекта легче. Несмотря на то что ситуация изменилась, срок сдачи остался прежним. К моменту завершения проекта план устарел и стал бесполезен, однако менеджер проекта продолжал нести за него ответственность. После того как руководство раскритиковало его в пух и прах, он смог оправдаться лишь отсутствием в его команде хороших игроков. Затем он покинул компанию, и на его место взяли Джоанну.
Но сильнее всех был расстроен Том, потому что ему единственному пришлось работать с клиентами, когда они столкнулись с проблемами. Самый крупный клиент этого продукта – казино Little Rock в Лас-Вегасе – хотел настроить все свои игровые автоматы так, чтобы они соответствовали тематике игр, установленных в автоматах в городах штата Арканзас. Заказчик просил создать новую функцию, позволяющую менять игры между сменами, не перемещая игровые терминалы. Их инженеры то и дело натыкались на ошибки в программе, разработанной командой Брюса, поэтому Тому и Дэну приходилось неделями вести телефонные переговоры с инженерами, чтобы придумывать заплатки и временные решения. Little Rock не отменила контракта, но их следующий большой заказ перешел к конкуренту. Не секрет, что директора и менеджеры винят за потерю бизнеса проект Slot-o-matic Weekend Warrior.
В конце концов все узнали, что проект пошел не так. И каждый считал, что виноват кто-то другой. Казалось, никто понятия не имеет, как исправить эти повторяющиеся проблемы. И ПО, которое они поставляли, по-прежнему было недостаточно хорошо организованным.
Брюс, Дэн и Джоанна пригласили Тома на обед. После разговора о прошлых проблемных проектах Джоанна предположила, что настало время попробовать agile-методологии.
Как и многие начинающие свое движение к Agile, они приступили к делу с дискуссии о том, что значит для них само это слово. Брюс сослался на сферу agile-разработки: специализированные книги, практики, тренинги, блоги и людей, практикующих Agile. Для Джоанны понятие Agile означало «способность проекта изменяться», основной набор методов, сосредоточенных на достижении цели. Дэн думал, что в рамках Agile не надо писать документацию, а нужно просто погружаться в код. Том понятия не имел, о чем они говорят, но был счастлив узнать массу способов избежать того, что случилось в прошлый раз.
«Стартующие в Agile» обычно начинают знакомиться с гибкими методами, практиками и идеями, и эта команда не была исключением. Дэн присоединился к ресурсу Agile Alliance и начал налаживать связи с другими agile-практиками. Брюс и Джоанна принялись читать блоги и книги о гибкой разработке и управлении проектами. Они познакомились с замечательными идеями и взялись воплощать их в жизнь, чтобы таким путем прогнозировать и устранять проблемы в своих проектах. Каждый из них обнаружил много полезного и сразу же начал пополнять этим свой арсенал.
Дэн уже писал автоматизированные модульные тесты для своих предыдущих проектов, но многие разработчики музыкальных автоматов никогда не делали этого. Он начал сотрудничать с разработчиками, чтобы организовать модульное тестирование и разработку через тестирование. Создал автоматизированный сборочный скрипт и настроил сервер сборки для проверки кода, создания программного обеспечения и проведения тестирования раз в час. И это сработало! Программисты сразу же увидели улучшение в их коде. Каждый день разработчик находил ошибку, которую никогда не выявил бы без автоматических тестов, и было ясно, что удалось избежать недельных отладок и отслеживания неприятных проблем в этой области. Мало того что стало меньше ошибок, облегчилась и процедура изменения кода, который пишут разработчики.