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