После выполнения несложного упражнения по составлению историй и организации их в карту все мы сформировали единое понимание того, как происходит процесс сейчас. Теперь можно было приступать к преобразованию этой карты в программное обеспечение, где точно такой же процесс должен был происходить в будущем.
С программами труднее
Я не хочу вас обманывать. Если вы профессионал в области разработки программного обеспечения, возможно, вам потребуется некоторое время, чтобы перейти от обсуждения экранов и функций к записи коротких глагольных фраз, которые формулируют то, что пытаются в реальности проделать люди. Продолжайте практиковаться. У вас получится.
Но если вы не знаете, кто ваши пользователи, чего они хотят достичь и как с этим справляются, будет гораздо труднее. К сожалению, попытка построить карту в этих условиях приведет лишь к выявлению того, что вам неизвестно. Если вы оказались в такой ситуации, лучшее, что вы можете сделать, – это изучить пользователей, их цели и задачи. Еще лучше, если вам удастся напрямую поработать с ними и построить карту вместе.
Я хочу свести главное из предыдущих четырех глав в шесть простых шагов. Вы можете задаться вопросом: «Почему он не сделал этого с самого начала?» Что ж, я мог бы пропустить все эти рассуждения и истории и просто перечислить требования. Но толку от этого не было бы никакого.
Мне известно множество работающих способов построения и использования карты историй, поэтому я вывел такой шестишаговый процесс, лучше всего подходящий для меня.
1. Сформулируйте проблему: для кого вы это делаете, зачем вы это делаете?
2. Обрисуйте общую картину. Концентрируйтесь на широте, а не на глубине, продвигайтесь на милю вперед и на дюйм вглубь (или на километр вперед и на сантиметр вглубь – для моих неамериканских друзей). Если у вас нет готового решения или даже если, как вам кажется, оно есть, попробуйте построить карту по состоянию на сегодня, включая проблемы и преимущества, которые отмечаются у ваших пользователей.
3. Исследуйте. Углубляйтесь и обсудите другие типы пользователей и то, как еще они могут выполнять свои задачи, а также варианты их действий, если (или, скорее, когда) что-то пойдет не так. Для пущей уверенности нарисуйте эскизы, составьте прототипы, протестируйте их, усовершенствуйте идеи решений, по ходу дела меняя и расширяя карту.
4. Выделите релизную стратегию. Помните: времени и ресурсов всегда не хватает. Концентрируйтесь на том, чего хочет достичь ваш бизнес, а также на людях, для которых создаете продукт. Выбросите вон все, что не нужно для реализации минимальных решений, которые, с одной стороны, удовлетворят нужды людей, с другой – помогут вашей организации достичь ее целей.
5. Выделите исследовательскую стратегию. Можете сформулировать то, что, по вашему мнению, является минимально жизнеспособным решением, но не забывайте, что это только гипотеза, пока не убедитесь в обратном. Используйте карту и обсуждения, чтобы выявить самые рискованные элементы. Разделите карту на совсем маленькие срезы минимально жизнеспособных продуктов-экспериментов. Вы сможете показать их группе пользователей и выяснить, что на самом деле для них полезно.
6. Выделите стратегию разработки. Если вы отбросите все, что не должны предъявить пользователям, останется то, что должны. Теперь разделите минимально жизнеспособное решение на части с точки зрения последовательности разработки. Сконцентрируйтесь на реализации пораньше – так вы быстрее обнаружите технические проблемы и риски разработки.
Карта только начало
Построение карты помогает вам охватить взглядом общую картину, иными словами, увидеть лес за деревьями. Это одно из самых больших преимуществ построения карты историй. Но если вы один из ответственных за посадку леса, у вас нет иного пути, кроме как сажать одно дерево за другим. Вы уже знаете два важных правила работы с картами историй.
• При изложении историй используйте как слова, так и рисунки, для того чтобы выработалось одинаковое понимание.
• Не говорите только о том, что нужно разработать, – обсуждайте, кто будет использовать продукт и почему таким образом вам удастся минимизировать объем работы и обеспечить максимальный реальный результат.
Держите это в уме, и все мало-помалу получится.
Мы уже обсудили несколько тактик использования историй, чтобы избежать ошибок. Поговорим еще о нескольких моментах, которые помогут вам правильно применять истории.
Карты пользовательских историй в SAP – суть в масштабировании
Андреа Шмиден
Когда Джефф впервые представил свою концепцию карт пользовательских историй, мы сразу увидели, какую пользу она может принести SAP. Создалось впечатление, что этот простой, но мощный метод может помочь трансформировать видение продукта в бэклог, а также разобраться, что мы разрабатываем, для кого и зачем. Поэтому мы решили его опробовать.
Однако, как мы вскоре убедились, то, что легко и просто для одиночного разработчика или отдельной команды, работающей по Scrum, совершенно иначе выглядит для группы по разработке продукта, состоящей из нескольких Scrum-команд. В SAP, огромной организации, где работают около 20 000 разработчиков, привычны огромные команды, работа которых зависит от других команд. Здесь это норма, а не исключение. Нам нужен был работающий способ масштабировать карты пользовательских историй для такой большой организации.
Задача
Сложная задача, стоящая перед нами, включала в себя два аспекта.
• Как составить карты сложных продуктов и не утонуть в куче стикеров?
• Как внедрить метод в организации по разработке и научить людей его использовать?
1. Карты пользовательских историй для крупных продуктов
В поиске ответа на первый вопрос мы решили, что самым лучшим будет провести несколько пилотных семинаров по проработке существующих проектов. Начали с небольшой команды самых заинтересованных сотрудников и приблизительно десяти пилотных проектов, над самым большим из которых работали 14 Scrum-команд. В этой пилотной фазе мы опробовали метод по-разному в нескольких видах: формат проведения семинара, содержание, фазы проекта, формат карты и т. д. Проведя несколько раундов с получением обратной связи и определения итераций, мы выделили набор хороших практик, которые, как оказалось, неплохо работают при разработке проектов большого размера.
Ключевые хорошие практики
Если команда пробует использовать карты историй в первый раз, мы рекомендуем привлечь к делу опытного тренера. На встрече с приглашающей стороной тренер обсуждает цели семинара, приглашенных, повестку дня, соответствующие вводные данные и т. д. Обычно он проводит однодневный семинар со всей командой, а затем при необходимости мы устраиваем более короткие сессии.
Работу в день семинара мы, как правило, начинаем с упражнения по видению продукта вроде хорошо известных «речи в лифте» или «темы номера», когда члены команды описывают, что бы они хотели прочитать о своем продукте в статье отраслевого журнала через год. Таким образом становится хорошо видно, есть ли у команды общее понимание основного направления работы, или необходимы дополнительные исследования (например, дополнительные интервью, создание прототипов, тестирование прототипов и т. д.).
На следующем шаге в фокусе оказываются типичные пользователи продукта. Если цель семинара – получить детализированный бэклог, пользовательские роли или персонажи должны быть получены на стадии пользовательского исследования. Если же проект находится на ранней фазе, команда записывает свои предположения, которые потом будут проверены при исследовании пользователей. Мы уже убедились в том, что это отличная подготовительная работа для исследования, – вот еще один аспект, когда дизайнерское мышление и практики составления карт пользовательских историй отлично дополняют друг друга.
После этого переходим к составлению пользовательских историй, последовательно проходя три уровня.
1. Сначала определяются высокоуровневые последовательности шагов по использованию продукта.
2. Затем последовательности шагов разбиваются на более четкие операции согласно пользовательским ролям.
3. Из пользовательских ролей выделяются конкретные пользовательские истории в формате «как <роль>, я хочу <функциональность>, что даст мне <выгоду>». Эти пользовательские истории включаются в первый вариант продуктового бэклога.
Такой трехуровневый процесс особенно полезен для больших продуктов. На каждом уровне команда может решить, когда имеет смысл погрузиться в обсуждение деталей и где следует рассмотреть зависимости от других команд. Этот подход позволяет сконцентрироваться на ключевых задачах разработки, держа в уме общую картину.
Чтобы читать карту было проще, мы используем стикеры определенных цветов для операций, а также для пользовательских историй, относящихся к определенным персонажу или роли, как вы можете видеть на графике.
Часто во время работы команды над картой выявляются дополнительные аспекты, так называемые белые пятна – области, где нужно выполнить больше исследований, или вопросы без ответов, зависимости, пробелы. Чтобы выделить эти проблемы, мы используем стикеры определенного цвета или размера. На первый взгляд может показаться, что помещать открытые проблемы на карту неудобно, но, как мы убедились по опыту, это один из самых полезных аспектов в процессе составления карт историй: вы получаете ясное и осязаемое представление элементов, которые требуют дальнейшего уточнения. После того как все проблемы оказываются на доске, обрабатывать их становится намного проще.
Как только команда обработала все детали (в разумной степени), мы расставляем пользовательские истории в бэклоге по приоритету. В зависимости от размера проекта и его фазы иногда это делается скорее на уровне пользовательских операций, а не пользовательских историй. Обычно мы пользуемся простыми техниками голосования, например точечной техникой, но иногда применяем для голосования упрощенную модель Кано, согласно которой команды помечают пользовательские истории как «обязательно», «желательно» и «опционально». Результаты этого простого голосования также являются хорошей основой для окончательной расстановки историй с участием других заинтересованных сторон, конечных пользователей и заказчиков.