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

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

6.5.4 Погашение технического долга

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

Рисунок 6.9 – Попытка объяснить Владельцу продукта, что нужно сократить задолженность

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

В 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 Прямо как сыр?