Если вы ещё не читали статью Майка Кона "Правила против общепринятых практик в Скраме", то я рекомендую вам с ней ознакомиться. Статья о практиках, которые довольно часто встречаются в Скрам-проектах, но не являются базовыми правилами Скрам.

Скрам поощряет подобные добавления. Более того, он специально построен минималистично, дабы команды могли добавить то, что им по вкусу. Не стоит путать подобные улучшения процесса с печально известным Скрам-ном. В отличие от последнего, добавленные практики улучшают процесс, повышая эффективность выпуска продуктов и выравнивая поток работ.

Сегодня я хочу поделиться разнообразными практиками по работе с требованиями.

За последние несколько лет перечисленные практики мне не раз довелось наблюдать за кулисами у успешных команд в роли Agile-коуча и рассказывать о них на тренингах Certified ScrumMaster в роли Скрам-Тренера.

Конечно же, это далеко не полный список практик, я буду рад услышать дополнения. Некоторые из перечисленных практик заслуживают отдельных статей, но пока они "work in progress".

Итак:

Целостное видение проекта и высокоуровневые требования хранить в виде беклога неудобно.

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

Двумя популярными специализированными техниками являются карты пользовательских историй (user story mapping) и карты влияния (impact mapping) — специализированные mind maps.

В настоящее время не так много электронных инструментов поддерживают создание подобных карт. Но Google docs для story mapping и обычный mind-mapping tool для карт влияния неплохо справляются с этими задачами.

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

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

Такие группы сейчас принято называть Командой Владельца Продукта. 

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

Когда и кем составляется беклог?

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

Вместо этого частой практикой является проводить во время спринтов запланированные встречи по проработке беклога. В иностранной литературе используется термин backlog grooming (буквально — «ухаживать»). 

В течение этих сессий участники:

По мере работы Команды Владельца Продукта и их груминг-сессий возникает немало артефактов и требований на разных фазах анализа. Для удобства управления потоком этой работы используются Канбан-доски. 

Как вы можете заметить, последняя колонка такой доски — это, собственно, и есть беклог продукта.

Именно эти готовые истории попадают в планы спринта.

Подобная доска может быть легко объединена с доской по разработке, что предоставит единый пульт управления проектом от идеи до релизов.

Какие еще практики работы с требованиями используете вы в Скраме?

Статья переопубликована с https://habrahabr.ru/

Февраль 2013