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

На нескольких примерах озвучу возможные варианты, и каждый сможет подобрать наиболее близкий к своей ситуации.

Пример первый: одна команда разработки.

Предположим, у вас есть Скрам команда из 5-7 человек. Команда, скорее всего, кросс-функциональная и в ней есть все люди, необходимые для превращения идеи (требования и т.п.) в работающий и потенциально готовый продукт.

И эта команда работает над одним проектом (продуктом), а значит, ей нужен всего лишь один Бэклог Продукта (product backlog). Бэклог продукта отсортирован по приоритетам, которые в свою очередь составляются на основе ценности, рисков и критичности каждого из элементов бэклога (требований, пожеланий).

Правда, чтобы команду обеспечить работой, то часто ей находят больше чем один продукт, а есть еще поддержка и доработка старых проектов. И вот ваш Бэклог Продукта скапливает в себе пожелания из разных областей. Нужно ли делать их отдельными списками? Моя настоятельная рекомендация – НЕТ.

Сама суть единого и плоского списка всех требований в том, что команда может сфокусироваться на том, что самое важное для бизнеса – т.е. на том, что находится сверху списка. И это уже задача представителей бизнеса (или хотя бы менеджмента) принимать решения о приоритетах между разными проектами. Команда не лучший советчик в этом вопросе, даже если вы сами придумываете свои продукты :-).

Когда все в одном списке (пусть даже с пометками о разных продуктах/системах) все равно для команды существует возможность сфокусироваться на определенном объеме, который можно закончить за спринт (итерацию) фиксированной длины. Если повезет, то можно группировать требования по «Релизам» и фокусироваться на одном продукте на несколько итераций. Хотя, даже если у вас одна итерация состоит из требований к разным продуктам – это все равно позволяет команде давать реалистичные обещания.

Пример второй: две команды.

Представим себе, что наша первоначальная команда еще немного подросла и теперь там 9-10 человек. И как-то складывается, что они тяготеют к подгруппам, которые выбирают себе требования по нескольким продуктам. И гениальная мысль посещает команду: «давайте разобьемся на две команды». Ок, хорошо, стоит ли делить и Бэклог Продукта?

Мой личный опыт показывает, что это не самая лучшая мысль, пусть она и приходит в голову первой. Стоит помнить, что бизнес представители по-прежнему должны принимать решения о приоритетах между продуктами. Зачем их путать, это легче делать в едином списке :-). А дальше уже как повезет…

Вариант 1: продукты полностью независимые и на время выпуска одного из них команды работают полностью автономно. Что я могу сказать – повезло :-). В этом случае можно сделать отдельные «Бэклоги релиза» по разным продуктам и каждая команда сосредоточится на чем-то одном до выпуска. А после этого возможно поменяет состав или просто возьмет следующий продукт/выпуск. Считайте, что у вас просто разные команды.

Вариант 2: продукты на одной платформе или зависимой функциональности. Вот тут то и начинается самое интересное. С одной стороны, срабатывает рефлекс «разделиться», о котором говорилось выше. С другой стороны, приоритеты у требований общие и зачастую даже добавляется техническая зависимость как риск/критичность.

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

Пример третий: много команд (и один продукт).

Такая ситуация возникает, когда вы работаете на очень большом проекте (да, бывают и такие). Предположим у вас есть коллектив в 20 и более человек, все работают над одним большим продуктом, который пусть и состоит из разных модулей (подсистем), все равно, сильно связан единым кодом, взаимодействием систем и т.п. Более того, всех этих людей объединяет единая цель ;-).

В целом, этот пример похож на предыдущий случай (Вариант 2 из примера с двумя командами). Представители бизнеса во главе с Владельцем Продукта (Product Owner) ведут единый Бэклог Продукта. Команды планируют свои спринты отдельно, объединяя требования по тематической функциональности, технологиям или архитектуре.

И, пожалуй, командам нужно очень часто обмениваться информацией, так как велика вероятность, что будут чисто технические пересечения. Это можно решать путем дополнительных ежедневных встреч, между несколькими представителями каждой команды. Кстати, это называется Скрам-Скрамов (Scrum-of-Scrum).

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