Из каких шагов состоит гибкий цикл разработки Agile

По какой-то причине Agile (Аджайл) многие разработчики воспринимают как самостоятельную методологию (фреймворк) работы над проектами. В реальности Agile – это скорее философия, общий подход, который объединяет целую группу гибких методологий (Scrum, Lean, Kanban и т.п.).

Вообще, методологии могут быть и не гибкими. Например, Waterfall. Лучшие практики для управления проектами можно посмотреть в нашем списке Топ-10.

Ниже остановимся на отдельном вопросе – из каких шагов будет состоять цикл разработки проекта по Agile-методикам.

О принципах Agile

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

Официальную версию принципов на русском языке можно увидеть на сайте agilemanifesto.org.

Высший приоритет отдаётся потребностям заказчика.
Требования к проекту могут меняться на любом этапе, даже на поздних стадиях разработки.
Цикл выпусков проекта должен быть частым (от 2 недель до 2 месяцев).
Представитель бизнеса (заказчика) должен работать в команде.
Над проектом должны работать только мотивированные профессионалы.
Лучший способ обмена информацией в команде – непосредственное общение.
Главный показатель прогресса – работающий проект (продукт).
Ритм разработки может быть бесконечным, и заказчики/пользователи должны иметь возможность поддерживать такой ритм.
Постоянное внимание к техническому совершенству.
Для минимизации расходов и работ все участники проекта должны стремиться к простоте.
Команды должны быть самоорганизующимися (для достижения лучших архитектурных решений).
Работу нужно постоянно анализировать и оптимизировать.

Ключевые идеи манифеста Agile:

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

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

Многие из этих принципов могут трактоваться по-разному, с разными техническими деталями и особенностями. Наверное, поэтому так много Agile-методик и фреймворков.

Методологии Agile (гибкие методологии управления проектами)

Рассмотрим привязку к циклам в наиболее востребованных Agile-методиках.

Канбан и циклы разработки проектов

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

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

Технические особенности, относящиеся к циклам разработки:

Итерации в канбан необязательны.
Темпы планирования и циклы могут устанавливаться исходя из стоящих задач и других обстоятельств.
Жесткой привязки к циклам релизов или к фиксированным циклам разработки здесь нет.
При этом время минимального цикла (итераций разработки) – это базовая метрика, позволяющая оценить общие затраты времени на проект.
Ключевые показатели (KPI) и вообще какие-либо оценки необязательны.
Нет чётких требований к приоритетам в разработке.
Новые требования могут быть выдвинуты заказчиком в любой момент.
На доску канбан можно занести сразу все задачи (бэклог) и отслеживать их состояния на протяжении всей жизни продукта.
Какие-либо правила к объёму или сложности задач отсутствуют.

Несмотря на отсутствие явных требований к цикличности совещаний и других внутренних мероприятий, у многих канбан-команд вырабатываются свои частные практики:

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

Scrum и циклы разработки

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

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

Бэклог проекта может быть общим (список пожеланий/задач клиента) и только для одного спринта.

Что касается технических нюансов циклов разработки по Scrum:

Итерации всегда стандартной (одинаковой) продолжительности. Продолжительность устанавливается при запуске проекта по согласованию с клиентом и всеми участниками команды.
Обязательно используются метрики (KPI или аналоги), которые позволяют оценить прогресс проекта.
У каждого спринта есть конкретная цель и задачи. Изменить их до конца «забега» нельзя, только на новой итерации (на новом спринте).
Требования к задачам таковы, что объём работ обязательно должен укладываться во временные рамки одного спринта.
Строго определяются роли участников команды (скрам-мастер, владелец продукта и остальные члены команды).
Бэклоги спринтов действуют только для каждого отдельно «забега». После окончания спринта его лог удаляется. Сквозным можно назвать только общий бэклог проекта.
У каждого элемента бэклога обязательно должен быть проставлен приоритет.

Теперь поговорим о шагах разработки.

Гибкие (agile) циклы и шаги разработки

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

В SCRUM порядок событий строго определен. Они должны происходить в следующей последовательности (в рамках одного спринта):

Планирование спринта (Sprint Planning).
Daily Scrum – ежедневная 15-минутная встреча перед началом работы над задачами из бэклога спринта.
Спринт ревью (Sprint Review) – предпоследнее событие спринта, нужно для инспекции результата.
Ретроспектива спринта (Sprint Retrospective) – событие анализа, последнее событие «забега».

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

Тем не менее, никто не мешает вам совместить модель последовательной разработки с любым agile-подходом.

Как это может выглядеть.

Так как любой программный продукт или проект имеет свой жизненный цикл, вы можете задействовать принципы последовательной/каскадной модели разработки (Waterfall): сбор и систематизация требований к продукту, аналитика, проектирование архитектуры (дизайн), реализация кода, тестирование, внедрение.
Чтобы не распалять силы на всех направлениях и на реализации всех задач, логично начать с минимально жизнеспособного продукта (MVP). То есть список функций и задач должен включать только те пункты, без которых работа продукта просто невозможна.
Когда MVP реализована, и вам есть что передать заказчику для внедрения, можно перейти на Agile-методики. Например, на Scrum.
Далее составляется общий бэклог задач к реализации, и на каждый новый спринт выносятся наиболее приоритетные фичи.
Представитель заказчика активно участвует в событиях и перед каждой новой итерацией может актуализировать список задач по проекту.