Текст книги "Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство"

Переход к agile требует применения иных измерений. Использование agile означает поиск новых показателей, которые имеют значение для команды и руководства. Эти метрики имеют важное значение, поскольку сфокусированы на поставке ценности заказчику.

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

Проект выполнен не полностью, и отчет с трехцветным представлением статуса не отражает истинного состояния. Слишком часто команда проекта приходит к заключению, что ей потребуется еще столько же времени на завершение остальной части проекта. Есть слишком много проектов, в которых команда приходит к выводу, что из-за вновь выявленных проблем часть завершенных работ по проекту составляет всего 10 % общего объема.

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

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

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

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

В agile предпочтительно использовать эмпирические и основанные на ценности показатели, а не предиктивные измерения. В agile измеряется то, что команда поставляет, а не то, что она предполагает поставить.

Команда, которая привыкла иметь базовые планы проекта и оценки освоенного объема и возврата инвестиций (Return On Investment, ROI), может оказаться в затруднительном положении при работе над проектом, если она не управляет им по базовому плану. Agile основана на работающих продуктах, имеющих ценность, которую можно продемонстрировать заказчикам.

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

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

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

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

Например, если команда в среднем выполняет 50 относительных единиц историй за одну итерацию, и команда считает, что ей остается выполнить еще 500 единиц, то, по оценке команды, ей надо пройти еще около 10 итераций. По мере уточнения владельцем продукта остающихся историй, а командой – своих оценок, оценка продолжительности проекта может увеличиваться или сокращаться, но команда в состоянии дать некоторую оценку.

Если команда оценивает время цикла в среднем как три дня на каждую историю, и ей остается пройти еще 30 историй, команде потребуется на исполнение работы еще 90 рабочих дней, т. е. примерно от 4 до 5 месяцев.

Следует отразить вариативность оценки с помощью диаграммы в стиле «урагана» или какого-либо другого способа измерения вариативности, который будет понятен спонсорам.

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

В некоторых основанных на итерации проектах, чтобы наглядно представить, где проект превышает установленные сроки, используются диаграммы сгорания. На рис. 5–1 показан пример диаграммы сгорания, где команда планировала осуществить поставку 37 относительных единиц. Относительные единицы определяют темпы соответствующей работы, риск и сложность требования или истории. Многие agile-команды используют относительные единицы для оценки трудозатрат. Пунктирная линия сгорания представляет план. На рис. 5–1 по результатам на третий день команда может видеть, что у нее появился риск для данной поставки.

Рис. 5–1. Диаграмма сгорания остатка относительных единиц

В некоторых проектах предпочитают использовать диаграммы выгорания. Те же данные, которые использованы на рис. 5–1, представлены на рис. 5–2 в форме диаграммы выгорания.

Рис. 5–2. Диаграмма выгорания для наглядного представления завершенных относительных единиц

На диаграммах выгорания представляется завершенная работа. Две диаграммы на рис. 5–1 и 5–2 основаны на одних и тех же данных, но представляют их двумя разными способами. Команды могут сами решать, какое представление своих данных лучше использовать.

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

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

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

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

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

ПОЛЕЗНЫЙ СОВЕТ

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

Рис. 5–3. Пример доски «канбан»

Знать время ожидания полезно, чтобы понять время цикла между первым подходом к определенному свойству и началом отрезка времени, которое требуется для релиза этого свойства заказчику. Лимиты незавершенной работы (work in progress, WIP) вверху каждого столбца, показанные здесь в квадратиках, позволяют команде видеть, как продвигать работу по доске. После того, как команда исчерпала свои лимиты незавершенной работы, она не может перемещать работу слева в следующий столбец справа. Вместо этого, команда выполняет работу из наиболее заполненного столбца справа и ставит вопрос: «Что мы делаем как команда, чтобы переместить эту работу в следующий столбец?»

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

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

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

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

ПОЛЕЗНЫЙ СОВЕТ

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

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

Команда может измерять завершенную работу диаграммой сгорания/выгорания работ по свойству или диаграммой выгорания бэклога продукта. Эти диаграммы наглядно представляют тенденции завершения работ с течением времени, как показано на рис. 5–4.

