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

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

Руководители проектов в MegaEnergy поддерживали осведомленность заинтересованных лиц и руководства, информируя их о ходе проекта с помощью периодических отчетов. Поскольку традиционные проекты управляются на уровне задач, в этих отчетах описывался процент завершенных задач, отставание от графика, возникшие проблемы и предлагаемые меры реагирования, текущие риски и рекомендуемые способы снижения их вероятности и влияния. Поскольку задачи имеют лишь косвенное отношение к желаемой пользователями функциональности, эти отчеты скорее расстраивали заинтересованных лиц, чем приносили пользу. Затем для отслеживания прогресса в MegaEnergy начали использовать отображение плана проекта в виде диаграммы Ганта. Это ключевой инструмент в управлении проектами на уровне задач. Выявив необходимые задачи, зависимости между ними, исполнителей и ресурсы, с его помощью можно определить итоговый срок завершения проекта и следить за его отклонениями от плана.

На протяжении многих лет в MegaEnergy применялся устоявшийся, очень традиционный и формальный процесс управления проектами, разработанный офисом управления программами, в котором работали высокопоставленные сотрудники, ранее руководившие проектом строительства трубопроводов. Диаграмма Ганта была для них святым Граалем для планирования и контроля над проектом. После первого провала проекта «Участок» они решили повысить степень детальности начального планирования и ужесточить процесс контроля изменений при второй попытке. Они полагали, что первый проект потерпел неудачу, потому что руководство допустило слишком много изменений в первоначальном плане. Услышав это, я вспомнил о данном Эйнштейном определении безумия: повторять одно и то же снова и снова и ожидать других результатов. Удивительно, но это очень распространенный подход. Если управляемый предопределенным подходом проект терпит неудачу, люди часто винят в этом недостаточно строгое следование этому же подходу и делают вывод, что для успеха очередной попытки необходимо лишь усилить контроль и повысить четкость артефактов проекта.

Высшее руководство, в том числе управляющий комитет проекта «Участок» и офис управления проектами, знали, что во время третьей попытки будет опробовано что-то новое. При этом работающие в офисе управления программами люди не были знакомы ни с управлением эмпирическим процессом, ни со скрамом. Однако они не возражали против нового подхода, если проект будет контролироваться принятым в MegaEnergy способом – с помощью диаграмм Ганта.

Это подкинуло нам задачку. Должны ли мы проводить обучение высшего руководства скраму, включая сотрудников офиса управления программами? Должны ли мы сообщить им о радикально ином подходе, который мы собрались использовать в проекте «Участок»? Должны ли мы вступить с ними в долгую дискуссию о различиях в управлении предопределенным и эмпирическим процессами? Мы знали, что эта дискуссия будет эмоциональной, ведь офис управления программами имел большую историю успеха в MegaEnergy. Их подход использовался для управления гораздо более массивными проектами, чем проект «Участок», а причиной неудач предыдущих двух попыток называли человеческие ошибки, а не недостатки процесса. Как убедить их в обратном?

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

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

Скрам-мастер Рут была опытным менеджером проектов в MegaEnergy. Она знала культуру MegaEnergy изнутри и снаружи, знала директоров, которые получали отчеты о прогрессе проекта «Участок». Она работала с сотрудниками из офиса управления программами и точно знала, чего они хотят и почему. Она знала, что отчеты с диаграммами Ганта являются основой их системы отчетности. Рут умела создавать и поддерживать в актуальном состоянии календарный и ресурсный планы проекта в Microsoft Project, который был стандартным инструментом управления проектами в MegaEnergy.

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

Подход, который мы решили применить для представления скрама высшему руководству и офису управления программами, напоминает мне старую шутку. Джон видит, как Хэнк тянет длинную веревку вверх по узкой, извилистой горной дороге. Джон спрашивает Хэнка, зачем он тянет веревку. «Потому что это проще, чем толкать ее!» – отвечает Хэнк.

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

В скраме существует четыре отчета, которые владелец продукта и скрам-мастер создают в конце каждого спринта. Первым делом я познакомил с ними Рут:

