Управление проектами на основе принципов Agile

Некоторым может показаться, что при переходе к методам agile из поля зрения теряется общая картина. Мы в корне с этим не согласны.

Dan Radigan Dan Radigan
Просмотр тем

Под редакцией руководителя программы Лорели Маллек

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

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

Что такое управление проектами по методике agile?

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

Сравнение каскадной модели и agile

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

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

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

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

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

Пример релиза в каскадной модели | Atlassian — тренер по agile

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

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

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

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

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

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

Пример управления проектом по методике agile | Atlassian — тренер по agile

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

Принципы Agile

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

Факторы, которые необходимо учитывать при переходе на модель Agile

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

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

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

План действий

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

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

Дорожная карта в agile | Atlassian — тренер по agile

Требования

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

Бэклог

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

Метрики agile

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

Agile строится на доверии

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

Заключение

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

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

продолжение темы
Workflow