Ситуация. Команда разделилась на истории и определила зависимости от людей вне команды. Участники планируют ввести их в курс дела во время спринта.
Последствия. Во время спринта работа встала, потому что продвижение команды зависит от людей, которые на данный момент недоступны.
Как сделать лучше? Привлекать людей на границах команды к участию в сессиях по доработке. Это позволит обсуждать процесс с ними, лучше их вовлекать и, таким образом, снизить риск, связанный с зависимостью (шестая К патерна 6К направлена на избавление от зависимостей).
Ситуация. Команда определила критерии готовности и список проверок. Разработчики применяют их слишком буквально и отказываются считать историю готовой, если не хватает какой-то мелочи.
Последствия. Команда возвращается к синдрому силосной башни: с одной стороны, бизнес определяет, что ему надо, с другой – разработчики делают, что от них требуют.
Как сделать лучше? Вполне вероятно, что критерии готовности были навязаны или не до конца всем понятны. Команда отвлекается и возвращается к старой схеме (типа владелец проекта/менеджер проекта), по которой разработчики начинают работать, только если у них есть подробная спецификация. Они боятся брать на себя обязательства и не чувствуют себя уверенными в том, что делают.
Следует поощрять общение во время этапа доработки. Доработка касается каждого участника команды, а не какой-то специализированной подгруппы. Определение критериев готовности – это набор рекомендаций (паттерн 6К), а не свод правил!
Чтобы идти дальше
Книги
‣ Gojko Adzic, David Evans, «Fifty quick ideas to improve your User Stories», Neuri Consulting LLP, 2014
8Определение критериев завершенности
«Ты завершил работу? Когда вы завершите этот код? Тестовая документация завершена? Ты завершил уборку в своей комнате?»
Рисунок 8.1 – «Уборка завершена!»
Эти вопросы часто возникают как в разработке, так и в жизни вообще. В Scrum они настолько важны, что есть целая практика, посвященная этому.
В конце спринта команда достигает определенного результата. Этого недостаточно: нужно, чтобы задачи были «завершены» – только тогда спринт можно считать успешно законченным.
Но что это вообще значит?
Ответ на вопрос у разных команд может звучать по-разному. Часто бывает, что начинающей команде ответить довольно сложно.
Пример: Николя полагает, что его работа завершена: код написан, тесты пройдены. Однако она почти завершена для Селин, Владельца продукта, которая считает, что конечный пользователь испытывает трудности при использовании продукта.
У всех разное восприятие завершенности.
Цель этой главы – показать, как сделать, чтобы критерии завершенности совпадали для всей команды и заинтересованных сторон.
8.1 Что означает «завершено»?
Темп в Scrum задается спринтом фиксированной и короткой продолжительности, который не может быть продлен и завершается определенным результатом.
Этот результат функционирует и имеет потенциальную ценность для заинтересованных сторон – в случае, если его содержание и качество безупречны.
Именно с целью снижения рисков в отношении содержания инкремента команда согласовывает цель спринта и доводит ее до сведения заинтересованных сторон.
У каждого спринта есть цель, которая определяется в начале и проверяется в конце. Она формулируется одной фразой, суммирующей содержание. На нем сосредотачивается команда, за него несет ответственность перед заинтересованными сторонами.
Постановка цели спринта усиливает фокус команды, ее целеустремленность и вовлеченность. Это позволяет команде, словно экипажу корабля, придерживаться единого курса.
Детали этой Scrum-практики представлены в следующей главе.
Именно с целью снижения рисков в отношении качества инкремента существуют критерии завершенности.
Команда может считать спринт успешным, если достигла его цели и уровня качества, заданного критериями завершенности.
Английский термин для критериев завершенности – Definition of Done, часто употребляемый франкофонами и сокращаемый до Do D. Как мне кажется, перевод критерии завершенности отлично применим.
В традиционном подходе, если результат оказывается ниже ожидаемого, дата перехода к следующему шагу обычно откладывается. В Scrum такой возможности нет: спринт всегда заканчивается в запланированную дату. Если цель к этому времени не достигнута, одна или несколько историй переходят на следующий спринт.
Если в конце спринта результат команды не отвечает критериям завершенности, сложно определить, что именно не соответствует качеству и переходит на следующий спринт. Более того, очень опасно проводить проверки только в конце спринта. Поэтому проверка соответствия критериям завершенности будет касаться элементов (историй, функциональностей) по мере их завершения, а не в конце спринта.
Определение критериев завершенности – это Scrum-практика, которая гарантирует качество всех частей процесса.
8.2 Завершенная история
Метафора спринта не применима к участникам команды (которые, скорее, бегут марафон), но сохраняет смысл, если представлять, что в качестве бегунов выступают истории.
Рисунок 8.2 – Участники дают команду «марш», и истории начинают спринтерский забег
Истории участвуют в забеге и, очевидно, финишируют не одновременно.
В настоящем спринте спортсмен завершает забег в момент пересечения финишной черты. Но при этом проверяют: есть ли у него официальный номер участника, не пересекал ли он соседних линий, принимал или нет допинг. Чтобы можно было считать историю завершенной, надо проверить, соответствует ли она условиям приемки – что тождественно финишной черте в спорте. Вспомогательные проверки, такие как проверка регистрационного номера бегуна, составляют критерии завершенности.
Критерии завершенности для истории – это список проверок, разработанный и контролируемый командой.
Если тест соответствия условиям приемки успешно пройден, история функционирует, но она еще не завершена. Возможно, она вызвала регрессию в истории, которая была до нее? Может быть, ее нелегко использовать (из-за плохой эргономики) или нельзя поддерживать (в связи с техническим долгом)? Чтобы избежать неприятных моментов, существуют критерии завершенности.
Чтобы окончательно завершить историю, нужно выполнить, помимо функционального тестирования, еще ряд проверок. Можно их разделить на три категории.
✓ Проверки на соответствие условиям приемки (кто, когда, кому).
✓ Проверки визуальных аспектов заинтересованными сторонами (удобство использования, надежность, производительность, безопасность, и т. д.).
✓ Проверки, заметные только команде (возможность поддержания, многократного использования, и т. д.).
Рисунок 8.3 – Три категории проверок завершенности
Назовем эти три категории так: функционирование, внешнее качество и внутреннее качество.
Для Peetic критерии завершенности содержат
Каждая история отличается от других и имеет свои условия приемки. В то же время, команда быстро приходит к пониманию, что проверки критериев завершенности могут быть общими для нескольких историй.
И тогда она создает список, действительный сразу для нескольких историй.
Нескольких, но не всех!
Истории, занесенные в один список, принадлежат к одному сториотипу, говоря языком Джеральда Месразоса, а затем Дэна Роастхорна в его «Exploring Scrum».
Паттерн сториотип состоит в группировании историй, имеющих общий список проверок завершенности.
В главе 6 «Структура бэклога» мы рассмотрели четыре типа историй. Концепция сториотипа идет дальше. Среди функциональных историй есть сториотип пользовательская история, содержащая код. Однако его проверки не применимы ко всем функциональным историям – в частности, к тем, которые не содержат код (это, например, услуга, предоставляемая пользователю по телефону).
Можно начать с одного списка. Для каждой истории нужно задать вопрос: подходят ли для нее проверки из общего списка? Если нет, значит, у нее ее собственные, соответствующие только ей, проверки.
8.3 Дополнения к завершенности
Завершить историю – это хорошо. Завершить функциональность – еще лучше!
Это происходит не так часто, ведь функциональность состоит из историй. Можно было бы сказать, что функциональность завершена, когда все входящие в нее истории завершены, но это не совсем так. Критерии завершенности функциональности показывают, что именно команде нужно доделать, чтобы можно было считать ее завершенной.
Например, убедиться при помощи тестов, что цепочка историй работает. Команда, скорее всего, обнаружит, что есть проверки, которые не рекомендуется выполнять для историй.
В данном случае тоже можно применить деление на три категории, упомянутые выше.
Чтобы не забыть про работу, связанную с проверками, можно создать завершающую историю для каждой функции.
Для Peetic функциональность завершена, если она включает: