что такое user story в agile
Что такое пользовательская история?
Так вот, пользовательские истории! Несомненно, это один из основных столпов agile(гибкой)-разработки и необходимый инструмент для продакт-менеджера.
Одним из принципов agile-разработки является идея разбиения крупных разработок на более мелкие части, называемые историями. На пути к тому, чтобы стать ниндзя-мастером на позиции продакт-менеджера и приносить пользу клиентам с помощью своего продукта, вам придется заботиться о бэклоге и содержащихся в нем пользовательских историй.
Но что такое пользовательская история?
Чтобы ответить на этот вопрос, давайте разделим это понятие на части:
История, в данном контексте, — это «устное или письменное изложение материала в художественной форме».
Пользователь — это человек, который владеет или пользуется чем-то по желанию, то есть человек, который использует компьютер, программное обеспечение, системы или компьютерные услуги.
Таким образом, можно сказать, что история пользователя — это письменное повествование об использовании системы.
Когда мы говорим о методологии agile-разработки, пользовательская история — это инструмент, который помогает переключить внимание с детализации требований к системе на их обсуждение.
Обычно это делается с помощью предложений, в которых говорится об удовлетворении требования, например:
Шаблон пользовательской истории
Давайте приведем несколько примеров обычных историй для иллюстрации?
Как менеджер по маркетингу, я хочу знать источник и механизм получения информации о том, что послужило причиной покупки на нашем сайте, чтобы понять, какие каналы коммуникации лучше всего подходят для реализации нашего продукта.
Как руководитель компании, я хочу знать среднюю величину дохода по каждому проданному продукту, чтобы решить, куда вкладывать больше или меньше средств.
Одно из преимуществ следования этой модели заключается в том, что автор истории вынужден сосредоточиться на «ЧТО», а не на «КАК» — за последнее отвечает команда разработчиков.
При создании новой истории автор всегда должен сосредоточиться на описании своих потребностей и цели, которую он пытается достичь с ее помощью. Благодаря этому команда, выслушав историю и не будучи ограниченной уже предложенными попытками решения, может свободно создать или предложить наилучшую альтернативу для решения проблемы.
Кто является действующими лицами или персонами в историях?
Это конечные пользователи историй. Именно они часто их пишут или запрашивают.
В примерах выше в качестве действующих лиц мы используем менеджера по маркетингу и руководителя компании, но участниками могут быть все, кто имеет отношение к вашему продукту, конечный клиент, внутренний пользователь, внешний пользователь, сам PM (продакт-менеджер) и т.д.
Только ли PM должен писать истории?
Определенно нет. PM действует как часть команды разработчиков продукта и служит составителем историй, которые могут поступать от клиента, других заинтересованных сторон (стейкхолдеров проекта) или даже от самой команды.
Задача PM, однако, состоит в том, чтобы убедиться, что истории хорошо описаны и содержат достаточно информации, чтобы команда могла их легко понять. Именно на основе конкретной пользовательской истории команда будет планировать свою работу и оценивать ее сложность.
Плохие пользовательские истории
Чтобы понять суть этого высказывания, давайте рассмотрим несколько примеров некорректно написанных историй использования?
A) «Не хватает кнопки загрузки».
B) «Я бы хотел, чтобы на прикрепленном экране отображалось больше информации о продукте».
C) «Включите больше изображений».
Один из способов превратить плохие истории в нечто полезное — использовать метод 5 Whys ( 5 “Почему«). Он также помогает автору быть более подготовленным и правильно описать свою следующую историю.
Гипотетически, давайте представим, что я применил этот способ с первой историей (А) из приведенных выше примеров.
Проблема: «Не хватает кнопки загрузки».
Обладая этой информацией, можно было бы улучшить исходную историю, например:
Я хочу экспортировать данные из отчета XYZ в формате CSV;
Чтобы вы могли предоставить совету директоров компании точную информацию о продажах и поступлении доходов от реализации нашей продукции.
Критерии приемки
Не стоит забывать, что хорошая пользовательская история также содержит четко сформулированные критерии приемки.
Критерии приемки, как следует из названия, — это критерии, по которым история может быть принята или отклонена.
Они представляют собой набор инструкций, каждая из которых дает четкий результат «прошел или не прошел» — например, контрольный список, в котором указаны функциональные и нефункциональные требования.
Критерии приёмки в конечном результате представляют собой «Определение выполненного» и, по существу, хорошо выполненного.
Используя эту идею и ранее упомянутую модель истории, мы могли бы определить некоторые критерии приемки:
Как BI-аналитик, я хочу экспортировать данные из отчета XYZ в формате CSV, чтобы предоставить совету директоров компании точную информацию о продажах и поступлении доходов от реализации нашей продукции.
Критерии приемки:
— При открытии отчета XYZ в конце списка результатов вы увидите кнопку, с помощью которой можно загрузить отчет в формате CSV;
— При нажатии на кнопку загрузка начинается автоматически;
— Файл экспортируется в формате UTF-8, чтобы быть совместимым с используемыми в настоящее время форматами;
Конечно, все это может быть гораздо сложнее и содержать большее количество шагов. На самом деле количество критериев не ограничено. Все зависит от размера истории, о которой идет речь. Однако ясно, что это не будет «Agile» (гибко), если это история с 423 критериями приемки.
Всех желающих приглашаем на открытый урок «Бизнес- и системный анализ как подготовка к тестированию качества программного продукта». На этом демоуроке обсудим:
— Зачем нужны User story для написания тест-кейсов?
— Как системные требования помогают наполнить тест-кейсы?
— Что такое тестовая модель и из чего она состоит?
— Как формируется тестовая модель и наполняется?
Об agile по-русски: User Stories
Это одна из статей серии «Про agile по-русски» (см. сноску внизу про значение термина «agile»), идея которых – поделиться опытом использования agile принципов (2) в разработке программного обеспечения. Основная суть этих подходов – кооперация между всеми членами проекта и адаптивность процесса разработки к неизбежным изменениям. Также важным аспектом Agile является принятие человеческого фактора в проекте как неотъемлемой части и более того – как наиважнейшей причиной прогресса. Agile акцентирует важность поддержания человеческих отношений и учета человеческих особенностей для успеха проекта.
Эта статья рассказывает о применении «user stories» («пользовательских историй») – одной из практик agile. Далее для краткости я буду называть их просто «историями».
Как структурирован этот материал?
В первой части (которая начинается буквально через пару абзацев) речь пойдет о принципах, стоящих за историями, и тем, какие преимущества получит проект от их применения.
В следующих частях я попробую изложить такие важные моменты, как планирование проектов с использованием историй, оценки стоимости и длительности проектов, также коснусь некоторых более сложных и тонких ситуаций с использованием историй, в частности таких как: возможность использования историй в аутсорсных проектах; варианты хранения историй; сложности, с которыми вы можете столкнуться (и дай Бог столкнетесь), начав использовать истории в своих проектах; также поделюсь своим личным опытом от использования историй.
Ваши комментарии помогут мне определить другие важные моменты, которые я обязательно постараюсь описать.
Как я познакомился с User Stories
Скажу честно, пока я не прочел книги Майка Кона (3), я не верил в то, что этот подход жизнеспособен. Я читал книги по экстремальному программированию (4), про то, как заказчики высказывают требования в виде коротких фраз и обсуждают их с командой, – но все это было далеко от моего понимания, в прочем, как и другие особенности XP… И мне кажется, я был не одинок.
К тому моменту, когда мне попались книги Майка, мой проект уже работал по Scrum (5), и я, видимо, уже созрел для восприятия более «крутых» тем из agile. Одной из таких тем для меня стали пользовательские истории.
User stories: экстремальный подход
Как и все другие идеи из agile, идея историй (если отбросить все предубеждения) весьма прозрачна и логична, как говорят: «it’s about common sense»
Если сжато, то суть историй состоит в том, что они, как основной механизм ведения требований проекта, служат не для документации требований, а скорее, напоминанием заказчику о наличии таковых для дальнейших обсуждений продукта с командой. По началу эта идея может показаться весьма экстремальной и противоречащей известным подходам. Но давайте по порядку.
Итак, вместо того, чтобы тратить время на написание, согласование и обновление спецификаций о требованиях к будущему продукту, заказчик (см сноски внизу) делает короткие высказывания о том, как пользователь будет пользоваться будущей системой. Будучи собранными в том или ином виде, эти высказывания используются для последующих обсуждений с проектной командой.
Почему же обсуждение требований так важно?
Принимая во внимание, что обсуждения необходимы, мы ставим процесс таким образом, чтоб без них просто нельзя было обойтись. Как вы понимаете, это можно достичь простым способом – достаточно упустить детали, описав лишь самое необходимое, – и команда будет вынуждена подискутировать с заказчиком, для выяснения упущенных деталей.
Какой заказчику от этого плюс? Кроме преимуществ перечисленных выше, – это отсутствие необходимости описывать детали до того момента, когда без них просто нельзя обойтись, что является хорошим способом сэкономить время. И вправду – зачем продумывать до мелочей то, что может существенно измениться, или что ещё хуже – вообще перестать быть необходимым.
Довольно тяжело объяснить сходу все аспекты и плюсы от использования историй – динамичной и легковесной базы для хранения требований. Давайте лучше попробуем разобрать некоторые из них на примере.
Как это работает на практике? Пример написания историй
Итак, у нас (заказчиков) есть потребность в реализации системы, которая бы позволила пользователям хранить и обмениваться фотографиями. Ожидается, что прибыль от системы будет достигаться за счет процента с продаж пользователями своих фотографий, также, возможно, за счет рекламы третьих компаний.
Те, которые хранят и обмениваются своими фотографиями – назовем их «пользователи».
Те, кто размещают свою рекламу, ориентированную на «пользователей» системы – назовем эту группу «рекламодатели».
Возможно, со временем мы сможем определить ещё какие-то роли. Пока мы упускаем их из виду. Чтобы начать достаточно имеющихся.
пользователь – одна из обобщенных пользовательских ролей;
действие – действие, выполняемое пользователем посредством взаимодействия с системой;
цель – конечная цель текущей задачи, выполняемой пользователем посредством взаимодействия с системой.
Пользуясь принципом симметричности требований, команда и заказчик принимают решение, что пользователь должен иметь возможность удалить свою учетную запись в случае необходимости:
Просто? Достаточно. По крайней мере, не сложнее, чем писать спецификации. Но дальше – интереснее.
Вопросы?
К этому моменту, я надеюсь, у вас появилось много интригующих вопросов, даже, может быть, их у вас стало больше, чем до начала чтения этой статьи… Я попробую вкратце разъяснить как же все-таки это все может работать.
Пример детализации.
Рассмотрим одну из историй, идентифицированную выше:
Во время обсуждения этой истории с командой заказчику задают вопрос о том какая информация нужна для создания пользовательской учетной записи. Обсуждая различные варианты, заказчик и команда приходят к тому, что для первой версии системы достаточно будет проверенного электронного адреса плюс имени пользователя и его пароля.
К истории дописывается этой комментарий. Теперь история выглядит так:
Нужен проверенный email и выбранные пользователем имя и пароль.
В ходе дальнейших высказываний кто-то из тестировщиков задает резонный вопрос о минимальной длине пароля и проверке на уникальности имени. Продолжая дискуссию, команда и заказчики приходят к мнению, что необходимо описать основные критерии готовности истории, чтобы команда понимала ожидания и знала, когда объявлять историю готовой:
Возможно во время реализации, тестирования и приема истории возникнут ещё какие-то дополнительные моменты. В этом случае они могут быть описаны в виде уточняющих тестов или как комментарии. Возможно из этих дополнения появятся новые истории.
Таким образом истории пополняются деталями по мере необходимости, эволюционируя от коротких высказываний до детализированных и согласованных требований со встроенными критериями готовности.
Конечно между историями существуют связи и логические цепочки – нельзя, к примеру, удалять пользовательские записи, не умея создавать их. Но все таки можно научиться составлять истории таким образом, чтоб обеспечить некоторую свободу в выборе порядка их реализации. Свободы будет, естественно, тем больше, чем больше самих историй и чем независимее они друг от друга.
Если же истории независимы, да к тому же их достаточно много, то можно смело предположить, что их ценность с точки зрения вклада в систему различна. А значит, варьируя порядком историй, можно выставить их в таком порядке, что первые «n» историй будут играть ключевую роль в полезности системы, в то время как другие истории будут скорее необязательными добавками, привлекающими пользователей или облегчающими их работу.
Конечно, порой не так легко и очевидно принять правильное решение о порядке историй, но в этом и состоит мастерство быть заказчиком (это отдельная, неисчерпаемая тема…)
Кроме инструментария ранжирования историй, в руках у заказчика есть и другие мощные средства, позволяющие повысить эффективность своих финансовых вложений. К примеру, одна из описанных на ранней фазе проекта историй в какой-то момент может показаться слишком большой в сравнении с другими, что усложняет понимание её приоритета:
В этом случае заказчик и команда могут попробовать разбить ее на несколько более мелких историй, каждая из которых может получить свой приоритет:
При этом нужно учесть, что начальная история не разбивается на две «под-истории», а замещается двумя новыми. Это не разбиение историй на подзадачи для постановки их программистам, это всего лишь переформулировка требований для более эффективного управления ими.
Подобный процесс разбиения сложных и больших истории на более простые может осуществляться в теории довольно долго. На практике же, заказчики и команда в скором времени вырабатывают совместное понимание адекватного размера историй и следуют ему при написании новых и разбиении существующих историй. Этот размер зависит от количества историй, реализуемых за итерацию. Но об этом поговорим подробнее, обсуждая планирование.
Я уверен, вы неоднократно будете пользоваться этими простыми но мощными средствами управления требованиями, когда начнете использовать истории в своих проектах.
Как вы до сих пор справлялись с подобными задачами?
Программный продукт – это не только код и документация. Это также знания о пользователях, рынке, особенностях продукта, технологиях и прочее. Если же проект – это развитие продукта, то тогда в нем должны гармонично изменяться все его составные части: код, документация и знания. А, следовательно, знания динамичны. Таким образом, что вчера казалось фактом, сегодня в свете новоприобретенных знаний таковым может уже не быть. Для историй это значит, что порядок приоритезации историй, сделанный вчера, уже сегодня, возможно, должен быть изменен.
И в этом нет ничего плохого: меняется мир, также меняются наши знания о мире. И это такой же факт для индустрии программного обеспечения, как и для всего остального.
Вот ещё один плюс хранения требований в виде списка относительно независимых историй. Его в любой момент можно пересортировать, добавить новые или удалить ненужные истории. Хранение требований в виде историй не препятствует динамичности знаний, а наоборот, базируется на том, что наши знания будут и должны меняться, иначе продукт устареет, ещё не начав использоваться.
Когда начальный набор историй готов, все истории обговорены и детализированы до нужной степени, ничего больше не остается, как перейти к их реализации, выпуская программный продукт, в соответствии с приоритетами заказчиков и желаниями пользователей.
Про оценивание размера историй, планирование историй по итерациям, предсказание времени готовности историй и прочие важные аспекты речь пойдет во второй части статьи.
Буду рад комментариям.
10 советов для написания хороших пользовательских историй
Также приглашаем всех желающих участвовать в открытом вебинаре на тему «Как спроектировать REST API и не умереть?». Участники вместе с экспертом на занятии рассмотрят следующие моменты:
• Основные плюсы и фичи REST API;
• Правильное разделение ресурсов в REST API;
• Наследование ресурсов и абстрактные ресурсы.
Пользовательские истории (User stories, юзер стори), вероятно, являются самой популярной техникой аджайл (гибкой методологии) для описания функциональности продукта: с пользовательскими историями очень легко работать. Но «рассказывать» эффективные истории бывает достаточно сложно. Следующие десять советов помогут вам в создании хороших пользовательских историй.
Скачать аудиоверсию можно здесь.
1. Пользователи прежде всего
Как следует из названия, пользовательская история описывает, как покупатель или пользователь использует продукт; она повествует с точки зрения пользователя. Более того, пользовательские истории особенно полезны для отражения конкретных функций, таких как поиск продукта или бронирование. На следующем рисунке показана взаимосвязь между пользователем, историей и функциональностью продукта (обозначена кружком).
Если вы не знаете своих пользователей или клиентов, и почему они хотели бы использовать ваш продукт, вам не следует браться писать какие-либо пользовательские истории. Сначала проведите необходимые исследования пользователей, например, с помощью наблюдения за ними или опроса. В противном случае вы рискуете написать спекулятивные истории, основанные на домыслах и идеях, но не на эмпирических данных и реальных свидетельствах.
2. Используйте персонажей, чтобы найти правильные истории
Отличный способ получить представление о пользователях и клиентах — это работа с персонажами (или персонами — persona). Это вымышленные персонажи, основанные на первичных сведениях о потенциальных клиентах. Обычно они состоят из имени и изображения; соответствующих характеристик, поведения и отношений; и цели. Цель — это выгода, которую хочет достичь персонаж, или проблема, которую персонаж хочет видеть решенной с помощью вашего продукта.
Но это еще не все: цели персонажей помогают вам выявлять правильные истории: спросите себя, какую функциональность должен обеспечивать продукт для достижения целей персонажей (я объясняю это в своей статье «От персонажей к пользовательским историям». Вы можете скачать удобный шаблон для описания своих персонажей с romanpichler.com/tools/persona-template.
3. Совместное создание историй
Пользовательские истории задуманы как легкий метод, который позволяет вам быстро продвигаться. Это не спецификация, а инструмент для совместной работы. Истории никогда не следует спихивать на команду разработчиков. Вместо этого они должны существовать в диалоге: Product Owner и команда должны обсуждать истории вместе. Это позволяет собирать только необходимый минимум информации, сокращать накладные расходы и ускорять доставку продукта.
Вы можете развить этот подход еще дальше и совместно писать истории во время вашего процесса обработки бэклога продукта. Это усиливает творческий потенциал и знания команды и результирует в создании лучших пользовательских историй.
Если вы не можете задействовать команду разработки к работе с пользовательскими историями, вам следует подумать об использовании другого, более формального метода для фиксирования функциональности продукта, например вариантов использования (юзкейсов).
4. Делайте истории простыми и лаконичными
Пишите истории так, чтобы их было легко понять. Старайтесь делать их простыми и лаконичными. Избегайте путаницы и двусмысленных терминов, используйте активную речь. Сосредоточьтесь только на том, что важно, и не отбросьте все остальное. Приведенный ниже шаблон помещает пользователя или покупателя, смоделированного как персонажа, в историю и ясно показывает ее преимущества. Он основан на широко известном шаблоне Рейчел Дэвис, но я заменил роль пользователя (user role) на имя персонажа, чтобы соединить историю с соответствующим персонажем.
Используйте этот шаблон, когда думаете, что он будет полезен, но не чувствуйте себя обязанным применять его всегда и везде. Поэкспериментируйте с разными способами написания своих историй, чтобы понять, что лучше всего подходит вам и вашей команде.
5. Начните с эпиков
Эпик (Epic) — это большая, схематичная, крупномасштабная история. Обычно с течением времени он разбивается на несколько пользовательских историй, на основе отзывов пользователей о ранних прототипах и новых продуктах. Вы можете думать о нем как о преамбуле и временном решении до более подробных историй.
Начало работы с эпика позволяет вам набросать функциональность продукта, не вдаваясь в детали. Это особенно полезно для описания новых продуктов и фич: позволяет охватить приблизительный объем и дает вам время, чтобы узнать больше о том, как наилучшим образом удовлетворить потребности пользователей.
Это также сокращает время и усилия, необходимые для интеграции новых идей. Если у вас много подробных историй в бэклоге продукта, то связать фидбэк с соответствующими элементами часто достаточно сложно, отнимает много времени, и несет в себе риск внесения несоответствий.
6. Уточняйте истории, пока они не будут готовы
Разбивайте свои эпики на более мелкие и подробные истории, пока они не достигнут готового состояния: ясные, выполнимые и проверяемые. Все члены команды разработки должны иметь общее понимание смысла истории; история не должна быть слишком большой, она должна комфортно вписываться в спринт; и должен быть эффективный способ определить, готова ли история.
7. Добавьте критерии приемлемости
Разбивая эпик на более мелкие истории, не забудьте добавить критерии приемлемости (Acceptance Criteria). Критерии приемлемости дополняют истории: они позволяют описать условия, которые должны быть выполнены, чтобы история считалась готовой. Критерии обогащают историю, они делают ее проверяемой и гарантируют, что история может быть продемонстрирована или выпущена для пользователей и других заинтересованных сторон. Как правило, для детализированных историй я люблю использовать от трех до пяти критериев приемлемости.
8. Используйте бумажные карточки
Пользовательские истории пришли к нам из экстремального программирования, и ранняя литература по экстремальному программированию оперирует карточками историй (story cards) а не пользовательскими историями. Причина проста: пользовательские истории были записаны на бумажных карточках. Такой подход дает три преимущества. Во-первых, бумажные карточки дешевы и просты в использовании. Во-вторых, они облегчают сотрудничество: каждый может взять карточку и записать идею. В-третьих, карточки можно легко сгруппировать на столе или стене, чтобы проверить последовательность и полноту, а также визуализировать зависимости. Даже если ваши истории хранятся в электронном виде, при написании новых историй стоит использовать бумажные карточки.
9. Делайте ваши истории видимыми и доступными
Истории нацелены передавать информацию. Поэтому не прячьте их на жестком диске, в джунглях корпоративной интрасети или в лицензированном инструменте. Сделайте их видимыми для всех, например, повесив на стену. Это способствует сотрудничеству, создает прозрачность и делает очевидным, что вы добавляете слишком много историй слишком быстро, так как у вас начинает заканчиваться свободное пространство на стене. Мой Product Canvas, показанный ниже, представляет собой удобный инструмент для поиска, визуализации и управления вашими историями.
10. Не полагайтесь исключительно на пользовательские истории
Для создания хорошего пользовательского опыта (user experience, UX) требуется нечто большее, чем пользовательские истории. Пользовательские истории полезны для отражения функциональности продукта, но они не подходят для описания пользовательского пути и визуального дизайна. Поэтому дополняйте пользовательские истории другими методами, такими как карты историй (story maps), диаграммы рабочих процессов, сториборды (storyboards), скетчи и макеты.
Кроме того, пользовательские истории плохо отражают технические требования. Если вам нужно передать, что должен делать такой архитектурный элемент, как компонент или сервис, тогда пишите технические истории или — что предпочитаю я — используйте какой-нибудь язык моделирования, такой как UML.
Наконец, написание пользовательских историй имеет смысл при разработке программного обеспечения, которое, вероятно, будет использоваться повторно. Но если вы хотите быстро создать одноразовый прототип или макет для проверки идеи, в написании историй может не оказаться необходимости. Помните: пользовательские истории не о документировании требований; они нацелены дать вам возможность действовать быстро и как можно быстрее разрабатывать программное обеспечение, не создавая никаких особых накладных расходов.