3

РАБОТА С БЭКЛОГОМ ПРОДУКТА

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

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

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

ГЛУБИННЫЕ СВОЙСТВА БЭКЛОГА ПРОДУКТА

Элементы бэклога продукта обладают четырьмя свой­ствами: имеют достаточную степень детализации, оценены, независимы и приоритизированы — в английском языке получается удобная аббревиатура DEEP (от detailed, estimated, emergent, prioritized) — глубинный. Рассмотрим эти свойства подробнее.

ДОСТАТОЧНАЯ СТЕПЕНЬ ДЕТАЛИЗАЦИИ

Элементы бэклога продукта имеют достаточную степень детализации, это показано на рисунке 3.1. Элементы с более высоким приоритетом описаны подробнее, чем менее важные. «Чем ниже приоритет, тем меньше деталей, вплоть до полного минимума», — пишут Швабер и Бидл (Schwaber and Beedle, 2002; 33). Следуя этому правилу, вы сохраняете бэклог продукта минималистичным, а его элементы — реализуемыми в течение спринта. В результате требования выявляются, декомпозируются и детализируются в течение всего проекта.

ОЦЕНКА

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

РАЗВИТИЕ

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

ПРИОРИТЕТНОСТЬ

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

РАБОТА НАД БЭКЛОГОМ ПРОДУКТА

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

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

Хотя владелец продукта отвечает за хорошее состояние бэклога продукта, работа над ним — это командный процесс. Выявляются и описываются элементы, они выстраиваются по приоритету, декомпозируются и детализируются всей scrum-командой. В Scrum выделяется на эту деятельность до 10% командного времени (Schwaber, 2007). При необходимости в процесс вовлекаются и заинтересованные лица. Требования больше не спускаются команде сверху, в их формулировании принимают участие все члены команды. Владелец продукта, scrum-мастер и команда общаются не через документацию, а лично.

Совместная работа над бэклогом продукта интересна и эффективна. Она порождает диалог как внутри scrum-команды, так и между командой и заинтересованными лицами. Она устраняет разделение на «бизнесменов» и «технарей», ликвидирует ненужные передаточные звенья. Требования становятся более ясными, к их разработке привлекаются коллективный опыт и творческий импульс всей scrum-команды, создается ощущение причастности к общему делу.

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

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

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

ВЫЯВЛЕНИЕ И ОПИСАНИЕ ЭЛЕМЕНТОВ

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

ВЫЯВЛЕНИЕ ЭЛЕМЕНТОВ

Выявление элементов бэклога продукта начинается с его создания. Лучше всего это делается совместными усилиями: члены scrum-команды и при необходимости заинтересованные лица в ходе мозгового штурма выявляют элементы, нужные для создания продукта, используя в качестве точки отсчета его идею, его видение или дорожную карту. При этом не пытайтесь думать обо всех элементах сразу. Каждый раз, когда вы работаете с бэклогом, сосредоточивайтесь на минимальной функциональности, необходимой для выхода продукта на рынок, и придерживайтесь принципа простоты, который обсуждался в главе 2. В ходе проекта появятся новые идеи, и бэк­лог продукта будет развиваться в соответствии с отзывами клиентов и пользователей. Если в самом начале бэклог продукта станет слишком длинным и сложным, будет трудно сосредоточиться и правильно расставить приоритеты. Используйте идею или видение продукта, чтобы направлять свои усилия. Сконцентрируйтесь на главном и отложите в сторону остальное. Нужно противостоять искушению слишком быстро добавлять новые подробности. Элементы перечня описываются с течением времени в соответствии с их приоритетностью. Низкоприоритетные элементы остаются неделимыми и обобщенными, пока их приоритет не изменится (либо они станут более срочными, либо основные задачи будут уже выполнены). Нефункциональные требования, которые относятся к свойствам всего продукта, служат исключением из этого правила. Как вы узнаете из этой главы, они должны быть подробно описаны с самого начала.

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

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

ОПИСАНИЕ ЭЛЕМЕНТОВ

