Пишу про разработку вообще и в частности про: JavaScript, HTML5, CSS3, AngularJS, ReactJS, Agile, Bitcoins

Как и зачем писать пользовательские истории – user stories

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

Начнем с базового понятия – пользовательские истории пришли для того чтобы заменить список требований. А почему agile именно так подходит к решению? Чем список требований помешал, ведь в итоге именно его и нужно выполнить, разве не так? Совершенно верно, возразить тут нечего, все именно так и обстоит и проблема совершенно не в списке задач.

Основная сложность не в том чтобы написать код. Вот это вообще не проблема. Да, разумеется программистам приходится решать сложные задачи, продумывать архитектуру и все это вот так вдруг не сделаешь. Ребята, я с вам вот ни разу не спорю, вы чертовски правы, я же и сам программист, я на вашей стороне 🙂 Тем не менее самая сложная часть в ежедневной работе это маневрирование между всеми участниками проекта и выстраивание понимания задачи между всеми. Разумеется не все время этим занято, но пока ты не уверен, что все говорят об одном и том же нет смысла начинать проект.

dilbert-agile-scrum

Давайте разберемся в ситуации.

Задачи программистам приходят со стороны бизнеса, как ответ на некую необходимость:

Это нормальные задачи, которые может ставить бизнес. Явно, что задачи связаны с техническим решением, поэтому конечно они приходят в R&D и все они сформированы как пользовательские истории. В чем преимущество сторон в таком подходе?

Бизнес не должен задумываться о том как реализовать ту или иную часть. Он и не хочет заниматься подробным описанием, потому что скорее всего не знает архитектуры и если слишком углубится в описание решения, то может усложнить процесс. Ведь вполне возможно, что именно так как написано ничего не реализовать. Разработчики, используя истории, в свою очередь получают свободу в принятии решения. Никто кроме них все равно не знает какой путь быстрее всего приведет к решению и как результат релизу на прод.

И главный плюс в том, что такая постановка задач вызывает диалог. Диалог между “заказчиком” и разработчиком, диалог между дизайнером и программистами. Это очень важная часть процесса. Если кто-то хочет поставить задачу и чтобы его больше не трогали до релиза, то это не реально. Конечно, если вам совсем наплевать на результат, то можно вообще на все забить.

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

Что должны включать в себя пользовательские истории (п.и.)?

user-stories

П.И. не должна быть слишком длинной. У вас нет необходимости описать все подводные камни задачи, иначе не останется места для обсуждения и вы только постфактум узнаете пошло что-то не так или нет. Кстати, если программисты перестают задавать вопросы – то вы определенно вкладываете слишком много информации в ваши п.и.

Простой шаблон п.и. будет следующим: <Кто (тип пользователя)> нужно (некое действие) <Что>, <Почему>. Несколько примеров историй с некоего сайта путешествий:

Первые три истории отвечают только на два вопроса: Кто и Что. Этого вполне достаточно, дополнительное пояснение не требуется. В последней же истории есть пояснение, для того чтобы было ситуация стала более понятной. Ведь программисту может быть не очевидно, например он часто не летает в одно и то же место и функция повторного заказа ему никак не поможет. Вместе с тем такое объяснение поможет ему понять задачи некоторых пользователей приложения.

Поскольку формулировка истории достаточно короткая, то нам необходимо как-то добавить критерии выполнения, иначе правильное выполнение будет невозможно. Критерия выполнения вполне могут родиться в процесс обсуждения истории. Например, для истории “Пользователю нужно иметь возможность отменить резервацию” критерии могут быть:

После того как критерии поняты мы можем начать писать “саб-таски” для истории. Саб-таски предназначены для определения и распределения задач между программистами. Саб-таски и критерии взаимозаменяемы, однако имеет смысл использовать и те и другие, потому что каждая группа предназначена для “своего пользователя”.

Ссылки по теме:

Поделиться:
comments powered by Disqus