Рисунок 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
15Разработка первоначального бэклога
Ранее мы изучили, как структурировать и регулярно дорабатывать бэклог. Бэклог – система из упорядоченных, взаимосвязанных элементов, постоянно пополняемая новыми записями и завершенными историями.
Этот механизм регулирования позволяет бэклогу развиваться на протяжении длительного времени и во благо экосистемы.
Однако бэклог не появляется сам по себе. Для его создания нужны определенные условия, регулирующие обратную связь.
В этой главе представлены идеи для разработки первоначального бэклога.
15.1 Бэклог: от и до
Прелюдия может начинаться в самых разных условиях. Все команды стартуют с разных точек. Это может быть спецификация на несколько десятков страниц, MVP или вообще ничего. Вариантов целое множество – и от них зависит способ разработки первоначального бэклога. С другой стороны, есть несколько очень хороших книг, к примеру, авторства Джеффа Паттона – по определению продукта в Agile-фреймворке. По этой причине мы ограничимся тем, что перечислим паттерны, которые могут пригодиться при создании бэклога. В зависимости от контекста они будут полезны во время прелюдии (см. главу 13).
В этой главе почти все имеет опциональный характер. Все, что требуется, – это иметь первоначальный бэклог, чтобы приступить к первому спринту. Бэклог станет источником задач для участников команды.
Владелец продукта играет важную роль в определении продукта. Но желательно, чтобы разработка бэклога была коллективной и проходила во время рабочих встреч с заинтересованными сторонами. На раннем этапе целесообразно приглашать представителей бизнеса, маркетинга: их присутствие позволит заполучить разные точки зрения на продукт.
Рисунок 15.1 – Коллективная разработка первоначального бэклога
К этому моменту Scrum-команда уже должна быть сформирована и участвовать в совещаниях.
• Во время прелюдии
В предыдущей главе мы узнали, что это одна из задач прелюдии. Разработка происходит в форме рабочих собраний, оптимально провести не менее двух таких встреч по полдня каждая.
Содержание бэклога сперва используется для проверки способности команды приступить к спринту: она может извлечь одну из историй и реализовать ее.
Первоначальный бэклог служит отправной точкой для первого сезона и запускает непрерывный рабочий поток с регулярными сессиями доработки.
• В конце сезона
Можно вернуться к бэклогу в конце сезона – вместе со всем, что представлено в этой главе, чтобы дополнить содержимое бэклога новыми функциональностями. Это станет поводом для определения цели на предстоящий сезон. Но мы в дальнейшем будем рассматривать первый вариант – тот, в котором разработка бэклога проходит на этапе прелюдии.
15.2 Системологический подход
О сложности говорится в первом предложении Руководства по Scrum:
Скрам – это фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов.
Оптимизация системы характеризуется принципом максимальный эффект при минимальных усилиях. Это то, в чем помогают предложенные понятия и подход.
Для создания первоначального бэклога предлагаю добавить три понятия: цель, воздействие на заинтересованные стороны и риск – в дополнение к функциям, историям и заинтересованным сторонам, которые у нас уже были.
• Цель сезона
Определенное во время прелюдии предназначение задает курс экосистемы, никак при этом не указывая на конкретные даты. Заинтересованные стороны также определяются бессрочно.
Для разработки первоначального бэклога нужно какое-то временное ограничение. Сезон – вполне премлемый отрезок времени.
Таким образом, цель будет состоять в следовании предназначению на следующий период, в данном случае, на следующий сезон.
• Воздействие
Традиционные методы определения продукта связаны с потребностями пользователей. Понятие воздействия выходит за рамки идеи потребности пользователя и фокусируется на его поведении.
Воздействие – это изменение в поведении заинтересованной стороны.
На этом уровне мы еще не углубляемся в сторону решения. Мы не предопределяем возможности. По сути, можем воздействовать, не занимаясь разработкой.
Воздействие ходить на встречи во время выгула моей собаки может быть достигнуто рассылкой писем, включающих бланк записи – минуя разработку специального технического решения.
Мы определим, какое воздействие на заинтересованные стороны позволит достичь цель сезона. Разумеется, это только гипотезы, которые попробуем подтвердить в самом скором времени.
• Риск
Риск – это событие, которое может произойти и поставить под угрозу цель сезона.
Мы постоянно сталкиваемся с рисками. Фактически, Agility – это подход, заключающийся в снижении рисков практическим путем. То, что при высокой ценности несет наибольшие риски, помещается в начало бэклога в качестве самых приоритетных задач.
Следовательно, понятие риска, функционального или технического, имеет важное значение при разработке первоначального бэклога.
Бэклог в первую очередь описывает поведение системы. Это ответ на вопрос что.
Как мы убедились, невозможно все знать с самого начала. Так и в первоначальном бэклоге нет детального описания всей предстоящей работы. Это одна из причин, по которой, в соответствии с паттерном поставки/работы, у нас есть уровень описания, оставляющий место для маневра.
Важные фунциональности – те, что несут высокую ценность, но не очень понятны команде – нужно запускать в работу в первую очередь, чтобы избежать функциональных рисков.
Но чтобы создать первоначальную версию бэклога сложного продукта, нужно также ответить на вопросы зачем и как.
Ответ на почему помогает команде понять, что делать. Представление о том, как реализовать решение, помогает расставить приоритеты при ответе на что, и, следовательно, упорядочить первоначальный бэклог.
Рисунок 15.2 – Три новых понятия и рабочие совещания
Внимание. Может показаться, что в представленном подходе мы идем только сверху вниз, от идей к историям. Это не так, движение возможно и снизу вверх.
• Цель и воздействие – помощники в понимании проблемы
На этапе прелюдии, а именно во время определения предназначения экосистемы, мы уже задавались главным вопросом почему. Мы также ответили на вопрос кто, определив заинтересованные стороны (см. главу о прелюдии).
При создании первоначального бэклога будет полезно дать ответ на вопрос почему в отношении экосистемы и продукта, чтобы определить цель на сезон.
Ответ на вопрос, каким образом заинтересованные стороны способствуют достижению цели, позволяет определить ожидаемое воздействие. Внимание: речь о реальной жизни, а не о программном обеспечении!
• Решение, соответствующее проблеме
Знание проблемы позволяет найти подходящее решение. Функциональность способствует достижению нужного воздействия. Это отвечает на вопрос что, какие функции предлагаются нашей системой.
Нужно углубиться в рассуждении на вопрос как, чтобы разобраться в приоритетах. Говоря о первоначальном бэклоге, мы интересуемся снижением неопределенности – доказательство того, что рассматриваемые компоненты хорошо вместе функционируют. Другими словами, снижение технических рисков.