Scrum не предписывает методов описания элементов бэклога продукта, но я предпочитаю работать с пользовательскими историями (Cohn, 2004). Как можно догадаться по названию, это история о том, как клиент или пользователь работают с продуктом. Она содержит имя, краткую информацию и критерии приемки — условия, которые позволяют понять, реализована история или нет. История может быть обобщенной или подробной. Обобщенные истории называются эпиками. Писать, декомпозировать и детализировать пользовательские истории несложно. Конечно, для описания требований можно применять любой другой метод. А если вы предпочитаете пользовательские истории, то необязательно описывать все элементы бэклога продукта. Например, требования по удобству пользователя рекомендуется отображать в виде прототипов или набросков.

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

СТРУКТУРИРОВАНИЕ БЭКЛОГА ПРОДУКТА

Бэклогу часто идет на пользу группировка элементов по тематическому признаку. Темы — это будущая функ­циональность продукта. Они структурируют бэклог, помогают расставить приоритеты, делают удобным доступ к информации. Так, примеры тем для мобильного телефона — это электронная почта, календарь, голосовая связь и органайзер. В принципе, каждая тема должна для начала содержать от двух до пяти обобщенных требований. Этой информации достаточно, чтобы понять, что нужно для производства продукта, при этом содержание бэклога не замусоривается лишними деталями. Темы создают иерархию в бэклоге, который теперь помимо индивидуальных элементов содержит и их группы. Вдобавок полезно провести дальнейшее разграничение между обобщенными требованиями, например эпиками, и детализированными элементами, например историями. Пример такого бэклога частично приведен в таблице 3.1.

Таблица 3.1. Образец бэклога продукта

Тема	Обобщенный элемент	Детализированный элемент	Усилия
Электронная почта	Создать электронное письмо	Как корпоративный пользователь, я хочу создавать тему письма	1

Темы в таблице 3.1 содержат обобщенные элементы. Со временем они декомпозируются на более детально описанные элементы. После оценки элемента командой фиксируется общий размер бэклога. Структуру из таблицы­ 3.1 можно применять вне зависимости от средства, которым вы пользуетесь для создания бэк­лога, — например, расположив соответствующим образом бумажные карточки на специальной доске или на стене офиса.

РАССТАНОВКА ПРИОРИТЕТОВ В БЭКЛОГЕ ПРОДУКТА

Никогда не забуду тот день, когда я предложил менеджеру продукта в области здравоохранения расставить приоритеты в отношении лежащих перед ней вариантов использования. Она посмотрела на меня с удивлением и ответила: «Я не могу. Они все очень важные».

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

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

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

ЦЕННОСТЬ

Ценность — это довольно обычный фактор при расстановке приоритетов. Разумеется, в первую очередь мы хотим реализовать самые ценные элементы бэклога продукта. Но что делает элемент бэклога ценным? Ответ прост — его важность для выхода продукта. Если это не так, то элемент не имеет значения и его можно исключить из текущего релиза или версии продукта. Scrum-команда либо лишает такой элемент приоритетности и помещает его в самый низ бэклога, либо отказывается от него. Если элемент важен для какой-то из будущих версий, то он появится вновь.

Прежде чем включить элемент в релиз, нужно понять, не будет ли продукт и без данного элемента приносить те же преимущества. Это помогает создать простой продукт с минимальной функциональностью, как описано в главе 2. Apple, например, выпускала iPhone первого и второго поколения без возможности копирования и вставки, что не повредило успеху гаджета. Если элемент действительно нужен, подумайте, нет ли альтернативы, которая приносит те же выгоды, но требует меньше усилий, времени или денег. Команды, к сожалению, часто сдерживают какие-то неявные ограничения, поэтому они не всегда способны оценить все варианты.

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

В случае сомнений исключайте требование из релиза и быстро выпускайте продукт без него, как сделала Google при разработке первого релиза Google News — агрегатора всемирных новостей. Разработчики не могли решить, как фильтровать новости — по дате или по месту. По­этому Google решила выпустить продукт вообще без этой функции. Вскоре после запуска появились запросы новых функций. Триста человек высказались за фильтрацию по дате, и только трое захотели фильтровать по месту — явное указание на то, какая функциональность должна быть приоритетной. Если бы Google выпустила продукт с обеими функциями, то релиз отнял бы больше времени и денег, а получить отзывы о том, какая функция важнее, было бы сложнее. Поставив на рынок намеренно недостаточный продукт, Google быстро осознала, что делать дальше.

