Как писать хорошие user stories: part 1

В продолжении статьи про SCRUM хотелось бы более углубиться в user stories.

В кругу фрилансеров я работаю уже более 7 лет и часто на моем пути были кастомеры которые сами не знали что хотят не говоря о том что бы составить правильно ТЗ. В итоге я делал как считал нужным и были не приятные моменты когда заказчик после недели моих бессонных ночей говорил что это не то что он хотел в итоге приходилось переделывать. Но со временем набираешься опыта и сегодня я выпытываю все до мелочей и лишь потом соглашаюсь на работу, но речь не об этом. Работая в команде мы, люди с разными взглядами и понятием правильного, должны найти общий язык что бы не создавать 
басню Крылова - Лебедь, Щука и Рак. И подробно составленный план действий является отличный помощником как в разработке проекта, так и в реализации готового СУПЕР продукта.
Для agile команд user stories – это первый и основной способ выявить потребности и нужды пользователя, для которого пишется конкретный продукт. В XP, скраме и канбане пользовательские истории успешно заменяют функциональные спецификации. Чем тогда истории лучше спецификаций?

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

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

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

Как писать юзер стори

    По мере возможности костяк user story должен быть написан заказчиком или хотя бы представителем бизнеса, который понимает потребности конечного пользователя, а не руководствуется HIPPO (highest paid person opinion).
    Текст самой истории должен объяснять роль/действия юзера в системе, его потребность и профит, который юзер получит после того как история случится:)

К примеру: Как, <роль/персона юзера>, я <что-то хочу получить>, <с такой-то целью>.
Хорошая User Story должна соответствовать модели «INVEST»:

• Independent. Reduced dependencies = easier to plan;
• Negotiable. Details added via collaboration;
• Valuable. Provides value to the customer;
• Estimable. Too big or too vague = not estimable;
• Small. Can be done in less than a week by the team;
• Testable. Good acceptance criteria;

Наиболее распространенные ошибки при написании историй
История для юзера

Пример: «Как пользователь я хочу управлять рекламными объявлениями, чтобы удалять устаревшие или ошибочные объявления». На первый взгляд, вы не увидите в этой истории никаких изъянов – все элементы на месте. А теперь расскажите-ка, для кого вы собираетесь сделать эту фичу и что этот юзер знает об управлении объявлениями? Он администратор портала объявлений, которому нужно время от времени чистить базу и премодерировать объявления? Или, может, он рекламодатель, которому нужно просматривать список созданных им объявлений и иметь возможность удалять ненужные объявления прямо из этого списка?
Вы могли заметить, что у этих двух пользователей совсем разные роли, с разными ожиданиями с разными требованиями к системе. Основная ошибка этой истории – игнорирование роли и персоны пользователя.
История для продакт оунера


Пример: «Как продакт оунер, я хочу, чтобы в системе была возможность удалять объявления, чтобы юзеры могли удалять объявления»
И опять, вроде бы все на месте, но что-то не так. Для начала эта история формата «хотели историю? – получили». Очевидно, что автор истории написал ее исключительно ради самого написания:) Конечно, ваш продакт оунер может написать все истории со своей точки зрения, а не с точки зрения нужд конечных пользователей, но это означает всего 2 вещи: вы движетесь не в ту сторону и у вас проблемы с имплементацией аджайла. Возьмите вашего продакт оунера за шкирку, потрясите его хорошенько и заставьте думать головой:)
История для девелопера


Пример: «Как девелопер, я хочу заменить виджет папок, чтобы у меня был лучший виджет папок:)»
Часто такие истории становятся частью technical debt, которй состоит из переход на обновленные версии фреймворков и библиотек, рефакторинга и так далее. У них есть полное право на то, чтобы быть сделанными, но на словах они не представляют никакой ценности для юзера и вам достаточно тяжело будет заставить продакт оунера «купить» их. К тому же по хорошему любая история должна создавать пользовательскую ценность и ваша команда должна уметь рассказать на демо, зачем она все-таки заимплементила ее. Так как же поступить с этой историей?

Перепишите ее с пользовательской точки зрения: «Как рекламодатель, я хочу, чтобы система позволяла создавать мне папки, чтобы я мог быстрее работать с большими списками объявлений»
Технические задачи к этой истории могут выглядеть так:
«Отрефакторить механизм добавления папок, чтобы позволять создавать вложенные папки вплоть до 3 уровня вложенности»
«Проапдейтить версию SDK для использования нового механизма локального хранения данных на устройстве»

При этом к такой истории гораздо проще написать критерии приемки:
«Пользователь может создавать папки с тремя уровнями вложенности»
«Пользователь не может создать больше 100 папок»

Никакой бизнес ценности для пользователя

Пример: «Как рекламодатель, я хочу чтобы у меня была возможность фильтровать объявления»

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

Никаких критериев приемки:)

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

• Лучше написать много историй поменьше, чем несколько громоздких.
• Каждая история в идеале должна быть написана избегая технического жаргона – чтобы клиент мог приоритезировать истории и включать их в итерации.
• Истории должны быть написаны таким образом, чтобы их можно было протестировать.
• Тесты должны быть написаны до кода.
• Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.
• Каждая история должна содержать оценку.
• История должна иметь концовку – т.е. приводить к конкретному результату.
• История должна вмещаться в итерацию.

В следующем посте я продолжу тему user stories, рассказав, о хороших и плохих практиках при их написании.