Кен Швабер - Скрам [Гибкое управление продуктом и бизнесом] [litres]

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

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

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