Откуда взялся Agile
В феврале 2001 года семнадцать человек, каждый со своим подходом к разработке, собрались на горнолыжном курорте в Юте и за два дня договорились о том, что у них общего. Получилась страница текста: четыре ценности и двенадцать принципов.
Ценности сформулированы как сравнение приоритетов. Люди и взаимодействие ставятся выше процессов и инструментов; работающий продукт — выше исчерпывающей документации; сотрудничество с заказчиком — выше согласования условий договора; готовность к изменениям — выше следования первоначальному плану.
К этому списку авторы приписали фразу, которую в пересказах теряют чаще всего: не отрицая важности того, что справа, мы больше ценим то, что слева. Документация, договоры и планы остаются нужными; спор идёт о том, чем жертвовать при конфликте.
Двенадцать принципов конкретнее и в основном про ритм: поставлять работающий результат каждые несколько недель, приветствовать изменение требований даже на поздней стадии, строить проекты вокруг мотивированных людей, регулярно спрашивать себя, как работать лучше.
Манифест писали для разработки программ. Перенос на маркетинг, кадры, производство и другие области — расширение по аналогии, и там он работает хуже: часть принципов опирается на возможность дёшево менять уже сделанное, которой в физическом мире нет.
Фреймворки семейства отвечают на разные вопросы. Scrum описывает ритм команды, Kanban — поток и ограничение работы, экстремальное программирование — инженерные практики. Их берут по отдельности и вместе.
- Требования уточняются по ходу, и заранее полный список составить нельзя
- Результат можно показывать и проверять каждые несколько недель
- Заказчик доступен для регулярной обратной связи
- Команда может влиять на то, как устроена её собственная работа
- Содержание и сроки жёстко зафиксированы договором или стандартом
- Промежуточный результат нельзя ни показать, ни проверить
- Стоимость изменения велика физически: здание, партия оборудования, тираж
- Заказчик появляется дважды: на подписании и на приёмке
Что общего у подходов семейства
Конкретные документы задаёт выбранный фреймворк. Общими остаются четыре вещи, без которых гибкость превращается в отсутствие порядка.
Упорядоченный список работ
Один на команду, с одним владельцем приоритетов. Из него берут работу в цикл или в поток.
Критерии завершённости
Общее понимание того, что считается сделанным: протестировано, интегрировано, доступно пользователю. Без них «готово» означает разное у каждого.
Работающий результат
Главный измеритель прогресса. Отчёт о выполненных задачах прогрессом не является, пока результат нельзя показать.
Регулярная обратная связь
От заказчика и пользователей, с фиксированной частотой. Обратная связь по требованию не приходит никогда.
| СОБЫТИЕ | ЧАСТОТА И ДЛИТЕЛЬНОСТЬ | УЧАСТНИКИ | ЧЕМ ЗАКАНЧИВАЕТСЯ |
|---|---|---|---|
| Планирование работы | от 30 мин до 4 ч | команда и владелец продукта | что берём в ближайший период |
| Ежедневная сверка | 10–15 мин | команда | что мешает и кому нужна помощь |
| Показ результата | 1–2 ч | команда и заказчик | обратная связь на работающем продукте |
| Разбор работы | 1–1,5 ч | команда | одно-два изменения в собственном процессе |
С чего начать переход
Переход начинается с двух вещей, которые не требуют выбора фреймворка: короткого цикла обратной связи и общего понимания завершённости.
- 1Сократите горизонт планированияПерейдите от квартального плана работ к периоду в две-четыре недели. Дальний горизонт остаётся на уровне целей.первый месяц
- 2Договоритесь о завершённостиОдин список критериев на команду. Самый дешёвый шаг перехода и первый, который даёт заметный эффект.первый месяц
- 3Заведите регулярный показ результатаРаз в две-четыре недели, на работающем продукте, с заказчиком в комнате. Показ по презентации этой роли не выполняет.первый-второй месяц
- 4Сведите приоритеты к одному человекуПока задачи приходят из трёх источников, короткий цикл превращается в частую смену приоритетов.второй месяц
- 5Выберите фреймворк под тип работыИтерации при планируемом объёме, поток при непрерывном входящем. Выбор проще делать после того, как первые четыре шага уже работают.второй-третий месяц
- 6Заведите разбор собственной работыРегулярная встреча с одним-двумя изменениями процесса за цикл. Именно она отличает гибкий подход от нового набора обрядов.постоянно
Что считать
Где обычно ломается
Берут обряды, оставляют управление
Гибкость понимают как отсутствие плана
Документацию отменяют целиком
Ждут ускорения
Переносят на работу с высокой ценой изменения
Разбор работы отменяют первым
Темы про Agile
Что нужно от инструмента
Гибкому подходу нужны три вещи от системы: один упорядоченный список работ, видимый статус каждой и история, по которой считаются время и частота поставки.
- 01Один список работ с порядком заменяет три источника задач и делает приоритет видимым.
- 02Доска со статусами вашего процесса показывает, где работа стоит прямо сейчас.
- 03Критерии завершённости живут чек-листом в шаблоне задачи и появляются в каждой карточке.
- 04История переходов даёт время до обратной связи и частоту поставки без ручного сбора.
- 05Цели связывают работу команды с квартальным результатом, оставляя состав работ гибким.
- 06Итоги разборов храните страницами: следующая встреча начинается с проверки прошлых решений.
Частые вопросы
Строго говоря, это набор ценностей и принципов, под который подходят разные методы. Методологией называют Scrum, Kanban, экстремальное программирование — у них есть роли, события и правила. Путаница безобидна в разговоре и вредна на практике: «внедрить Agile» невозможно, внедряют конкретный подход.