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