О важности User Stories

Original author: Sunit Parekh
  • Translation
Здравствуйте, уважаемые читатели.

Сегодня мы хотели бы поговорить с вами о важном аспекте гибкого управления проектами, но не о чистом Agile, а о планировании проекта и итераций. Речь пойдет о жанре «Пользовательских историй», которым посвящена очень успешная на Западе книга Джеффа Паттона с предисловием Мартина Фаулера:



В статье, текст которой вас ждет под катом, мы перевели «User Story Mapping» как «визуализация функционала». Вариант взят из очень интересной книги Бориса Вольфсона "Гибкое управление проектами и продуктами", также выходившей в нашем издательстве.

Итак, автор статьи прочитал труд Паттона и решил, что так должен поступить каждый. Насколько убедительные примеры он привел — судить вам.



Одна из ключевых целей при планировании проекта – общими усилиями собрать требования. Но зачастую бывает сложно решить, с чего начать и на чем сосредоточиться. Визуализация функционала (story mapping) – увлекательная работа, где все члены команды участвуют в формировании списка требований (бэклога) – расклеивают карточки на стене, а не пишут скучную 100-страничную спецификацию.

Такой способ визуализации функционала изобрел Джефф Паттон, а мне об этом рассказал Шираг Доши. Я считаю, что это очень эффективный и полезный способ фиксации требований на этапе продумывания проекта.

Чертим карту функционала

Визуализация функционала — это нисходящий способ сбора требований, которые представляются в древовидной форме. Перед началом визуализации нужно обрисовать себе весь проект целиком. Для этого расставляются цели. Для достижения цели нужно выполнить те или иные действия. А для выполнения действия пользователь должен решить задачу. При разработке ПО конкретные задачи могут быть сформулированы в виде пользовательских историй.

Структура карты: Цели — Действия — Задачи — Истории

Рассмотрим для примера приложение для работы с интернет-магазином, в рамках обращения с которым выделим конкретную цель:‘найти товар’. Чтобы лучше понять весь процесс, визуализируем этот функционал на карте.



Достичь цель ‘найти товар’ можно несколькими способами, например, ‘просмотреть дерево с каталогом товаров’, ‘воспользоваться текстовым поиском’, ‘посмотреть промо-товары’. Остановимся на втором варианте – «просмотрим дерево с каталогом товаров» и визуализируем такой функционал. ‘



Далее, чтобы добраться до желаемого товара, пользователь должен выполнить определенные задачи,



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



Так и продолжаем подробно прорабатывать каждую ветку функционала, начиная с целей и достраивая целостную карту. По моему опыту, на полную визуализацию функционала может уходить от трех дней до двух недель в зависимости от размера и сложности проекта.

Для справки: вот «ветка» из одной визуализации функционала, взято из реального проекта,



А вот как выглядит вся карта после пяти дней работы:



Итак, разобравшись с визуализацией функционала, давайте обсудим, каковы достоинства такого подхода.

Преимущества визуализации функционала

  1. Визуальное представление бэклога (общая картина) позволяет всем заинтересованным поработать в одной плоскости, вместе оценить объем и сложность работы. Кроме того, эта работа косвенно помогает понять масштабы проекта.
  2. При фиксации требований на бумаге улучшается взаимодействие и формируется общее понимание работы.
  3. Поскольку время на разработку проекта обычно ограничено, визуализация функционала помогает глубоко погрузиться в проект и сосредоточиться на важных аспектах приложения. Если помечать «желаемые» фичи как «вторичные», то вся команда экономит время на разработку.
  4. Интересно, что если расклеить на стене все «истории», то команде становится проще соотносить их размеры.
  5. Структурирование проекта в виде карты помогает приоритезировать задачи и с легкостью сегментировать бэклог на релизы, конкретизируя минимально жизнеспособную версию каждого релиза. Сегментирование может быть горизонтальным или вертикальным: например, выделяем ограниченное число фич, либо выделяем много фич, но в каждой из них обозначаем уровень минимальной жизнеспособности.
  6. Визуальную карту можно преобразовать в бэклог при помощи специальных инструментов для Agile-разработки, например, Mingle.


Обогащаем получившуюся карту дополнительной информацией

Иногда требуется зафиксировать на карте проекта сравнительно много информации – например, пометить вопросы, возникшие в ходе работы, альтернативные подходы… все это также попадает в визуализацию. Вот несколько практических примеров:

  1. Разными цветами обозначаем различные уровни карты. Например, цели будут оранжевыми, фичи – голубыми, сюжеты – зелеными, а истории – желтыми.
  2. Рядом с соответствующей областью карты размещается каркасная модель.
  3. Организуем специальную нотацию при помощи особых стикеров – например, в виде точек или звездочек:


  • Важно помечать и вторичные фичи, чтобы у всех было общее представление о проекте
  • Важно выделять альтернативные возможности, чтобы UX получался более насыщенным, а неосновные решения были не слишком затратными


На маленьких стикерах ставим пометки, записываем предположения, предварительные выводы или вопросы

Альтернативные способы визуализации функционала

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

