Нет никакого волшебного шаблона, который нужно использовать для пользовательских историй (User Story). Они могут написаны огромным числом способов. Но самый популярный шаблон написания пользовательских историй выглядит так:

Как…, я …, поэтому…..

Это шаблон возник благодаря agile-коучу Рэйчел Дэвис (Rachel Davies) в британской компании Connextra в начале 2000-х. С того времени он стал признанным стандартом пользовательских историй.

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

Три элемента стандартного шаблона

Этот шаблон и три его составляющих элемента я уже описывал ранее в статье In User Stories Applied следующим образом:

• Как (роль), я хочу (функция), поэтому (бизнес-ценность).

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

• Кто нуждается в этом функционале
• Что они хотят
• Почему они этого хотят

Давайте рассмотрим подробнее каждую из этих частей шаблона истории пользователя.

Кто: первый элемент шаблона пользовательской истории

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

Других, кто использует эти функции, можно назвать опытными пользователями.

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

Эти роли пользователей составляют первую часть стандартного шаблона пользовательских историй. Следовательно, тот, кто разрабатывает текстовый редактор, должен иметь пользовательскую историю: «Как опытный пользователь, я хочу проверить орфографию…»

Что: второй элемент шаблона пользовательских историй

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

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

• Как участник, я должен ввести надежный пароль….

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

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

Почему: третий элемент шаблона пользовательских историй

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

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

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

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

Может ли «почему» быть необязательным?

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

Я не считаю её обязательной, поскольку иногда она просто не несёт никакой ценности. Рассмотрим историю о входе в систему: как участник, я должен войти в систему. Какое «почему» вы можете добавить к этой истории, которое добавит ценности или пояснит смысл? Действительно ли это помогает или это просто лишний текст, добавленный в соответствии с шаблоном:

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

Хотя я не считаю «почему» обязательным, я пишу его почти всегда. Я изучил бэклог, который писал и 62 из 64 историй (97%) имели пункты «почему». Небольшое число отступлений не позволяет мне считать этот пункт обязательным.

Сильные стороны шаблона Пользовательской истории из трёх частей

Что же позволило этому шаблону выдержать столь длительное испытание dременем? В конце концов, практика из начала 2000-х годов, которая и много лет спустя набирает популярность, должна иметь под собой что-то для этого. Я думаю, есть четыре ключевые сильные стороны шаблона.

Он охватывает три из пяти W

Я поступил в университет на журналистику. Мне кажется, я идеализировал фильмы, наполненные газетными репортёрами, жующими сигары, например « Туз в рукаве», «Гражданин Кейн», «Это случилось однажды ночью» и «Вся президентская рать». Журналистов учат, что любая газетная статья должна ответить на пять вопросов, каждый из которых начинается с W:

• Кто? (Who?)
• Что? (What?)
• Когда? (When?)
• Где? (Where?)
• Зачем? (Why?)

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

Элементы в правильном порядке

Я считаю, что элементы – кто, что и почему – стоят в правильном порядке. Представьте любую историю – не пользовательскую, а фильм, роман или анекдот, которую вы хотите рассказать другу. Самое главное в любой истории почти всегда – кто это делает. Мы называем этого человека главным героем.

Когда мы смотрим фильм, мы интересуемся главным героем до самого сюжета. Мне не интересно, каким образом взорвана Звезда Смерти, пока я не расскажу о Люке, Хане или Лее.

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

История от первого лица

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

Истории обо мне, о тебе, о нас, о ней и о нем интересны.

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

Первый британский альбом The Beatles имел местоимения в 8 из 14 названий песен (57%). В 19 минутах и 30 секундах этих восьми песен Битлз использовали 325 личных местоимений – одно местоимение каждые 3,6 секунды.

Это сработало настолько хорошо, что их второй альбом имел местоимения в 64% названий. Битлз повысили этот показатель до 79% в третьем альбоме.

В интервью журналу Billboard Пол Маккартни сказал: “Все наши ранние песни включают ‘me’ или ‘you’. Мы были совершенно откровенны и бесстыдны перед фанатами: «Люби меня, пожалуйста, пожалуйста, я хочу держать тебя за руку».

Стандартный шаблон пользовательской истории начинается с Я – самого личного из личных местоимений. У меня нет оснований утверждать это – я не ученый – но я клянусь, что что-то происходит, когда у нас есть пользовательская история, которая начинается с Я. Мы относимся иначе, чем если бы тоже самое было написано, как традиционное Система должна.

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

Заинтересованным сторонам нравится писать их

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

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

У меня никогда не было такой проблемы с пользовательскими историями. Я могу провести семинар по написанию историй с заинтересованными сторонами, просто написав как_____, я ______ так что _______ на доске и сказать им, что мы собрались, чтобы заполнить пробелы столько раз, сколько сможем.

Заинтересованные стороны это понимают. Это естественный способ говорить с ними.

Были предложены другие шаблоны для выражения историй, некоторые из них имеют преимущества, но большинство менее естественны. Например, Behavior-Driven Development (разработка через поведение), является отличным cпособом выражения тестов или уточнения на примерах. Мартин Фаулер (Martin Fowler) описывает его синтаксис, как «стиль представления тестов». И это фантастика для написания спецификаций тестов, но вовсе не так подходит для общения с клиентами. Отчасти это потому, что его шаблон менее естественен. Я говорю с двух или трех лет. Я не знаю, начинал ли я когда-нибудь предложение с дано. Я определенно никогда не использовал дано, когда и затем в таком порядке в предложении. Я бессчетное число раз говорил: “Я хочу это, потому, что.”

Недостатки шаблона пользовательских историй из трёх частей

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

Слишком много историй написано просто “как пользователь…”

Слишком часто члены команды начинают историю каждого пользователя с «как пользователь…», иногда это результат ленивого мышления, и авторы историй должны постараться лучше понять пользователей продукта, прежде чем писать так много историй «как пользователь…».

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

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

В подобных случаях команды должны использовать альтернативные способы выражения того, что продукт должен делать. Синтаксис, используемый историями работ или Feature-Driven Development (разработка, управляемая функциональностью, может стать лучшим выбором.

Шаблону часто рабски следуют

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

Сегодня я написал пункт бэклога продукта: «изменение способа отправки напоминаний о проведении вебинаров, как мы обсуждали в пятницу».

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

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

Что думаете вы?

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

Оригинал статьи Why the Three-Part User Story Template Works So Well, автор Майк Кон (Mike Cohn).