Попробовать бесплатно
Гибкие3 темы

Agile: ценности, принципы и что из этого следует на практике

Agile — зонтик над Scrum, Kanban, экстремальным программированием и десятком менее известных подходов. Под ним лежит короткий документ 2001 года: четыре ценности и двенадцать принципов. Знать их полезно, потому что фреймворки меняются, а разногласия в командах почти всегда упираются именно в эти четыре строчки.

9 мин чтенияуровень: базовыйобновлено
КРАТКО
  • Манифест написан в 2001 году семнадцатью практиками разработки; это одна страница текста
  • Четыре ценности сформулированы как выбор приоритета, при котором обе стороны остаются нужными
  • Общее у всех подходов семейства: короткий цикл, работающий результат, обратная связь, право менять план
  • Скорость сама по себе не обещана: обещана предсказуемость и раннее обнаружение ошибок
01 · ЧТО ЭТО

Откуда взялся Agile

В феврале 2001 года семнадцать человек, каждый со своим подходом к разработке, собрались на горнолыжном курорте в Юте и за два дня договорились о том, что у них общего. Получилась страница текста: четыре ценности и двенадцать принципов.

Ценности сформулированы как сравнение приоритетов. Люди и взаимодействие ставятся выше процессов и инструментов; работающий продукт — выше исчерпывающей документации; сотрудничество с заказчиком — выше согласования условий договора; готовность к изменениям — выше следования первоначальному плану.

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

Двенадцать принципов конкретнее и в основном про ритм: поставлять работающий результат каждые несколько недель, приветствовать изменение требований даже на поздней стадии, строить проекты вокруг мотивированных людей, регулярно спрашивать себя, как работать лучше.

Манифест писали для разработки программ. Перенос на маркетинг, кадры, производство и другие области — расширение по аналогии, и там он работает хуже: часть принципов опирается на возможность дёшево менять уже сделанное, которой в физическом мире нет.

Фреймворки семейства отвечают на разные вопросы. Scrum описывает ритм команды, Kanban — поток и ограничение работы, экстремальное программирование — инженерные практики. Их берут по отдельности и вместе.

ПОДХОДИТ, КОГДА
  • Требования уточняются по ходу, и заранее полный список составить нельзя
  • Результат можно показывать и проверять каждые несколько недель
  • Заказчик доступен для регулярной обратной связи
  • Команда может влиять на то, как устроена её собственная работа
НЕ ПОДХОДИТ, КОГДА
  • Содержание и сроки жёстко зафиксированы договором или стандартом
  • Промежуточный результат нельзя ни показать, ни проверить
  • Стоимость изменения велика физически: здание, партия оборудования, тираж
  • Заказчик появляется дважды: на подписании и на приёмке
02 · АРТЕФАКТЫ И СОБЫТИЯ

Что общего у подходов семейства

Конкретные документы задаёт выбранный фреймворк. Общими остаются четыре вещи, без которых гибкость превращается в отсутствие порядка.

ЭЛЕМЕНТ

Упорядоченный список работ

Один на команду, с одним владельцем приоритетов. Из него берут работу в цикл или в поток.

владелец: Владелец продукта
ЭЛЕМЕНТ

Критерии завершённости

Общее понимание того, что считается сделанным: протестировано, интегрировано, доступно пользователю. Без них «готово» означает разное у каждого.

владелец: Команда
ЭЛЕМЕНТ

Работающий результат

Главный измеритель прогресса. Отчёт о выполненных задачах прогрессом не является, пока результат нельзя показать.

владелец: Команда
ЭЛЕМЕНТ

Регулярная обратная связь

От заказчика и пользователей, с фиксированной частотой. Обратная связь по требованию не приходит никогда.

владелец: Владелец продукта
События
СОБЫТИЕЧАСТОТА И ДЛИТЕЛЬНОСТЬУЧАСТНИКИЧЕМ ЗАКАНЧИВАЕТСЯ
Планирование работыот 30 мин до 4 чкоманда и владелец продуктачто берём в ближайший период
Ежедневная сверка10–15 минкомандачто мешает и кому нужна помощь
Показ результата1–2 чкоманда и заказчикобратная связь на работающем продукте
Разбор работы1–1,5 чкомандаодно-два изменения в собственном процессе
03 · ВНЕДРЕНИЕ

С чего начать переход