ЗНАНИЯ, НЕОПРЕДЕЛЕННОСТЬ И РИСК

«Риск — сущностная характеристика инновационного продукта. Каждое решение, касающееся проекта (принимается оно явно или по умолчанию), связано с рисками», — пишут Смит и Мерритт (Smith and Merritt, 2002; 4). Таким образом, риск — неотъемлемая часть разработки ПО. Ни один продукт без риска просто не выпустить. С риском связана неопределенность, и чем она выше, тем рискованнее проект. Неопределенность же, в свою очередь, связана с недостатком знаний. Чем меньше мы знаем о том, что нужно разрабатывать и как это делать, тем больше неопределенность. Таким образом, знания, неопределенность и риск взаимосвязаны.

Поскольку риск и неопределенность влияют на успех продукта, неопределенные и рискованные элементы должны быть наделены высоким приоритетом. Это ускоряет процесс получения нового знания, устраняет неопределенность и снижает риск. Если, например, scrum-команда не уверена в некоторых аспектах дизайна пользовательского интерфейса, то соответствующие варианты нужно побыстрее изучить и проверить, собрав отзывы клиентов и пользователей. Если команда не знает, какой уровень доступа к данным для третьей стороны применить, нужно ввести требования, запускающие транзакции базы данных, чтобы можно было оценить различные варианты. Риск может содержаться и в инфраструктуре, и в среде — например, не до конца настроенном процессе разработки или в том, что члены scrum-коман­ды не сидят в одном помещении.

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

ВОЗМОЖНОСТЬ ВЫПУСКА

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

Кроме того, это хороший способ уменьшить риски. Если scrum-команда сомневается, стоит ли внедрять функ­цию и как именно это делать, ранние релизы помогут ответить на этот вопрос, как в упоминавшемся случае с Google News.

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

ВЗАИМОЗАВИСИМОСТИ

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

Объединение нескольких зависящих друг от друга элементов бэклога продукта в один более крупный и пере­формулирование для устранения зависимости — вот два основных метода работы с взаимозависимыми пользовательскими историями (Cohn, 2004; 17). Рассмотрим в качестве примера две истории: «Я как пользователь хочу написать текстовое сообщение» и «Я как пользователь хочу написать электронное письмо». Они зависят друг от друга, поскольку обе связаны с обработкой текста. Если сначала внедрить текстовые сообщения, это сократит усилия на работу с электронными письмами, и наоборот. Первый вариант — соединить их в более крупную пользовательскую историю — не очень подходит нам, поскольку история получается слишком сложной. Второй вариант — разбить требования по-иному. Если общая функциональность выделяется в отдельную историю — «Я как пользователь хочу вводить текст», то две исходные истории больше не зависят друг от друга. Таким образом, их оценка больше не связана с порядком работы над ними.

ПОДГОТОВКА К ПЛАНИРОВАНИЮ СПРИНТА

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

ВЫБОР ЦЕЛИ СПРИНТА

Цель спринта формулирует его желаемый результат. Он должен подвести scrum-команду на шаг ближе к запуску успешного продукта. Один владелец продукта выбрал для первого спринта следующую цель: «У высоких деревьев глубокие корни». Эта фраза отлично описывала цель спринта — закладку основания для всего последующего проекта. Хорошая цель спринта обширна, но реалистична. Она должна оставлять команде пространство для маневра и не предполагать непременную реализацию всех главных элементов бэклога продукта. Как и в случае с бэклогом, вся команда должна принимать участие в формулировке цели. Это обеспечит ясность задач и мотивацию. Установить цель спринта важно по нескольким при­чинам.

• Она порождает единение между владельцем продукта, scrum-мастером и командой: все движутся к единой цели.
• Она минимизирует вариативность, ограничивая тип требований, над которыми предстоит работа в ходе ближайшего спринта, — например, по­средством выбора элементов одной темы. Так облегчается командная деятельность и увеличивается темп разработки.
• С ее помощью проще объяснить заинтересованным лицам, над чем работает команда.

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

КОГДА НУЖНО И РОВНО СТОЛЬКО, СКОЛЬКО НУЖНО

