- PVSM.RU - https://www.pvsm.ru -
Недавно, на Скрам портале была опубликована статья Майка Кона об Общепринятых практиках в Скраме [1] — практиках, которые довольно часто встречаются в Скрам-проектах, но не являются базовыми правилами Скрам.
Скрам поощряет подобные добавления и специально построен минималистично, дабы команды могли добавить то, что им по вкусу. Не стоит путать подобные улучшения процесса с печально известным Скрам-ном. В отличие от последнего, добавленные практики улучшают процесс, повышая эффективность выпуска продуктов и выравнивая поток работ.
Сегодня я хочу поделиться множеством таких практик, собранных вокруг работы с требованиями. За последние несколько лет перечисленные практики мне не раз довелось наблюдать за кулисами у успешных команд в роли agile-коуча и рассказывать о них на тренингах Certified ScrumMaster [2] в роли скрам-тренера.
Я ни в коем случае не претендую на полноту практик и буду рад услышать дополнения. Некоторые из перечисленных практик заслуживают отдельных статей — это work in progress.
Итак:
Структурированные карты требований
Видение проекта и высокоуровневые требования хранить в виде беклога неудобно. Это не одномерные списки. Идеи — это списки со сложными связями. Для работы с идеями проекта современные Владельцы Продуктов и аналитики используют специализированные техники и форматы. Двумя популярными специализированными техниками являются карты пользовательских историй (user story mapping [3]) и карты влияния (impact mapping [4]) — специализированные mind-мепы.
В настоящее время не так много электронных инструментов поддерживают создание подобных карт. Но Google docs для story mapping и обычный mind-mapping тул для карт влияния неплохо справляются с этими задачами.
Работает это так: идеи проекта на ранней фазе составляются в виде визуальных карт. Это удобный и естественный способ. После чего, по мере хода проекта, Владелец Продукта во время груминг сессий (см ниже) наслаивает из этих карт пользовательские истории. Таким образом беклог продукта никогда не переполнен и состоит из небольшого управляемого подмножества элементов требований.
Команда Владельца Продукта
В большинстве проектов, которые мне довелось наблюдать за последние несколько лет проработкой требований занимается большем, чем один человек. Иногда это пара человек, чаще — группа, состоящая из менеджеров продуктов, аналитиков, специалистов предметной области, архитекторов, представителей конечных пользователей.
Такие группы сейчас принято называть Командой Владельца Продукта.
Такая практика нисколько не идет в разрез с правилом Скрам о наличие только одного Владельца Продукта. Такая команда управляется одним стратегическим менеджером, который владеет высокоуровневым видением продукта, направляет и координирует работу группы.
Сессии груминга беклога
Когда и кем составляется беклог? Выполнение этой работы между спринтами приводит к резанной загрузке Команды Владельца Продукта и зачастую оттягивает запуск спринтов, ухудшая качество планов.
Вместо этого, частой практикой является проводить во время спринтов запланированные встречи по проработке беклога. В иностранной литературе используется термин backlog grooming [5] (буквально — «ухаживать»). В течение этих сессий участники:
Доски процесса анализа
По мере работы Команды Владельца Продукта и их груминг сессий возникает немало артефактов и требований на разных фазах анализа. Для удобства управления потоком этой работы используются Канбан-доски.
Пример состояний такой доски:
Новые идеи (5) |
Детализация (3) |
Готово для груминга с командой (3) |
Прототипирование (3) |
Проработка интерфейсов (3) |
... | Готово для планирования в спринт (10) |
Как вы можете заметить последняя колонка такой доски — это собственно беклог продукта. Именно эти готовые истории попадают в планы спринта.
Подобная доска может быть легко объединена с доской по разработке, что предоставит единый пульт управления проектом от идеи до релизов.
Какие еще практики работы с требованиями используете вы в Скраме?
В следующих статьях я поделюсь своими наблюдениями об общепринятых практиках взаимодействия в команде, планированием, слежением за ходом проекта и поставками.
Автор: krivitsky
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/28104
Ссылки в тексте:
[1] Общепринятых практиках в Скраме: http://scrummaster.ru/home/the-rules-vs-the-generally-accepted-practices-of-scrum
[2] Certified ScrumMaster: http://scrumguides.com.ua/scrummaster-product-owner-certifications/
[3] user story mapping: http://scrumguides.com.ua/articles/kak-myi-zapuskaem-proektyi
[4] impact mapping: http://impactmapping.org/
[5] backlog grooming: http://scrumguides.com/articles/uhod-za-beklogom-gruming-ili-kak-sdel/
[6] Источник: http://habrahabr.ru/post/170767/
Нажмите здесь для печати.