Текст книги "Все о SCRUM. Изучение, разработка, интеграция"

6.6 Антипаттерны

6.6.1 Огромный бэклог

Ситуация. Бэклог содержит абсолютно все задачи к выполнению – значит, он включает в себя все идеи и баги. Получается более сотни элементов разного размера и статуса.

Последствия. Владелец продукта потерялся в бэклоге, не говоря уже об участниках команды. Приоритизация отсутствует.

Как сделать лучше? Постараться применить предложенные паттерны, особенно паттерн лотков.

6.6.2 Бэклог тикетов

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

Последствия. Два источника задач для команды, хаос.

Как сделать лучше? Сделать бэклог уникальным списком задач (одно из свойств бэклога).

6.6.3 Спрятанный бэклог

Ситуация. Владелец продукта при приоритизации элементов бэклога использует инструмент типа электронных таблиц.

Последствия. Никто не видит бэклог, кроме самого Владельца продукта.

Как сделать лучше? Перед тем, как принять решение о пользе и преимуществах инструмента, попробовать перейти к визуальному менеджменту.

6.6.4 Призрачная работа

Ситуация. Исходя из принципа, что бэклог создается для продукта, в него входит только то, что напрямую касается самого продукта. Таким образом, команда иногда работает над элементами, которые не внесены в бэклог.

Последствия. Владелец продукта и заинтересованные стороны не знают об этом. Отсутсвует прозрачность.

Как сделать лучше? Вносить в бэклог все, даже если есть сомнения по поводу связи элемента бэклога и продукта. Использовать паттерн «сториотип», чтобы классифицировать истории.

6.6.5 Несколько бэклогов для команды

Ситуация. Многие организации, переходящие к 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 Критерии готовности

7.2.1 Готовый Бэклог

Цель доработки – бэклог с достаточным количеством готовых историй.

Чтобы понять, какое количество является достаточным, можно ориентироваться на результаты предыдущих спринтов.

Пример: Команда Peetic за спринт завершает в среднем 10 историй. Прийти к концу спринта с десятком готовых историй для нее будет оптимально.

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

Доработка касается двух частей бэклога и применима как к функциям, так и к историям.

7.2.2 Готовая история

Неотъемлемой частью работы команды является прохождение через этап готово, а затем и завершено. Нельзя утверждать, что история готова на 100 % – это всегда зависит от команды. Только она может решить, готова ли история. Чтобы принять это решение, она может положиться на критерии готовности.

Критерии готовности – это список рекомендаций. Внимание: он не содержит элементов управления, применимых ко всем историям без разбора. Это рекомендации, которые требуют оценки.

Какие именно рекомендации? Команды иногда опираются на давнюю статью (2003) Билла Уэйка, в которой он говорит об акрониме INVEST. Статья была написана еще до популяризации критериев готовности, поэтому неуместно адаптировать нашу концепцию в соответствии с ней. Я предлагаю использовать рекомендации, которые формируют паттерн 6К.

• Паттерн 6К

Команды, только приступившие к определению критериев готовности, могут использовать этот паттерн. Согласно ему участники должны задать себе несколько вопросов. Ответ будет зависеть от контекста. То, что получится, и станет рекомендациями, которые помогут команде принять решение о готовности истории.

Рисунок 7.2 – 6К

✓ Какой вклад приносит история: что именно и кому?

✓ Как хорошо она разложена на части: достаточно ли она маленькая?

✓ Было ли коллективное обсуждение: как хорошо историю проговорили?

✓ Возможен ли краткий обзор: сможем мы использовать ее для демонстрации во время обзора?

✓ Обладает ли она критериями завершенности: чтобы она была готова, хорошо бы знать критерии ее завершенности.

✓ Какие риски: есть ли риски в реализации этой истории? Есть возможность их минимизировать?

• Пример контекстуализации 6К

Пример Peetic. История добавить маршрут выгула собак проверена паттерном 6К (таблица 7.1).

Этот паттерн полезен для направления обсуждения во время доработки. Иногда в фокусе разговора связанные с историей данные (например, условия приемки), которые будут изучены с точки зрения качества.

7.2.3 Готовая функциональность

Концепция готовой функциональности эквивалентна готовой истории. Но с одним нюансом: она не переходит из готовой в завершенную за один спринт. Цель остается той же: снизить риски, прежде чем вкладывать огромные средства в разработку.

Исходя из этого, паттерн 6К, соответственно адаптированный, может применяться и для функциональности:

✓ чтобы оценить, есть ли вклад, необходимо попытаться подтвердить гипотезу о влиянии на пользователя,

✓ декомпозиция будет заключаться в нахождении наименьшей функциональности, которая способна привнести этот вклад,

✓ заинтересованные стороны будут сильнее вовлечены в обсуждение.

