Better User Stories — это видеокурс от Майка Кона из Mountain Goat Software, призванный помочь вам в работе с пользовательскими историями в вашей организации.
https://www.mountaingoatsoftware.com/training/courses/better-user-stories
Ниже приведены мои заметки по этому курсу.
Модули курса
- Что такое истории
- Пользователи, роли пользователей и персоны
- Составление карт историй и семинары по написанию историй
- Добавление деталей с помощью условий удовлетворения или критериев приемлемости
- Вкладывайте деньги в хорошие истории
- Разделение историй
- Преодоление общих проблем
- Вещи, которые не являются пользовательскими историями
Что такое истории
История пользователя — короткое простое изложение, рассказанное с точки зрения пользователя.
История может быть улучшена с помощью пункта so that.
Шаблон истории:
As a <type of user>,
I <want/can/need/am required to> <some goal>
so that <some reason>
Ответы на вопросы с помощью шаблона:
1. Кому это нужно?
2. Что им нужно?
3. Почему?
3Cs пользовательской истории
- Карточка
- Разговор
- Подтверждение
Карточка
Начальная точка рассказа.
Представляет собой следующее:
* обещание команды разработчиков задавать вопросы.
* обещание владельца продукта быть доступным для разъяснений.
* Возможность для владельца продукта избежать написания длинных документов спецификации.
Разговор
Начинается с двустороннего обещания, представленного карточкой истории:
— от команды разработчиков — обещание задавать вопросы
— от владельца продукта — обещание быть доступным для ответов на вопросы (Как владелец продукта, я пишу достаточно, чтобы команда и я могли хорошо поговорить, чтобы мы могли быть проворными).
Подтверждение
Способ владельца продукта сообщить команде, что необходимо сделать для того, чтобы история считалась завершенной.
— что такое условия удовлетворения
Добавление деталей в пользовательскую историю
Несколько способов сделать это:
1. разбить историю на более мелкие истории
2. добавить к сюжету список того, что владелец продукта ожидает от завершенного сюжета (критерии приемки).
История — это указатель на требование
- attach additional supporting information/diagrams to the story
Пользователи, роли пользователей и персоны
Роль пользователя — это:
— совокупность характерных потребностей, интересов, ожиданий и моделей поведения по отношению к определенной системе.
— пользователи, которые имеют общие потребности, интересы или поведение
— сочетание пользователей, которые имеют достаточно общего, чтобы мы могли считать их потребности в значительной степени схожими.
Контекст, характеристики и критерии
Чтобы определить роли пользователей, учитывайте их сходство:
— контекст
— физическое окружение
— социальная среда
— знание домена
— квалификация (разработчик против бабушки)
— доступ к системе (медленная или высокая скорость интернет-соединения)
— характеристики
— частота взаимодействия с системой
— регулярность взаимодействия
— сложность выполняемой работы
— объем выполняемой работы
— психическое состояние пользователя (использование системы в стрессовом состоянии или нет)
— критерии
— главная цель пользователя
— второстепенные цели
— простота использования
— надёжность
— точность результатов
Как проводить ролевое моделирование пользователей
Этот процесс обеспечит значимое понимание того, кто является пользователями продукта, чем они отличаются друг от друга и какая функциональность им нужна.
4 этапа ролевого моделирования:
- Мозговой штурм первоначального набора ролей пользователей
- делается один раз в начале проекта
- присутствует вся команда
- быстро и яростно — никаких суждений
- Организуйте первоначальный набор
- сгруппировать похожие роли вместе
- определить совокупные роли
- Консолидировать
- рассмотрите каждую роль и посмотрите, можно ли их объединить
- переименовать объединенную роль
- Уточнить
- исключить роли, которые не важны для продукта
- удалить слишком широкие роли.
Документирование ролевой модели пользователя
Итоговые документы включают:
— саму модель — диаграмму, представляющую иерархические отношения между ролями пользователей
— одностраничное описание для каждой роли
Структура:
User role title
- Context (category 1)
- attribute 1.1
- description
- attribute 1.2
- description
- attribute 1.3
- description
- Characteristics (category 2)
- attribute 2.1
- description
- attribute 2.2
- description
- attribute 2.3
- description
- Criteria (category 3)
- attribute 3.1
- description
- attribute 3.2
- description
- attribute 3.3
- description
Ссылка на шаблон роли пользователя [].
Персоны (введение)
- Highly descriptive and detail archetypes representing each user role.
- user role on steroids
- it’s given a name, specific goals, attitudes, and an environment
ВАЖНО:
— Если вы неправильно составите персону, то в итоге вы создадите абсолютно правильный продукт для абсолютно неправильного типа людей.
— Без данных, подтверждающих детали, персона — это всего лишь предположение.
Создавайте персону, когда:
1. Вы создаете продукт, требующий большого внимания.
— продукт, который требует много размышлений либо перед тем, как пользователь его купит, либо во время его использования.
2. Вы не угадываете лишние детали.
— использовать данные о пользователях существующих продуктов
— проводите исследования о вероятных пользователях продукта
— поговорить с реальными пользователями
— наблюдать за реальными пользователями
Атрибуты, которые необходимо учитывать при создании персоны
Учитывайте ТОЛЬКО те атрибуты, которые важны для вашего продукта.
Набор атрибутов, на которые следует обратить внимание при определении персоны:
— Демографические (количественные)
— возраст
— пол
— география
— уровень дохода
— образование
— Психографические (качественные)
— страхи
— предпочтения
— взгляды
— мнения
— образ жизни
— ценности
Документирование персоны
Дайте персоне имя, вы также можете приложить фотографию и цитаты из интервью с реальными пользователями.
Опишите их:
— Демографические данные
— личность
— Цели
— Навыки или опыт
— Страхи
— Отношение и чувства
— Окружение
Ссылка на шаблон персоны [].
Декорированные роли пользователей
Типы ролей пользователей:
— граждане первого класса
— украшенные роли пользователей (как украшенные символы в математике)
— создаются путем добавления описательного введения к имени первоклассного гражданина, как, например:
— первый пользователь, первый посетитель, первый зарегистрированный член
— забывчивый зарегистрированный член
— как пользователь, завершивший CyQu, я могу скачать отчет.
Написание пользовательских историй для правильного пользователя
Принципы:
— не пишите все истории, используя роль, находящуюся на вершине иерархии (совокупная роль)
— используйте роль, наиболее вероятную для выполнения истории. Это
— предотвращает превращение каждой истории в «Как пользователь, …».
— вводит нас в образ мышления этого пользователя
— если вы постоянно чувствуете, что вынуждены писать одну и ту же историю для разных ролей пользователей, это может быть индикатором того, что вам следует пересмотреть определенные вами роли пользователей
— включайте в историю несколько ролей, когда:
— роли с одинаковой вероятностью могут выполнять эту историю
— роли настолько разные, что одна из них может быть забыта
— роли будут использовать функциональность немного разными способами
Составление карт историй и написание историй
Четыре времени для написания историй
1. Whenever a new idea occurs to you
2. During iteration review meetings
3. During product backlog refinement/grooming meetings
4. During story-writing workshop - the most strategic
- attended by the whole team
- attended by important stakeholders
- being help quarterly
Значимая цель определяет масштаб семинара по написанию историй
Определите важную цель на квартал: MVP или MMF.
- MVP и MMF (Minimum Marketable Feature)
MMF — кусок функциональности, который обеспечивает подмножество требований заказчика, и который способен вернуть ценность заказчику, когда будет выпущен как самостоятельная единица.
Значимая цель включает в себя:
— бизнес-цель
— пользовательская цель
Значимая цель:
— обеспечивает фокус
— ведет к большей креативности
Участники семинара по написанию историй, продолжительность и подготовка
Важные вопросы:
1. Кто ведет семинар?
— скрам-мастер/тренер
2. Кто присутствует на семинаре?
— владелец продукта
— вся команда разработчиков
— заинтересованные лица
— пользователи/клиенты
3. Сколько длится работа?
— 4-5 часов с перерывами
— зависит от:
— количество участников
— есть ли общее видение
— является ли работа новой
4. Какая подготовка проводится заранее?
— основные вопросы для встречи
— в продукте уже должны быть определены роли/персоны пользователей
— распечатайте роли/персоны пользователей и прикрепите их на стену
— владелец продукта должен быть готов представить важную цель на квартал
— клейкие записки, ручки, маркеры
Повестка дня семинара по написанию историй
5 шагов:
1. Владелец продукта представляет значимую цель
2. Обсуждение ролей пользователей и персон, соответствующих целям семинара
3. Генерация историй — все истории, которые достигают значимой цели
4. Выбор историй — какие истории лучше всего выполнят важную цель.
5. При необходимости запланируйте последующие сессии
Сопоставление историй
Добавление второго измерения (последовательность/рассказ) к списку бэклога (обычно однонаправленного и приоритетного от наиболее до наименее важного).
Концепции/термины карты повествования:
— Повествование — последовательность элементов, читаемая по всей карте повествования
— Костяк — самый верхний один или два нарратива
— Шаг — любой элемент на карте
— Действие — набор шагов, выполняемых для достижения цели.
Принятие решений с помощью карты историй
Карты историй могут помочь:
— определить недостающую функциональность
— спланировать релиз для определения MVP
— создать дорожную карту продукта
Вопросы, которые следует задать в отношении каждого этапа:
1. Что еще может понадобиться пользователю?
2. Какая дополнительная информация может оказаться полезной для пользователя?
3. Что может пойти не так?
Добавление деталей с помощью условий удовлетворенности или критериев приемлемости
Прогрессивное уточнение — добавление деталей с течением времени
Изначально истории специально расплывчаты. Они открывают разговор.
Приступая к проекту, включите в него большие истории-платформы для функциональности, которая, как вы знаете, должна быть построена, но которая не будет начата до далекого будущего. Затем уточняйте эти истории, постепенно разбивая их на все более мелкие истории в течение всего проекта. Просмотреть список историй только один раз в начале проекта будет недостаточно.
Постепенная доработка истории включает в себя:
— разделение истории на более мелкие истории
— добавление деталей к истории
Эпосы и темы
Эпопея — одна большая пользовательская история. История, которая больше, чем может сделать одна команда за одну итерацию.
Тема — набор связанных историй.
— История может быть одновременно в двух темах.
Два способа добавления деталей в историю
1. Ask product owner questions and split into smaller stories accordingly
2. Add tests to the stories
Оба подхода функционально эквивалентны. Все, что может быть написано в качестве теста к рассказу, может быть написано в качестве подтемы и наоборот.
Когда лучше выбрать одно, чем другое?
— Когда у вас есть большая история, разделите ее.
— Когда у вас уже достаточно маленькая история, добавьте тесты.
Условие удовлетворенности
Чтобы считаться выполненной, пользовательская история должна соответствовать ожиданиям владельца продукта. Лучший способ определить это — один или несколько разговоров с владельцем продукта. Если у членов команды есть конкретные потребности в сюжете, можно встретиться и обсудить сюжет и с ними, но первым шагом должен быть разговор с владельцем продукта.
Насколько уместна детализация
Достаточно подробностей, чтобы команда могла закончить историю в течение итерации.
Работа с командой, которая хочет слишком много деталей
- Product owners should not specify every small detail.
- Product owner may not be the best person to make a decision.
Определение готовности и почему его наличие может быть опасным
- A **Definition of Ready** enables a team to specify certain pre-conditions that must be fulfilled before a story is admitted into an iteration.
- Goal - prevent problems before they start.
- Each team decided on their own Definition of Ready for each story to be included into an iteration.
- Some of the rules can cause trouble and prevent the team from being agile locking it into a stage-gate flow (one thing cannot start until another thing is done).
Если определение готовности необходимо, лучше всего, если оно будет сфокусировано на рекомендациях, а не на жестких правилах. А при наличии определения готовности команде нужно будет позаботиться о том, чтобы подчеркнуть одновременность работы. Например, немного кодирования происходит даже в то время, когда еще идет проектирование. Это позволяет избежать создания процесса stage-gate, в котором вся одна деятельность должна быть завершена, прежде чем начнется ЛЮБАЯ следующая деятельность.
Agile-команды должны практиковать параллельный инжиниринг, при котором виды деятельности перекрываются -> большинство команд даже не должны использовать определение готовности.
Инвестируйте в хорошие истории
Атрибуты хорошей истории:
— Независимый
— Обсуждаемый
— история открывает разговор между владельцем продукта и командой разработчиков
— Ценность
— для клиента
— для пользователя
— заинтересованным сторонам
— Оцениваемый
— история не должна быть слишком большой для оценки
— если история не поддается оценке сегодня, оставьте ее и вернитесь к ней позже
— Соответствующий размер или малый
— верхняя часть бэклога всегда содержит более мелкие истории, которые готовы перейти в следующую итерацию
— тестируемый
— возможность определить критерии подтверждения
Разделение историй
Зачем разделять историю?
— разные приоритеты
— нехватка времени
— размер — слишком большой, чтобы быть завершенным за одну итерацию
2 типа больших историй:
— сложные — принципиально большие и не могут быть разделены: встречаются редко
— составной — объединяет несколько действий пользователя в одно: может быть разделен.
Подход SPIDR к разделению историй на части
- Spikes
- research activity intended to build knowledge
- timeboxed
- should only be used to remove excess uncertainty from a story -> do not overuse spikes
- Paths
- drill down to find underlying steps/paths
- Interfaces
- story that has multiple user interfaces
- Data
- split by the data handled by the story
- Rules
- look at the conditions of satisfaction and pull out any rules that make the story too big
История трассирующей пули
История — это трассирующая пуля в технологическом стеке системы.
Преимущества:
— снижение архитектурного риска
— легче расставить приоритеты
— делают возможными ранние релизы
Закрытые истории
При разделении историй старайтесь создать закрытую историю
Закрытая история — та, которая заканчивается достижением пользователем значимой цели.
Три вещи, которые нужно сделать, если вы не можете разделить историю
1. Try harder
- most stories are compound rather than complex
- walk through the SPIDR approach
2. Let it take more than one iteration
3. Feel guilty
- if you allow a story to span more than one iteration, feel guilty
Преодоление общих проблем
Управление зависимостями между историями
Техники работы с зависимостями между историями:
1. Объедините истории
2. Разделяйте истории как можно позже
3. Пересмотрите способ, которым были разделены истории
4. Аннотируйте истории с важными зависимостями
Не документируйте очевидные зависимости
Истории со слишком большим количеством деталей
- when you first write the story, focus on WHAT the user wants to achieve and HOW they want to achieve it
- initially leave UI assumptions out
Вовремя и достаточно
— разработчики нуждаются в достаточном количестве информации, предоставляемой им вовремя
Тратим слишком много времени на разделение историй на части
Если вы тратите слишком много времени на разделение историй, подумайте о следующем:
— оцените, не слишком ли подробны истории
— подумайте, достаточно ли малы истории
— рассмотрите возможность перехода на более длительную итерацию (избегайте итераций продолжительностью более 4 недель).
Истории с участием более чем одной команды
- Indicate all the team need/can work on a story
- mark appropriate dependencies
Истории, которые на самом деле являются задачами
Плохая привычка — создавать задачи, которые маскируются под истории
Истории против задач
— история
— обычно то, над чем работает более одного человека
— содержит несколько типов работы
— задача
— обычно выполняется одним человеком
— содержит один тип работы
Истории, которые на самом деле являются заданиями, создают проблемы:
1. Дуэт не приносит ценности
2. Они рискованны
3. Они ведут к поэтапной разработке
Не все должно быть историей пользователя
Нефункциональные требования
Требования, которые имеют отношение к работе системы, а не к ее специфическому поведению
Часто называются -способности
— переносимость
— ремонтопригодность
— тестируемость
— масштабируемость
— удобство использования
Они являются ограничениями на то, как разрабатывается система
Истории и ошибки
Сообщение об ошибке и просьба о новой функции — это принципиально/концептуально одно и то же — желание внести изменения в систему.
Баги не должны быть написаны в синтаксисе истории.
Особенности Feature-Driven Development
FDD — разработка, управляемая функциями
— список функций = бэклог продукта Scrum
— синтаксис: <action> the <result> <by|for|of|to> a(n) <object>.
Синтаксис функции FDD может быть полезен:
— когда нет непосредственного пользователя.
— для более технических частей системы
— для задач по разработке API
Истории заданий
Разновидность пользовательских историй
Истории заданий решают две проблемы, выявленные в историях пользователей:
- Многие пользователи имеют одну и ту же цель
- Пользователи не знают решения своей проблемы
Шаблон для историй заданий:
When ______ I want to ______ so I can ______ .
Когда использовать истории заданий:
- Когда знание мотивации пользователя важнее, чем знание подробностей о пользователе
- Когда члены команды разработчиков и пользователь уже часто общаются