Пользовательские истории. Искусство гибкой разработки ПО - [44]
Мне кажется, шаблоны историй работают точно так же, как «плуг». Используйте их, чтобы составлять описания к своим первым историям. Читайте их вслух, чтобы инициировать обсуждение. Но не слишком расстраивайтесь, если однажды обнаружится, что они работают не всегда. Как и техника «плуга» для горнолыжников, это не лучший выбор для сложного пути.
Мой любимый шаблон: если я записываю истории на стикерах или карточках и они не отправляются сразу же на большую сложную карту, то я даю им простые короткие названия, а затем записываю под ними:
Кто:
Что:
Почему:
Под каждый ответ отводится несколько строчек, ведь нужно перечислить каждого конкретного «Кто?», немного рассказать о «Что?», а также привести несколько различных причин для «Почему?». Кроме того, я люблю оставить на карточке место, чтобы добавить еще немного информации после того, как мы начнем обсуждать эту историю. Меня ужасно раздражает, когда некоторые пишут название истории прямо посередине карточки, ведь теперь на ней нельзя сделать никаких пометок! Но, конечно, тут я уже придираюсь.
Чек-лист: о чем говорить
По-настоящему обсудите «Кто?». Пожалуйста, не говорите о пользователях вообще. Будьте конкретны. Ясно называйте тех пользователей, которых подразумеваете. Например, с Гэри мы говорили об администраторе группы или ее фанатах.
Говорите о разных типах пользователей. У многих видов программного обеспечения, особенно коммерческого, существует множество типов пользователей, работающих с одной и той же функциональностью. Обсудите функциональность с точки зрения разных пользователей.
Говорите о заказчиках. В случае разработки коммерческих продуктов заказчик (или лицо, принимающее решение о покупке) зачастую может быть одновременно и пользователем. Но, рассматривая корпоративные продукты, необходимо обсуждать также тех, кто принимает решение, организацию в целом и выгоды, которые они получают.
Говорите обо всех заинтересованных сторонах. Обсуждайте людей, спонсирующих покупку программы. Говорите о других людях, которые могут сотрудничать с вашими пользователями.
Случаи, когда можно учитывать только одного пользователя, очень редки.
Как следует обсудите «Что?». Я очень люблю, когда истории начинаются с пользовательских задач – действий, которые пользователи хотят выполнить, применив мой программный продукт. Но что же делать с сервисами, работа которых не видна в пользовательском интерфейсе, – теми, которые авторизуют вашу кредитную карту для покупки или пускают вас на сайт страховки? Вашим пользователям не приходится явно делать выбор, чтобы авторизовать свои кредитные карты или подтвердить введенные данные для авторизации. Поэтому не только можно, но и нужно обсудить самые разные сервисы и системы, которые могут их вызывать. Стоит также рассмотреть особые компоненты UI и поведение экрана. Просто не упускайте из виду заинтересованных людей и их мотивы.
По-настоящему обсудите «Почему?». Обговорите самые разные заботы и нужды пользователей. Как следует погрузитесь в «Почему?», потому что, как правило, их несколько и они накладываются друг на друга. Можно очень долго «тыкать их палочкой», чтобы наконец выявить истинные мотивы, лежащие в основе всего.
Обсудите мотивы других пользователей. Обсудите мотивы компании, в которой работают пользователи. Обсудите мотивы всех сторон, заинтересованных в бизнесе. Исследуя «Почему?», можно сделать множество интереснейших открытий.
Обсудите то, что происходит за рамками программного обеспечения. Подумайте, где и когда люди могут использовать ваш продукт, как часто они это делают. Представьте себе, кто еще может присутствовать при использовании продукта. Все эти факторы могут вам помочь нащупать наилучшее решение.
Обсудите, что произойдет, если все пойдет не так. Что будет, если произойдет какой-то сбой? Что случится, если система вдруг прекратит работу? Какими альтернативными способами пользователи могут достичь своих целей? Как они удовлетворяют свои нужды сейчас?
Обсудите вопросы и предположения. Если вы проговорите все это, то, скорее всего, столкнетесь со многими вещами, о которых не знаете. Сформулируйте свои вопросы и обсудите, насколько важно получить ответы перед тем, как приступить к работе над программным обеспечением. Нужно решить, кто проделает все необходимое для получения информации, и сохранить вопросы до следующего обсуждения. Как вы убедитесь, порой для полного рассмотрения некоторых историй требуется очень долго их обсуждать.
Запланируйте время на проверку своих предположений. Действительно ли вы понимаете пользователей? Вы точно знаете, чего они хотят? Реальны ли их проблемы? Смогут ли они, используя ваше решение, справиться с этими проблемами?
Рассмотрите также свои технические предположения. На какие базовые системы мы полагаемся? Будут ли они в самом деле работать так, как мы планируем? Есть ли какие-то технические риски, которые необходимо учесть?
