Последствия. Команда быстро сталкивается с трудностями, связанными с накапливающимся техническим долгом.
Как сделать лучше? Scrum, и в частности, критерии завершенности, позволяют выявить проблемы – это одно из его главных преимуществ. Но усилия, необходимые для устранения технического долга, определяет сама команда.
Ситуация. Команда применяет практики в строгом соответствии с книжками и рассказами других.
Последствия. Участники рискуют быть отрезанными от реальности. То, что практика сработала для одного проекта, не значит, что она сработает в другом контексте.
Пример, рассказанный Хенриком Книбергом. В книге «Scrum и ХР: Заметки с передовой» он показал технику, которая называется
Рисунок 14.4 – Обратите внимание на деконтекстуализацию: счастливый обладатель новенькой книжки сразу хочет применить все знания на практике
Как сделать лучше? Как мы убедились, что нет строгого, сугубо теоретического Scrum. Четко определен только фреймворк. Все проекты разные, отличаются контекстами и реализацией практик.
Ситуация. Команде не удается применить Scrum. Участники говорят себе, что не все получается сразу. Поэтому они внедряют Scrum постепенно, используют фрагменты разных практик. Исходя из принципа, что Scrum адаптируется, команда вводит в работу только то, что просто.
Иногда я вижу команды, которые ввели Scrum без предварительного обучения или помощи со стороны. Чаще всего от Scrum в их работе только схватки и спринты.
Последствия. Полученные результаты разочаровывают. Улучшения нет – особенно, если команда забывает или игнорирует ретроспективы.
Как сделать лучше? В Agility много опциональных практик, это правда, но Scrum – это цельный фреймворк, который нельзя разбивать на части и использовать только то, что удобно и просто.
Мы уже поговорили о Shu Ha Ri, и эту ситуацию можно резюмировать концепцией Shu, первой фазы:
Команда следует Scrum-практикам, фреймворк не подлежит обсуждению. Команда должна адаптировать практики под контекст.
Ситуация. Для сохранения бэклога команда использует информационные технологии. Scrum адаптируется к этим инструментам.
Последствия. Теряются все преимущества визуального управления.
Как сделать лучше? Нужно подождать несколько спринтов, прежде чем решить, действительно ли нужны эти инструменты.
Чтобы идти дальше
Онлайн-ресурсы
‣ Philippe Kruchten, The Context of Software Development, Web, 2009
‣ James Shore, Diana Larsen, Your Path through Agile Fluency, Web, 2018
Ранее мы изучили, как структурировать и регулярно дорабатывать бэклог. Бэклог – система из упорядоченных, взаимосвязанных элементов, постоянно пополняемая новыми записями и завершенными историями.
Этот механизм регулирования позволяет бэклогу развиваться на протяжении длительного времени и во благо экосистемы.
Однако бэклог не появляется сам по себе. Для его создания нужны определенные условия, регулирующие обратную связь.
В этой главе представлены идеи для разработки первоначального бэклога.
Прелюдия может начинаться в самых разных условиях. Все команды стартуют с разных точек. Это может быть спецификация на несколько десятков страниц, MVP или вообще ничего. Вариантов целое множество – и от них зависит способ разработки первоначального бэклога. С другой стороны, есть несколько очень хороших книг, к примеру, авторства Джеффа Паттона – по определению продукта в Agile-фреймворке. По этой причине мы ограничимся тем, что перечислим паттерны, которые могут пригодиться при создании бэклога. В зависимости от контекста они будут полезны во время прелюдии (см. главу 13).
В этой главе почти все имеет опциональный характер. Все, что требуется, – это иметь первоначальный бэклог, чтобы приступить к первому спринту. Бэклог станет источником задач для участников команды.