Рис. 5–4. Диаграмма свойств

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

В agile освоенный объем определяется объемом завершенных свойств, как показано на рис. 5–5. Диаграмма выгорания бэклога продукта показывает объем завершенной работы в сравнении с предполагаемым общим объемом работы через промежутки времени между контрольными событиями или итерациями.

Рис. 5–5. Диаграмма выгорания бэклога продукта

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

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

Рис. 5–6. Освоенный объем в контексте agile

Обычно используемые метрики управления освоенным объемом (earned value management, EVM), как, например, индекс выполнения сроков (schedule performance index, SPI) и индекс выполнения стоимости (cost performance index, CPI), можно без труда представить в терминах agile. Например, если команда планировала завершить 30 относительных единиц в одной итерации, но фактически завершила лишь 25, то SPI составляет 25/30 или 0,83 (т. е. темп работы команды составляет лишь 83 % от планового). Таким же образом, CPI – это освоенный объем (т. е. ценность завершенных свойств) на текущую дату, поделенный на фактическую стоимость на текущую дату или, как показано на рис. 5–6, 2,2 млн долл. США / 2,8 млн долл. США = 0,79. Это означает, что в сравнении с планом из каждого доллара по плану получено лишь 79 центов (но, безусловно, этот расчет основан на предположении, что прогноз остается верным).

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

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

Рис. 5–7. Диаграмма суммарного потока завершенных свойств

Адаптируйте этот суммарный поток для доски рабочих задач проекта.

6. Организационные соображения для гибкости проекта

Каждый проект существует в некотором организационном контексте. Культуры, структуры и политики могут влиять как на управление проектом, так и на его результат. Эти факторы могут создавать проблемы лидерам проектов.

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

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

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

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

В публикации PMI «Управление изменениями в организациях: практическое руководство» (Managing Change in Organizations: A Practice Guide) описан комплексный и целостный подход, обеспечивающий успешное осуществление значимых изменений. Содержащиеся там рекомендации включают в себя следующее:

♦ модели для описания динамики изменений,

♦ фреймворк для реализации изменений,

♦ применение практик управления изменениями на уровне проекта, программы и портфеля.

В разделах 6.1.1 и 6.1.2 рассматриваются соображения по управлению изменениями, относящимися непосредственно к контексту agile.

На рис. 6–1 показано отношение между этими двумя темами.

Рис. 6–1. Отношение между управлением изменениями и подходами agile

Все проекты решают задачу осуществления тех или иных изменений. Однако есть два ключевых фактора, которые дополнительно мотивируют к использованию практик управления изменениями в контексте agile:

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

♦ Изменения, связанные с подходами agile. Организации, которые только приступают к использованию подходов agile, также сталкиваются с высокой степенью изменений. Более высокие уровни сотрудничества могут требовать более частой передачи работ между командами, подразделениями и поставщиками. Декомпозиция работы на итеративные прототипы связана с доработками, которые могут восприниматься отрицательно. Лидерам следует рассмотреть методы управления изменениями, чтобы найти способы устранения барьеров для перехода к подходам agile.

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

♦ готовность высшего руководства к осуществлению изменений;

♦ готовность организации изменить то, как она относится к сотрудникам, рассматривает и оценивает их;

♦ функции централизации и децентрализации управления проектом, программой и портфелем;

♦ фокус на краткосрочном бюджетировании и метриках в противоположность долгосрочным целям;

♦ зрелость и возможности управления талантами.

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

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

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

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

♦ Сотрудники являются узкими специалистами с ограниченным набором инструментов или поощрений для разностороннего развития своих навыков, вместо формирования «Т-образных» специалистов.

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

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

♦ наглядного и активного спонсорства высших руководителей;

♦ внедрения практик управления изменениями, включающих в себя коммуникации и коучинг;

♦ неуклонного расширения внедрения практик agile от проекта к проекту;

♦ инкрементного введения практик agile в работу команды;

♦ осуществления руководства на основе личного примера использования методов и практик agile, где это возможно.