Больше, чем plain vanilla scrum. Общепринятые практики работы с требованиями

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

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

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

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


    Итак:

    Общепринятые практики работы с требованиями в Скрам


    Структурированные карты требований

    Видение проекта и высокоуровневые требования хранить в виде беклога неудобно. Это не одномерные списки. Идеи — это списки со сложными связями. Для работы с идеями проекта современные Владельцы Продуктов и аналитики используют специализированные техники и форматы. Двумя популярными специализированными техниками являются карты пользовательских историй (user story mapping) и карты влияния (impact mapping) — специализированные mind-мепы.

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

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

    Команда Владельца Продукта

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

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

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

    Сессии груминга беклога

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

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


    Доски процесса анализа

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

    Пример состояний такой доски:
    Новые идеи
    (5)
    Детализация
    (3)
    Готово для груминга с командой
    (3)
    Прототипирование
    (3)
    Проработка интерфейсов
    (3)
    ... Готово для планирования в спринт
    (10)


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

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

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

    В следующих статьях я поделюсь своими наблюдениями об общепринятых практиках взаимодействия в команде, планированием, слежением за ходом проекта и поставками.
    SCRUMguides
    Company
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 2

      +1
      Ммм, канбан доска для отслеживания статуса проработки задач — это хорошая мысль!
        0
        Артём Сердюк придумал отличную альтернативу шаблону бизнес-модели Остервальдера — более интуитивный и наглядный канвас в виде воздушного шара. Думаю, скоро Артём представит его широкой общественности.

        Использовал этот канвас уже в четырёх проектах и получил массу положительных отзывов — от заказчиков, партнёров и, самое главное, разработчиков, которым я первым делом объясняю бизнес-модель заказчика и дорожную карту проекта, а уж потом мы составляем карту эффекта (тот самый impact map). Это серьёзно повышает предметную ориентированность команды и хорошо проецируется на цели спринтов.

        Надеюсь, со временем применение данного инструмента тоже станет общепринятой техникой для скрам-команд. По крайней мере, я буду прикладывать к этому все необходимые усилия.

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