Как только бóльшая часть долга будет погашена, необходимо принять меры, чтобы в дальнейшем не оказаться в такой ситуации. В этом цель критериев завершенности.
Пример погашения технического долга. Переписать нерабочий код, отвечающий за загрузку.
Выявление технического долга и работа по его погашению – один из шагов на пути устойчивого развития.
6.6 Антипаттерны
Ситуация. Бэклог содержит абсолютно все задачи к выполнению – значит, он включает в себя все идеи и баги. Получается более сотни элементов разного размера и статуса.
Последствия. Владелец продукта потерялся в бэклоге, не говоря уже об участниках команды. Приоритизация отсутствует.
Как сделать лучше? Постараться применить предложенные паттерны, особенно паттерн лотков.
Ситуация. Исходя из принципа, что бэклог является списком задач для команды, создается бэклог не только для историй, но и для всех тикетов из багтрекера, которым команда пользуется уже несколько лет.
Последствия. Два источника задач для команды, хаос.
Как сделать лучше? Сделать бэклог уникальным списком задач (одно из свойств бэклога).
Ситуация. Владелец продукта при приоритизации элементов бэклога использует инструмент типа электронных таблиц.
Последствия. Никто не видит бэклог, кроме самого Владельца продукта.
Как сделать лучше? Перед тем, как принять решение о пользе и преимуществах инструмента, попробовать перейти к визуальному менеджменту.
Ситуация. Исходя из принципа, что бэклог создается для продукта, в него входит только то, что напрямую касается самого продукта. Таким образом, команда иногда работает над элементами, которые не внесены в бэклог.
Последствия. Владелец продукта и заинтересованные стороны не знают об этом. Отсутсвует прозрачность.
Как сделать лучше? Вносить в бэклог все, даже если есть сомнения по поводу связи элемента бэклога и продукта. Использовать паттерн «сториотип», чтобы классифицировать истории.
Ситуация. Многие организации, переходящие к Scrum, действуют по схеме, в которой одна команда работает над несколькими проектами одновременно. Для каждого проекта свой бэклог.
Последствия. Невозможно приоритезировать задачи. Мультизадачность мешает работе.
Как сделать лучше? Лучше, если команда целиком и полностью посвящена одному проекту. Все вносится в единственный, уникальный бэклог, его по ходу работы составляет Владелец продукта.
Чтобы идти дальше
Книги
‣ Джефф Паттон, «Пользовательские истории. Искусство гибкой разработки ПО», Питер, 2017
‣ Dan Rawsthorne, Doug Shimp, «Exploring Scrum, The Fundamentals», CreateSpace Independent Publishing Platform, 2011
7Доработка бэклога
С появлением Scrum в наших краях понятие бэклога заиграло новыми красками, чему несказанно обрадовались любители историй. В корзину отправились большие технические документы, истории пришли им на смену. Мы зафиксировали все задачи на post-it и приступили к работе.
Возможно, все зашло слишком далеко. Команды рассчитывают завершить к концу спринта определенное количество историй, но зачастую им это не удается.
Можно заметить, что команды начали спринт с историй, которые они плохо знали или которые были слишком большими. Вполне вероятно, что завершить их у команд не получится.
Эти истории не были готовы, не были хорошо доработаны.
Доработка – это аккуратный баланс между определением всего и бездействием перед началом спринта. Это снижающий риски минимум.
Доработка – это повторяющаяся деятельность, которая заключается в поддержании бэклога в готовности, чтобы повысить шансы на успех будущих спринтов.
7.1 Прямо как сыр?
В английском языке ранее использовался термин груминг. В первом издании этой книги я перевел его глаголом причесывать: Владелец продукта причесывает бэклог. В третьем издании я изменил перевод на Владелец продукта культивирует бэклог и говорил о лотке культивации. Между тем, в маленьком «Руководстве по Scrum» версии 2013 года появился термин refinement».
Я использую перевод доработка начиная с четвертого издания.
Внимание! Доработать бэклог – не значит красиво обклеить его Post-it®, и все.
Бэклог дорабатывается, как сыр.
Искусство доработки для Scrum-команды заключается в приготовлении историй в нужный момент.
Рисунок 7.1 – Очень долгая доработка может навредить
7.2 Критерии готовности
Цель доработки – бэклог с достаточным количеством готовых историй.
Чтобы понять, какое количество является достаточным, можно ориентироваться на результаты предыдущих спринтов.
Пример: Команда Peetic за спринт завершает в среднем 10 историй. Прийти к концу спринта с десятком готовых историй для нее будет оптимально.
Scrum-подход, непрерывный поток по определению, занижает это количество и побуждает команду иметь достаточно готовых историй на протяжении всего спринта, а не только к его концу.
Доработка касается двух частей бэклога и применима как к функциям, так и к историям.
Неотъемлемой частью работы команды является прохождение через этап готово, а затем и завершено. Нельзя утверждать, что история готова на 100 % – это всегда зависит от команды. Только она может решить, готова ли история. Чтобы принять это решение, она может положиться на критерии готовности.
Критерии готовности – это список рекомендаций. Внимание: он не содержит элементов управления, применимых ко всем историям без разбора. Это рекомендации, которые требуют оценки.
Какие именно рекомендации? Команды иногда опираются на давнюю статью (2003) Билла Уэйка, в которой он говорит об акрониме INVEST. Статья была написана еще до популяризации критериев готовности, поэтому неуместно адаптировать нашу концепцию в соответствии с ней. Я предлагаю использовать рекомендации, которые формируют паттерн 6К.
• Паттерн 6К
Команды, только приступившие к определению критериев готовности, могут использовать этот паттерн. Согласно ему участники должны задать себе несколько вопросов. Ответ будет зависеть от контекста. То, что получится, и станет рекомендациями, которые помогут команде принять решение о готовности истории.
Рисунок 7.2 – 6К
✓ Какой вклад приносит история: что именно и кому?
✓ Как хорошо она разложена на части: достаточно ли она маленькая?
✓ Было ли коллективное обсуждение: как хорошо историю проговорили?
✓ Возможен ли краткий обзор: сможем мы использовать ее для демонстрации во время обзора?
✓ Обладает ли она критериями завершенности: чтобы она была готова, хорошо бы знать критерии ее завершенности.
✓ Какие риски: есть ли риски в реализации этой истории? Есть возможность их минимизировать?
• Пример контекстуализации 6К
Пример Peetic. История добавить маршрут выгула собак проверена паттерном 6К (таблица 7.1).
Этот паттерн полезен для направления обсуждения во время доработки. Иногда в фокусе разговора связанные с историей данные (например, условия приемки), которые будут изучены с точки зрения качества.
Концепция готовой функциональности эквивалентна готовой истории. Но с одним нюансом: она не переходит из готовой в завершенную за один спринт. Цель остается той же: снизить риски, прежде чем вкладывать огромные средства в разработку.
Исходя из этого, паттерн 6К, соответственно адаптированный, может применяться и для функциональности:
✓ чтобы оценить, есть ли вклад, необходимо попытаться подтвердить гипотезу о влиянии на пользователя,
✓ декомпозиция будет заключаться в нахождении наименьшей функциональности, которая способна привнести этот вклад,
✓ заинтересованные стороны будут сильнее вовлечены в обсуждение.
Для проверки гипотезы может потребоваться, чтобы соответствующие истории уже были завершены – если подходить с научной точки зрения, как в Lean Startup.
Для минимизации усилий необходимо иметь хорошее представление об историях. Это подразумевает участие всей команды.
Решение о готовности функциональности остается за Владельцем продукта, который в свою очередь опирается на мнение команды и заинтересованных сторон. Их может представлять один человек, с которым Владелец продукта чаще всего контактирует по вопросам продукта.
7.3 Доработка – командная работа
Доработка бэклога осуществляется командой во время спринта с целью обеспечить успех следующих спринтов.
Доработанный бэклог позволяет начать следующий спринт в улучшенных условиях. В частности, избежать переутомления при планировании спринта и создать атмосферу, в которой участники будут сами свободно вовлекаться в процесс.
Очевидно, что Владелец продукта является главным действующим лицом при доработке бэклога.
Чаще всего он привлекает к этому процессу команду: большая часть работы состоит из разговоров с участниками. Рекомендуется, чтобы вся Scrum-команда участвовала в доработке.