Как только избрана цель спринта, нужно подготовить ровно столько элементов для будущего спринта, сколько нужно и когда нужно. (Крупные проекты, при работе над которыми необходимо заглядывать далеко вперед, описаны ниже в этой же главе.) Работа с бэклогом продукта во время первого спринта строится вокруг элементов для второго спринта, во время второго спринта — вокруг элементов для третьего и т. д. У такого подхода есть ряд преимуществ: сводятся к минимуму траты времени и денег на описание элементов, а также снижается количество элементов, нуждающихся в подробном описании. Избыточное количество информации — это пустая трата сил. Подробно описывая лишь те элементы, которые, вероятнее всего, понадобятся для следующего спринта, мы даем бэклогу продукта возможность развиваться.

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

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

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

ДЕКОМПОЗИЦИЯ ЭЛЕМЕНТОВ

Декомпозиция элементов бэклога продукта — это постепенное их уменьшение до степени готовности для спринта. Такой процесс, известный также как последовательная декомпозиция элементов (Reinertsen, 1997), может занимать более чем один спринт. Возможно, декомпозицию какого-то элемента придется начать за несколько спринтов до его возможного внедрения, особенно если он большой и сложный. Это позволяет собрать необходимые отзывы клиентов, пользователей и других заинтересованных лиц еще до подробного описания элемента. Рассмотрим, как можно провести последовательную декомпозицию пользовательских историй.

Как показано на рисунке 3.3, scrum-команда изначально вписала в бэклог продукта эпик «Создать электронное письмо». Поскольку это слишком большая и неопределенная задача для одного спринта, эпик разделили на несколько недетализированных пользовательских историй. История «Задать получателя» была затем вновь разбита на две более подробные пользовательские истории. Теперь они достаточно малы для спринта. Эпик — это пример сложной истории, то есть пользовательской истории, имеющей не одну цель (Cohn, 2004; 24–25). Для декомпозиции подобной истории вводим отдельную историю для каждой цели. Таким образом, «Создать электронное письмо» разделяется на «Задать тему», «Задать получателя» и «Задать важность».

Затем нужно подвергнуть декомпозиции и другие пользовательские истории, в том числе сложные и имеющие слишком много критериев. Обычно сложная пользовательская история слишком велика для разработки за один спринт из-за внутренней неопределенности или слишком большой функциональности (Cohn, 2004; 25–26). Если она чересчур туманна, мы вводим в бэклог продукта один или несколько элементов, исследующих эту неопределенность и порождающих соответству­ющие знания, например: «Исследовать JavaServer Faces как технологию пользовательского интерфейса». Если история описывает слишком много функций, то мы разбиваем ее на несколько, чтобы впоследствии пошагово добавлять функциональность. Эта техника известна как разрезание торта (Cohn, 2004; 76). Например, пользовательскую историю «Проверка пользователя» можно разложить на «Проверку имени пользователя» и «Проверку пароля».

Иногда кажется, что с историями все в порядке, но только до определения критериев приемлемости. Если их более десяти или если требования скрываются в самих критериях, то нужно переработать историю и подвергнуть ее декомпозиции. Вот пример: «Я как пользователь хочу удалить текстовое сообщение». Критерии приемлемости таковы: «Я могу выбрать любое текстовое сообщение. Я могу удалить текст сообщения. Я могу сохранить измененное сообщение». Во-первых, второе условие избыточно, а во-вторых, два других вводят новые требования, а не указывают критерии приемлемости. Такую историю нужно разбить на три части — историю об удалении текстовых сообщений, о правке текстовых сообщений и о сохранении измененных сообщений.

ОБЕСПЕЧЕНИЕ ЧЕТКОСТИ, ПРОВЕРЯЕМОСТИ И ОСУЩЕСТВИМОСТИ

