Agile больше, чем просто небольшие водопады?

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

Правильно ли мое понимание или есть что-то большее? Каковы гибкие философии?

На простом уровне, да. Простое выполнение Водопада каждые две недели не делает вас гибким , но это итеративно (что составляет половину гибкого).

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

Тем не менее, существует гораздо больше гибкости, чем просто итеративный и постепенный. Арендаторы Agile включены в Манифест разработки Agile Software . В Манифесте изложены четыре ключевых момента:

Индивидуумы и взаимодействия над процессами и инструментами

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

Рабочее программное обеспечение над всеобъемлющей документацией

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

Сотрудничество с клиентом в рамках переговоров по контракту

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

Реагирование на изменения в соответствии с планом

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

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

Да и нет - фактический процесс можно рассматривать как серию небольших водопадов, но разница в том, что процесс развивается и совершенствуется благодаря вкладу всей команды (dev, qa, business etc) в ретроспективах, которые должны привести гораздо более узкому подразделению, способному реагировать на проблемы, точно планировать и доставлять. Я сильно упрощаю это здесь, это намного больше, но я не думаю, что это плохая отправная точка.

Я бы сказал, что это упрощенный способ выразить это. Да, когда вы приступаете к этому, это небольшие потоки воды, но за этим стоит гораздо больше, что заставляет его работать. Целая методология, которая меняет подход к проектам ... Не говоря уже о мышлении, необходимом для этого.

Если вы серьезно относитесь к Agile, вот хорошая (и длинная) серия веб-трансляций, которые могут вас заинтересовать:

http://autumnofagile.net/

Забудьте Agile на минуту, подумайте, что означает «водопад».

Существует фаза требований, на которой каждый пытается выяснить, какие проблемы должен решить конечный продукт. Люди спорят об этом какое-то время, а потом все соглашаются на ряд требований. На этом этапе ваша сфера действия определена, контракты подписаны, и клиент может уйти и ждать, пока вы не найдете продукт, который отвечает этим определенным требованиям.

Далее идет один (или, может быть, два) этап (ы) проектирования. Проектировщики (которые могут быть, а могут и не быть разработчиками) спорят о том, КАК система должна идти вместе, чтобы соответствовать требованиям, подписанным. Могут возникнуть проблемы, если они не совсем понимают требование, что может означать, что они должны вернуться к клиенту, потенциально повторно открыть фазу требований (и получить еще один раунд согласований) или, по крайней мере, привести в действие управление изменениями. , Часто дизайнеры просто делают свои лучшие предположения. Они могут придумать логическую модель данных и множество UML, описывающих новую систему и то, как она должна работать. Тогда они подписывают это.

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

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

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

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

Agile методологии сосредоточены на прочном общении и сотрудничестве между всеми заинтересованными сторонами. Принцип «Сотрудничество с клиентом вместо переговоров по контракту» означает, что вам не нужно проходить серию подписей и отказов, а вместо этого просто работать вместе с заказчиком, каждая итерация определяет требования для части головоломки. и немедленное формирование тестов, дизайна и рабочего кода - со всеми игроками, связывающимися как можно более непосредственно (исключая затраты на перенос и риски). Рабочий код быстро тестируется заказчиком, что исключает риск временной задержки. Все действия происходят в совместном вихре, а не в нисходящем потоке.

Для отличного обзора того, что пытаются делать гибкие методологии, я настоятельно рекомендую «Гибкую разработку программного обеспечения: совместная игра» Эллиста Кокберна .

Да, это более или менее правильно. О том, как это сделать, было много написано и обсуждено, но суть кучки маленьких водопадов.

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

Это правильно или есть что-то большее?

И то и другое. Да, это точное суммирование концепции, но здесь суммируется много деталей. Я имею в виду, что почти все аспекты планирования меняются, когда вы планируете просто на следующую неделю, а не на следующий год.

Если вы посмотрите на статическую структуру (определение процесса) гибкого проекта, то да, это похоже на множество небольших водопадов. Но цель гибкого проекта - получить более быструю и качественную обратную связь .

• Вы выполняете тестовую разработку, чтобы сразу узнать, работает ли ваше программное обеспечение
• Клиент находится на месте и проводит приемочные испытания, чтобы узнать, когда вы закончите
• У вас есть ретроспектива, чтобы настроить ваш процесс на основе того, что прошло хорошо, а что нет.

В Agile Manifesto подчеркивает некоторые различия между гибким и водопадом (воспринятыми тех , кто подписал).

Действительно «проворный» часто означает водопады 1-2 дня, а не недели. Это не означает, что вы не следуете общему плану, и что реальные циклы выпуска составляют 1-2 дня. Но вы должны стараться иметь работающий, проверенный продукт каждый день, и вы можете выпускать его - теоретически - каждый день.

Скрам, например, использует спринты 4 недели, но спринт - это не просто один водопад (по крайней мере, так не должно быть). Вы можете менять приоритеты каждый день, когда видите, что что-то идет не так, как планировалось в начале спринта.