Определение готовности: документ на два предложения, который пропускает большинство команд

Спросите троих в команде, что значит "готово", и обычно получите три ответа — код слит, код слит и протестирован, код слит, протестирован и задеплоен. В этом разрыве рождается переделка, и почти всегда дешевле закрыть его одним написанным предложением, чем продолжать платить за повторное открытие "завершённой" работы.

"Готово" — это соглашение команды, а не индивидуальное суждение

Без письменного определения каждый молча применяет свой стандарт, и разрыв становится видимым только когда кто-то удивляется — задача, отмеченная готовой, которой всё ещё нужны тесты, или фича, названная выпущенной, которая на самом деле никогда не задеплоилась. Определение готовности — не документация ради документации, а то, что предотвращает это удивление в принципе.

Оно должно быть достаточно коротким, чтобы все его реально помнили

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

Одно определение для команды, исключения — явно

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

Прикрепите его к доске, а не к странице вики

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