Когда элемент доведен до достаточно малого размера, следует убедиться в его четкости, проверяемости и осуществимости­. Требование считается четким, если все члены scrum-команды одинаково понимают его смысл. Совместное описание требований и выражение элементов бэклога продукта в простой и сжатой форме облегчают достижение четкости. Элемент называют проверяемым, если существует эффективный способ определить удовлетворенность реализацией требования в течение спринта. У истории должны быть критерии приемки, которые определяют ее проверяемость. Элемент является осуществимым, если он может быть внедрен за один спринт в соответствии с критериями приемки, принятыми в команде. (О стандартах осуществления говорится в главе 5.) Для обеспечения осуществимости мы оцениваем зависимость от других элементов, в том числе функ­циональных и нефункциональных требований. Если история ограничена, например, требованием пользовательского интерфейса, то должно быть ясно, каким будет получающееся обновление продукта. В противном случае команда должна перед реализацией пользовательской истории исследовать требование пользовательского интерфейса. Если это требует больших усилий, то исследования должны быть проведены во время отдельного спринта — например, можно создать одноразовый прототип для изучения дизайна пользовательского интерфейса.

ОПРЕДЕЛЕНИЕ МАСШТАБОВ ЭЛЕМЕНТОВ

Оценка элементов бэклога продукта позволяет нам примерно понять их сложность и трудоемкость. Это полезно по двум причинам — облегчает расстановку приоритетов и позволяет отслеживать и прогнозировать ход проекта. В Scrum используются два различных типа оценок: приблизительные — в бэклоге продукта, указывающие на примерный масштаб элемента, — и более точные оценки в спринт-бэклоге, сообщающие размер задач, на которые разбит элемент бэклога, обычно выраженный в рабочих часах. В этом разделе рассказывается об определении масштабов элементов бэклога продукта. Они оцениваются, если выявляются новые или модифицируются старые элементы либо изменяется командное понимание размеров элемента. Поэтому необходимо средство измерения, быстрое и удобное в использовании. Я предпочитаю очки историй.

ОЧКИ ИСТОРИЙ

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

Таблица 3.2. Распространенный спектр очков за пользовательскую историю

Очки	Размер футболки
0	Подарок — элемент уже внедрен
1	XS	Очень маленький
2	S	Маленький
3	M	Средний
5	L	Большой
8	XL	Очень большой
13	XXL	Двойной очень большой
20	XXXL	Огромный

Нелинейная последовательность из таблицы 3.2 ускоряет процесс принятия решений командой. Она предот­вращает продолжительные дискуссии об «истинной ценности», которые могут возникнуть при использовании линейных последовательностей.

Команда может продолжить спектр, представленный в таблице 3.2, добавив более крупные значения — 40 и 100, если сопоставление сравнительных оценок остается верным. Однако какой бы спектр значений ни был бы избран, последовательность должна быть удобной для команды и оставаться неизменной. Поскольку очки историй — критерий относительный и произвольный, нельзя сравнивать их у разных команд, если только они не договорились об общем спектре очков с общей семантикой.

ПОКЕРНОЕ ПЛАНИРОВАНИЕ

Очки историй — хороший, но недостаточный инструмент. Нам нужен метод эффективной командной оценки, и он существует — это покерное планирование (Cohn, 2005; 56–59). В покерном планировании каждому члену команды выдается колода карточек, которая содержит определенное количество очков. Если мы используем, например, спектр из таблицы 3.2, то в колоде будет восемь карточек, каждая из которых имеет одно из значений спектра. Оценка начинается сразу после того, как участникам будут розданы все карточки.

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

Перед оценкой владелец продукта объясняет элемент членам команды, а те кратко обсуждают, какие шаги нужно предпринять для разработки элемента в соответствии с приемочными критериями. После обсуждения каждый член команды независимо от других определяет значение элемента, не делая каких-либо предположений по поводу того, кто будет внедрять этот элемент, поскольку это решится только на ежедневном scrum-митинге. Каждый член команды выбирает карточку с нужной оценкой и кладет ее на стол лицевой стороной вниз. После того как все положили карточки, их одновременно переворачивают. Если оценки расходятся, то два члена команды, чьи значения оказались наиболее далеки друг от друга, приводят краткую аргументацию своей позиции. Затем команда приступает к следующему раунду. Все карточки возвращаются в колоду, и члены команды вновь выбирают те из них, которые лучше всего соответствуют их оценкам, — по сравнению с первым раундом они могут либо измениться, либо сохраниться. Этот цикл продолжается, пока все оценки не совпадут. Правила принятия решений основаны на консенсусе: все члены команды должны быть довольны оценкой. После того как команда оценила более двух элементов, нужно сравнить новые оценки с существующими, чтобы убедиться, что их относительный масштаб верен. Например, можно сгруппировать элементы одного размера.

