The Scrum Framework — второе издание

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

---

Пользовательские истории Scrum: полный обзор эффективного управления

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

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

Чтобы написать ясную и эффективную историю Scrum, используйте формат «Как [роль], я хочу [возможность], чтобы [польза]». Например: «Как клиент, я хочу легко отслеживать статус заказа, чтобы соответственно планировать своё расписание».

Характеристики пользовательских историй Scrum

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

Существуют разные рекомендации по формулированию историй. Например, можно использовать такой шаблон:

Как [участник], я [хочу|должен] [выполнить действие], чтобы [получить результат]
Или сокращённый вариант:
Как [участник], я [хочу|должен] [достичь результата]

Участник: Человек или персона, чью потребность описывает история, а не тот, кто отвечает за бэклог. Часто это пользователь, но лучше уточнить конкретную роль. Точные участники, например «Администратор», «Авторизованный клиент» или «Неавторизованный посетитель», облегчают понимание и задают контекст.

Действие: То, что участник хочет сделать. Если действие обязательно, можно использовать слово «должен», в остальных случаях — «хочу».

Результат: То, чего участник хочет достичь действием. Это результат выполнения действия с его точки зрения.

Пользовательская история Scrum: обзор

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

Это краткие неформальные описания функций с ясным вниманием к потребностям конечного пользователя, или участника истории. Они часто следуют структуре «Как [пользователь/участник], я хочу [функция], чтобы [польза]». Простой, но сильный формат объясняет, кто будет использовать функцию, чего он хочет и зачем. Объединяя ответы «кто», «что» и «почему», история даёт полное целостное представление о требовании.

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

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

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

Роль пользовательских историй в гибком управлении проектами

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

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

Учитывая значение историй в Agile, организациям крайне важно обучать команды их эффективному созданию. International Scrum Institute предлагает всесторонние ресурсы для освоения этой основы гибкого подхода. Они помогают составлять уточнённые истории и описывают лучшие практики управления ими в бэклоге продукта.

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

Эффективное создание пользовательских историй Scrum

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

Понимание потребностей пользователей

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

Структура историй

SMART — один из полезных способов обсуждения желаемого результата истории, а не обязательный шаблон Scrum:

• Конкретность (Specific) — Определите, что необходимо сделать
• Измеримость (Measurable) — Определите, как измерить успех
• Достижимость (Achievable) — Убедитесь в выполнимости при заданных ограничениях
• Значимость (Relevant) — Согласуйте с бизнес-целями и потребностями пользователей
• Ограниченность во времени (Time-bound) — Задайте ясный срок поставки

Это даёт команде разработки понятные ориентиры и помогает каждой истории напрямую поддерживать цели проекта и приносить пользователям реальную ценность.

Вовлечение команды

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

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

Опираясь на принципы создания историй, рассмотрим способы их приоритизации для максимального влияния на Agile-проекты.

Приёмы приоритизации пользовательских историй

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

Метод MoSCoW

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