Для проверки гипотезы может потребоваться, чтобы соответствующие истории уже были завершены – если подходить с научной точки зрения, как в Lean Startup.

Для минимизации усилий необходимо иметь хорошее представление об историях. Это подразумевает участие всей команды.

Решение о готовности функциональности остается за Владельцем продукта, который в свою очередь опирается на мнение команды и заинтересованных сторон. Их может представлять один человек, с которым Владелец продукта чаще всего контактирует по вопросам продукта.

7.3 Доработка – командная работа

7.3.1 Зачем? Чтобы обеспечить успех будущих спринтов

Доработка бэклога осуществляется командой во время спринта с целью обеспечить успех следующих спринтов.

Доработанный бэклог позволяет начать следующий спринт в улучшенных условиях. В частности, избежать переутомления при планировании спринта и создать атмосферу, в которой участники будут сами свободно вовлекаться в процесс.

7.3.2 С кем? С командой и ее границами

Очевидно, что Владелец продукта является главным действующим лицом при доработке бэклога.

Чаще всего он привлекает к этому процессу команду: большая часть работы состоит из разговоров с участниками. Рекомендуется, чтобы вся Scrum-команда участвовала в доработке.

Заинтересованные стороны приглашаются по мере необходимости. Команда призывает к участию и экспертов, когда приступает к обсуждению моментов, по которым нужна консультация.

В процессе доработки бэклога поставки Владелец продукта привлекает больше заинтересованных сторон. У него может быть привилегированный собеседник.

7.3.3 Когда? Во время сессии доработки

Желательно, чтобы доработка носила постоянный характер и проходила в рамках командной работы – например, во время собрания по доработке бэклога.

Таким образом, доработка связана со Scrum-подходом, как и события спринтов, и нет необходимости в ее специальном включении в бэклог.

Есть два возможных варианта проведения собрания по доработке:

✓ Регулярное. Например, по средам. Это самый простой вариант для новичков в Scrum.

✓ По запросу. Scrum-мастер следит за готовностью историй, и в случае их недостатка организует собрание по доработке бэклога (см. главу 20 «Применение Kanban в Scrum»).

Разумно поступает команда, которая посвящает 2 часа в неделю коллективной доработке, что составляет чуть более 5 % ее рабочего времени. В оставшейся части главы мы подробнее рассмотрим случай, когда доработка проводится в рамках заранее запланированных собраний.

Собрание по доработке проходит по крайней мере один раз за спринт. Количество сессий зависит от длины спринта.

Для начала, и даже для двухнедельных спринтов, я рекомендую планировать два собрания. В таком случае во время второго собрания можно сфокусироваться на основной цели, чтобы было достаточно готовых историй к следующему спринту.

7.3.4 С чем? Со структурированным бэклогом

Наличие структурированного бэклога облегчает работу по его доработке.

✓ Учитывая, что цель состоит в своевременном наличии готовых историй, выделение этих историй в бэклоге облегчает их отслеживание.

✓ Идеи, запросы, обратная связь, которые Владелец продукта еще не обработал, находятся в песочнице.

Другие истории находят свое место в доработке естественным образом. Итак, у нас есть одно место для доработки и еще два для ожидающих задач, до и после доработки.

Рисунок 7.3 – Доработка рабочего бэклога

Доработка бэклога поставки происходит на более высоком уровне.

7.4 Результат доработки

7.4.1 Готовый бэклог

Доработка является причиной перемещений историй и функциональностей внутри бэклога. Некоторые переходят в статус готово. Другие, которые были в песочнице, передвигаются на этап доработки. Какие-то убираются, делятся на части и т. д.

Готовая история должна быть маленькой и предельно понятной – такой, чтобы была возможность быстро ее закончить и получить обратную связь.

Готовая функциональность должна иметь минимальные риски или не иметь их вовсе.

7.4.2 Доверительные отношения с экосистемой

Команда лучше всех знает, что запланировано на следующие спринты. Благодаря коллективному обсуждению, она укрепляет доверительные отношения с Владельцем продукта и заинтересованными сторонами. Она вовлекается в работу после изучения доступных вариантов.

Рисунок 7.4 – Поток в рабочем бэклоге

Владелец продукта уверен в способности команды разрабатывать элементы, которые были доработаны вместе с ним.

Заинтересованные стороны видят – в частности, благодаря бэклогу поставки – что команда планирует к разработке.

Планирование следующего спринта (глава 9) будет проще и быстрее. Разработка среднесрочного плана (глава 16) также значительно облегчается.

7.5 Доработка рабочего бэклога

Детали и порядок работы, выполняемой во время доработки, зависят от ситуации. Вот возможная последовательность действий и паттернов:

1. Просмотреть список готовых историй. Если их недостаточно, подготовка новых историй – первоочередная задача. (П).

2. Изучить те, что находятся на доработке, чтобы выявить epics и разложить их на части. (Р).

