Эта статья снова родилась просто из повседневной практики. Признаться, Story Map для проектов мы начали строить не так давно, до этого мы обходились просто написанием общих концептов. Однако после внедрения Story Mapping мы сразу получили массу плюсов от этой практики. А плюсы эти появляются еще до того, как начинается непосредственно разработка проекта. В общем, сегодня расскажу о том, как мы это делаем и что в итоге получаем.
Началось все с того, что нам нужно было оценить разработку проекта. Планируемый объем работ был достаточно большой (в целом разработка оценивалась примерно в 5 месяцев), поэтому проект нужно было разделить на два этапа. Что будет в первой, а что попадет во вторую версию пока не было до конца понятно. К этому времени у нас уже был написан концепт-документ на основе наших интервью заказчика, кратко, но практически полностью, описывающий будущий продукт.
Чем плох концепт-документ или ТЗ? Он напрямую не отражает динамики проекта, не показывает приоритетов, плохо показывает масштаб. Кроме того, т.к. приоритизации нет, усложняется планирование релизов. Все эти нюансы являются препятствиями для реализации наших задач: оценки разработки и составления плана релизов.
Можно было поступать по-старинке: делать "плоскую" декомпозицию задач, оценивать их, строить план релизов и работать. Но тогда мы решили повысить нашу эффективность и попробовать построить Story Map. Суть в том, что мы раскладываем все пользовательские сценарии (User Story) по двум осям: время и приоритет. Схематично это выглядит вот так:
В самой верхней части карты находятся самые большие задачи, что-то большое, что пользователи могут делать в системе, их называют активностями (Activity). Например, "Управление сервером" или "Администрирование". Или так: "Я, как администратор, могу настраивать конфигурацию сервера, чтобы предотвращать неполадки и проводить мониторинг".
Понятно, что такие пользовательские истории слишком большие, чтобы их можно было целиком включать в итерацию, поэтому они разбиваются на Задачи. Например, "Настройка сокетов", "Настройка тайм-аутов". Далее Задачи разбиваются на Подзадачи. Например, "Установка тайм-аута на исходящие подключения", "Установка тайм-аута на повторные подключения". В результате получается визуальное представление будущего проекта.
Приоритетность задач меняется путем вертикального перемещения. Горизонтально активности располагаются в порядке использования системы. К примеру, "Регистрация", потом "Настройка личного кабинета", затем "Публикация контента" и т.д. То есть в последовательном порядке. Какие-то активности все-таки будут вне этой последовательности, но это нормально.
Мы строим Story Map прямо на окнах в офисе, а потом переносим его в цифровой вид, чтобы он всегда был под рукой у клиента и у нас. Вот так выглядит живой пример Story Map для первого этапа реального проекта:
Что в результате мы получили? Визуальное представление будущего проекта, которое ясно дает понять его функционал, а также явно определяет приоритетность той или иной части.
После окончания Story Mapping, из получившейся карты строится бэклог (Backlog) проекта и начинается разработка :). Кстати, карта может иногда меняться в силу изменений каких-то требований или условий бизнеса клиента.
Подобные практики визуализации работы — это способ разъяснить себе и клиенту суть решаемых задач, чтобы их понимание было одинаковым. Эффективно взаимодействовать можно только с простыми вещами. Story Mapping — это один из способов упросить предмет, с которым мы взаимодействуем (проект ПО).
The New User Story Backlog is a Map, Jeff Patton.
Началось все с того, что нам нужно было оценить разработку проекта. Планируемый объем работ был достаточно большой (в целом разработка оценивалась примерно в 5 месяцев), поэтому проект нужно было разделить на два этапа. Что будет в первой, а что попадет во вторую версию пока не было до конца понятно. К этому времени у нас уже был написан концепт-документ на основе наших интервью заказчика, кратко, но практически полностью, описывающий будущий продукт.
Чем плох концепт-документ или ТЗ? Он напрямую не отражает динамики проекта, не показывает приоритетов, плохо показывает масштаб. Кроме того, т.к. приоритизации нет, усложняется планирование релизов. Все эти нюансы являются препятствиями для реализации наших задач: оценки разработки и составления плана релизов.
Можно было поступать по-старинке: делать "плоскую" декомпозицию задач, оценивать их, строить план релизов и работать. Но тогда мы решили повысить нашу эффективность и попробовать построить Story Map. Суть в том, что мы раскладываем все пользовательские сценарии (User Story) по двум осям: время и приоритет. Схематично это выглядит вот так:
В самой верхней части карты находятся самые большие задачи, что-то большое, что пользователи могут делать в системе, их называют активностями (Activity). Например, "Управление сервером" или "Администрирование". Или так: "Я, как администратор, могу настраивать конфигурацию сервера, чтобы предотвращать неполадки и проводить мониторинг".
Понятно, что такие пользовательские истории слишком большие, чтобы их можно было целиком включать в итерацию, поэтому они разбиваются на Задачи. Например, "Настройка сокетов", "Настройка тайм-аутов". Далее Задачи разбиваются на Подзадачи. Например, "Установка тайм-аута на исходящие подключения", "Установка тайм-аута на повторные подключения". В результате получается визуальное представление будущего проекта.
Приоритетность задач меняется путем вертикального перемещения. Горизонтально активности располагаются в порядке использования системы. К примеру, "Регистрация", потом "Настройка личного кабинета", затем "Публикация контента" и т.д. То есть в последовательном порядке. Какие-то активности все-таки будут вне этой последовательности, но это нормально.
Мы строим Story Map прямо на окнах в офисе, а потом переносим его в цифровой вид, чтобы он всегда был под рукой у клиента и у нас. Вот так выглядит живой пример Story Map для первого этапа реального проекта:
На построение подобной карты может уходить несколько часов.
Что в результате мы получили? Визуальное представление будущего проекта, которое ясно дает понять его функционал, а также явно определяет приоритетность той или иной части.
- Мы и клиент понимаем объем проекта: нам гораздо проще его оценить, а заказчик понимает за что он платит.
- Планирование релизов упрощается: образно говоря, можно просто провести горизонтальную линию, чтобы отсечь все, что на данный момент имеет меньший приоритет.
- Очевидный, но немаловажный факт: обе стороны понимают, как должен работать продукт.
Заключение
После окончания Story Mapping, из получившейся карты строится бэклог (Backlog) проекта и начинается разработка :). Кстати, карта может иногда меняться в силу изменений каких-то требований или условий бизнеса клиента.
Подобные практики визуализации работы — это способ разъяснить себе и клиенту суть решаемых задач, чтобы их понимание было одинаковым. Эффективно взаимодействовать можно только с простыми вещами. Story Mapping — это один из способов упросить предмет, с которым мы взаимодействуем (проект ПО).
Ссылки
The New User Story Backlog is a Map, Jeff Patton.
Комментариев нет:
Отправить комментарий