Страница 7 из 12
(По иронии судьбы одна из самых цитируемых работ в области программной инженерии – это эссе Фреда Брукса No Silver Bullet («Серебряной пули не существует», 1986). В нем он убедительно доказывает, что эта задача невыполнима. Что еще нужно, чтобы остановить бесплодные попытки найти загадочную панацею?)
Предлагалось большое количество радикальных способов, претендующих на звание «серебряной пули». Они, как правило, были двух видов: методология, дающая командам надежный способ создания программного обеспечения, или технология, которую программисты могли использовать для предотвращения или устранения ошибок. Идея состояла в том, что если компания приняла решение о выборе методологии и технологии, то вся команда должна была следовать им неукоснительно, поскольку только в этом случае можно создавать отличное ПО.
Дэн и Брюс не понаслышке знают, что все это иллюзии, потому что на протяжении многих лет управляли проектами, хватаясь за разные методики и технологии, не получая при этом каких-либо реальных улучшений. Попытки компании найти серебряную пулю для процесса программной разработки, как правило, заканчивались печально для всех участников. Но хуже всех приходилось Брюсу и Дэну, потому что им насильно предлагалось следовать за вечно меняющимися процессами.
Джоанна тоже сталкивалась с этим. На предыдущей работе она регулярно выдвигала множество жестких требований и давала массу распоряжений, чтобы придумать план разработки программного обеспечения. Команды приступали к буквальному выполнению ее плана. Однако они были обречены на создание негодного и бесполезного ПО. Пользователь получал устаревший продукт, не успев им воспользоваться.
Правда, некоторым командам, с которыми работала Джоанна, удавалось выпускать отличное программное обеспечение на основе водопадного процесса (или подобного ему) со сложной в разработке предварительной документацией. Она руководила рядом лучших проектов разработки ПО для медицинских устройств, в которых применялся водопадный подход.
Водопад действительно бывает полезен. Если вы хорошо знаете, что необходимо вам прежде всего, и первым делом создаете именно это, то получаете довольно эффективный способ создания ПО. Проекты создания программного обеспечения для медицинских устройств, которыми руководила Джоанна, – это тот редкий случай, когда требования к программе действительно писались в самом начале работы и в ходе проекта практически не было изменений.
Но для запуска успешного водопадного проекта требуется нечто большее, чем просто стандартные требования, отсутствие которых создает так много проблем. Команды, разрабатывающие прекрасное ПО при помощи водопадного подхода, как правило, имеют несколько общих характеристик. Это:
• хорошая коммуникация, потому что успешные команды, уполномоченные компанией вести водопадную разработку, постоянно поддерживают контакт со своими пользователями, менеджерами и руководителями на протяжении всего проекта;
• хорошие методики, особенно такие как анализ кода и автоматизированное тестирование, которые направлены на поиск ошибок на раннем этапе. Обычно это называется «предотвращение дефектов» и необходимо команде, чтобы прежде всего понять, как эти ошибки попали в код;
• ящики, полные документации, которые редко открываются, потому что люди в команде понимают, что сам факт написания плана и вопросы, которые возникают во время планирования, – это важнее, чем слепое следование этому плану.
Есть еще одна сторона общей картины. Дэн начал свою карьеру после революционного переворота 1990-х годов в области инструментов разработки ПО и технологий, поэтому он трудился только в командах, которые использовали объектно-ориентированную разработку для создания лучших образцов программного обеспечения. Системы контроля версий, автоматическое тестирование, лучшие интегрированные среды разработки (integrated development environments, IDEs), которые включают в себя функции для автоматизации программирования, такие как рефакторинг и проектирование классов, и другие революционные средства, помогали Дэну сохранить контроль над кодом. У Брюса опыт взаимодействия с проектами гораздо длительнее, чем у Дэна, он наблюдал разные команды разработчиков, которые часто использовали программные средства для автоматизации рутинных и повторяющихся задач.
Брюс и Дэн знают по опыту собственных проектов, что наиболее успешные люди эффективно используют такие методы, инструменты и идеи. Это позволяет им выделять больше времени на контакты с пользователями и партнерами, а также думать о проблемах, которые приходилось решать вместо того, чтобы трудиться над кодом.
И оказалось, что водопадные проекты эффективны в тех случаях, когда их команды принимают многие ценности, принципы и практики, которые характерны для agile-проектов. Проекты, которые выполняются с использованием отдельных гибких методов и практик (а это нельзя считать настоящим следованием ценностям и принципам Agile), в итоге нередко сталкиваются с теми же проблемами, которые преследуют водопадные проекты.
К сожалению, Брюс, Дэн и Джоанна сумеют убедиться в этом лишь на собственном горьком опыте.
Водопадный подход требует от команды полного описания программного обеспечения в начале проекта, а затем точного создания того, что было описано.
Водопадный подход затрудняет возможность реагировать на изменения из-за сосредоточения внимания на документах, а не на сотрудничестве.
Серебряной пули, или практики, которая помогает создавать безупречные проекты, не существует.
Команды, использующие водопадный подход, делают это путем принятия эффективных методов и принципов создания ПО, особенно таких, которые улучшают коммуникацию.
Agile для спасения! (Правильно?)
Вы, наверное, знаете, на что похож водопадный подход, даже если впервые столкнулись с термином «водопад»[8]. Джоанна, Брюс и Дэн тоже знают. Прежде чем приступить к планированию музыкального автомата, они говорили о том, каким образом водопадные процессы вызывали проблемы у их команд в прошлом.
Над последним проектом вместе с Брюсом и Дэном работал Том, менеджер по работе с клиентами. Он провел много времени в разъездах, помогая заказчикам в торговых галереях, казино, барах и ресторанах устанавливать и использовать разработанное для них ПО. Втроем они потратили несколько недель на создание спецификации для нового игрового автомата.
Том провел в офисе лишь половину из того времени, которое отвели ему Брюс и Дэн, чтобы начать проектирование программного обеспечения и планирование архитектуры. Как только все трое согласовали требования, они назначили встречу с CEO и топ-менеджерами компании, чтобы ознакомить их с требованиями, внести необходимые изменения и получить разрешение на начало разработки.
К этому моменту Том вернулся к работе с клиентами, переложив ответственность за проект на Брюса и Дэна. Они разбили проект на задачи, разделили их между членами команды, и все начали писать программное обеспечение. Когда команда практически закончила создание ПО, Том собрал группу бизнес-пользователей, менеджеров проектов и руководителей, чтобы продемонстрировать им почти готовую программу для слот-машины «Боец по выходным».
Но все прошло не так гладко, как ожидалось.
Во время демонстрации программы состоялся неприятный разговор с CEO[9]. Он сказал: «Программа выглядит замечательно, но разве не предполагалось, что она будет иметь режим видеопокера?» Это было неожиданное заявление. Судя по всему, директор был уверен, что они работают над программным обеспечением, которое может быть развернуто на базе либо игрового автомата, либо оборудования для видеоигры в покер. Состоялся напряженный разговор между топ-менеджерами, советом директоров и двумя крупными заказчиками. Жаль, что никто не потрудился передать команде детали разговора.
8
Если вы менеджер проекта и готовились к экзамену PMP, то уже все знаете о водопадном подходе. Сертификация PMP охватывает не только программное обеспечение, но и множество методологий в различных отраслях промышленности. Хорошо иметь полный набор чертежей при строительстве небоскреба или моста, даже если эти документы меняются.
9
Chief Executive Officer – главное должностное лицо компании, аналог генерального директора в российской иерархии. Прим. ред.