Процесс нужен, чтобы команда предсказуемо поставляла ценность, а не ради ритуалов. Метрики нужны, чтобы видеть узкие места, а не ставить оценки людям. На собесе EM почти всегда спрашивают, какие метрики вы смотрите и что с ними делаете.
Scrum и Kanban без догм
- Scrum: спринты фиксированной длины, планирование, ежедневная синхронизация, обзор, ретроспектива. Хорош, когда работа планируемая и нужна регулярная обратная связь от бизнеса.
- Kanban: непрерывный поток, визуализация доски, лимиты незавершённой работы (WIP), управление потоком. Хорош для поддержки, платформенных команд, потока заявок.
Многие команды живут в гибриде. Важно не название, а что процесс решает конкретные проблемы команды. Ретроспектива единственная церемония, которую почти никогда не стоит выкидывать: это механизм улучшения самого процесса.
DORA: четыре ключевые метрики
Исследование DORA (DevOps Research and Assessment, книга «Accelerate») связало эти метрики с результатами организаций:
| Метрика | Что показывает |
|---|---|
| Deployment frequency | Как часто выкатываем в прод |
| Lead time for changes | Время от коммита до работы в проде |
| Change failure rate | Доля выкаток, которые привели к сбою, откату или хотфиксу |
| Time to restore service | Как быстро восстанавливаемся после сбоя (в новых отчётах называется failed deployment recovery time) |
Первые две про скорость, вторые две про стабильность. Главный вывод исследований: скорость и стабильность не противоречат друг другу, лучшие команды сильны в обоих.
Пример расчёта за 4 недели: 40 деплоев, 6 из них вызвали инцидент или откат. Частота 10 в неделю, change failure rate 6 / 40 = 15%.
Flow-метрики
- Lead time (от запроса до готовности) и cycle time (от начала работы до готовности).
- Throughput: сколько задач завершено за период.
- WIP: сколько задач в работе одновременно.
- Flow efficiency: доля времени, когда над задачей реально работали, от всего времени в пути. Часто 15-40%: остальное ожидание ревью, тестов, другой команды.
Закон Литтла связывает их для стабильного потока: WIP = throughput × cycle time, отсюда cycle time = WIP / throughput. Если команда закрывает 10 задач в неделю и держит 30 в работе, средняя задача идёт 3 недели. Снизите WIP до 15, и при той же пропускной способности cycle time упадёт до 1,5 недели. Поэтому лимиты WIP ускоряют поставку.
Опросы и SPACE
Цифры из систем показывают не всё. Фреймворк SPACE предлагает смотреть шире: удовлетворённость и благополучие (Satisfaction), результат (Performance), активность (Activity), коммуникация и сотрудничество (Communication), эффективность и поток (Efficiency). Регулярный короткий опрос команды о том, что мешает, часто ценнее сотни графиков.
Как не испортить метрики
- Закон Гудхарта: когда метрика становится целью, она перестаёт быть хорошей метрикой. Сделаете KPI из числа деплоев, получите деплои по одной строке.
- Метрики команды, а не человека. Число коммитов или строк кода на человека вредно.
- Смотреть тренд, а не абсолютное значение, и сравнивать команду с собой.
- Пара метрик, которые уравновешивают друг друга: скорость и стабильность.
- Метрика без действия бесполезна: каждый график должен отвечать на вопрос «что мы поменяем».
Частые ошибки
- Внедрить Scrum «по книге» в команду поддержки.
- Мерить продуктивность story points или часами.
- Собирать двадцать метрик и не смотреть ни одну.
- Лимит WIP на доске есть, но его никто не соблюдает.
Что спросят на собесе
- Какие метрики команды вы смотрите и какое решение приняли по ним.
- Что такое DORA-метрики, как их собрать.
- Почему лимит WIP ускоряет команду.
- Руководство хочет мерить продуктивность разработчиков по коммитам. Ваш ответ.
- Scrum или Kanban для вашей команды и почему.