Scrum

Роли: у приоритета один хозяин

Владелец продукта единолично решает, что попадает в бэклог и в каком порядке. Команда решает, как это сделать и сколько взять. Скрам-мастер отвечает за процесс и снимает помехи. Аналитик наполняет элементы содержанием - и обычно он же обнаруживает, что порядок в бэклоге противоречит сам себе.

Ломается это всегда одинаково: приоритет начинают назначать трое - владелец продукта, руководитель направления и тот, кто громче написал в чат. Бэклог превращается в свалку одинаково срочных пожеланий, и когда нужно сократить объём, сокращать нечем: всё первое.

// Проверка на живой приоритет простая. Спроси, что уберут, если спринт придётся урезать вдвое. Если ответа нет ни у кого, приоритета нет, есть список.

Готовность общая, приёмка частная

DoD (definition of done), определение готовности - единый для всех элементов набор условий: код прошёл ревью, тесты написаны и зелёные, документация обновлена, функция выкачена на стенд. Один список на команду, не меняется от задачи к задаче.

Критерии приёмки - индивидуальны для каждой истории и описывают конкретное поведение: «при сумме больше 100 000 требуется подтверждение руководителя», «при отказе банка показывается причина и кнопка повтора». Путаница этих двух вещей даёт классическое «готово, но у пользователя не работает»: критерии выполнены, а на стенд не выкачено и миграция не написана.

// Приём, который экономит месяцы: внести обновление документации прямо в определение готовности. Пока это работа «когда будет время», её не делает никто и никогда - времени не бывает.

Цель спринта и срочная задача в середине

Цель спринта защищена не из вредности. Она даёт команде короткий отрезок, на котором можно спокойно довести работу до конца, не переигрывая планы каждое утро. Объём внутри уточняется по договорённости, подмена цели ломает смысл всей конструкции.

Посчитаем, во что обходится «маленькая срочная задача». Двухнедельный спринт - это десять рабочих дней. Задача на три дня съедает 30 процентов, плюс переключение туда и обратно, плюс недоделанные хвосты того, что отложили. Реально теряется около половины спринта, и цель не достигается.

// Если срочность настоящая, честный ход - отменить спринт и спланировать заново. Отмена спринта - законный инструмент, а не катастрофа и не приговор команде. Тихо подсунуть задачу хуже: цель формально жива, а достичь её уже нельзя.

Недобор объёма лечится до спринта

Команда берёт 40 поинтов и стабильно доводит 28 - это 70 процентов, и виноватыми назначают исполнителей. Смотреть надо раньше: сколько элементов зашло в спринт без критериев приёмки и с открытыми вопросами. Если таких шесть из десяти, объём вскрывается внутри спринта, и оценка перестаёт значить хоть что-то.

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

// Обе причины лежат до планирования, и первая - зона аналитика. Отсюда простое правило: элемент без критериев приёмки в спринт не заходит, каким бы срочным он ни был.

Как отвечать: «Команда стабильно не завершает взятый объём. Где причина?»

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

Кандидат ищет причину в подготовке, а не в исполнителях, называет свою зону ответственности и считает цену срочной задачи.

На чём валятся

• −− Считают закрытые задачи результатом спринта вместо работающего инкремента.
• −− Путают определение готовности с критериями приёмки.
• −− Разрешают назначать приоритет нескольким людям сразу.
• −− Меняют цель спринта в середине и удивляются, что ничего не доводится до конца.
• −− Сравнивают команды по скорости в поинтах: шкала у каждой своя, а показатель начинает расти сам.
• −− Проводят все события, но бэклог не меняется от обратной связи - ритуал без петли.