Здравствуйте, дорогие читатели.
Сегодня мы хотели бы поговорить с вами о важном аспекте гибкого управления проектами, не о чистом Agile, а о планировании проектов и итераций.
Речь пойдет о жанре «User Stories», которому посвящена очень успешная на Западе книга Джеффа Паттона с предисловием Мартина Фаулера: 
В статье, текст которой ждет вас под катом, мы перевели «User Story Mapping» как «функциональная визуализация».
Вариант взят из очень интересной книги Бориса Вольфсона" Гибкое управление проектами и продуктами ", также изданное нашим издательством.
Итак, автор статьи прочитал работу Паттона и решил, что это должен сделать каждый.
Насколько убедительно он приводил примеры – судить вам.
Одной из ключевых целей при планировании проекта является сбор требований.
Но зачастую бывает трудно понять, с чего начать и на чем сосредоточиться.
Визуализация функционала (история маппинга) — это увлекательная работа, где все члены команды участвуют в формировании списка требований (бэклога) — расклеивая карточки на стене, а не написав скучное 100-страничное техническое задание.
Этот метод визуализации функциональности был изобретен Джефф Паттон и он мне об этом рассказал Чираг Доши .
Я считаю, что это очень эффективный и полезный способ фиксации требований на этапе проектирования проекта.
Составление функциональной карты Функциональная визуализация — это нисходящий способ сбора требований, представленных в виде дерева.
Прежде чем приступить к визуализации, необходимо обрисовать весь проект. Для этого ставятся цели.
Для достижения цели необходимо выполнить определенные действия.
И чтобы выполнить действие, пользователь должен решить задачу.
При разработке программного обеспечения конкретные задачи можно сформулировать в виде пользовательских историй.
Структура карты: Цели – Действия – Задачи – Истории Рассмотрим для примера приложение для работы с интернет-магазином, в рамках которого выделим конкретную цель: «найти товар».
Чтобы лучше понять весь процесс, давайте визуализируем эту функциональность на карте.
Достичь цели «найти товар» можно несколькими способами, например «просмотреть дерево с каталогом товаров», «использовать текстовый поиск», «просмотреть акционные товары».
Остановимся на втором варианте — «просмотреть дерево с каталогом товаров» и визуализировать такой функционал.
' 
Далее, чтобы добраться до нужного продукта, пользователю необходимо выполнить определенные задачи, 
Теперь эти задачи можно сформулировать в виде пользовательских историй и перейти к разработке программы.
Так что продолжаем детально прорабатывать каждую ветку функционала, начиная с целей и заканчивая всей картой.
По моему опыту, полная визуализация функционала может занять от трёх дней до двух недель, в зависимости от размера и сложности проекта.
Для справки: вот «ветвь» от одной функциональной визуализации, взятой из реального проекта, 
А вот как выглядит вся карта после пяти дней работы: 
Итак, разобравшись с визуализацией функционала, давайте обсудим, в чем преимущества такого подхода.
Преимущества функциональной визуализации
- Визуальное представление бэклога (общая картина) позволяет всем желающим работать в одной плоскости и вместе оценивать объем и сложность работы.
Кроме того, эта работа косвенно помогает понять масштаб проекта.
- Записывая требования на бумаге, улучшается коммуникация и формируется общее понимание работы.
- Поскольку время на разработку проекта обычно ограничено, визуализация функций помогает глубже погрузиться в проект и сосредоточиться на важных аспектах приложения.
Если вы пометите «желаемые» функции как «второстепенные», вся команда сэкономит время разработки.
- Интересно, что если приклеить все «истории» на стену, команде становится проще соотносить их размеры.
- Структурирование проекта в виде карты помогает расставить приоритеты задач и легко сегментировать бэклог на релизы, указывая минимально жизнеспособную версию каждого релиза.
Сегментация может быть горизонтальной или вертикальной: например, мы выбираем ограниченное количество признаков или выбираем множество признаков, но в каждом из них обозначаем уровень минимальной жизнеспособности.
- Визуальную карту можно преобразовать в бэклог с помощью специальных инструментов Agile-разработки, например, Пообщаться .
Вот несколько практических примеров:
- Разные цвета обозначают разные уровни карты.
Например, цели будут оранжевыми, функции — синими, истории — зелеными, а истории — желтыми.
- Каркасная модель размещается рядом с соответствующей областью карты.
- Организуем специальную пометку с помощью специальных стикеров – например, в виде точек или звездочек:
- Важно также отмечать второстепенные функции, чтобы у всех было общее понимание проекта.
- Важно выделить альтернативные варианты, чтобы UX был богаче, а непрофильные решения не были слишком дорогими.
Альтернативные способы визуализации функциональности При визуализации функциональности важно сначала определиться со структурой, а затем при необходимости изменить ее.
Необходимо представить структуру проекта в самом начале работы и отталкиваться от нее.
Иногда полная структура получается только после двух-трех итераций.
Одна альтернативная структура называется «путешествия пользователя».
Такой подход помогает определить требования с точки зрения пользователя — например, покупателя, продавца, администратора и т. д. В этом случае визуализация принимает вид Пользователь – Цели – Путешествия – Действия – Истории .
Другой альтернативой, особенно при разработке НФР (нефункциональных требований), может быть: НФР – Требование – История .
Полная карта крупных проектов может содержать до шести уровней.
Однако в типичном проекте обычно достаточно 3-х уровней.
Подготовка к функциональной визуализации
Итак, вы полны решимости начать свой следующий проект с функциональной визуализации.
Вот что вам для этого понадобится:
- Большой конференц-зал со свободными стенами, который будет в вашем распоряжении на весь период реализации проекта.
- Разноцветные наклейки, по одной на каждый уровень.
- Маркеры жирного шрифта, чтобы надписи на наклейках легко читались издалека.
- Специальные стикеры (точки или звездочки) — для записи дополнительной информации на карте.
- Маркерная доска, на случай, если неудобно в некоторых местах клеить наклейки на стены.
- Хорошая камера, чтобы сфотографировать всю карту.
Ниже приведены несколько советов, как избежать распространенных ошибок и успешно справиться с визуализацией.
- На этапе функциональной визуализации мы знакомимся с требованиями к продукту, а потому обязательно фиксируем все возможности вместе с альтернативами, чтобы избежать бесконечных дискуссий.
- Вдаваясь в детали, мы регулярно расставляем приоритеты, чтобы не тратить время на неважные темы.
- Мы регулярно удаляем ненужные наклейки, чтобы они не превращались в огромную бесконечную кучу.
Оставляем удобные проходы вдоль стен.
- Работая с наклейками, мы следим, чтобы они не гнулись и не склеивались на протяжении всего проекта – иначе их будет трудно увидеть на фотографиях.
Такой подход помогает прийти к общему пониманию проблемы, выделить существующие пробелы в бэклоге, уловить взаимозависимости и более точно оценить относительные размеры стадий проекта.
В дальнейшем такая визуализация помогает правильно сегментировать проект и адекватно планировать время подготовки всех релизов.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Актуальность книги 77,11% Да, книга очень нужна 64 15,66% Узкая тема, неинтересно 13 1,2% Читал в оригинале, не понравилось 1 13,25% Пожалуйста, перепечатайте книгу Бориса Вольфсона 11 Проголосовали 83 пользователя.
38 пользователей воздержались.
Теги: #Управление разработкой #Управление проектами #Бизнес-модели #agile #пользовательские истории #книги #книги #итерации
-
Планшет Android – Волшебная Штуковина
19 Oct, 24 -
Что Мы Знаем О Лучших Ноутбуках
19 Oct, 24 -
Интервью О Прошлом И Будущем Библиотек C++
19 Oct, 24 -
Ультимейкер Внутри Ультимейкера
19 Oct, 24 -
Firefox Затмил Ie6 И Угрожает Ie7
19 Oct, 24