1. Старый бэклог – содержит элементы бэклога по состоянию на начало предыдущего спринта;

2. Новый бэклог – содержит бэклог продукта в начале следующего спринта;

3. Отчет об изменениях – описывает все различия между бэклогами продукта в первых двух отчетах;

4. График сгорания элементов бэклога продукта.

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

■ Почему содержание будущих спринтов было изменено?

■ Почему дата или содержание релиза были изменены?

■ Почему во время спринта команда реализовала меньше требований, чем ожидалось?

■ Куда помещена невыполненная в спринте работа?

■ Почему команда разработки была менее или более эффективной, чем ожидалось?

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

Дальше мы постарались преобразовать бэклог продукта в диаграмму Ганта. Изображенный на рис. 7.1 бэклог хранился в электронной таблице в виде простого упорядоченного списка требований. Зависимые требования следовали в списке после требований, от которых они зависели. Таким простым способом разрешались зависимости между требованиями. Сами требования сегментировались в спринты и реализовывались уникальными строками.

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

Рут открыла файл с электронной таблицей бэклога проекта в Microsoft Excel и создала новый проект в Microsoft Project. Она скопировала и вставила весь список элементов бэклога из Excel в Project в столбец «Название задачи», а оценки – в колонку «Длительность». Это был прямой перенос из одного продукта Microsoft в другой. Она сгруппировала требования (MS Project считал их задачами) в спринты, как показано на рис. 7.3.

Затем Рут заполнила представления «Задачи» и «Отслеживание», для каждого элемента бэклога указав длительность работы, а для каждого спринта – дату его начала. Столбец «% завершения» обычно содержал значение 100 почти для каждой строки в конце спринта. Мы договорились, что, если где-то будет не 100 %, она разделит элементы и поместит невыполненную работу в будущие спринты.

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

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

В конце первого спринта руководство получило новые отчеты. Они были во многом похожи на старые отчеты, за исключением того, что Рут отслеживала не завершение задач, а создание функциональности. Написав об этом в предисловии к отчетам, она пришла с ними к управляющему комитету. На графике сгорания бэклога продукта Рут показала влияние реализованных элементов бэклога продукта на весь релиз. Затем она показала разницу между бэклогами продукта в начале и конце спринта. В этом конкретном случае разница была большой. Владелец продукта повысил значение первого инкремента, приняв решение о поставке его в промышленную среду. Это означает, что функциональность инкремента продукта была готовой к поставке, пользователи отдела учета земельных участков прошли обучение и начали использовать эту функциональность в своей повседневной работе. Решение о поставке повлекло добавление в бэклог релизного спринта длительностью в две недели – половину стандартного спринта MegaEnergy. Обсуждая его, управляющий комитет осознал основную выгоду скрама: инкремент каждого спринта потенциально может быть поставлен пользователям. В рассматриваемом случае владелец продукта Джейн решила, что ранняя поставка была оправданна. Владелец продукта инспектировала ситуацию и адаптировала план. Управляющий комитет увидел инкрементальную природу скрама и преимущества частых инспекций и адаптаций.

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

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

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

Скрам доказывает свою ценность успехом проектов. Однако предлагает подход, который радикально отличается от традиционного управления проектами: ожидание перемен и приветствие изменений вместо избегания их. Адаптация – естественная часть проекта, а вовсе не исключение из правил. Когда эти концепции обсуждаются теоретически, большинство людей соглашаются с обоснованностью подхода, но, когда мы предлагаем использовать эти концепции в очень важном проекте, руководство действует крайне осторожно. Менеджеры хотят знать, чем этот подход лучше. Они спрашивают, насколько он рискованный и не приведет ли такое количество изменений к катастрофе. В рассмотренной ситуации Рут доказала ценность нового подхода, представив его на языке инвесторов проекта. Она продемонстрировала преимущества и ценность скрама руководителям, не обучая их концепциям и теории аджайловых процессов. В результате у руководства сложилось положительное отношение к скраму. Как сказал генеральный директор другой компании во время обзора спринта: «Я не знаю, что такое скрам, но он мне нравится». Пусть так и будет.