• Обязательные (Must Have): Незаменимые функции для базовой работы продукта или основных потребностей пользователей. Без них главное назначение продукта окажется под угрозой.
• Важные (Should Have): Важные, но не критичные для первого выпуска функции. Они делают продукт полнее, но при необходимости могут быть отложены.
• Желательные (Could Have): Желательные, но необязательные функции, улучшающие пользовательский опыт или добавляющие ценность. Их можно перенести без ущерба основной функциональности.
• Не включаемые сейчас (Won't Have): Функции, которые сейчас считаются ненужными и намеренно исключены из текущего объёма работ.

Ясная классификация MoSCoW помогает заинтересованным сторонам согласовывать ожидания с Agile-командой и договариваться о первоочередной разработке.

Модель Кано

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

• Базовые свойства: Основные требования, которые клиенты ожидают и часто принимают как должное. Их выполнение не обязательно повышает удовлетворённость, но отсутствие вызывает недовольство.
• Линейные характеристики: Эти свойства напрямую связаны с удовлетворённостью: чем лучше характеристика, тем выше удовлетворённость. Но действует убывающая отдача: чрезмерные улучшения не всегда усиливают восторг клиентов.
• Восхищающие свойства: Их наличие способно удивлять и радовать клиентов, а отсутствие обычно не оказывает сильного отрицательного влияния на удовлетворённость.

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

Эти приёмы приоритизации помогают Agile-команде поставлять действительно важную функциональность, не тратить усилия на второстепенное и повышать общую удовлетворённость клиентов.

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

Роль заинтересованных сторон в пользовательских историях Scrum

В Scrum заинтересованные стороны подобны путеводным звёздам. Они знают, чего хотят пользователи и что нужно бизнесу. Их вклад необходим для историй, отражающих требования и ожидания обеих сторон. Без них работа похожа на поездку без карты: без направления легко заблудиться.

Например, при разработке мобильного банковского приложения заинтересованные стороны представлены маркетингом, клиентской поддержкой, ИТ-безопасностью и несколькими технологическими подразделениями. Их взгляды вместе дают полное понимание приложения. Маркетинг может подчёркивать удобный привлекательный интерфейс, поддержка — простоту взаимодействия, а ИТ-безопасность — надёжные защитные протоколы.

Как для воспитания ребёнка нужны усилия всего сообщества, так для успешного воплощения истории нужны все эти разные взгляды.

Вовлечение заинтересованных сторон в уточнение историй помогает в нескольких отношениях:

• Практическая значимость: Они делятся реальными ситуациями и потребностями пользователей, согласовывая истории с практическими требованиями бизнеса.
• Цикл обратной связи: Активное вовлечение позволяет собирать отзывы на каждом этапе и итеративно улучшать результат.
• Соответствие бизнес-целям: Заинтересованные стороны связывают истории с более широкими бизнес-целями и поддерживают стратегические решения.

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

Кроме того, участие с самого начала укрепляет чувство сопричастности и ответственности и создаёт благоприятную среду для сотрудничества и общения.

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

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

Оценка сложности для эффективного управления Scrum

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

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

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

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

Оценки усилий из покера планирования полезны не только для Спринта, но и для распределения ресурсов и понимания возможностей команды. Во время планирования Владелец продукта использует их, приоритизируя истории по сложности и потенциальной ценности.

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

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

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

Использование пользовательских историй Scrum в управлении бэклогом продукта

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

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

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

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

Каждая история должна ясно и конкретно описывать свою функцию. Хорошо построенная история обычно использует формат: «Как (роль), я хочу (функция), чтобы (польза)».

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

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

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

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

Каковы основные компоненты пользовательской истории Scrum?

Ответ: роль или персона, краткое описание желаемой функциональности и критерии приёмки. Они помогают понять точку зрения пользователя и задают ясные ориентиры разработке. В опросе Stack Overflow 2023 года 87% Agile-команд подчеркнули важность чётких историй для эффективного управления бэклогом.

Как история помогает Планированию Спринта и приоритизации в Scrum?

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

Для чего нужна пользовательская история в Scrum?

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

Как писать эффективные истории для гибкой разработки?

Ответ: используйте принцип «трёх C»: Card — краткое описание на карточке, Conversation — обсуждение деталей, Confirmation — критерии приёмки. Истории должны быть краткими, конкретными и упорядоченными по ценности для клиента. В опросе VersionOne 65% Agile-команд отметили, что небольшие чётко сформулированные истории помогали успеху проекта. Для общего понимания требований также необходимо постоянное сотрудничество разработчиков, Владельцев продукта и клиентов.

Какие есть лучшие практики и типичные ошибки при работе с историями Scrum?

Ответ: ясно определяйте роль, цель и пользу каждой истории, расставляйте приоритеты по ценности и сложности, вовлекайте всю команду в написание и оценку и регулярно уточняйте бэклог. Типичные ошибки — излишние детали или техническая направленность, отсутствие заинтересованных сторон, недостаточное разделение крупных историй и нерегулярное обновление бэклога. По данным опроса Scrum Alliance, следующие этим практикам команды сообщали об улучшении общения (74% респондентов), соответствия бизнес-целям (68%) и удовлетворённости клиентов (62%).

Итоги: пользовательские истории Scrum

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

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

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