ОЦЕНКА НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ

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

Чтобы добиться точных оценок, требуется три фактора: команда должна понимать, что нужно для внедрения элемента, ее члены — уметь выявлять взаимозависимости этого элемента с другими, а критерии готовности должны быть доступными. Если команда не может оценить элемент, необходимо добавить в бэклог продукта новый элемент, который создаст требуемое знание, например: «Создание прототипа или макета для исследования вариантов дизайна пользовательского интерфейса».

Только члены команды, занимающиеся реализацией инкремента продукта, должны оценивать элементы бэклога. Владелец продукта и scrum-мастер не принимают участия в оценке и не влияют на ее результаты (если они не являются одновременно рядовыми сотрудниками команды или если команда не обращается к ним за советом). Однако владелец продукта должен присутствовать на совещании. Многие элементы бэклога продукта будут выглядеть довольно приблизительно, так что владельцу продукта потребуется их объяснить и конкретизировать.

ЭКСПРЕСС-ОЦЕНКА

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

РАБОТА С НЕФУНКЦИОНАЛЬНЫМИ ТРЕБОВАНИЯМИ

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

ОПИСАНИЕ НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ

Нефункциональные требования могут быть выражены как ограничители (Newkirk and Martin, 2001; 16–18). Например, можно описать требование к производительности, как показано на рисунке 3.4.

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

УПРАВЛЕНИЕ НЕФУНКЦИОНАЛЬНЫМИ ТРЕБОВАНИЯМИ

При управлении нефункциональными требованиями полезно провести границу между глобальными и локальными требованиями. Первые относятся ко всем функциональным требованиям и обычно формируют небольшую группу. Пример — ограничитель производительности, показанный на рисунке 3.4. Глобальные нефункциональные требования должны быть конкретизированы как можно раньше — при выработке продуктового видения или открытии бэклога продукта. Если не удается обнаружить и скорректировать вовремя, это может привести к неверному выбору и отрицательно повлиять на успех продукта. Глобальные нефунк­циональные требования лучше поместить в отдельную часть бэклога продукта, как показано в таблице 3.3. Полезно внедрить глобальные нефункциональные требования в критерии готовности. Таким образом, каждое обновление продукта должно будет удовлетворять этому требованию.

В отличие от своих глобальных родственников, локальные нефункциональные требования относятся только к конкретному функциональному требованию — например, требованию к производительности по получению информации. Если нефункциональное требование выражено как ограничитель, просто добавляем этот ограничитель к истории (Newkirk and Martin, 2001) и (Cohn, 2004). Это можно сделать, аннотировав историю ограничителем.

БЭКЛОГ ПРОДУКТА ПРИ МАСШТАБИРОВАНИИ

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

ИСПОЛЬЗОВАНИЕ ЕДИНОГО БЭКЛОГА ПРОДУКТА

Для работы над каждым большим scrum-проектом нужен один бэклог продукта, содержащий описание всего функ­ционала, необходимого для создания продукта. Избегайте отдельных журналов для каждой команды или компонента, где требования к продукту трансформируются в требования к подсистеме или компоненту. Это приводит к лишнему объему работы, поскольку содержание должно быть выделено из общего потока требований, который должен прорабатываться, а при реализации надо постоянно следить за синхронизацией. Постарайтесь давать всем командам указания из общего бэклога продукта, отдавая при этом предпочтение функциональным командам, о чем говорилось в главе 1. Дэрин Фишер, один из инженеров проекта браузера Chrome, так описывает действия Google по работе с одним бэклогом продукта в рамках большого проекта: «Когда дело дошло до требований, многие процедуры свелись к совещаниям в формате мозгового штурма, где мы обсуждали функционал. У нас в Google была открытая внутренняя рассылка, там люди могли выразить свое мнение по поводу того, как сделать лучше… Мы старались, чтобы элементы бэклога продукта были конкретными и минималистичными. Затем мы предлагали этот список команде, и ее члены сами выбирали, над чем хотят работать».

