Как можно использовать метод водопада и метод Agile в одном проекте?
Это невозможно.
Все гибкие методологии должны быть итеративными. В противном случае они не будут соответствовать первому и третьему принципам манифеста :
Нашим наивысшим приоритетом является удовлетворение потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.
...
Доставляйте работающее программное обеспечение часто, от пары недель до пары месяцев, отдавая предпочтение более коротким временным рамкам.
Водопад по определению не является итеративным подходом :
Водопадная модель представляет собой линейный последовательный (неитеративный) подход к проектированию программного обеспечения, при котором прогресс течет в одном направлении вниз (как водопад) через этапы концепции, инициации, анализа, проектирования, построения, тестирования, развертывания и обслуживания. .
Таким образом, вы не можете использовать итеративный и неитеративный подходы одновременно.
Обновление: есть несколько методологий, которые не являются ни классическими водопадными, ни гибкими (например, модель RUP или Spiral). Они могут взять что-то из обоих подходов, но они не являются ни тем, ни другим.
Для таких вещей есть термин Wagile :
Разработка программного обеспечения Wagile — это группа методологий разработки программного обеспечения, которые являются результатом перехода от Agile обратно к водопаду, выполнения множества коротких водопадов и размышления о гибкости, модели Waterfall, маскирующейся под Agile-разработку программного обеспечения и т. д.
И это так плохо, как кажется...
Нашел хорошую статью о таком процессе...
Сергей Кудрявцев прав, это невозможно.
Фундаментальный принцип waterfallзаключается в том, что работа по управлению продуктом выполняется заранее: исследуется рынок, создается концепция, опрашиваются клиенты, разрабатывается весь продукт, а затем всесторонний и исчерпывающий PRD передается в отдел разработки, который затем разрабатывает продукт. , тестирует его, а затем развертывает. Весь прогресс течет в одном направлении, и PRD представляет собой директиву от продукта к разработке.
С agile, Product по-прежнему будет исследовать рынок, создавать концепцию и опрашивать клиентов, но весь продукт не будет определен до начала разработки. PRD или несколько PRD будут переданы инженерам, но это будут живые документы меньшего размера. Инженеры ответят своими отзывами и проблемами, и PRD будет соответствующим образом обновлен. То же самое происходит, когда от клиентов поступают отзывы и опасения. Процесс является итеративным, и эти документы представляют собой понимание клиента, разделяемое между Продуктом и Техническим отделом.
С другой стороны, agile антишаблоны — это почти определение waterfallтребований:
Антишаблоны, на которые стоит обратить внимание
- Весь проект уже подробно описан до начала каких-либо инженерных работ.
- Перед началом работы требуется тщательная проверка и твердое одобрение от всех команд.
- Дизайнеры и разработчики не знают, когда требования были обновлены
- Требования никогда не обновляются в первую очередь (потому что все подписались под ними, помните?)
- Владелец продукта пишет требования без участия команды
Проблема будет ощущаться особенно остро, когда одна часть организации внедряет agile, а другая waterfall. Если Product использует agileи Engineering waterfall, то Product будет задаваться вопросом, почему все так долго, а Engineering будет жаловаться на то, что PRD «недоделаны». Если наоборот, инженеры будут задаваться вопросом, над чем они должны работать, а продукт будет жаловаться, что инженерам нужно подождать. Возникнет чувство обиды.
Обновление : Стив Бланк только что опубликовал некоторые мысли на эту тему в AgileFall — Когда водопад возвращается в Agile :
AgileFall — это ироничный термин для управления программами, когда вы пытаетесь быть гибким и экономичным, но продолжаете использовать каскадные методы разработки. Это часто дает результат, похожий на сочетание воска для пола и десертной начинки.
Далее он описывает, как можно изменить процесс, чтобы вернуться в нужное русло.
Водопад основан на предпосылке, что раннее обнаружение ошибок — до того, как будут вложены значительные средства — дешевле, чем позднее обнаружение ошибок. Таким образом, вы планируете заранее, чтобы избежать неожиданностей позже.
Agile основан на предпосылке, что вышеизложенное является хорошим шагом к предотвращению ошибок, но не защитит вас от изменений и осложнений. Таким образом, итеративная работа в меньшем масштабе дает то же самое, что и водопад, и даже больше.
Вы можете попытаться аргументировать что-то вроде «Scrum на самом деле просто итеративный, перекрывающийся водопад» или «Agile просто выступает за выполнение гораздо более коротких каскадных подпроектов один за другим», и в зависимости от того, кто спросит и чего они хотят, вы можете добиться успеха.
Вы можете включить несколько agile-принципов, таких как тесное сотрудничество, расстановка приоритетов, вовлечение клиентов, непрерывное тестирование, такие ценности, как открытость, смелость и уважение, в каскадный проект и считать эту миссию выполненной.
Проблема в том, что и водопад, и agile имеют определенные ожидания. Как правило, это скорее противоречащие друг другу ожидания, чем практики, отстаиваемые «моделями». И, как правило, именно ожидания, связанные с водопадом, делают водопад проблематичным. Как и ожидание того, что диаграмма Ганта-водопад обладает пророческими качествами. Или ожидание, что, поскольку вы добавили некоторое буферное время в конце, вы можете легко втиснуть еще несколько функций или «разъяснений» функций. Где Agile неукоснительно противостоит этим...
Вы можете делать успешные проекты как с водопадом, так и с agile. Попытка запихнуть и то и другое в один и тот же проект обычно является признаком того, что не все в вашей группе понимают суть agile. И вы пытаетесь решить проблемы, от которых люди пока не хотят избавляться.
Натан Купер