Беклог команды – узаконенное скрам-но или полезное нововведение?

Автор: Алексей Кривицкий

После 15-минутного вступления в Скрам для Владельцев Продуктов от Хенрика Книберга я все чаще встречаю термин «team backlog» в жаргоне аджалистов.

Недавно, отвечая на вопросы от участников тренинга (чуток самопиара не грех) о том, что делать когда «команда одна, а проектов много», словил себя на использовании этого термина.

В кулуарах февральской конференции AgileBaseCamp после мини-доклада Тима Евграшина обсуждался вопрос не является ли командный беклог – отходом от Скрам. Ведь нашим идеалом является наличие беклога продукта, над которым работает одна или несколько фиксированных Скрам-команд. И выходит, что создание смешанного беклога из разных проектов является не чем иным, как отходом от идеалов. И следовательно, скрам-ном: «мы делаем Скрам, но работаем со смешанным беклогом по разным продуктам».

Давайте разберемся. Для этого нам придется рассмотреть несколько вариантов комбинации команд и продуктов (проектов).

СТАНДАРТНЫЕ КЕЙСЫ

Один продукт (проект) – одна Скрам-команда:

один беклог, одна команда

Это самый простой случай. Так сказать, plain vanilla scrum. Даже нечего добавить.

Один продукт (проект) – несколько Скрам-команд:

один беклог, много команд

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

Речь о нетривиальный случаях, где кажется, что Scrum не применим.

НЕСТАНДРАРТНЫЕ КЕЙСЫ

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

Проектов больше, чем потенциальных Скрам-команд:

много проектов, мало людей

Что делать в этом случае?

Решение первое и плохое – распределить людей по проектам:
распределение людей по проектам

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

К примеру:
- Что, если Оля увольняется?
- Что, если Коле нужна помощь?
- Что, если Проект 1 закрывается?

Что еще происходит, когда вы распределяете людей между проектами таким образом? Вы теряете все те выгоды, которые приходят, когда люди общаются и взаимодействуют. Я видел такие компании. Там тихо, печально и очень серьезно. Там общаются в курилках на отвлеченные темы. Там нет чувства, что “мы все делаем одно большое дело”. Такие компании не раскрывают потенциал своих сотрудников, гребя веслами на моторной лодке…

Я несколько раз участвовал в перестройке таких компании в структуру, подобную приведенной ниже:
много проектов - единная команда

Решение – тривиально. Результаты – обычно превосходят самые смелые ожидания. И все просто потому, что вы объединили людей в команду. Теперь они не “один на один” каждый со своим заказчиком. Теперь они, сообща и помогая друг другу, достигают общих целей, сформированных во время живых обсуждений. Кто не верит? Не ищите аргументов, это просто нужно увидеть в действии.

Но тут возникает та самая проблема, ради которой я пишу эту статью – на основании чего командам планировать свою работу в разных проектах?

И тут нам ничего не остается, как завести смешанный беклог или беклог команды:
командный беклог

ПРИОРИТЕЗАЦИЯ ПРОЕКТОВ ДЛЯ КОМАНДЫ

Вариантов приоритезации проектов внутри смешанного беклога можно придумать бесконечно много. Вот самые типичные из них:

1. Последовательное завершение проектов:
последовательное завершение проектов

2. Сфокусированные спринты:
последовательное завершение проектов

3. Смешанные спринты:
спринты со смешанными приоритетами

Обратите внимание на длину проектов в каждом из вышеприведенных вариантах. В первом случае – она минимальна. В последнем – максимальна.

Сравните уровень сфокусированности команды? В последнем случае он минимален, а частота переключения контекста работы максимальна. Это далеко от идеала.

В каком случае вы смело управляете сроками и загрузкой команды и честно говорите заказчикам: “наша супер команда сейчас занята, но через месяц она будет вся ваша”? В первом – с последовательным завершением проектов. Это идеальный вариант. Самый честный по отношению к заказчикам.

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

Какой вариант выбираю я? Первый. Если не работает, то второй. А если и он не работает, то комбинацию первого и второго только с двумя меньшими командами.

Третий вариант – последний выбор. Но даже со всеми своими минусами он намного лучше ситуации с раскидыванием людей по проектам. Наличие команды – огромный плюс.

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

КТО ПРИОРИТЕЗИРУЕТ БЕКЛОГ КОМАНДЫ?

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

Как-то так.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>