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.
Далее составляется общий бэклог задач к реализации, и на каждый новый спринт выносятся наиболее приоритетные фичи.
Представитель заказчика активно участвует в событиях и перед каждой новой итерацией может актуализировать список задач по проекту.