Сравнение управления проектами по методике agile и с использованием каскадной модели

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

Популярность agile для управления проектами привела к тому, что многие организации стали расширять область применения этой методики, перенося ее с отдельных команд и проектов на целые программы. Методика agile распространилась за пределы команд разработки ПО и теперь используется в командах ИТ, маркетинга, коммерческого развития и других.

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

Современные клиенты и бизнес требуют быстрого реагирования и внесения изменений. Методика agile дает необходимую гибкость для корректировки и выполнения итераций в процессе разработки. Управление проектами по методике agile является также краеугольным камнем концепции DevOps, которая подразумевает совместную работу команд разработки и эксплуатации.

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

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

A single missed deadline or scope change during a waterfall project can cause outsized impacts on subsequent releases. Additionally, when a team is fully focused on the next phase of work, resolving technical debt or fixing bugs can be painful if the team is fully allocated to new feature work and always pressing forward to the next stage.

Ниже представлена иллюстрация типичного каскадного проекта с жесткими временными интервалами. Такая модель формирует настрой в духе «сейчас или никогда», побуждающий разработчиков, владельцев продукта и заинтересованные стороны запрашивать от коллег как можно больше времени в каждый временной интервал. Это объясняется тем, что в будущем может не быть возможности вернуться к предыдущим итерациям. Команды, использующие каскадную модель, обычно стараются контролировать область работ в проекте методом «контроля изменений». При этом все участники соглашаются с тем, что изначальные требования должны оставаться неизменными в соответствии с договором.

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

• Управление блокерами и зависимостями. При управлении проектом в традиционном стиле часто опираются на понятие «критического пути». Его суть в том, что работу над проектом нельзя продолжать, пока не будет устранена проблема-блокер.
• Сложность проверки пригодности продукта и сбора обратной связи от пользователей. Конечный пользователь сможет «потрогать» продукт, только когда он будет полностью завершен, поэтому все серьезные проблемы в исполнении продукта и коде становятся явными только после релиза.

Преимущества каскадной модели

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

Недостатки каскадной модели

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

Первыми методику agile внедрили команды разработчиков ПО, перешедшие от традиционного последовательного (каскадного) подхода к такому методу, который предполагал непрерывное получение обратной связи и корректировку процесса на протяжении всего жизненного цикла разработки.

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

Итеративный подход к выпуску релизов открывает множество возможностей для команды.

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

Agile-подход позволяет командам уверенно встречать изменения, которые неизбежно возникают во время работы над проектом.

Более значимое преимущество заключается в том, что участники команды разработчиков обладают общим набором навыков. Как следствие, работа становится более открытой к изменениям во всех частях базы кода команды. Так усилия и время не окажутся потраченными впустую, если изменится направление проекта. (Подробнее об этом читайте в нашей статье о создании успешной Agile-команды.)

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

Преимущества управления проектами по методике agile

• Более быстрые циклы обратной связи.
• Выявление проблем на ранней стадии.
• Больше возможностей повысить удовлетворенность клиентов.
• Значительное ускорение выхода на рынок.
• Повышение прозрачности и подотчетности.
• Повышение производительности выделенных команд с течением времени.
• Гибкая расстановка приоритетов, ориентированная на поставку ценности.

Недостатки методики agile

• Критический путь и зависимости между проектами могут быть определены не так четко, как в каскадной модели.
• Организации требуется время на освоение.
• Полноценное внедрение методики agile с конвейером непрерывного развертывания требует затрат и определения множества технических зависимостей.

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

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

Давайте посмотрим, за счет каких механизмов в agile-программах работа упорядочивается, движется и структурируется в виде итераций.

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

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

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

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

Показатели в Agile определяют успех команд. Ограничения незавершенной работы (WIP) позволяют команде (и компании в целом) сосредоточить основные усилия на более важной работе. С учетом диаграмм Burndown и контрольных диаграмм команда может прогнозировать график поставки, а с помощью диаграмм непрерывного процесса — выявлять проблемные места. Эти показатели и артефакты поддерживают общую сосредоточенность на больших целях и формируют уверенность в том, что команды способны выполнить намеченную работу.

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

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

Learn more about agile project management and check out our free jira project management template. Plus, dive into agile adoption with agile tools for software teams, and learn how to communicate the progress of work across teams.