Читать онлайн «Гибкое управление проектами и продуктами». Страница 8

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

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

Скорость команды за последние восемь спринтов

На схеме, изображенной ниже, в спринт отбираются истории пользователей A, B, C, D и F.

Отбор элементов журнала пожеланий продукта в журнал пожеланий спринта

Для мониторинга прогресса в Scrum используется специальный график – диаграмма сгорания (Burndown Diagram). По горизонтальной оси на таком графике откладываются дни спринта, а по вертикальной – количество оставшихся «пунктов» и/или закрытых историй пользователей. Дополнительно строится идеальная диаграмма сгорания, которая показывает запланированный ход работ.

Диаграмма сгорания показывает, что спринт завершился в соответствии с планом

В дальнейшем анализ будем проводить по количеству оставшихся «пунктов», но все сказанное может распространяться и на истории пользователя.

Анализ производится путем сравнения реального графика с идеальным:

• если реальный график выше идеального, значит, команда отстает от плана;

• если реальный график ниже идеального – команда опережает план.

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

Рассмотрим самую стандартную ситуацию – с отставанием от графика.

Отставание от плана

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

• серьезная ошибка в планировании;

• болезнь или иная причина отсутствия одного или нескольких членов команды;

• недооценивание и реализация рисков (обычно технологических).

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

Обратной ситуацией является опережение плана.

Опережение графика

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

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

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

Все истории в первом столбце и отсортированы по важности

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

Вид доски в середине спринта

Команда выполняет задачи по важности, начиная с самых верхних, доводя их до статуса «Готово». Если все истории пользователей удалось реализовать, то при завершении спринта доска будет выглядеть следующим образом.

Доска при завершении спринта, если все истории были реализованы

Еще одним способом использования доски является следующий подход:

• истории пользователей берутся достаточно большие (3–7 на спринт) и располагаются в отдельном столбце;

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

Истории пользователей разбиваются на продуктовые задачи

Существуют две фактически противоположные друг другу теории в мотивации людей: X и Y.

Теории X и Y

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

Можно было бы дать совет не брать таких людей на работу. Однако, во-первых, их действительно много и среди них есть очень талантливые, а во-вторых, такое поведение и низкая мотивация не являются врожденными и неизлечимыми. Да, подобных сотрудников зажечь и увлечь работой будет непросто; да, для них нужно осуществлять тщательное планирование и контроль результатов; да, такие люди, безусловно, вызов и проверка для руководителя. Часто в итоге у начальника вырабатывается авторитарный стиль руководства. При таком подходе не будет поступать снизу никаких рацпредложений по инновациям, даже если первоначально они были. В данном случае не всегда следует действовать методом кнута, так как это только усилит отторжение коллективом руководителя. Команда, настроенная против лидера, не проявляющая инициатив, вряд ли сможет приносить прибыль компании, соответственно, цель не будет достигнута.

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

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

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

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

Чтобы узнать, посолен ли борщ, достаточно опустить в него два электрода, а затем пустить по ним ток. Если появится запах хлора, значит, борщ уже посолен.

В физике есть такое понятие, как эффект наблюдателя: если над системой ведется наблюдение, оно вносит изменение в ее поведение. Очень интересно этот эффект проявляется в организации работы команд разработчиков (да и в любых производственных процессах). Как только мы начинаем считать любые метрики, мы вносим изменения в поведение команды и отдельных ее членов.

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

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

Можно попробовать сократить количество дефектов в продукте, для чего считать, сколько ошибок сделал каждый разработчик. Лучших работников будем награждать бонусами, а к худшим применять санкции. Все просто и прозрачно. На деле получится по-другому: разработчики будут спорить по каждой ошибке с тестировщиками, появится боязнь и желание избегать рисков. В результате мы получим отсутствие инициативы и нежелание выполнять поставленные задачи (меньше задач – меньше ошибок).