Уорд Каннингем предложил концепцию технического долга [30]. Он провел аналогию с финансовым долгом: когда вы берете долги, проценты постепенно накапливаются – так и стоимость разработки со временем возрастает, если у программного обеспечения есть технические недостатки.
Каждая дополнительная минута, потраченная на код низкого качества, соответствует процентам по долгу.
Технический долг заметен только разработчикам (и то не всегда), другие заинтересованные стороны в это не посвящены. Как следует из названия, он носит технический характер и может принимать разные формы: некорректная архитектура, плохо написанный код, плохо соблюдаемый стандарт кодирования, отсутствие документации или нехватка автоматизации тестирования.
Профилактические меры относятся к критериям завершенности, в то время как меры курирования составляют истории типа погашения технического долга.
Неполное или неудачное применение критериев завершенности – обычная причина обнаружения ошибок.
Команда Peetic хочет, чтобы каждая завершенная пользовательская история имела онлайн-справку на английском языке. Команда разрабатывает пользовательскую историю регистрации и в конце спринта, когда приемочные тесты успешно пройдены, переносит ее в колонку завершено.
Позднее, в следующем спринте, команда замечает, что в онлайн-справке отсутствует текст на английском. Это баг, который участники заносят в бэклог.
Все, что не было завершено во время спринтов, из-за чего пользователи не смогут использовать продукт, – работа, которую необходимо выполнить перед вводом в эксплуатацию.
Необходимо срочно дорабатывать эти моменты во время последнего спринта, буквально накануне релиза. Чтобы избежать переноса даты, следует вносить понятие ввода в эксплуатацию в критерии завершенности.
8.6 Антипаттерны
Ситуация. Критерии завершенности представляют собой список, который тянется до самого пола, но на деле состоит из одних лишь пожеланий.
Последствия. Критерии завершенности расплывчаты.
Как сделать лучше? Внести ограничение количества пунктов в списке, например, до десяти конкретных проверок.
Ситуация. Если спросить у команды, есть ли у нее критерии завершенности, участники отвечают: да, есть. Если спросить, что именно входит в их критерии завершенности, участники говорят: надо открыть список и уточнить.
Последствия. Критерии завершенности особо не используются командой.
Как сделать лучше? Повесить список критериев завершенности на стену команды, чтобы каждый участник его видел.
Чтобы идти дальше
Книги
‣ Dan Rawsthorne, Doug Shimp, «Exploring Scrum, The Fundamentals», CreateSpace Independent Publishing Platform, 2011
9Планирование спринта
В области компьютерного прогнозирования есть много примеров, иллюстрирующих возможные трудности работы в команде. Вот три, которые суммируют типичные ситуации в организациях, где управление проектами является «традиционным».
✓ Разработчик кода не особо любит вопросы о том, когда он закончит. Иногда руководитель проекта после нескольких дней настойчивых расспросов может получить в ответ жалостливое «хорошо, я постараюсь закончить завтра». Такая ситуация объясняется привычкой лидера запрашивать прогноз и затем оказывать давление.
✓ Есть руководители проектов, которые самостоятельно занимаются планированием, определяют основные задачи, переводят их в цифры и назначают сотрудникам своей команды. Если задачи не выполняются, как было запланировано руководителем, он может сколько угодно ворчать – участники команды будут говорить, что прогнозы не были реалистичными.
✓ В организациях, где ИТ находится на приличной дистанции от других отделов, можно говорить о недостатке доверия. Никто не верит датам, объявленным руководителем ИТ-проекта. В том числе и разработчики.
Scrum не обещает чудес и не предсказывает будущее!
Чтобы уменьшить уровень неопределенности, Scrum использует краткосрочное планирование. Позже мы увидим, что по необходимости можно строить планы и на среднесрочную перспективу. Но в этой главе наш горизонт – это спринт.
9.1 Зачем планировать спринт?
Планирование – это первое событие спринта. Оно позволяет добиться успеха, сосредоточившись на цели, которую команда сама разработала.
На самом деле, это не планирование в его первичном смысле. В результате события у команды не появляется подробного плана, где расписано, кто чем занимается на протяжении всего спринта.
Это пища для размышления в самом начале спринта, которая подкрепляет команду на пути к цели.
Это также ритуал, который готовит команду к совместной работе во время спринта – прямо как подготовка и наставления команде в раздевалке перед матчем по регби, чтобы игроки вышли на поле, объединенные общей целью.
Рисунок 9.1 – Единая цель команды
На английском планирование спринта звучит как sprint planning, а его результат – бэклог спринта, он же sprint backlog. Иногда этот термин употребляется и французами… Со своей стороны, я не использую бэклог спринта (с первого издания этой книги) по следующим причинам:
✓ использование этого термина порождает путаницу с другим бэклогом,
✓ в непрерывном потоке спринта не все истории с самого начала переходят в статус в процессе, его получают те, над которыми мы действительно работаем. А в бэклоге спринта в процессе оказываются сразу все истории, которые планируются к работе во время спринта.
В этом отличие от «Руководства по Scrum». По данному вопросу я скорее склоняюсь к позиции «Scrum3.0».
9.2 Принципы планирования
На самом деле в спринте участвует не команда, а истории.
Чтобы преуспеть в спринте, истории должны начинать забег со стартовых блоков. Это знак того, что они готовы.
Историю можно считать готовой, если она достаточно маленькая, все участники команды ее хорошо понимают и готовы ее завершить в течение спринта.
Доработка, проведенная во время предыдущего спринта, в принципе позволяет команде получить достаточно готовых историй (см. главу 7).
Во время спринта работа над историями идет непрерывным потоком. Истории стартуют так быстро, как только возможно, и участвуют в спринтерской гонке, пока не придут к финишу.
Коллективное планирование важнее результата: размышления и обсуждения во время этого ритуала объединяют команду.
Эта практика подчеркивает важную роль команды в разработке планов. Задачи команды принадлежат самой команде, это она решает, как организовать свою работу.
Планирование спринта – катализатор самоорганизации.
На этом этапе вовлекается Владелец продукта. Поскольку собрание может быть длительным и включать технические обсуждения, РО не сильно стремится присутствовать в начале, когда рассматривается что, а присоединяется на моменте исследования как. Тем не менее, очень важно, чтобы он остался и ответил на вопросы, которые команда непременно задаст. Обязательно, чтобы он присутствовал во время взаимодействия команды.
Заинтересованные стороны участвуют только по запросу команды – в частности, когда их содействие необходимо во время спринта. В принципе, это планируется в рамках доработки (это шестое К – какие риски?).
Планирование – событие, которое начинает спринт. Оно ограничено во времени, как и другие события спринта.
В ранее издававшихся публикациях о Scrum планирование спринта было представлено в двух частях: определение границ и цели спринта и определение необходимых задач и их оценка.
Раньше каждая из этих частей могла длиться полдня. Сегодня все иначе: со спринтами по 2–3 недели и более продвинутой техникой доработки бэклога, продолжительность собрания по планированию сильно сокращена, и само собрание может быть проведено всего один раз.
По моему опыту, собрание по планированию спринта длится менее двух часов. Это сохраняет мотивацию участников на протяжении собрания.
Непрерывный поток спринта влияет на сессию планирования: результат собрания обеспечивает команду достаточным количеством задач для начала спринта. Дополнительные задачи могут быть внесены по требованию во время спринта.
9.3 Результаты планирования спринта
Главный результат: команда концентрируется на своей цели в спринте.
В идеале, эта цель касается функциональности, уже известной заинтересованным сторонам и внесенной в бэклог поставки. Но завершено для функциональности не всегда будет совпадать с окончанием спринта. Поэтому следует разработать общую формулировку.
Например, для Peetic. Открыть интернет-магазин корма для домашних животных.
Это объект коммуникации.
✓ Фраза, которая его описывает, видна всей команде на протяжении спринта.
✓ Цель доводится до сведения заинтересованных сторон, которые будут знать, во что вовлечена команда.
Рисунок 9.2 – Две цели спринта
Эта цель касается продукта. Она сопровождается другой целью, выбранной на прошедшей ретроспективе (см. главу 12) и касающейся процесса (или кайдзена