Управление программой по методике agile

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

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

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

Эта задача не из простых, но никто не говорит, что это невозможно. 

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

Для начала ответим на основной вопрос: в чем отличие agile?

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

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

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

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

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

Итерации не только избавляют от критических путей, но и позволяют получать обратную связь по продукту в процессе разработки.

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

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

Создание отличной agile-программы

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

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

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

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

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

Требования

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

Бэклог

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

Механизмы agile-поставки

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

Метрики agile

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

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

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

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

Up Next
Workflow