Для большинства заинтересованных лиц и руководителей отчеты в скраме сдвигают привычную парадигму. Обычно базовый план фиксируется, а любые отклонения от плана рассматриваются как нежелательные. Периодические отчеты руководству показывают, насколько фактическое состояние проекта соответствует базовому плану. Вместо этого скрам сообщает о несоответствиях плану, реакциях на эти несоответствия и влиянии на план проекта. Скрам приветствует изменения и предоставляет отчеты, отслеживающие изменения и их влияние на проект.
Решение проблемы
Скрам-мастер Рут была опытным менеджером проектов в 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. Обсуждая его, управляющий комитет осознал основную выгоду скрама: инкремент каждого спринта потенциально может быть поставлен пользователям. В рассматриваемом случае владелец продукта Джейн решила, что ранняя поставка была оправданна. Владелец продукта инспектировала ситуацию и адаптировала план. Управляющий комитет увидел инкрементальную природу скрама и преимущества частых инспекций и адаптаций.
