Антипаттерны «мы работаем по Agile»

Шесть способов проводить все церемонии Scrum и при этом не получить от них ничего. Признаки, причины и лечение — без утешительных формулировок.

Cargo cult agile («карго-культ Agile») — ситуация, когда команда воспроизводит внешнюю форму гибкого процесса (стендапы, спринты, доска, покер планирования), но не меняет способ принятия решений. Ритуалы есть, эффекта нет.

Как понять, что у вас Agile только на бумаге

Простой тест из трёх вопросов. Может ли команда сама решить, что взять в спринт? Может ли она сказать «нет» задаче, которую принесли в среду? Что реально изменилось в процессе после последних трёх ретроспектив?

Если ответы — «нет», «нет» и «ничего», ритуалы работают вхолостую. Дальше — конкретные формы, в которые это вырождается. Каждая встречается в реальных командах постоянно, и почти каждая начиналась с добрых намерений.

Антипаттерн 1: мини-водопад внутри спринта

Признаки. Первые два дня спринта аналитик «дописывает требования», разработчики скучают. Середина — все пишут код. В четверг последней недели весь спринт разом падает в тестирование, тестировщик сидит до ночи, часть задач не успевает и переезжает. Доска в пятницу выглядит так: колонка Testing забита, Done почти пуста.

По сути это водопад, ужатый до двух недель. Все проблемы водопада остались (обратная связь в конце, тестирование как узкое горлышко, «не успели — перенесём»), а плюсы гибкости так и не появились.

Почему так выходит. Люди привыкли думать этапами: сначала всё спроектировать, потом всё написать, потом всё проверить. Плюс задачи нарезаны горизонтально: «сделать таблицы в БД», «сделать API», «сделать интерфейс». Такую тройку невозможно закончить иначе как последовательно.

Лечение. Нарезать задачи вертикально: не «слой базы», а «пользователь может отменить заказ» — с базой, API и кнопкой внутри одной истории. Первую такую историю доводить до Done в первые дни спринта, а не в последние. Ввести лимит WIP на тестирование: если там уже две карточки, разработчик идёт помогать проверять, а не берёт третью задачу. И честно смотреть на график: если Done растёт только в последний день — вы делаете водопад.

Антипаттерн 2: velocity как KPI

Признаки. На стене висит график velocity по командам. Руководитель на встрече говорит: «У соседей 60 очков, у вас 40, подтянитесь». В следующем спринте у команды внезапно 65.

Что произошло? Ничего хорошего. Задачи, которые вчера оценивали в 3 балла, сегодня оценивают в 5 — и это не жульничество в чистом виде, а нормальная человеческая реакция на измеримую цель. Экономист Чарльз Гудхарт сформулировал это так: когда показатель становится целью, он перестаёт быть хорошим показателем.

Velocity — это единица измерения, привязанная к конкретной команде, как «средний рост учеников в классе». Сравнивать 40 очков одной команды с 60 очками другой так же осмысленно, как сравнивать градусы Цельсия с милями.

Что ломается. Инфляция оценок делает планирование бесполезным (velocity перестаёт предсказывать). Команда начинает избегать сложных, но нужных задач — за рефакторинг и разбор техдолга очков не дают. Появляется соблазн «дотянуть» задачу до Done без тестов, лишь бы засчиталась в спринт.

Лечение. Velocity видит только команда и использует только для одного — прикинуть, сколько влезет в следующий спринт. Наружу, менеджменту и в отчёты, идут другие показатели: время прохождения задачи, количество выпущенных изменений, дефекты в проде, ценность для клиента. Если руководителю очень нужна цифра — дайте ему lead time, её невозможно накрутить оценками.

Антипаттерн 3: Scrum-мастер-надсмотрщик

Признаки. Стендап превращается в обход: Scrum-мастер по очереди спрашивает каждого, что тот сделал вчера, и записывает. Люди отчитываются ему, а не друг другу. Он же назначает задачи, он же требует «поднять velocity», он же ведёт таблицу с процентами загрузки. Фактически это менеджер, у которого сменилась табличка на двери.

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

Лечение. Роль Scrum-мастера — снимать препятствия, а не собирать отчёты. Практический приём: пусть команда проведёт стендап без него, глядя на доску, а не на человека. Обсуждение идёт по карточкам справа налево — сначала то, что ближе к готовности. Задачи люди берут сами. А Scrum-мастер в это время делает свою настоящую работу: выбивает доступ, который команда ждёт четвёртый день, и договаривается со смежниками. В манифесте Agile это первый пункт: «Люди и взаимодействие важнее процессов и инструментов».

Антипаттерн 4: бэклог-свалка

Признаки. В бэклоге 700 задач. Половина заведена больше года назад. Никто не помнит, что означает тикет «Переделать фильтры (обсуждали с Сергеем)». Груминг превращается в археологию, а поиск нужного — в лотерею.

Свалка выглядит безобидно («пусть лежит, вдруг пригодится»), но у неё есть цена. Каждый разбор бэклога занимает часы. Дубли живут годами. И главное — в куче хлама не видно, что действительно важно.

