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

Стили управления

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

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

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

Команды уровня 1

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

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

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

Команды уровня 2

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

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

Команды уровня 3

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

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

Команды уровня 4

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

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

Лучшие практики управления командой в Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выбор эталонной задачи

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

• простой и понятной для команды;

• типичной для данного проекта;

• небольшого размера.

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

Эту историю пользователя команда принимает за 1 «пункт». Тогда история пользователя, которая будет в два раза меньше эталонной, будет иметь размер 1/2 «пункта», а история пользователя, которая в пять раз больше эталонной, будет иметь размер 5 «пунктов». Таким образом, «пункт» – это относительная безразмерная единица измерения.

Для оценки используется дискретная логарифмическая шкала:

Причем оценки в 40 и 100 «пунктов» за пользовательскую историю применяются для эпиков и считаются неточными. Такая шкала относит к одному размеру истории пользователя в 20 и 21 «пункт», но к разным – задачи в 2 и 3 «пункта».

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

Шкала размеров историй пользователей

Получается, что с каждой новой оцененной историей пользователей у нас появляются новые «эталоны» для сравнения.

Ход покер-планирования

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

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

Карты выкладывают рубашкой вверх

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

Карты одновременно переворачиваются

Затем скрам-мастер организует обсуждение: в качестве паттерна можно порекомендовать начинать с участников команды, которые дали максимальную и минимальную оценку.

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

Обычно разброс оценок снижается с каждым последующим раундом и сходится к консенсусной оценке.

В конце оценка записывается на стикер с историей пользователей и при необходимости заносится в трекер.

Обсуждение начинается с участников с минимальной и максимальной оценкой

Второй раунд

Консенсусная оценка

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

Отбор задач на спринт