Гибкое управление проектами и продуктами

На схеме, изображенной ниже, в спринт отбираются истории пользователей 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 («планирование-действие-проверка-корректировка»), чтобы у вас была возможность получить обратную связь от команды и внести изменения в случае необходимости.

Глава 5. Управление контрактами

Сроки и долгосрочное планирование в Agile

Существует мнение, что в гибких методологиях планирование либо отсутствует вообще, либо носит краткосрочный характер.

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

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

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

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

Необходимо отметить, что недоверие преодолеть очень непросто.

Оценка сроков методом PERT

Рассмотрим стандартный подход к оценке сроков завершения проекта – метод PERT (Program (Project) Evaluation and Review Technique), или метод оценки по трем точкам. Его преимуществом является простота и определенный учет рисков. К недостаткам относят маленькую точность и необходимость иметь полную информацию о масштабе работ, что не очень подходит для Scrum.

Метод заключается в получении трех оценок: