Какой тип жизненного цикла подходит вашему проекту?

При выборе типа жизненного цикла разработки не стоит верить вашим чувствам. Сделайте решение на основе действительно важных факторов.

Какой тип жизненного цикла будет наиболее эффективным для вашего проекта? Это очень важный стратегический вопрос, потому что неверный выбор может привести к катастрофическим результатам. Подумайте только о запоздалых результатах, недовольных клиентах, перерасходах и отмененных проектах!

В 80-х и ранних 90-х стандартом считалась водопадная модель. Наряду с быстрыми темпами разработки программного обеспечения и ростом популярности интернета, многие компании начали переходить к более гибким жизненным циклам, таким как итеративная, пошаговая, спиральная и гибкая модель. Эти новые методы предоставляют гибкость и поддерживают быструю разработку, предоставляя компаниям возможность быть первыми на рынке. На сегодняшний день существуют десятки моделей жизненного цикла, каждая  из которых имеет свои преимущества и недостатки.

Водопадная модель

Данная модель является традиционным методом и используется уже не первый десяток лет, доказав при этом свои преимущества в способности предоставления своевременных результатов. Более того, согласно публикации 1998 года (Standard 2167A), Министерство обороны США активно поддерживало использование данного метода во всех своих проектах.

Водопадная модель - это последовательный метод разработки с четко определенными выходными продуктами на каждом этапе. Многие специалисты в исследуемой  области до сих пор строго выполняют анализы ревизий для того, чтобы обеспечить наличие удовлетворительных входных критериев для перехода к следующему этапу.

Стандартные этапы водопадной разработки выглядят следующим образом:

 

Итеративная, пошаговая модель

Основной целью итеративной разработки является пошаговое создание системы, начиная с базовых функций системы и с постепенного добавления всех остальных до того, как вся система будет готова. В сравнении с водопадной, итеративная разработка придает большую гибкость в применении новых требований или изменений. Она также предоставляет возможность улучшений в последующих итерациях, основываясь на уроках, полученных в результате предыдущих этапов.

Следующая диаграмма четко отображает итерации данного метода:

При таком подходе проект в каждой фазе своего развития проходит повторяющийся цикл:

Планирование — Реализация — Проверка — Оценка

Гибкая модель (Agile)

Гибкая методология возникла из-за нужды в таком процессе разработки приложений, который смог бы приспособиться к быстро развивающейся эволюции интернета. Гибкая модель в какой-то степени является вариантом итеративного метода разработки, где выходные результаты предоставляются на каждом этапе. Главным отличием является то, что срок предоставления выходных результатов в случае с гибкой моделью сокращается с месяцев до недель. Компании, практикующие данный метод, предоставляют программное обеспечение и модернизации в течение недель. Более того, манифест гибкой разработки включает в себя такие принципы, как сотрудничество, документация и др.

Следующая диаграмма согласно методологии разработки программного обеспечения от Microsoft демонстрирует различные компоненты жизненного цикла гибкой модели:

Другие варианты

Существуют и другие модели и методологии, такие как разработка на основе тестирования (Test Driven Development), рациональный унифицированный процесс разработки (RUP), методология «чистой комнаты» (Cleanroom) и др.  
Тем не менее, все эти модели также могут быть отнесены к водопадной модели, поскольку они являются последовательными, обладая при этом четкой границей между этапами, так же, как и этапы гибкой и итеративной моделей, периодически повторяются, при этом граница между этапами не так ясно выражена.

Далее я приведу несколько вопросов, ответы на которые помогут вам в выборе типа жизненного цикла:

Насколько стабильны требования?

Одним из основных факторов при выборе метода является четкость и стабильность требований к проекту. Частые изменения в требованиях после старта проекта могут помешать продвижению проекта в соответствии с планом. В таком случае вам стоит выбрать гибкую либо итеративную модель, потому что каждая из них предоставляет возможность приспособить новые требования даже после того, как проект был запущен. С другой стороны, если вы уже используете более традиционную модель разработки, при которой существует правило наличия четкого набора требований перед переходом к следующему этапу, то вам стоит выбрать водопадную модель. Тем не менее, такие традиционные проекты встречаются все реже, так как компании  осознают все преимущества использования гибких методов в управлении проектами.

Кто же является конечным пользователем системы?

Уделите немного времени тому, чтобы ознакомиться с пользователями и заинтересованными сторонами. Кто они? Эта группа сосредоточена или разбросана по разным местам? Как они могут повлиять на проект? Контролируемая группа пользователей, которая имеет значительное влияние на проект, может помочь вам в определении требований и управлении изменениями. Это означает, что вы сможете достичь стабильности относительно требований проекта и использовать водопадную модель.

С другой стороны, если пользователи рассредоточены, то у вас будет целый набор требований, которые вы не сможете определить, пока пользователи не будут использовать систему и требовать новых функций. Такая ситуация является типичной при разработке ПО. К примеру, Google начал использование Gmail и всех продуктов, таких как Google Docs, Calendar в качестве BETA-версии, поскольку необходимо было узнать реакцию пользователей и улучшить функциональность, основываясь на полученных отзывах. Microsoft - разработчик самого известного ПО в мире, Windows и Office - также применяет гибкие методы в своих разработках. В последнее время методология разработки программного обеспечения от Microsoft (MSF - Microsoft Solution Framework) стала включать в себя гибкий подход. Что касается гибкой модели, то, согласно данной методологии, «маленькие итерации позволяют снизить уровень ошибок в предположениях и представить быстрый отчет о точности ваших планов. Каждая итерация должна в результате предоставлять стабильную часть всей системы". Microsoft и Google выбрали гибкость в разработке, потому что их клиенты представлены в виде очень распределенной группы пользователей.

Временные рамки проекта агрессивны или консервативны?

Опытные руководители решают проблемы агрессивных сроков путем ведения переговоров и снижения частоты выходных результатов. Итеративный подход поможет достичь этого путем предоставления возможности разработки частичной функциональности на раннем этапе. Это создаст впечатление того, что проект будет выполнен, несмотря на агрессивные сроки, также известные как "быстрые шаги". В то время как временные рамки всего проекта не были сокращены, существует возможность того, что вы удовлетворите заинтересованные стороны, предложив необходимые ключевые функции. Если ваш проект не слишком зависит от сроков, и пользователи смогут подождать до выпуска полноценной системы, то водопадная модель будет лучшим подходом в данной ситуации.

Каков размер проекта?

Большие проекты зачастую требуют большое количество рабочих групп для работы над четко определёнными комплектующими. Масштаб выходных результатов пропорционален размеру команды проекта, выполняющей данную работу. Поэтому большим командам назначается больший набор комплектующих, которые должны быть четко определены. В таком случае длинные итерации или водопадная модель будут более пригодны.

Где расположены команды проекта?

Если у вас есть несколько команд в проекте, и они расположены в различных местах, то координация их работы должна быть более детальной и строгой. Задачи должны быть четко определены для того, чтобы избежать непонимания и излишней работы. В таких случаях водопадная модель будет наиболее благоприятной, поскольку она предполагает контрольные точки и предоставление четких результатов в конце этапов. Применение гибкой методологии в случае с таким разбросом команд предполагает возможность появления новых препятствий. Поскольку гибкая разработка лучше всего применима в случаях с тесными контактами и открытой культурой, исполнители, работающие удаленно, испытают больше трудностей, чем те, которые используют подход, основанный на планировании.

Какие ресурсы являются критическими?

Некоторые проекты требуют включения уникального, высококвалифицированного ресурса либо интеграции специализированного оборудования. В таких случаях данные ресурсы не всегда сразу же доступны и требуют составления плана, а команда проекта должна обеспечить то, что ресурс будет полностью использован согласно предусмотренному графику. Более того, должны быть выполнены тесты по всем возможным сценариям, пока ресурс доступен. В противном случае требование повторного использования ресурса может повлечь задержки проекта. В таких случаях водопадная модель будет наилучшим выбором, поскольку каждая контрольная точка должна быть выполнена до перехода от одного этапа к другому, и вы будете уверены в том, что критический ресурс будет правильно использован.