User Stories as a thinking tool

Автор: Алексей Кривицкий.

Сегодня, благодаря книге Майка Кона и куче статей, термин user stories (по-русски "пользовательские истории" или просто "истории") стал насколько популярен, что его стали использовать повсеместно, заменяя им такие привычные нашему уху термины как "требование", "фича", "задача", и прочее.

Это, без сомнений, подчёркивает то, что Agile прочно входит в наши дома (офисы), укоряняется в наших умах (и, дай Бог, в умах наших менеджеров и заказчиков). Становится неотъемлемой частью профессии, гордо именуемой "разработчик программного обеспечения" (читать без иронии и сарказма).

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


Давайте рассмотрим пример. Предположим, что речь идёт о системе аналогичной Gooogle Сalendar, где пользователи могут управлять своими событиями.
Есть такое требование:

• Система должна предоставлять возможность отображения событий календаря пользователя в виде списка, отсортированного по времени (по возрастанию). Отображаемые данные каждого события должны содержать краткое описание события, место, дату и время начала, длительность.

Имея сноровку, это требование можно довольно быстро привести к виду историй, который пропагандирует Майк Кон: As as a [user], I can [do], so that [value]:

• Как владелец календаря, я могу просмотреть события своего календаря в виде списка, отсортированного по времени (по возрастанию) с тем, чтобы знать своё расписание.
  
  Детали: Отображаемые данные должны содержать краткое описание события, место, дату и время начала, длительность.
  

Вспомнив, про концепцию Card Conversation Confirmation (предлагаемую экспишниками, в частности Роном Джеффриз), мы, можем добавить тесты - критерии приёмки истории. Но не суть. Сейчас не об этом.

Вопрос в следующем. Является ли описанная история настоящей историей?

Формально - да. Формат и размер делают ещё очень схожей с тем, что называют user stories. Но тут есть один важный ньюнс.

Давайте рассмотрим другую историю:

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

На сколько эта история отличается от предыдущей? С первого взгляда - довольно сильно. В первой мы говорили про web view в виде списка. Тут мы говорим про email. Наверное, можно придумать ещё десяток способов отображения расписания...

Так что же пользователю нужно на самом деле?
(Заказчик): Знать своё расписание.
(Мы): Зачем?
(Заказчик): Затем, чтобы видеть все спланированные события наперёд.
(Мы): Зачем нужно видеть спланированные события наперёд?
(Заказчик): Затем, чтобы не пропускать события или заблаговременно измененять свои планы, не подводя других людей.
(Мы): Зачем это нужно?
(Заказчик): Ну, так ведут себя серьёзные и деловые люди!
(Мы): Ага!!

Значит цель пользователя на самом деле является: а) не пропускать свои события; б) иметь возможность заблаговременно изменять свои планы:

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

Что изменилось по сравнению с предыдущими двумя историями? Эта история - ни слова не говорит про программное обеспечение. Её можно решить вообще без компьютера, завёв карманный календарик, ведя расписание на настенном календаре или заведя секретаршу.

- Так чем же отличается эта история от приведённого сначала требования и двух других историй?
- Она описывает проблему, а не решение.
- И что эта так важно?
- О да! Говоря о проблеме, мы склонны совместно с профессионалами предметной области найти более интересные решения, о которых мы сначала даже и не подозревали. Более креативные и свежие решения. Так зачем себя ограничивать, выбирая изначально всего лишь один вариант решения проблемы?
Встаёт более философский вопрос. А что если проблему можно будет решить вообще без программного обеспечения? Разве это так уж и плохо?
В принципе, нет. Ведь наша задача - помогать решать проблемы наших заказчиков (клиентов, пользователей).

Итог

Когда вы пишите истории, пытайтесь найти проблему, которую вы намерены решить. Опишите её в истории. Если вы догадываетесь на фазе написания истории о хорошем способе её решения (к примеру отсылать email с расписание), допишите это явно ("как вариант решения ...")в истории, но отдельно от поставленной проблемы.

Если к вам приходят истории, написанные вашими заказчиками, бизнес аналитиками или ещё кем-то, потратьте время, поговорив с ним и найдя проблему. Они вам за это будут благодарны, поверьте. Five Whys (техника "пяти почему"), которую я продемонстрировал выше, почти всегда даст вам нужный результат. Главное объяснить, что вы задаёте глупые вопросы не потому что вы глупы :)

Старайтесь выделять проблемы из решений. Храните их и управляйте ими отдельно. В Скраме для складирования проблем служит Product Backlog, для управления решениями - Sprint Backlog.

Побочные эффекты

Описание проблем обычно намного компактнее, чем описание возможных решений. Эта одна из причин, по которой в Agile проектах входной документации намного меньше, чем в традиционных проектах.

--------

Удач! Не бойтесь экспериментировать и пробовать новое.
"Anyone who has never made a mistake has never tried anything new" (Einstein)