Один вариант альтернативной структуры называется‘пользовательские путешествия’. Такой подход помогает определиться с требованиями с точки зрения пользователя – например, покупателя, продавца, администратора, т.д. В таком случае визуализация приобретает вид Пользователь — Цели — Путешествия — Действия — Истории.

Другая альтернатива, особенно при разработке NFR (нефункциональных требований) может быть такой:
NFR — Требование — История.

Полная карта больших проектов может содержать до шести уровней. Однако в типичном проекте обычно достаточно 3 уровней.



Подготовка к визуализации функционала

Итак, вы твердо намерены начинать следующий проект с визуализации функционала. Вот что для этого потребуется:

  1. Большой конференц-зал со свободными стенами, который будет в вашем распоряжении на весь срок продумывания проекта.
  2. Разноцветные стикеры, по одному стикеру на каждый уровень.
  3. Жирные маркеры, чтобы надписи на стикерах легко читались издалека.
  4. Особые стикеры (точки или звездочки) – чтобы фиксировать на карте дополнительную информацию.
  5. Маркерная доска, на случай, если в каких-то местах клеить стикеры на стены будет неудобно.
  6. Хороший фотоаппарат, чтобы сфотографировать всю карту.


Делюсь опытом

Занимаясь визуализацией функционала, я часто сталкивался с проблемами и преодолевал их. Далее – несколько советов о том, как избежать распространенных ошибок и успешно справиться с визуализацией.
  1. На этапе визуализации функционала мы знакомимся с требованиями к продукту, и поэтому обязательно фиксируем все возможности вместе с альтернативами, чтобы избежать бесконечных дискуссий.
  2. Вдаваясь в подробности, регулярно расставляем приоритеты, чтобы не тратить времени на маловажные темы.
  3. Регулярно убираем ненужные стикеры, чтобы они не превратились в огромную неоглядную кучу. Оставляем удобные проходы вдоль стен.
  4. Работая со стикерами, следим, чтобы они не загибались и не слипались на протяжении всего проекта – иначе их будет сложно рассмотреть на фотографиях.


Заключение

Визуализация функционала – эффективный механизм продумывания требований к проекту, поскольку он очень нагляден. Такой подход помогает прийти к общему пониманию проблемы, выделить имеющиеся пробелы в бэклоге, уловить взаимозависимости, точнее оценить относительные размеры этапов проекта. В дальнейшем такая визуализация помогает правильно сегментировать проект и адекватно спланировать время на подготовку всех релизов.

Only registered users can participate in poll. Log in, please.

Актуальность книги

  • 76.0%Да, книга очень нужна60
  • 16.5%Узкая тема, не заинтересовало13
  • 1.3%Читал в оригинале, не понравилось1
  • 13.9%Допечатайте пожалуйста книгу Бориса Вольфсона11

Comments 6

    0
    Хорошая тема, но по понятным причинам не подходит для удаленной работы, когда команда раскидана по миру. Мы используем диаграммы связей — благо современный интернет дает приличный выбор инструментов для этого.
      0
      Скажите пожалуйста, какими конкретно инструментами пользуетесь? Спасибо
        0
        Для локальной работы (например, когда готовлю структуру самостоятельно) — MindManager. Он очень хорош под винду.
        Когда работаем группой — MindMeister (правда он стоит $15 в месяц для большой команды).
        Иногда приходится работать в XMind, но его функционала порой не хватает.
      0
      «Полная карта больших проектов может содержать до шести уровней»
      уровни чего? проработки требований?
        +1
        Хм, «функционал». https://toster.ru/q/14928
        В блоге издателя ожидаешь грамотного русского.
          0
          Встречал достаточно команд которые активно начинали визуализировать функционал, но, повыкладывав пару недель красочные стены своего кабинета в Инстаграм, завязывали с этим делом.

          Мы как-то тоже попробовали, но, увы, не полетело.

          Я не хочу сказать, что подход плох, просто есть достаточно много мелких, казалось бы, несущественных моментов, которые препятствуют оклеиваюнию рабочего пространства стикерами. Из не очевидных, вроде отсутствия подходящего помещения, на ум сразу приходят:

          — На раннем этапе истории (желтые листки) часто дублируются. Причем какая-нибудь авторизация пользователя может, пусть и формально, присутствовать во всех задачах/действиях;
          — Не всем нравится заниматься этим делом и, лично я считаю, что привлекать команду разработки стоит только на этапе историй, иначе планирование затянется и превратится в процесс обсуждения бизнес-целей с тестерами и фронтендерами;
          — Очень слабый контроль за зависимостями задач (пользовательских историй) и, как следствие, практически полное «переобдумывание» некоторых постановок при переносе в онлайн;
          — Иногда проще просто описать проект каскадным списком (условно приняв, что без отступа — это «идеи», отступ первого уровня — это «действия» и т.д.), чем расклеивать стикеры;

          П.С. Ну и, конечно, плохой почерк участвующих в процессе — ой как мешает сосредоточиться, временами :)

          Only users with full accounts can post comments. Log in, please.