Предлагаю вам пройти небольшой тест на владение навыком описания хороших пользовательских историй. Для простоты, сфокусируемся только на заголовках историй. Приемочные тесты, сценарии BDD и прочие вещи пока оставим в стороне.
Почти все умеют писать истории, например, по шаблону Майка Кона “Я, как <роль в системе>, могу <сделать что-то>, для того, <чтобы>”.
Но насколько они получаются качественные?
Кстати, что такое качественная история, обсудим внизу, после того, как пройдете тест :)
Итак, приступим.
Представьте себе, что вы с командой начинаете разработку CRM для тренинговой компании, которая проводит обучающие курсы и набирает на них студентов.
Какой самый главный вопрос следует задать по каждой из приведенных историй?
-
Я, как сейлз, хочу видеть полный список участников курса, чтобы сделать с ними то, что мне нужно.
-
Я, как сейлз менеджер, хочу видеть список курсов, чтобы отслеживать количество зарегистрированных участников на них.
-
Я, как сейлз, хочу видеть отчет по интересам клиентов в курсах, для того, чтобы принять решение о создании нового курса и приглашения этих клиентов принять в нем участие.
-
Я, как сейлз, хочу указать для клиента его интерес к определенному курсу, чтобы знать, кто хочет пойти на такой курс и в нужный момент поставить в расписание такой курс и пригласить на него участников.
Ответы, близкие к правильным:
- А что планируется с ними сделать, какой основной сценарий работы с этим списком?
- А зачем отслеживать, какие действия будет предпринимать менеджер и на основании чего?
- На основе каких правил будет приниматься решение о создании нового курса?
- Пожалуй, идеальная история :) Какой вопрос задали бы вы?
Общаясь с разными компаниями (даже теми, кто уже несколько лет работает по Agile), я очень часто вижу такие примеры историй в реальных проектах.
Начинаешь задавать вопросы, а ответов на них ни у кого в команде нет. И даже у заказчиков их тоже часто нет.
А мы уже планируем такие истории в релиз и итерации, начинаем работу.. а потом сталкиваемся с огромными проблемами на приемке, когда оказывается, что нужно было сделать совсем по-другому.
Одна из основных целей пользовательских историй — лучше понять потребности бизнеса, задав нужные вопросы заказчикам как можно раньше.
Чтобы будущая реализация фич в продукте соответствовала не только ожиданиям заказчиков, с которыми они пришли к нам, но и их реальным бизнес-потребностям.
А сделать мы это можем только в том случае, если наш информационный контекст максимально приближен к бизнес контексту.
Когда у каждого человека в проектной команде есть детальные ответы на вопросы “Зачем?” по каждой истории.
Очень часто, получив ответ на вопрос «Зачем?», мы должны к этому ответу задать еще раз вопрос «Зачем?». Иногда и в третий раз. До тех пор, пока мы в месте с заказчиками не придем к пониманию, что мы докопались до сути.
Пример диалога:Я, как сейлз менеджер, хочу видеть список курсов, чтобы отслеживать количество зарегистрированных участников на них.
— Зачем видеть количество? Чтобы понимать, набирается ли группа по каждому курсу.
— А зачем понимать про набор группы? Чтобы принять решение: проводить/дополнительно продвигать/переносить/отменять данный курс.
— А на основании чего будет приниматься решение? Минимальное количество участников для проведения курса — 8 человек.
— А как часто проводится мониторинг и пересмотр такого решения? 1 раз в неделю если до курса больше месяца, 3 раза в неделю если меньше месяца, каждый день если до курса меньше двух недель.
И только если каждый отдельно взятый человек в нашем проекте знает ответы на эти вопросы, мы сможем научиться не только попадать в ожидания заказчиков и клиентов, но и даже предвосхищать их.
А теперь самое главное:
Откройте вашу очередь заявок/требований от бизнеса. Посмотрите на каждую историю. Достаточно ли в ней раскрыт вопрос “Зачем это нужно?»
Мы очень подробно обсуждаем тему с «Зачем» на тренинге «Управление требованиями и продуктом в Agile«.
А так же способы и инструменты, позволяющие нам научиться на ранних стадиях задавать правильные вопросы бизнесу и смотреть на любые утверждения через призму гипотез, нуждающихся в подтверждении.