Эз э систем ай вонт ту… Actor и Value в User story

Пост обновлен апр. 10

Все помнят, что такое 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». Я знал, что рано или поздно мы перейдем и на эту дрянь.