В системологическом подходе, которого мы придерживаемся, функциональность – то, что приносит бизнес-ценность для пользователей. Одна история слишком мала, поэтому она завершается без уведомления пользователей. Функциональность представляет собой больше, чем просто сумму историй, из которых она состоит, поэтому она имеет свои собственные критерии завершенности.
Каждый раз, когда функциональность завершена, встает вопрос о ее релизе.
Результат спринта содержит отдельно проверенные истории или функции. Но возможны и другие проверки.
В зависимости от контекста, эти проверки сильно различаются. Для некоторых проектов с высокой критичностью важна документация. Качество документов важно в определении критериев завершенности спринта.
Можно проводить проверки кода, что мы – по крайней мере, в начале – делаем не для каждой истории, а в целом, например, для тестового покрытия.
Инструменты, измеряющие качество кода [29], позволяют получить информацию, полезную для проверки условий завершенности. Если у команды есть стандарты кодирования, критерии завершенности базируются на них.
Как правило, в конце спринта результат развертывается в среде, доступной для заинтересованных сторон.
Команда Peetic отметила в Git результат спринта и развернула в предпроизводстве.
Если проверки завершенности спринта не были пройдены, спринт все равно будет завершен в намеченную ранее дату. Это необходимо учитывать при добавлении историй с целью погашения технического долга. Вопрос следует поднять во время ретроспективы. Чтобы избежать такой ситуации, нужно проверять соответствие критериям завершенности на протяжении спринта, а не в конце.
«Завершено» для сезона не отличается от «завершено» для спринта – за исключением того, что окончание сезона соответствует вводу в эксплуатацию.
Ввод в эксплуатацию может быть выполнен, в зависимости от контекста, для каждой функциональности, каждого спринта, каждого сезона или вообще без подобной привязки.
В этом случае полезно определить, что требуется для продукта.
Следует ли проводить маркетинговые мероприятия? Тесты производительности? Нужно ли оформлять сопровождающие документы для ввода в эксплуатацию?
Список проверок для ввода в эксплуатацию позволяет понять, что нужно сделать в конце (если об этом не позаботиться в ходе спринта) для каждой функциональности. В идеале это делается как можно раньше, чтобы максимально сократить срок до ввода в эксплуатацию. Это может потребовать корректировки критериев завершенности по мере продвижения команды.
Здесь необходимо участие заинтересованных сторон: скорее всего, Scrum-команда не справится самостоятельно.
8.4 Как определить критерии завершенности
В предыдущей главе мы прошли критерии готовности – этап на пути к критериям завершенности. Мы поняли, что история должна быть готова в начале спринта, если мы хотим увеличить шансы на ее завершение. Действия, описанные ниже, касаются определения критериев завершенности, но могут применяться и для определения критериев готовности.
В процесс вовлечена вся команда – и это нормально: именно участники команды будут применять критерии на практике. Участие Владельца продукта в коллективной работе играет важную роль, желательно участие и заинтересованных сторон.
Критерии завершенности впервые разрабатываются во время прелюдии, перед первым спринтом.
Этот процесс не является частью собрания, имеющего какое-либо название в Scrum-терминологии: у него нет строгого формата. Самое главное, что работа выполняется в команде. Мозговой штурм мне кажется наиболее подходящей формулой для сбора идей каждого участника и согласования критериев завершенности.
Scrum-мастер модерирует собрание и консолидирует собранные идеи. В частности, он должен обеспечить, чтобы были услышаны голоса тех, кто больше остальных участвовал в тестировании и качестве.
Я рекомендую сначала прописать весь список проверок на Post-it®, а затем связать их с одним из уровней (история, функциональность, спринт, сезон или ввод в эксплуатацию) для одной из трех категорий. Можно изобразить это при помощи кругов, по одному на уровень, чтобы легче визуализировать и менять уровни во время обсуждения.
Отдельным пунктом обсуждения является уровень, на котором следует разместить нефункциональные или кроссфункциональные требования (удобство использования, надежность, производительность, безопасность и т. д.).
Рисунок 8.4 – Критерии завершенности на нескольких уровнях
Для Peetic. Совместимость с Firefox 57.0, доступность на планшетах, онлайн-справка, доступная в виде подсказок, находятся на уровне функциональности.
Цель этого первого определения – в получении списка проверок, по крайней мере, для пользовательских историй. Этот список будет обновляться с каждым спринтом и дополняться другими типами историй.
Практика, называемая определением критериев завершенности, превращается в одноименный артефакт.
Список публикуется таким образом, чтобы вся команда его видела и одинаково понимала.
Если команда располагается в открытом офисе, публикация списка выглядит как плакат, прикрепленный рядом с планом спринта. В него можно включить результат собрания в виде списка проверок на Post-it® в кругах, соответствующих уровням.
Список можно размещать и в других формах общения, используемых командой: интранет, wiki, инструменты и т. д. В любом случае важно, чтобы он был видимым и отображался в легко доступной панели инструментов.
Список не должен быть слишком длинным, иначе ему будет трудно следовать. В него не следует добавлять проверки чего-то очевидного для всей команды, он должен включать лишь то, что еще не стало для участников рабочей привычкой.
Элементы списка удаляются, как только входят в привычку команды.
Во время спринта проводятся проверки, чтобы убедиться в успешном завершении истории. Они осуществляются без помощи сторонних организаций – этим занимается команда, ответственная за достижение качественного результата.
• Кто проводит проверку завершенности?
Команда решает, кто именно отвечает за проверки. Может быть целый ряд проверок для одной истории. Разумно разделить их между несколькими людьми.
Некоторые команды практикуют перекрестную проверку: проверку истории осуществляет человек, не участвовавший в работе над ней. Идея отличная, но подобная практика может создавать задержки в связи с ожиданием, пока нужный человек не станет доступен для той или иной проверки.
• Что делать, если проверка не пройдена?
Команда возобновляет работу, чтобы до окончания спринта все же пройти проверку. В ином случае, историю нельзя считать завершенной.
Команда достигает определенного результата в конце спринта, но при этом завершает истории по ходу, не дожидаясь его окончания.
Пока идет работа над реализацией истории, она в процессе. По завершении она отправляется в финишный лоток (или в колонку завершено). Для этого не нужно ждать конца спринта.
Рисунок 8.5 – «Это конец»
Этап завершения – последний в жизненном цикле истории. После него ничего нет.
Немного статистики. Peetic с командой из пяти разработчиков реализует примерно десять историй и в среднем завершает одну историю в день.
В таблице функциональностей каждая колонка означает какой-либо этап. Когда функциональность завершена, она переходит в самую правую колонку под названием завершено.
Команда Peetic за сезон, состоящий из пяти спринтов, завершает примерно 5–10 функциональностей, то есть 1–2 за спринт. Могут быть спринты, в частности, первый, без завершенных функциональностей вовсе.
Ретроспектива – это событие, во время которого команда может оценить свой способ работы. Критерии завершенности оказывают влияние на многие практики, и эта встреча – идеальный повод проверить, соблюдаются ли они.
Во время ретроспективы рассматриваются причины, по которым не были пройдены те или иные проверки.
Критерии завершенности и готовности развиваются и меняются с каждым спринтом по нескольким причинам.
✓ Команда упустила какие-либо аспекты и подчеркнула их во время спринта. Другие же вошли в ее привычку и были удалены.
✓ Практики команды регулярно, каждый спринт, развиваются в рамках ретроспективы. Критерии завершенности и готовности также меняются, чтобы принять во внимание эти улучшения.
✓ Команда поднимает вопрос о добавлении новых сториотипов.
Когда приближается момент ввода в эксплуатацию, можно повысить уровень, необходимый, чтобы приблизиться к цели, – и осуществить релиз, не тратя времени на выполнение того, чего не хватает.
• Применение концепции сториотипа
Команда Peetic описывает сториотип пользовательская история следующим образом:
У каждой команды свои сториотипы, так как они зависят от контекста.
8.5 Последствия незавершенности
Неспособность правильно определять критерии завершенности для истории негативно влияет на будущие спринты. Два наиболее частых последствия – это обнаружение багов, которые необходимо впоследствии исправить, и появление технического долга, который будет нужно погасить.