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