Введение в управление проектами: сравнение методологии Agile и каскадной модели

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

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

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

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

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

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

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

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

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

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

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

• Требует меньшей координации благодаря последовательным процессам с четко определенными этапами.

• Понятные этапы проекта позволяют четко определить зависимости между работами.

• Стоимость проекта можно оценить после определения требований.

• Больше внимания уделяется документированию проекта и требований.

• Этап проектирования, предшествующий написанию любого ПО, выполняется более методично и лучше структурирован.

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

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

• Риск потери времени из-за задержек и препятствий при переходе на следующий этап.

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

• Дополнительные накладные расходы на коммуникацию во время передачи работы на следующий этап.

• Владение продуктом и вовлеченность могут быть не такими сильными, как при использовании методики 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-подход дает возможность реагировать на изменения, не сходя с намеченного пути. Кроме того, он отлично подходит для любой программы. 

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