Переход начинается с двух вещей, которые не требуют выбора фреймворка: короткого цикла обратной связи и общего понимания завершённости.

  1. 1Сократите горизонт планированияПерейдите от квартального плана работ к периоду в две-четыре недели. Дальний горизонт остаётся на уровне целей.первый месяц
  2. 2Договоритесь о завершённостиОдин список критериев на команду. Самый дешёвый шаг перехода и первый, который даёт заметный эффект.первый месяц
  3. 3Заведите регулярный показ результатаРаз в две-четыре недели, на работающем продукте, с заказчиком в комнате. Показ по презентации этой роли не выполняет.первый-второй месяц
  4. 4Сведите приоритеты к одному человекуПока задачи приходят из трёх источников, короткий цикл превращается в частую смену приоритетов.второй месяц
  5. 5Выберите фреймворк под тип работыИтерации при планируемом объёме, поток при непрерывном входящем. Выбор проще делать после того, как первые четыре шага уже работают.второй-третий месяц
  6. 6Заведите разбор собственной работыРегулярная встреча с одним-двумя изменениями процесса за цикл. Именно она отличает гибкий подход от нового набора обрядов.постоянно
04 · МЕТРИКИ

Что считать

Частота поставкиКак часто результат доходит до пользователя. Прямое следствие короткого цикла.Число выпусков или завершённых элементов за период.
Время до обратной связиСколько проходит от идеи до реакции пользователя. Главная величина, ради которой всё затевается.Медиана от начала работы до первой обратной связи.
Доля доведённого до концаКакая часть взятого в период доведена до состояния «готово» по общим критериям.Завершённые элементы к взятым за период.
Скорость изменения планаКак часто меняются приоритеты внутри периода. Высокая частота означает, что цикл длиннее, чем нужно.Число замен работ внутри периода.
Улучшения процессаСколько изменений в собственной работе команда внедрила и проверила.Закрытые улучшения по итогам разборов за квартал.
05 · ТИПИЧНЫЕ ОШИБКИ

Где обычно ломается

Берут обряды, оставляют управление

ЧТО ДЕЛАТЬПроверьте, кто решает состав работы внутри периода. Ежедневные встречи и доски при неизменном порядке «сверху спустили список» дают прежний результат с новыми названиями.

Гибкость понимают как отсутствие плана

ЧТО ДЕЛАТЬПлан остаётся, меняется его горизонт и детальность: цели на квартал, состав работ на две недели. Отсутствие плана — это отсутствие плана, и манифест такого не предлагал.

Документацию отменяют целиком

ЧТО ДЕЛАТЬВернитесь к формулировке: работающий продукт ценнее исчерпывающей документации. Слово «исчерпывающей» и есть предмет спора; необходимая документация остаётся.

Ждут ускорения

ЧТО ДЕЛАТЬОбещана предсказуемость и раннее обнаружение ошибок. Скорость иногда растёт как следствие, но заявлять её как цель перехода — верный способ разочаровать руководство через квартал.

Переносят на работу с высокой ценой изменения

ЧТО ДЕЛАТЬПроверьте, можно ли дёшево переделать сделанное. Там, где нельзя — стройка, тираж, партия оборудования, — короткие циклы дают меньше, а классическое планирование больше.

Разбор работы отменяют первым

ЧТО ДЕЛАТЬДержите его в календаре как обязательный. Команда без регулярного разбора собственного процесса застывает в первой попавшейся конфигурации и перестаёт улучшаться.
07 · В SHTAB

Что нужно от инструмента

Гибкому подходу нужны три вещи от системы: один упорядоченный список работ, видимый статус каждой и история, по которой считаются время и частота поставки.

  • 01Один список работ с порядком заменяет три источника задач и делает приоритет видимым.
  • 02Доска со статусами вашего процесса показывает, где работа стоит прямо сейчас.
  • 03Критерии завершённости живут чек-листом в шаблоне задачи и появляются в каждой карточке.
  • 04История переходов даёт время до обратной связи и частоту поставки без ручного сбора.
  • 05Цели связывают работу команды с квартальным результатом, оставляя состав работ гибким.
  • 06Итоги разборов храните страницами: следующая встреча начинается с проверки прошлых решений.
08 · FAQ

Частые вопросы

Строго говоря, это набор ценностей и принципов, под который подходят разные методы. Методологией называют Scrum, Kanban, экстремальное программирование — у них есть роли, события и правила. Путаница безобидна в разговоре и вредна на практике: «внедрить Agile» невозможно, внедряют конкретный подход.

Соберите свой процесс в Shtab

Доски и статусы, оценка трудозатрат, дерево целей, отчёты и трекер времени — в одном инструменте.