3. Проанализировать песочницу и kanban-таблицу функциональностей с целью обновления списка историй к доработке. (О).

4. Выбрать, что можно удалить. (В).

5. Единогласно решить, что остается на этот сезон, а что уйдет в следующий. (Е).

6. Рассмотреть новые или разложенные элементы (Р).

7. Классифицировать истории в лотке доработки. (К).

Рисунок 7.5 – Доработка

Из описанной последовательности получается акроним ПРОВЕРКа. На практике действия не последовательны: иногда образуются петли и появляются дополнительные пункты.

7.5.1 Подготовка новых историй

Есть ли необходимость в заранее готовых историях? Если да, команда рассматривает наиболее приоритетные истории в лотке доработки.

Разговор с РО должен снабдить команду знаниями. Решение о готовности истории принимается, когда команда считает, что риски не закончить ее во время спринта уменьшены. Участники опираются на критерии готовности.

Если применить паттерн 6К, обсуждение будет сфокусировано на К, которых не хватает в истории, чтобы счесть ее готовой – в частности, на возможности краткого обзора во время демо и определения и обсуждении рисков, стоящих перед командой.

• Возможность краткого обзора на демо с условиями приемки

Первое, о чем стоит подумать: как провести демо? того, что команда собирается показать во время демонстрации этой истории. Можно представить сценарий и продумать условия приемки.

Пример истории запись на выставку». Можно определить условие успеха:

✓ Заявка принята – запись собаки на выставку прошла успешно.

Другое условие – условие неудачи.

✓ Заявка отклонена – запись не удалась, достигнут предел допустимых заявок.

Второе условие может соотноситься с той же историей или входить в другую, новую. Это искусство декомпозиции истории.

• А дальше – BDD

Условие приемки относится к исполнению истории. Поведение истории во время ее реализации зависит от начального состояния и параметров исполнения. Практика BDD (Behaviour Driven Development) позволяет описать это поведение на примере программируемого устройства.

Каждый тест формально состоит из трех элементов:

✓ состояние перед исполнением теста (речь о контексте теста);

✓ событие, которое запускает исполнение истории;

✓ состояние после реализации (речь об ожидаемом результате).

Формально, текстовая структура BDD выглядит следующим образом:

✓ Дано – контекст и последствие контекста.

✓ Когда – событие.

✓ Тогда – результат и другой результат.

На английском это Given When Then.

Такой способ работы особенно подходит для интерактивных приложений. Он делает возможными короткие и быстрые тесты, так как описывается реакция только на одно событие – то, что запускает историю.

Пример истории заявка на оформление регистровой родословной для собаки

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

Можно использовать BDD для условия принятия:

Дано: хозяин породистой собаки и событие оформления регистровой родословной для данной породы.

Когда: хозяин записывает собаку соответствующего возраста на оформление регистровой родословной.

Тогда: он проинформирован о своей заявке и количество заявок увеличено.

Советую прописывать пункт дано в прошлом, когда в настоящем и тогда в будущем времени.

• Риски сведены к минимуму

Обсуждение рисков может иметь технический характер.

Часто команда задумывается над концепцией истории, чтобы снизить риски ее реализации.

И продолжает в таком духе, пока не будет достаточно готовых историй.

Это очень важно: в случае, если к следующему спринту не будет достаточно готовых историй, команда потратит на это столько времени, сколько ей потребуется.

7.5.2 Разложение на части

Истории, которые должны быть разложены на части в первую очередь – это истории, которые пойдут в работу во время следующего спринта или спринта за ним.

Понимание, насколько необходимо разбить данную историю и как именно это сделать, требует опыта. Команде в этом поможет паттерн разделение.

• Паттерн «Разделение»

Этот паттерн предлагает 9 возможных путей для размышлений о декомпозиции истории.

Рисунок 7.6 – Паттерн «разделение истории»

Ниже примеры основных направлений.

Вариации на тему Данных

Пример истории добавить питомца в мой профиль

Если система предполагает разных питомцев и возможность создания истории различна для каждого вида, то создется так много историй, сколько питомцев есть в системе: добавить собаку, добавить кошку (не надо выгуливать), добавить хамелеона (без фото) и т. д.

Разработчики рискуют переделывать всю работу, если с самого начала не задумываются об универсальном дизайне. Ничто не мешает подумать об этом с самой первой истории.

Разложение на части по бизнес-правилам

В случае, если правила ограничивают доступ к функции, можно определить историю, которая игнорирует эти правила, а затем другие истории, чтобы их принять. Первая история позволяет обучиться, она приносит ценность знаний.

Пример. Можно предложить поиск предков породистой собаки, но зарезервировать эту услугу за владельцами собак, которые приобрели корм для питомца за 100 € и являются членами клуба Peetic более одного года.

