Все помнят, что такое user story?
Я уверен, что помнят все, но на всякий случай поглядим в самый авторитетный источник – BABOK. Он определяет user story (далее US) так: A small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.
Это определение находится в глоссарии, а вот в разделе «Техники» написано более расширенно: The title of the story describes an activity the stakeholder wants to carry out with the system. Typically, it is an active-verb goal phrase similar to the way use cases are titled.
Далее BABOK пишет в несколько другом ключе: The most popular format includes three components:
• Who: a user role or persona.
• What: a necessary action, behaviour, feature, or quality.
• Why: the benefit or value received by the user when the story is implemented.
For example, "As a <who>, I need to <what>, so that <why>."
Вот еще несколько вариантов определения:
· “As a <user role>, I can <activity> so that <business value>” (использовано в книге «Agile software requirements», отличная книга)
· "As a <role> I can <capability>, so that <receive benefit>" (это я взял из Википедии)
· "As a <type of user>, I want <some goal> so that <some reason>" (популярное определение, которое я встречал во многих местах, приписывается Майклу Кону)
Трехэлементный формат US – кто, что, зачем – интуитивно понятен, сравнительно прост и достаточно удобен. Почти всегда. Периодически бывают ситуации, когда в умелых руках три части user story становятся похожи на те три сцепленные между собой шестеренки с картинки, которую вставляют в каждую презентацию. Ну, вы все ее наверняка видели.
Всегда ли ценность заключена в действиях пользователя?
В определениях выше вторая составляющая US сформулирована как действие или возможность, предоставленное некоему актору для достижения им какой-то цели. Все формулировки подводят к тому, что что кто-то что-то делает. «To <what>», пишет BABOK, а не просто «<what>».
Также все определения прямо говорят о пользователе системы. Это вполне логично, ведь система делается для того, чтоб ей кто-то пользовался. И еще это оправдано с точки зрения тестируемости: при таких-то условиях я, как пользователь системы, делаю какие-то действия, в ответ на что система должна делать так-то и это критерий ее соответствия ожиданиям. Ну и вообще, даже само словосочетание «user story» говорит о том, что следует смотреть с перспективы действий пользователя системы. Это приводит к тому, что user story зачастую сводятся к описанию функций, которые предоставляет система, в виде «as a user I want to».
Однако вполне возможна ситуация, когда требования связаны не с действием или возможностью, а их ограничением либо отсутствием.
Пример из реальной жизни о ценности для бизнеса, пользователе и функциональности. В одном интернет-магазине обнаружили, что некоторые недобросовестные покупатели приобретают подарочный сертификат, оплачивают его с помощью Paypal, а потом обращаются в Paypal за аннуляцией трансакции. Paypal бдит права покупателя и возвращает деньги. Но за это время покупатель успевает приобрести товары, оплатив покупку подарочным сертификатом. Это очень плохое поведение, пожалуйста, никогда так не поступайте!
Так вот, заказчик (владелец интернет-магазина) обращается к команде разработки с change request’ом относительно уже реализованной функциональности оплаты: в случае, если в корзине есть подарочный сертификат, сделать невозможной оплату через Paypal. Понятен ли business value этого требования? Я бы сказал, что даже очень. Как будет выглядеть user story в формате «As a <user role>, I can <activity> so that <business value>»? «Как покупатель, при наличии в корзине подарочного сертификата я хочу не иметь Paypal среди доступных методов оплаты, чтоб недобросовестно не получить товар бесплатно»? Как-то так?
Cui prodest?
(Cui prodest? — Кому выгодно? — крылатая фраза, приписываемая римскому юристу Кассиану Лонгину Равилле, который рекомендовал судьям всегда искать, кому может быть выгодно данное преступление.)
Несложно заметить, что определение user story соответствует определению требования заинтересованной стороны (stakeholder requirements): «требования заинтересованной стороны описывают потребности заинтересованных сторон, которые необходимо удовлетворить, чтобы выполнить бизнес-требования». Кроме того, определение value (ценности) в BABOK включает в себя упоминание stakeholder’а: «стоимость, важность или полезность чего-либо для заинтересованной стороны в данном контексте». То есть важна не сама по себе ценность, но и кто её получит.
Напрашивается очень банальный вывод – «who», ради которого делается US, это тот самый stakeholder, который получит ценность. Это представление хорошо согласуется с коротким определением из BABOK в самом начале статьи. Оно хорошо соответствует I advocate writing user stories in the form of “As a <…>, I want <…> so that <…>” (это Майкл Кон).
Но, возвращаясь к «as a user I want to», пользователь системы – это только один из stakeholder’ов. Конечно, ценность для конечного пользователя очень важна: счастлив пользователь – счастлив и заказчик системы, удовлетворяется потребность, которая привела к инициации изменений и старту проекта. Счастливы разработчики, покупая сыры и смузи (которые тоже представляют собой ценность заинтересованной стороны). Ну, конечно, не в том случае, когда пользователь счастлив от того, что заплатил сертификатом, оплату которого аннулировал Paypal. Из этого следует, что не все ценности одинаково полезны, и ценность для одних stakeholderов может противоречить ценности для других stakeholder’ов.
Более того, крайне редко создание систем происходит по воле пользователей. Чаще всего за создание системы платит заказчик, не являющийся конечным пользователем. Иногда платит кто-то третий. Иногда систему создает скучающий программист, у которого много свободного времени. Для всех этих сторон ценности сильно отличаются.
Пример из реальной жизни: департамент HR для эффективной утилизации человеческих ресурсов (это, кстати, объективация, по возможности избегайте её) компании хочет, чтоб все сотрудники во вновь созданной HR системе зашли в свой профиль и заполнили его, чтобы департамент знал, какими навыками и технологиями владеют гребцы.
Формулировки user story для этой системы звучали примерно так: «как пользователь системы, я хочу заполнить свой профиль для того, чтоб профиль был заполнен и HR департамент что-то с ним делал». Как несложно заметить, пользователь системы, то есть сотрудник, не получает никакой пользы от того, что несколько часов будет заполнять многостраничную анкету. Теоретически, можно было бы дописать «… чтоб меня оценили и дали промоушн», но… ну камон, вам давали промоушн за заполненный профиль? Честно было бы написать «как начальство HR департамента, я хочу, чтоб сотрудники заполнили профили, для эффективной утилизации человеческих ресурсов и роста маржинальности». При этом, конечно, начальство HR департамента не заполняет профили и, возможно, вообще не имеет какой-либо роли в системе.
Зачем надо заморачиваться с правильным определением stakeholder’а-выгодоприобретателя? Правильное понимание выгодоприобретателя позволяет правильно приоритизировать требования. Приоритизация на основе «больше ценности» может привести к тому, что какая-то группа stakeholder’ов будет счастлива, но бизнес-потребности не будут удовлетворены и инициатива не будет успешной.
Что происходит, когда «why» в US неочевиден?
Хорошо сформулированная ценность в US очень важна для формирования оптимального решения вообще и для правильной приоритизации в частности. К сожалению, этой частью US часто пренебрегают. User story «как пользователь, я хочу регистрироваться в системе, чтоб быть зарегистрированным в системе» вы, поди, сами видели. Я, по крайней мере, видел много раз.
Иногда, чтоб было не так заметно, пишут «как пользователь, я хочу заполнить регистрационную форму, чтоб зарегистрироваться в системе».
Это плохой паттерн, не надо так.
Если у функциональности не видно ценности, и очевидно, что это требование не лишнее, не надо просто вставлять отписку для формального соответствия формату US. Это повод подумать над этой функциональностью с командой и заказчиком. Может быть, ценности не видно из-за плохого понимания доменной области (например, незнания требований регулятора). Может быть, функциональность является необходимым условием для реализации других функций, которые несут большую ценность. Может быть, ценности действительно нет, а требование следует выкинуть. Может быть, stakeholder подсунул вместо требования о необходимой функции своё решение о том, как эта функция должна быть реализована.
Если вернуться к «как пользователь, я хочу регистрироваться в системе, чтоб быть зарегистрированным в системе», то во многих случаях для пользователя в этом нет ценности. Весьма вероятно, что пользователь не хочет получать очередную спам-рассылку и не хочет, чтоб его персональные данные остались еще на одном сайте. И на самом деле «чтоб пользователь был зарегистрированным в системе» хочет другой stakeholder – заказчик. (Я сам слышал от заказчика требование «We want to force customer to register».) Например, продавец хочет узнать день рождения покупателя, чтоб потом подсунуть под видом специального персонального дисконта попытку апсейла.
В этом случае заказчик должен иметь в виду, как он собирается принудить пользователя сделать то, что пользователь не хотел бы, для получения своей ценности. Классика – это старые добрые кнут (не Дональд) и пряник. Можно либо дать (или пообещать) пользователю плюшки в виде каких-то нынешних или грядущих удобств. Либо просто лишить его доступа к важной функциональности пока пользователь не зарегистрируется. Если так, корректной формулировкой user story было б «как пользователь, я хочу зарегистрироваться в системе, чтоб получить доступ к функционалу авторизированного пользователя».
Если отношения и коммуникации с заказчиком нормальные, заказчик сам расскажет, что он планирует заинтересовать пользователя. Если никак не планирует, стоит ему озвучить этот вопрос.
Что происходит, когда «who» в US неочевиден?
Понятное дело, совершенно естественно хотеть видеть требования к системе в виде «когда происходит то-то, система делает то-то». Это, кстати, очень соответствует формату нотации Gherkin "Given... When... Then". Но во многих случаях «When» не относится к действиям пользователя. Например, это может быть реакция на какое-то событие.
Поэтому люди берут и пишут «as a system I want to».
Разумеется, система может рассматриваться как актор, но это не повод приписывать ей какие-либо интенции. Система не является приобретателем ценности.
Нет ничего более беспомощного, безответственного и испорченного, чем писать «as a system I want to». Я знал, что рано или поздно мы перейдем и на эту дрянь.
Можно ли вообще обойтись без этой мороки с правильными user story?
В моем представлении, не заморачиваться можно в двух случаях:
1. Это небольшая высокомотивированная и очень стабильная команда, где все хорошо понимают как предметную область в целом, так и нужды заказчика, и с постоянным вовлечением PO в работу команды. В этой ситуации возможно и нет смысла тратить время на то, чтоб для каждого элемента беклога указывать stakeholderа и ценность в явном виде – все и так их более-менее понимают, а если что-то неочевидно – это можно в любой момент проговорить дополнительно. Например, в книжке «Scrum and XP from the trenches» Хенрика Книберга (лучшая книжка по скрам, которую я прочитал) автор вообще не акцентируется на формате US, пишет «элементы беклога» и получается отлично: The product backlog is basically a prioritized list of requirements, or stories, or features, or whatevers. Things that the customer wants, described using the customer’s terminology.
2. Это outstaff-компания с частой ротацией кадров, где получают указания от удаленного заказчика, у которого все требования это must have, а разработчики просто закрывают тикеты. Ведь части «who» и «why» нужны для правильной приоритизации требований на основе stakeholder value. И если приоритизация требований происходит по-другому, то и от user story можно оставить только часть, отвечающую за функцию системы, так как другие ее части не будут добавлять никакой полезности и нет смысла писать туда что-то только для соответствия формату.
Это глубоко субъективное мнение, не надо со мной спорить, я сразу со всеми согласен.
Насколько критичным надо быть к value требований?
Выше я писал про то, насколько важно правильно понимать и формулировать ценность требований. Очень часто то, что говорит stakeholder о требуемых возможностях системы для обеспечения desired value это на самом деле не то, что ему нужно на самом деле. Про это написаны сотни статей и там описываются разные техники, например «Five Whys». Но я немного не об этом.
К сожалению или нет, в отечественном аутсорсе большая часть проектов это достаточно стандартные системы. И в них многое очень конвенционально и это нормально. ERP, e-commerce, healthcare, ну вы сами все знаете.
Клиенту, как правило, нужны достаточно очевидные, нормальные, конвенциональные штуки.
Если клиент хочет, чтоб на product listing page были тайлы с продуктами, на которых отображается фото продукта, его название и цена, тут излишне задавать клиенту пять почему.
Противоречит это написанному выше о важности “who” и ”why” в «как пользователь, я хочу зарегистрироваться»? Да. Я бы в этом случае говорил просто об элементе беклога «регистрация пользователя», чтоб отразить факт, что ценность подразумевается.
Задавать вопросы о ценности и пять почему надо начинать тогда, когда клиент просит что-то, что неочевидно и нестандартно. Как те пресловутые семь красных перпендикулярных линий, причем одна в виде котенка. Если никто в устоявшейся доменной области что-то до сих пор не сделал – это не все дураки, один я умный, а, возможно, это просто никому не нужно. Я не призываю отвергать любые нестандартные идеи, а только сосредотачивать выяснение причин и реального бенефита именно на них, а не на стандартной функциональности. Если клиент хочет, чтоб на тайле с product listing page были только фото продукта, его название и цена, тут нужно задавать клиенту пять почему требование именно такое.
Необычные штуки должны бы внедрятся после формулирования гипотезы, экспериментальной проверки и прочего А/В тестирования с претотипированием и фокус-группами. (Претотипирование – термин, восходящий к работе Альберто Савойя, от pre-prototype.) Нормальный заказчик нормально воспримет вопрос о business value новых требований. Хороший заказчик еще и оценит неравнодушное отношение к бизнесу клиента. Особенно это касается сложной и трудозатратной функциональности. Бывают клиенты, которые фонтанируют креативными идеями, бывают те, кто ловят кайф от того, что их пожелания воплощают в код сто человек. Рано или поздно у них заканчиваются деньги. Не стоит им подыгрывать.
Резюме
Все три составные части user story важны (а не только часть, отвечающая за действие), если мы хотим нормально использовать этот инструмент – не для описания функциональных требований, а для правильной приоритизации требований заинтересованных сторон. Если приоритизация основана на чем-то ином, не стоит использовать неподходящий формат.