Борис Вольфсон - Гибкое управление проектами и продуктами

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

Во-вторых, команда не определяет состав сама, она опять же формируется сверху. Однако могу сказать, что на определенном этапе взросления, когда команда может объективно оценивать вклад участников, ей можно доверить даже самостоятельное формирование состава команды.

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

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

В зависимости от этапа командообразования необходимы различные стили лидерства. Попробуем использовать для этого модель ситуативного лидерства, которую разработали Херси и Бленчард, и объединим ее с моделью Такмана.

Стили лидерства по Херси и Бленчарду

Уровни команд соответствуют этапам командообразования из предыдущего раздела.

Командам данного уровня требуется предписывающий стиль лидерства. Лидер должен точно указывать, что команде необходимо сделать. Таким командам нужно выработать уверенность, и они не могут на данном этапе стать настоящими Agile-командами.

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

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

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

Эти команды могут стать гибкими, но им требуется сильный тренер или скрам-мастер, который научит их вырабатывать свои решения и полагаться на них. Конечно, часть решений команды будут ошибочными. В этом нет ничего страшного, ведь именно на ошибках учатся. Особое внимание нужно уделить ретроспективам как основному методу выработки улучшений в Scrum.

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

Такие команды часто сосредоточены на тактических задачах, поэтому тренер или скрам-мастер должен максимально внимательно относиться к стратегическим задачам и долгосрочному планированию.

Команды этого уровня хотят и могут стать (и часто являются) гибкими, и им необходим делегирующий стиль лидерства.

Лидер не должен помогать принимать решения команде, но может помогать в выборе методов поиска решений. Скрам-мастер должен сосредоточиться на максимизации производительности больше, чем на соблюдении сроков.

Посмотрим, какие лучшие практики и инструменты рекомендуется использовать команде и скрам-мастеру для наиболее эффективного создания продукта. Эти практики отлично интегрируются в Scrum и многими специалистами уже считаются его неотъемлемой частью.

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

• все элементы журнала пожеланий должны иметь уникальную числовую важность;

• самые важные элементы журнала пожеланий должны быть уточнены и понятны всей команде и владельцу продукта;

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

Основным результатом планирования спринта является журнал пожеланий спринта – список задач, которые команда планирует реализовать в рамках спринта. Поскольку длина спринта в Scrum жестко фиксирована, то команда определяет количество элементов журнала пожеланий (объем работ), которые она может реализовать. Можно данную ситуацию отобразить на классическом треугольнике управления проектами.

Проектный треугольник в Scrum

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

Покер-планирование (Planning poker) – консенсусная относительная оценка историй пользователей командой. Этот вид оценки не входит в классический Scrum, но является паттерном для оценки историй пользователей.

Покер-планирование проводится следующим образом.

1. Каждому участнику раздается колода карт с числовыми весами для оценки требований.

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

3. Каждый член команды дает свою оценку, кладя карту рубашкой вверх.

4. После того как все члены команды сделали оценку, все карты переворачиваются и оценки сверяются.

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

Покер-планирование