Первая история. Найти предков моей собаки.

Вторая история. Ограничить поиск только для авторизованных лиц.

Оптимизация, отличная от производительности

В случае, если история слишком большая, команда не сможет ее завершить за один спринт и при этом ничем особо не рискует – можно попробовать сделать ее за первый спринт, не беспокоясь о производительности. Затем, уже в следующем спринте, заняться другой историей о нефункциональных требованиях.

Пример. Первая история касается поиска. Ее цель – сначала предоставить результаты. Затем другая – цель уже в оптимизации поиска, например, чтобы результаты отображались менее чем за две секунды.

Spike

Если разработчики отмечают, что для создания истории есть несколько технических решений, есть смысл разложить ее на две части: первая – для изучения решений и выбора одного из них, вторая – для реализации с выбранным решением.

Исследование под названием spike, или шип [28]28
  Также используется термин «пик». Это изобретение экстремального программирования (XP), особый тип пользовательской истории, который используется для получения знаний, необходимых для снижения риска технического подхода, лучшего понимания требований или повышения надежности оценки истории. Спайк – отличный способ снизить риски на раннем этапе и позволяет команде получить обратную связь и развить понимание сложности предстоящего PBI. – Прим. ред.


[Закрыть], помогает снизить риски при ее реализации.

7.5.3 Обновление списка историй к доработке

Начиная с этапа песочницы, Владелец продукта и команда обсуждают, что делать с предложениями. Варианты следующие:

1. переместить идею на этап доработки, чтобы включить в текущий сезон;

2. удалить ее;

3. решить, что это предложение больше истории, а то и epic истории, и переместить ее в kanban-таблицу функциональностей.

Рисунок 7.7 – Выход из песочницы

7.5.4 Очистка бэклога

Нужно регулярно чистить бэклог.

Идеи того, какие задачи еще можно включить в бэклог, обычно идут потоком и предполагают куда больше работы, чем может позволить себе команда.

Новые идеи представляют собой цикл обратной связи. Если ничего не делать, бэклог будет постоянно увеличиваться.

Элементы, которые застаиваются в конце списка, являются первыми кандидатами на удаление.

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

7.5.5 Решение, что остается на этот сезон, а что уходит в следующий

Принцип паттерна ледяного лотка состоит во временной очистке историй, чтобы во время доработки более четко увидеть текущую ситуацию. Паттерн позволяет визуально уменьшить количество историй на этапе доработки.

Паттерн касается команд, у которых темп сезона задается благодаря вводу в эксплуатацию. В конце каждого сезона безусловно остаются истории, которые уходят в разработку на следующий сезон. Их можно заморозить в ледяном лотке до нужного момента, чтобы не тратить на них время сейчас.

Истории, находящиеся в ледяном лотке, заморожены до следующего сезона. Когда он начнется, эти истории будут разморожены и вернутся на этап доработки.

Суть паттерна не в том, чтобы поместить в ледяной лоток все запросы, которые не были приняты РО. Ледяной лоток – не мусорка. По решению Владельца продукта ненужные запросы безжалостно удаляются. Только те истории, что представляют интерес для следующего сезона, будут заморожены в ледяном лотке. Период заморозки длится несколько недель. Ледяной лоток необходимо очищать в начале каждого нового сезона.

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

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

7.5.6 Оценка новых или разложенных элементов

Это действие опционально и касается добавленных или разложенных историй со времени последней сессии доработки. Команда должна решить, не слишком ли история большая и стоит ли ее разбить на части.

Оценка помогает команде сделать прогноз на сезон.

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

Рисунок 7.8 – Оценка усилий

Другие проблемы и способы оценки мы рассмотрим в главах 16 «Планирование на среднесрочную перспективу» и 18 «Наглядность при помощи индикаторов».

7.5.7 Классификация историй в лотке доработки

При добавлении элементов к доработке можно их сразу упорядочивать в списке. Новые элементы не всегда помещаются в конец списка.

Владелец продукта самостоятельно изучает порядок и представляет его команде для обсуждения, которое будет включать стоимость и зависимости.

Иногда участники настаивают на высокой приоритизации технической работы, которая кажется им наиболее важной. Вся команда участвует в приоритизации, но в случае разногласий окончательное решение – за Владельцем продукта.

Количество историй в доработке не должно увеличиваться (не более двадцати-тридцати элементов). Их порядок обновляется на каждом совещании, благодаря этому сам процесс упорядочивания не занимает много времени.

Порядок (или порядковый приоритет) соответствует последовательности реализации историй. Порядок историй основан на порядке функциональностей. Так как мы стремимся быстро закончить функциональность, составляющие ее истории остаются связанными.

Между историями могут быть зависимости, которые влияют:

✓ на другие истории,

✓ на людей, которые могут реализовать историю,

✓ на сроки.