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

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

Рисунок 15.1 – Коллективная разработка первоначального бэклога

К этому моменту Scrum-команда уже должна быть сформирована и участвовать в совещаниях.

15.1.3 Когда разрабатывать первоначальный бэклог?

• Во время прелюдии

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

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

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

• В конце сезона

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

15.2 Системологический подход

О сложности говорится в первом предложении Руководства по Scrum:

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

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

15.2.1 Понятия

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

• Цель сезона

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

Для разработки первоначального бэклога нужно какое-то временное ограничение. Сезон – вполне премлемый отрезок времени.

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

• Воздействие

Традиционные методы определения продукта связаны с потребностями пользователей. Понятие воздействия выходит за рамки идеи потребности пользователя и фокусируется на его поведении.

Воздействие – это изменение в поведении заинтересованной стороны.

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

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

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

• Риск

Риск – это событие, которое может произойти и поставить под угрозу цель сезона.

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

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

15.2.2 Подход

Бэклог в первую очередь описывает поведение системы. Это ответ на вопрос что.

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

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

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