Лечение.

Срок годности. Задача, которую не взяли в работу за полгода, удаляется. Если она правда важна — её заведут снова, и это займёт десять минут. Практика жёсткая, но освобождающая.
Пирамида детализации. Верхние 10–15 задач разобраны подробно, следующие 20 — крупными мазками, остальное — просто заголовки. Не пытайтесь описать всё детально: половина этих описаний устареет раньше, чем понадобится.
Потолок размера. Договоритесь: в бэклоге не больше, скажем, 100 задач. Хочешь добавить сто первую — что-то удали.

Антипаттерн 5: вечно переносимая задача

Признаки. Задача «Интеграция с 1С» переезжает из спринта в спринт третий раз подряд. На стендапе про неё говорят одно и то же: «ещё чуть-чуть, процентов на 85 готова». Через месяц она всё ещё на 85%.

За «85 процентов» почти всегда прячется одно из трёх: задача слишком большая и на самом деле состоит из пяти; в ней есть блокер, о котором стыдно сказать; либо непонятно, что вообще считать готовым.

Лечение.

Резать. Задача, которая не влезает в спринт целиком, не должна попадать в спринт. Её надо разбить на куски, каждый из которых имеет самостоятельный смысл.
Definition of Ready. Договорённость, без чего задачу нельзя брать: понятны критерии приёмки, нет неразрешённых зависимостей, известен заказчик.
Правило второго переноса. Если задача переехала во второй раз — она не просто переезжает, а выносится на обсуждение. Что мешает? Можно ли разбить? Нужна ли она вообще?
Не измерять готовность процентами. Карточка либо в Done, либо нет. «85%» — это ноль ценности для пользователя.

Антипаттерн 6: ретро без изменений

Признаки. На ретроспективе люди пишут стикеры, обсуждают час, расходятся. Через две недели — те же стикеры почти теми же словами. Постепенно народ перестаёт стараться: пишут «всё нормально», лишь бы отпустили. Ретро становится самой ненавистной встречей.

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

Лечение.

Одно действие, не десять. С ретро выходят с одним конкретным изменением, у которого есть владелец и срок. «Улучшить коммуникацию» — не действие. «Пётр до пятницы настраивает уведомление о падении сборки в общий чат» — действие.
Первый пункт следующего ретро — проверка предыдущего действия. Сделали? Помогло? Если не сделали — почему, и что это говорит о нашей способности что-то менять.
Действие должно быть в зоне влияния команды. «Пусть руководство наймёт ещё тестировщика» — не сработает. «Мы вводим лимит WIP на тестирование» — сработает.
Безопасность. Если на ретро присутствует человек, который решает вопрос премий, честного разговора не будет. Никакие фасилитационные техники этого не перевесят.

Как это работает

Все шесть антипаттернов растут из одного корня: внешнюю форму скопировали, а решения принимаются по-старому. Спринт превращают в отрезок плана, velocity — в норму выработки, Scrum-мастера — в контролёра, ретро — в вентиляцию пара. Ритуалы не отменяют иерархию сами по себе — они лишь дают команде место, где можно что-то решить. Если решать по-прежнему нельзя, место остаётся пустым.

Поэтому диагностика простая. Смотрите не на то, проводятся ли церемонии, а на то, менялось ли за последние три месяца хоть что-нибудь в том, как команда работает. Если нет — Agile у вас на слайдах.

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

Частые ошибки

Лечить симптом церемонией. Задачи не успевают — «давайте добавим ещё один стендап в день». Больше встреч не даёт больше времени.
Чинить всё сразу. Команда после статьи вроде этой находит у себя все шесть антипаттернов и берётся исправлять разом. Берите один, самый болезненный, доводите до конца.
Винить людей вместо системы. «Тестировщик медленный» — а он один на пять разработчиков, и все задачи прилетают к нему в четверг. Это не он медленный, это поток так устроен.
Считать процесс важнее результата. Если ваша команда выпускает работающий продукт и все довольны — не надо «внедрять Scrum правильно» ради самого Scrum.
Молчать про антипаттерн, потому что «так решило руководство». Ретроспектива нужна именно для того, чтобы это озвучить. Если и там нельзя — вот вам и главный вывод о процессе.

Итоги

Тест на карго-культ: команда не решает состав спринта, не может сказать «нет» и ничего не меняет после ретро.
Мини-водопад лечится вертикальной нарезкой историй и лимитом WIP на тестирование.
Velocity — инструмент планирования для самой команды, не KPI и не средство сравнения команд; наружу давайте lead time.
Scrum-мастер снимает препятствия, а не собирает отчёты; стендап — синхронизация команды, а не доклад.
Бэклогу нужны срок годности, пирамида детализации и потолок размера.
«Готово на 85%» третий спринт подряд — это ноль; режьте задачу и вводите правило второго переноса.
Ретро без одного конкретного действия с владельцем и сроком — потерянный час; без ретро остальное не чинится.