kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Спринт 9/18: Agile-практики → Тема 2/7: Истории → Урок 1/6
Пользовательские истории
В прошлом уроке вы узнали, что функции в бэклоге продукта можно описывать в виде пользовательских историй. В этом уроке вы узнаете, что это такое, из чего состоят пользовательские истории и как СА с ними работает.
Что такое пользовательские истории
Пользовательская история (User Story) — это техника описания функций ПО от первого лица, то есть с использованием местоимения «я».
Функции бэклога продукта описывают пользовательские и функциональные требования. В истории входят как пользовательские требования, так и функциональные. Кроме того, они могут включать нефункциональные требования.
Создатель пользовательских историй — один из авторов Agile-манифеста разработки ПО Кент Бек (Kent Beck).
Преимущества пользовательских историй
По сравнению с другими техниками описания пользовательских требований User Story:
- Понятна и пользователю, и участникам команды разработки. Системный аналитик описывает истории на простом и понятном пользователям языке.
Если необходимо, системный аналитик может включить в историю профессиональный жаргон, которым владеют пользователи одного класса или конкретная персона, но он не должен использовать термины из области разработки ПО.
- Позволяет ограничить объём функциональности и спланировать сроки её реализации.
- Подходит при работе короткими итерациями. Из историй формируется бэклог продукта. Оттуда команда разработки переносит истории в бэклог итерации.
- Экономит время команды разработки. User Story позволяет кратко записать требования и обсудить их детали в ходе реализации.
- Акцентирует внимание на устном обсуждении требований с пользователями и командой разработки.
- Способствует единому пониманию требований. В обсуждении историй участвуют пользователи и команда разработки.
Из чего состоит пользовательская история
Рон Джеффрис (Ron Jeffries), ещё один автор Agile-манифеста разработки ПО, вывел три элемента, которые составляют пользовательские истории. Джеффрис назвал их 3C, то есть three C’s, или «три си»:
- Card (Карточка).
- Conversation (Обсуждение).
- Confirmation (Подтверждение).
В русском языке эквивалентом этого обозначения можно считать 3П (нет, это не про зарплату):
- Пишем.
- Проговариваем.
- Подтверждаем.
Системный аналитик описывает на карточке пользовательскую историю. Задача карточки — напомнить СА и команде разработки, что нужно обсудить детали этой истории. Обсуждение поможет системному аналитику и другим участникам команды разработки достичь единого понимания требований. Убедившись, что все друг друга одинаково поняли, системный аналитик записывает детали на карточку.
Пример для разбора: изучим составляющие User Story для соцсети, где пользователи рассказывают о жизни своих домашних питомцев. Пользователи хотят общаться с друзьями, показывать им фото питомцев и оценивать публикации друг друга.
1. Пишем
В 3C Джеффриса эта составляющая называется карточкой, потому что раньше пользовательские истории записывали вручную на индексных карточках. Так называются плотные листы бумаги небольшого размера (с линовкой или без неё), которые используются для ведения картотек.
Когда появились таск-менеджеры, от использования бумажных карточек отказались. Независимо от формата (бумажного или электронного) карточка состоит из:
- Названия.
- Шаблона записи истории.
- Примечаний.
- Критериев приёмки.
- Сценариев приёмки.
Название
Системный аналитик пишет на карточке её название, которое будет использоваться в обсуждении и переписке. Оно должно быть кратким. Название должно передавать суть функции и позволять отличить одну из них от других. Карточки могут называться так:
- «Написать другу».
- «Сделать публикацию».
- «Прикрепить к публикации фотографии».
- «Оценить публикацию».
Названия нужны для того, чтобы упростить коммуникацию в команде. Системному аналитику и другим участникам команды разработки гораздо проще сказать «Коллеги, давайте обсудим прикрепление фотографий к публикациям», чем «Коллеги, давайте обсудим, как пользователю социальной сети было бы удобно прикреплять фотографии к публикации, чтобы показать друзьям своего питомца».
Шаблон истории
Истории могут быть записаны в свободной форме, но на практике такой формат не помогает сформировать единое понимание для всех участников разработки. Поэтому британская IT-компания Connextra разработала шаблон записи истории: «пользователь — задача — цель» (Role — Feature — Reason). Его так и называют — «шаблон Connextra» (Connextra Format).
Connextra — одна из первых компаний, которые начали использовать гибкую модель разработки ПО. Когда сотрудники Connextra стали составлять бэклог с использованием историй, они столкнулись с проблемой: большинство людей часто не понимали, что должно быть написано в истории, и записывали пользовательские требования в свободной форме.
При взаимодействии с историями разработчикам приходилось искать автора истории и обсуждать с ним подробности. Со временем компания разработала собственный шаблон, который оказался настолько удачным, что Connextra продемонстрировала его на лондонской конференции XPDay 2001. После этого шаблон компании стали применять команды разработки по всему миру.
Шаблон истории — это структура описания целей и задач пользователя. Шаблон состоит из трёх частей:
- Как [кто?] (пользователь).
- Я хочу [чего?] (задача).
- Чтобы [для чего?] (цель).
В оригинале шаблон описывают так:
Как
В первой части шаблона СА записывает класс пользователя или имя персоны. Историю можно написать от лица организации, государственного органа или ПО, которое будет взаимодействовать с разрабатываемым продуктом.
Если карточка истории пишется от лица человека, лучше использовать в шаблоне персону, а не класс пользователя. Это позволяет конкретизировать историю, рассказать её: например, от лица Николая, мужчины 40 лет из Перми, который хочет прикрепить к публикации фотографию своего умного и серьёзного хомячка Бориса.
С помощью персон системный аналитик и команда разработки могут проявить больше эмпатии. Им будет проще найти решения, которые удовлетворят потребности пользователей. В этом случае команда и СА будут понимать, как их работа помогает людям, а значит, лучше вовлекутся в процесс разработки и получат больше удовлетворения.
Я хочу
Во второй части шаблона записывают задачу, которую пользователь хочет выполнить с помощью ПО. Важно описать именно то, что пользователь хочет сделать, не углубляясь в то, как эту задачу нужно выполнить.
Это значит, например, что в карточке истории не нужно упоминать элементы интерфейса, потому что:
- Пользователи хотят выполнять свои задачи, а не просто нажимать на кнопки или открывать окна на экране.
- Описание того, как пользователь работает с элементами интерфейса, отвлекает команду разработки от задач, которые он хочет выполнить.
- Особенности экранов определяются, когда историю обсуждает команда разработки. С момента создания карточки и до её обсуждения может пройти время, в течение которого пользовательский интерфейс может измениться, а значит, описывая его в карточке, системный аналитик зря потратил время.
- Обсуждая историю, участники разработки могут предложить свои варианты того, как можно реализовать пользовательский интерфейс. Члены команды могут предложить вариант получше, но они не понимают пользователя так, как СА, и могут не попасть в его цели. Системный аналитик должен рассказать им, что пользователь хочет сделать, чтобы вместе с ними определить, как задача может быть выполнена.
Во второй части шаблона слово «хочу» можно заменить на «должен» или другие глаголы, которые выражают отношение пользователя к задаче. Вряд ли все пользователи хотят вводить надёжный пароль при регистрации, они скорее должны задавать пароль, который поможет избежать кражи данных.
Чтобы
В третьей части шаблона записывается цель пользователя, для достижения которой он выполняет задачу. Цель — это проблема, которую он хочет решить, или возможность, которую он хочет использовать в рамках взаимодействия с ПО. Цель выражает ценность, которую можно получить при реализации истории.
Цель — конечное состояние, тогда как задача — это действие, которое направлено на достижение этого состояния. Цель стабильна и не изменяется с течением времени, задачи же могут меняться. Например, чтобы предложить гостям на ужин утку в апельсинах, достаточно выполнить задачу «заказать блюдо „Утка в апельсинах“», раньше для этого пришлось бы идти в магазин, покупать утку, апельсины, разделывать тушу, цитрусовые и дальше готовить их.
Эта часть истории важна, потому что задача, которую пользователь хочет выполнить, чтобы достичь своей цели, может не привести к желаемому. Команда разработки может предложить пользователям лучшие пути по достижению цели, так как они — эксперты в разработке ПО (обладают соответствующими знаниями, опытом и кругозором). Например, цель — показать друзьям своего питомца, её можно достичь с помощью разных задач:
- Добавить фото хомячка к публикации в социальной сети.
- Провести прямой эфир с хомячком.
- Создать виртуального хомячка.
История «Прикрепить фотографию» будет записана на карточке так:
«Как Николай, я хочу прикрепить фотографии к публикации, чтобы показать друзьям своего хомячка Бориса».
Перед вами описаны цели и задачи. Определите, какие из описаний — цели, какие — задачи.
Примечания
Системный аналитик записывает в примечаниях детали, которые предстоит уточнить у пользователей и команды разработки. Детали записываются в виде вопросов («Нужно прикреплять GIF-анимацию?»), побуждений к действию («Обсудить форматы фотографий: JPEG, PNG, HEIF, другие») или предложений.
Примечания напоминают системному аналитику о том, что детали истории нужно обсудить с пользователями и командой разработки.
Критерии приёмки
Критерии приёмки — это детали того, что пользователь хочет получить в результате реализации истории. Критерии приёмки помогают команде понять, когда она может закончить реализацию историй.
Критерии приёмки оформляются в виде лаконичного утверждения, которое уточняет шаблон истории, и отвечают на вопрос: «Что именно ожидает получить пользователь?» Иногда критерии приёмки описывают ограничения и важные характеристики ПО, то есть отвечают на вопрос: «Как ПО должно работать, чтобы соответствовать ожиданиям пользователя?»
Системный аналитик записывает в виде критериев приёмки то, что ему уже известно об ожиданиях пользователей от ПО. Например, если он знает, что в истории «Прикрепить фотографию» пользователи хотят прикреплять несколько фото и они должны отображаться в порядке добавления. Тогда на карточке истории в качестве критериев приёмки системный аналитик напишет:
- Можно прикрепить несколько фотографий (до 10).
- Фотографии должны быть отсортированы в порядке прикрепления.
Сценарии приёмки
Сценарий приёмки — это шаги, описывающие то, как пользователь мог бы проверить соответствие реализованной истории критериям приёмки. То есть отвечает ли поведение ПО ожиданиям пользователя.
Пользователю необязательно проверять разработанную историю по написанным сценариям приёмки. Проверяет реализованную историю команда разработки, например системный аналитик или тестировщик.
Сценарии приёмки отвечают на вопросы:
- Как именно пользователь будет работать с реализованной функциональностью?
- Какое поведение он ожидает от ПО?
В качестве сценариев приёмки системный аналитик записывает то, что ему уже известно об ожиданиях пользователей от поведения ПО во время работы с ним. Например, он знает, что в истории «Прикрепить фотографию» пользователи хотят прикреплять до 10 фотографий к публикации, а если их больше, то чтобы прикреплялись первые 10 из них.
Системный аналитик оформляет сценарии приёмки, используя определённый набор слов и двоеточия для некоторых из них:
2. Проговариваем
Когда системный аналитик описал все элементы карточки, он организует встречу, на которой обсуждает историю с пользователями и командой разработки. Участники встречи оговаривают те вопросы, которые СА записал в примечаниях, и те, что возникли в ходе обсуждения.
Например, разработчики могли бы спросить:
- Каков максимальный размер фотографии в мегабайтах?
- Нужно ли запретить другим пользователям копировать опубликованные фотографии?
Иногда пользователи и команда разработки не успевают обсудить на встрече все вопросы. Оставшиеся вопросы системный аналитик записывает на карточке в виде новых примечаний (вопросы, затронутые в ходе обсуждения, он вычёркивает). Например:
- Обсудить возможность обрезки фотографий.
- Какие фильтры для обработки фотографий добавить?
Во время обсуждения команда может составлять диаграммы процессов и данных, таблицы с расчётами, разрабатывать прототипы экранов, а также использовать другие инструменты коммуникации, которые помогут достичь единого понимания.
Основное преимущество истории в том, что её обсуждают. Это позволяет объединить опыт, знания и эрудицию разных участников команды и разработать более качественное ПО.
3. Подтверждаем
Вопросы, по которым участники обсуждения пришли к единому пониманию, записывают на карточке в виде критериев и сценариев приёмки, дополняя или изменяя информацию, которую записали до обсуждения.
Например, пользователи ответили, что хотели бы прикреплять фотографии в форматах JPEG и PNG, а GIF-анимации им не нужны. Системный аналитик записывает на карточке критерий приёмки: «Можно прикрепить фотографии в форматах JPEG и PNG».
Также он добавляет на карточку новые сценарии приёмки, описывающие, какого поведения пользователь ожидает от ПО. Например, пользователь хотел бы, чтобы при выборе фотографий в галерее отображались только фотографии подходящих форматов (JPEG и PNG).
Это ещё не всё
В гибкой модели разработки ПО системный аналитик не стремится описать до начала реализации все элементы карточки истории, обсудить все открытые вопросы и подтвердить ожидания пользователя от поведения ПО.
Часть требований станет известна системному аналитику при описании истории по шаблону, другая часть требований будет выявлена в её обсуждении. Наконец, некоторые детали истории обнаружатся при её подтверждении. Но в реализации истории также вскроется множество подробностей, и это нормально.
Таким образом, системный аналитик пишет карточку истории:
- в ходе текущей итерации или незадолго до её начала, при этом до того, как команда разработки приступит к реализации;
- каждый раз, когда пользователи и команда разработки обсуждают историю и хотят записать выясненные детали;
- когда во время реализации обнаруживаются новые детали.
Соотнесите элементы карточки истории с их назначением.
Краткая формулировка истории, которую используют в обсуждении и переписке.
Название
Кратко передать суть истории и отличить одну карточку истории от других помогает название.
Часть карточки, описывающая цели и задачи пользователя.
Шаблон истории
Сформировать единое понимание пользователя, его цели и задач позволяет шаблон истории.
Детали истории, которые предстоит уточнить, в виде вопросов, побуждений к действиям или предложений.
Примечания
Это детали истории, вопросы и предложения команды и пользователей, которые системный аналитик записывает в примечаниях.
Описание деталей того, что пользователь хочет получить в результате реализации истории.
Критерии приёмки
Ожидания пользователя от реализации истории записывают в критериях приёмки. Они также устанавливают границы истории для команды разработки, то есть помогает ей понять, когда они могут закончить реализацию историй.
Описание шагов того, как пользователь мог бы проверить соответствие реализованной истории критериям приёмки.
Сценарии приёмки
Ответы на вопросы «как именно пользователь будет работать с реализованной функциональностью?» и «какое поведение он ожидает от ПО?» команда даёт в сценариях приёмки.
Подведём итоги
Пользовательская история (User Story) — это описание пользовательских требований от лица пользователя, то есть от первого лица, с использованием местоимения «я».
Системный аналитик пишет историю на карточке, проговаривает её детали с пользователями и командой разработки и фиксирует единое понимание истории в подтверждении.
Системный аналитик пишет карточку истории:
- в ходе текущей итерации или незадолго до её начала, при этом до того, как команда разработки приступит к реализации;
- каждый раз, когда пользователи и команда разработки обсуждают историю и хотят записать выясненные детали;
- когда во время реализации обнаруживаются новые детали.
Карточка состоит из следующих элементов:
- Название.
- Шаблон истории.
- Примечания.
- Критерии приёмки.
- Сценарии приёмки.
Шаблон истории состоит из следующих частей:
- Как [кто?] (пользователь).
- Я хочу [чего?] (задача).
- Чтобы [для чего?] (цель).
В следующих уроках вы подробнее узнаете о том, каким критериям должна соответствовать история, и о том, как писать критерии и сценарии приёмки.
Чат поддержки