Image

Что за история (пользователя)?

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

« Как <роль или личность>, я могу <цель / потребность>, чтобы < почему >»

Или, в другом случае:

«Как <определенный класс пользователей>, я хочу <иметь возможность выполнять / делать что-то>, чтобы <получить какую-то ценность или выгоду> »

Почему истории пользователей?

Истории пользователей - отличный способ четко определить ваш продукт . Набор четко определенных и приоритетных пользовательских историй может помочь вам сформулировать функциональность вашего продукта на «простом английском» - без каких-либо технических подробностей и деталей реализации.

«Использование ¨R подход уполномочивает содержательное обсуждение продукта истории», как внутри команды разработчиков продукта и с внешними заинтересованными сторонами.

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

  1. Пользовательские истории помогают достичь кросс-команды ясности на то , чтобы строить, для кого , почему и когда . Поскольку их легко определять, понимать и редактировать, они могут стать стандартным способом общения и обобщения функциональности продукта как техническими, так и нетехническими участниками. Они чрезвычайно полезны для обсуждения объема продукта или в качестве отправной точки для технических погружений. Они являются ключевыми элементами гибкой инженерии.
  2. Истории пользователей поощряют участие нетехнических участников . Современные программные проекты обычно сложны, включают широкий спектр технологий, сокращений и вариантов реализации. Во многих случаях терминология или технический язык обычно не понимаются даже в рамках одной команды, что создает «шум» и риски для проекта. Пользовательские истории устраняют этот технический аспект, поэтому любой член команды может внести свой вклад, просто думая «как пользователь» . Команда может использовать нетехнический язык и эффективно сотрудничать при определении , проверке или расстановке приоритетов пользовательских историй. Влияние на сотрудничество и командную динамику может быть значительным.
  3. Они помогают в определении всего продукта - как набор твердой, мудро приоритизированных истории. Команда разработки продукта может мыслить масштабно, определять супернабор пользовательских историй, а затем назначать приоритеты (которые отражают ожидаемую ценность для пользователя, сложность, зависимости и другие бизнес-приоритеты). Вам не нужно принимать жесткие решения и отмечать элементы как «выходящие за рамки». Вместо этого вы можете присвоить этим «сумасшедшим» идеям более низкий приоритет, одновременно повышая при этом пользовательские истории, отражающие основные функции вашего продукта . Определение «линий разреза», определяющих объем каждой итерации, фазы или версии, в таком случае зависит от доступных ресурсов и скорости работы команды .

Написание G reat пользовательских историй

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

Пользовательские истории ≠ задачи

Пользовательские истории - это не задачи. Фактически, для успешной реализации одной истории могут потребоваться сотни отдельных задач.Задачи о реализация; пользовательские истории оопределение.

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

Оставайся на высоком уровне

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

Понять пользователей

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

Независимо от техники, вам понадобится набор ключевых пользователей - в идеале в виде персонажей - прежде чем вы начнете составлять пользовательские истории.

Думайте как пользователь

Часть пользовательской истории < как особый класс пользователей / персонажей / ролей > определяет угол, перспективу - то, как конкретный пользователь воспринимает функциональные возможности, описанные в истории.

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

Мыслить масштабно

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

Хорошая практика - мыслить масштабно и позволять «сумасшедшим» историям пользователей попадать в бэклог. Административные накладные расходы на ведение расширенного бэклога продукта невелики; его ценность - с точки зрения ясности продукта, видения и возможностей - огромна.

Используйте эпики

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

Не отбрасывайте - вместо этого расставляйте приоритеты

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

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

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

Настройка на успех, а не просто принятие

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

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

Отметьте истории, добавьте метаданные

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

Должным образом управление метаданными вашего stories- сек ОСТОЯНИЯ, прогресс, ссылки, приоритеты, ресурсы и т.д. . - помогает исследовать, отслеживать и понимать ваше отставание.

Не придерживайтесь липких заметок!

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

Image

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

Вам все еще нужны спецификации

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

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

Визуализация помогает

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

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

0
Нет комментариев. Ваш будет первым!