Гибкие методологии опираются на людей и взаимодействие между ними, поэтому грамотное управление людьми выходит на первый план. В этой главе мы выясним, как мотивировать команду, оценивать и развивать ее в сторону гибкости.
Что такое команда
Определений команды существует несколько десятков. Будем придерживаться следующего, которое дал Майкл Армстронг.
Команда – это небольшая группа людей, взаимодополняющих и взаимозаменяющих друг друга, которые собраны для совместного решения задач производительности и в соответствии с подходами, посредством которых они поддерживают взаимную ответственность.
Этапы командообразования
Чтобы группа людей превратилась в сплоченную команду, она должна пройти несколько этапов. Наиболее распространенной моделью командообразования является модель Такмана.
Этапы командообразования
В своем развитии команды проходят несколько этапов.
1. Формирование.
На данном этапе происходит создание команды и постановка целей, распределение и закрепление ролей (в том числе социальных). Отдельные члены команды еще не очень понимают цель и задачи, которые перед ними поставлены.
Отсутствие направленности к цели у членов команды
2. Бурление.
На этом этапе участники осознают свои цели и определяют вектор движения. Обратите внимание, что векторы разнонаправлены между собой и с направлением, которое необходимо для достижения цели.
Разнонаправленность членов команды
Цель также стала более четкой и понимаемой для команды.
На данном этапе часто возможны конфликты и противостояние между членами команды, поэтому особенно возрастает роль скрам-мастера как модератора.
3. Нормализация.
Следующим этапом идет такой, когда члены команды притираются друг к другу и начинают двигаться сонаправленно.
Сонаправленность членов команды
Основной задачей скрам-мастера является помощь команде для перехода на следующий этап.
4. Функционирование.
На данном этапе команда становится самоуправляемой и способной оптимизировать свою производительность, поэтому векторы, направленные к цели, удлиняются.
Сильная сонаправленность членов команды
Хотя команды являются самоуправляемыми, они не становятся бесконтрольными. Руководство устанавливает контрольные точки, чтобы избежать нестабильности и хаоса. В то же время руководство избегает жесткого микроконтроля, который убивает креативность.Х. Такеучи и И. Нонака. Разработка нового продукта. Новые правила игры
5. Расформирование.
Когда цели, поставленные перед командой, достигнуты, наступает этап расформирования и направление «движения» участников снова рассинхронизируется.
Рассинхронизация членов команды на этапе расформирования
Командообразование в Scrum. Как было описано выше, чтобы работать эффективно, команда должна находиться на этапе функционирования. Соответственно, главной задачей команды (и, в частности, скрам-мастера) является максимально быстрый переход между этапами (табл. 4.1).
Таблица 4.1.
Приблизительное время для различных этапов командообразования
Спринты предполагаются двухнедельными. Самый лучший вариант в таблице выше не описан: можно просто взять сыгранную команду.
Самоорганизация в командах
Давайте сначала четко определим, что не является самоорганизующейся командой и что не входит в ее полномочия.
Во-первых, команда не может сама себе ставить цели, они всегда приходят извне. Как правило, задачи спускаются сверху – от руководства или из отдела продаж.
Во-вторых, команда не определяет состав сама, она опять же формируется сверху. Однако могу сказать, что на определенном этапе взросления, когда команда может объективно оценивать вклад участников, ей можно доверить даже самостоятельное формирование состава команды.
Что же может команда, если цель ей ставится сверху? Она может выбрать максимально эффективный способ, которым будет достигать этой цели. Эффективность в данном случае можно измерить сроком, составом и ценой работ. При этом команде приходится адаптироваться к ограничениям, которые заданы в проекте, и условиям окружающей среды, потому что, как правило, механизмов влияния на них у команды нет.
Децентрализация и умение адаптироваться свойственны не только командам разработчиков. Посмотрите на колонию муравьев, как они строят муравейник и выполняют повседневную работу. Такая же параллельная работа ведется и в гибких командах: контроль и «власть» децентрализованы и распределены между членами команды. Соответственно, решения, из которых складывается конечный результат, принимаются каждым членом команды, разделяя ответственность, но не размывая ее между всеми.
Стили управления
В зависимости от этапа командообразования необходимы различные стили лидерства. Попробуем использовать для этого модель ситуативного лидерства, которую разработали Херси и Бленчард, и объединим ее с моделью Такмана.
Стили лидерства по Херси и Бленчарду
Уровни команд соответствуют этапам командообразования из предыдущего раздела.
Команды уровня 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 «пункта».
В итоге все наши истории пользователей в журнале пожеланий будут разбиты по следующим категориям.
Шкала размеров историй пользователей
Получается, что с каждой новой оцененной историей пользователей у нас появляются новые «эталоны» для сравнения.
Ход покер-планирования
После обсуждения истории пользователей начинается первая раздача, при которой все участники команды выкладывают карты рубашкой вверх (на схеме скрам-мастер находится в правом нижнем углу).
Важно, чтобы при обсуждении историй пользователя не было давления, которому все начинают невольно подчиняться и ставить оценки, уже не вдумываясь в суть.Ксения Колосова, руководитель проектов
Карты выкладывают рубашкой вверх
После этого все карты одновременно переворачиваются.
Карты одновременно переворачиваются
Затем скрам-мастер организует обсуждение: в качестве паттерна можно порекомендовать начинать с участников команды, которые дали максимальную и минимальную оценку.
Скрам-мастер должен следить за временем, в течение которого длится обсуждение истории пользователей. По истечении времени происходит второй раунд и дальнейшее обсуждение.
Обычно разброс оценок снижается с каждым последующим раундом и сходится к консенсусной оценке.
В конце оценка записывается на стикер с историей пользователей и при необходимости заносится в трекер.
Обсуждение начинается с участников с минимальной и максимальной оценкой
Второй раунд
Консенсусная оценка
В процессе обсуждения сглаживаются разногласия между владельцем продукта и командой, владелец продукта начинает понимать процесс работы над задачей, а команда точнее и детальнее понимает суть задачи.Ксения Колосова, руководитель проектов
Отбор задач на спринт
Команда отбирает задачи на спринт в соответствии со своей скоростью и приоритетами, установленными владельцем продукта. Скорость прогнозируется на основе эмпирических данных за прошлые спринты с учетом реальных обстоятельств, например болезни или отпуска сотрудника.
Скорость команды за последние восемь спринтов
На схеме, изображенной ниже, в спринт отбираются истории пользователей A, B, C, D и F.
Отбор элементов журнала пожеланий продукта в журнал пожеланий спринта
Диаграмма сгорания
Для мониторинга прогресса в Scrum используется специальный график – диаграмма сгорания (Burndown Diagram). По горизонтальной оси на таком графике откладываются дни спринта, а по вертикальной – количество оставшихся «пунктов» и/или закрытых историй пользователей. Дополнительно строится идеальная диаграмма сгорания, которая показывает запланированный ход работ.
Диаграмма сгорания показывает, что спринт завершился в соответствии с планом
В дальнейшем анализ будем проводить по количеству оставшихся «пунктов», но все сказанное может распространяться и на истории пользователя.
Анализ производится путем сравнения реального графика с идеальным:
• если реальный график выше идеального, значит, команда отстает от плана;
• если реальный график ниже идеального – команда опережает план.
Анализ диаграммы сгорания во время спринта. Для единообразия анализ будем проводить на пятый день спринта, хотя на практике диаграмму сгорания можно использовать с третьего дня для выработки корректирующих действий.
Рассмотрим самую стандартную ситуацию – с отставанием от графика.
Отставание от плана
Команда должна на очередном скрам-митинге обсудить, почему очки за пользовательскую историю сгорают так медленно, и выработать контрмеры. Самые распространенные причины следующие:
• серьезная ошибка в планировании;
• болезнь или иная причина отсутствия одного или нескольких членов команды;
• недооценивание и реализация рисков (обычно технологических).
Об отставании необходимо максимально оперативно сообщить владельцу продукта, если он не ведет ежедневный мониторинг диаграммы сгорания. Если команда сама не сможет выработать контрмеры, нужно, чтобы владелец продукта убрал из спринта одну или несколько историй пользователя с минимальным приоритетом.
Обратной ситуацией является опережение плана.
Опережение графика
В таком случае команде необходимо в журнал пожеланий спринта взять одну или несколько дополнительных историй пользователей с высшим приоритетом, которые не вошли в спринт.
Доска задач
Самым наглядным инструментом мониторинга и управления внутри спринта является доска задач, которая по функционалу похожа на аналогичный инструмент из канбана. Однако, поскольку в Scrum имеются фиксированные итерации, доска по завершении спринта «обнуляется» – с нее убираются все стикеры.
На стикерах указывается наименование истории пользователя, и они двигаются по соответствующим состояниям во время спринта. В начале спринта все истории пользователей находятся в первом столбце, отсортированные вертикально по важности.
Все истории в первом столбце и отсортированы по важности
По мере реализации историй пользователей члены команды меняют статусы задач, и доска к середине спринта выглядит примерно так.
Вид доски в середине спринта
Команда выполняет задачи по важности, начиная с самых верхних, доводя их до статуса «Готово». Если все истории пользователей удалось реализовать, то при завершении спринта доска будет выглядеть следующим образом.
Доска при завершении спринта, если все истории были реализованы
Еще одним способом использования доски является следующий подход:
• истории пользователей берутся достаточно большие (3–7 на спринт) и располагаются в отдельном столбце;
• истории пользователей разбиваются на небольшие продуктовые задачи, которые и передвигаются по состояниям по соответствующей дорожке.
Истории пользователей разбиваются на продуктовые задачи
Теории X и Y
Существуют две фактически противоположные друг другу теории в мотивации людей: X и Y.
Теории X и Y
Теория X
Согласно теории X, люди работают, только чтобы получать зарплату. Думаю, все сталкивались с такими сотрудниками: пришел с утра, посидел до обеда, потом потерпел до вечера и домой. Они не работают, а отбывают положенное время. Для них работа измеряется часами, а не достигнутыми результатами.
Что делать руководителю
Можно было бы дать совет не брать таких людей на работу. Однако, во-первых, их действительно много и среди них есть очень талантливые, а во-вторых, такое поведение и низкая мотивация не являются врожденными и неизлечимыми. Да, подобных сотрудников зажечь и увлечь работой будет непросто; да, для них нужно осуществлять тщательное планирование и контроль результатов; да, такие люди, безусловно, вызов и проверка для руководителя. Часто в итоге у начальника вырабатывается авторитарный стиль руководства. При таком подходе не будет поступать снизу никаких рацпредложений по инновациям, даже если первоначально они были. В данном случае не всегда следует действовать методом кнута, так как это только усилит отторжение коллективом руководителя. Команда, настроенная против лидера, не проявляющая инициатив, вряд ли сможет приносить прибыль компании, соответственно, цель не будет достигнута.
Теория Y
Теория Y гласит, что люди в принципе высокомотивированы на достижение результатов и сама работа приносит им удовольствие. Опять же всем нам знаком типаж людей с большой самомотивацией. У них и вокруг них всегда кипит работа (передаю привет моей команде), они успевают за день сделать не одно дело, и их производительность труда намного выше среднего.
Что делать руководителю
Необходимо внимательно следить за мотивацией своей команды, четко понимать, чего она ожидает, поддерживать каждый успех и внимательно следить за инициативами, чтобы они не пропадали, а реализовывались. Управлять лучше по отклонениям, не сильно наседая. При осуществлении контроля в данном случае необходимо ставить четкие цели и добиваться, чтобы команда их понимала и разделяла.
X + Y
Обычно руководитель работает на стыке обеих теорий, используя тот или иной подход в зависимости от ситуации. В общем случае надо стараться работать по принципу теории Y, зажигая людей, в крайнем – прибегать к методам теории X, четко объясняя, в чем именно проблема.
Для работы в рамках Scrum команда должна состоять в основном из людей, которые больше соответствуют теории Y, иначе команда не будет самоорганизованной и эффективной.
Эффект наблюдателя
Чтобы узнать, посолен ли борщ, достаточно опустить в него два электрода, а затем пустить по ним ток. Если появится запах хлора, значит, борщ уже посолен.
В физике есть такое понятие, как эффект наблюдателя: если над системой ведется наблюдение, оно вносит изменение в ее поведение. Очень интересно этот эффект проявляется в организации работы команд разработчиков (да и в любых производственных процессах). Как только мы начинаем считать любые метрики, мы вносим изменения в поведение команды и отдельных ее членов.
Не навреди
С точки зрения управления мерить в численном виде (вводить метрику) – идея, на первый взгляд, очень здравая. Мы получаем точные данные и на их основе производим необходимые действия. Однако, к сожалению, не все так просто: как только мы вводим метрику, поведение команды начинает меняться. Команда и каждый ее член начинают подстраиваться под введенную нами метрику.
Далеко за примерами ходить не надо. Все знают понятие «индусский код»: как только разработчикам начинают платить за количество написанных строчек кода, они начинают писать больше кода, зачастую бессмысленного, забывают о рефакторинге, так как его делать становится невыгодно, и т. д. Таким образом, наше начинание по замеру производительности оборачивается против нас.
Можно попробовать сократить количество дефектов в продукте, для чего считать, сколько ошибок сделал каждый разработчик. Лучших работников будем награждать бонусами, а к худшим применять санкции. Все просто и прозрачно. На деле получится по-другому: разработчики будут спорить по каждой ошибке с тестировщиками, появится боязнь и желание избегать рисков. В результате мы получим отсутствие инициативы и нежелание выполнять поставленные задачи (меньше задач – меньше ошибок).
Подойдем с другой стороны и будем считать, сколько ошибок находят тестировщики. В этой ситуации также появятся косвенные эффекты, ведь каждый тестировщик будет расценивать малейшее отклонение как дефект.
Вывод из приведенных выше примеров простой: при введении метрик необходимо руководствоваться прежде всего принципом «Не навреди».
Что делать
Проанализируйте, как измерения могут повлиять на поведение команды и отдельных ее членов. Причем анализ надо проводить в первую очередь по поводу неочевидных аспектов, которые могут проявиться не сразу. Подумайте, какие метрики могут послужить основой для обсуждений, например, на ретроспективах, если вы используете Scrum. Может быть, ваши измерения в действительности никому не нужны и вы меряете просто потому, что можете мерить?
Посчитайте, сколько времени у вас уходит на сбор информации по метрикам. Весьма вероятно, что этот процесс можно автоматизировать, в особенности если мы говорим о метриках кода, метриках качества и т. п.
При внедрении метрик, как и любых других инноваций, хорошо использовать цикл Деминга Plan-Do-Check-Act («планирование-действие-проверка-корректировка»), чтобы у вас была возможность получить обратную связь от команды и внести изменения в случае необходимости.