РАСШИРЬТЕ ГОРИЗОНТ ГРУМИНГА

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

СОЗДАЙТЕ РАЗЛИЧНЫЕ ВИДЕНИЯ БЭКЛОГА ПРОДУКТА

Крупные agile-проекты, в которых участвует несколько функциональных команд, могут выиграть от использования разных представлений о бэклоге продукта (Cohn, 2009; 330–331). Каждое представление соотносится с определенным разделом. Если в течение следующих нескольких спринтов функциональная команда работает, например, по теме «органайзер», то видение бэклога для команды ограничивается соответствующим разделом. Это может предотвратить конфликты между несколькими владельцами продукта и командами, использующими один и тот же бэклог.

РАСПРОСТРАНЕННЫЕ ОШИБКИ

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

ЗАМАСКИРОВАННАЯ СПЕЦИФИКАЦИЯ

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

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

СПИСОК ПРОСЬБ К САНТА-КЛАУСУ

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

НАВЯЗЫВАНИЕ ТРЕБОВАНИЙ

Иногда владелец продукта пишет элементы бэклога продукта в одиночку и затем на совещании по планированию спринта вручает их команде. Такой подход укрепляет разделение на «мы» и «они»: владелец продукта здесь, а коман­да — там. Это отказ от знаний, опыта и творческого потенциала команды, который усложняет планирование спринта. Владелец продукта должен привлекать к грумингу бэклога продукта коллег по scrum-команде­. Назначьте несколько сессий по грумингу бэклога во время спринта, пригласите остальных членов scrum-команды и напоминайте им о необходимости выделять на это время при каждом спринте. Никогда не забывайте девиз сотрудничества, отраженный в agile-манифесте: «Представители бизнеса и разработчики должны каждый день вместе работать над проектом» (Beck et al., 2001).

ПРЕНЕБРЕЖЕНИЕ ГРУМИНГОМ

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

КОНКУРИРУЮЩИЕ БЭКЛОГИ ПРОДУКТОВ

У одного моего клиента с командой работали сразу пять владельцев продукта. Поскольку каждый из них хотел, чтобы все было сделано как можно быстрее, команде приходилось иметь дело со всеми пятью бэклогами во время каждого спринта. Это давало владельцам продукта определенный уровень комфорта: они знали, что над их требованиями идет работа. Но при этом они были крайне разочарованы, ведь проходит масса времени, прежде чем что-то делается! Казалось бы, в одновременной работе над несколькими продуктами нет ничего плохого: все заняты, над всеми требованиями трудятся… Но мгновенно ничего не происходит. Напротив, у команды нет общей цели спринта, а драгоценное время тратится на переключение между задачами. Если вашей команде приходится работать с несколькими бэклогами, сделайте так, чтобы каждый спринт был выстроен вокруг только одного продукта. Лучше всего попросить команду работать над единственным продуктом в течение нескольких спринтов, чтобы она могла быстро выпустить новую версию. Затем можно переходить к следующему. Этот подход требует расставить приоритеты для продуктов и назначить процедуру для управления продуктовым портфелем. В проблеме моего клиента в итоге оказался виноват CEO компании, который хотел, чтобы все было сделано «еще вчера», и не мог назначить приоритеты, которыми могли бы руководствоваться владельцы продукта.

ВОПРОСЫ ДЛЯ САМОКОНТРОЛЯ

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

Следующие вопросы помогут вам применить идеи, описанные в этой главе.

• Как у вас на работе выявляются и описываются требования?
• Обладает ли ваш продукт DEEP-характеристиками? Как ведется работа над грумингом бэклога вашего продукта?
• Насколько сложно коллективно выявлять и описывать требования при каждом спринте?
• Как вы работаете с нефункциональными требованиями? Где и как они фиксируются?

Отправить

teplapidlogaAppes

купити теплу підлогу під плитку

Josephtak

рулетка кс го

EuresruUsema

алмазная коронка 192

viberappJew

вайбер на ноутбук

Robertnig

заказать рекламный баннер

Dannyemusa

Капец! ---------- Смотреть военные фильмы 2024 года которые уже вышли в хорошем качестве hd на Films-2024

Elmergab

проститутки метро просвещения

AllenCOw

элитные проститутки спб