Диаграмма сгорания задач
Одной из самых сильных сторон Скрама является метрика текущих задач. Вы можете навсегда попрощаться с долгими днями споров о прогрессе или замораживании работ в состоянии «практически готово». Диаграмма сгорания задач – это простое и наглядное отображение прогресса, и она используется командой для отслеживания хода разработки продукта во время спринта.
Блистательная мысль
Необновляющийся журнал требований продукта – однозначный признак того, что что-то идет не так; изменения естественны и более чем ожидаемы. Но и другая крайность – когда журнал обновляется излишне часто – тоже указывает на проблемы.
Блистательная мысль
Когда вы обновляете статус выполненных в спринте работ, реальный прогресс будут отображать только полностью завершенные задачи. Те, что закончены на 25 %, 50 % или 75 %, в данном случае не учитываются.
Особенно будьте внимательны в случае задач, которые завершены на 99 %.
Переход на Agile похож на обучение вождению. Пока вы на пассажирском сиденье, все выглядит довольно просто; если вникнуть в основы, главные принципы тоже будут для вас ясны. Но только сумасшедший запрыгнет за руль и устремится на улицу с интенсивным движением после того, как прочтет несколько статей в интернете. Разумный человек сначала как минимум разберется с теорией. Эта книга – как правила дорожного движения.
Прежде чем применять Скрам, нужно не только разобраться в его основах, но и понять, как именно все элементы методологии работают вместе. Можно встретить так называемые Скрам-команды, работающие без каких-то ключевых ролей или артефактов; некоторым из них это даже вполне удается. Но для стабильного успеха необходимо предварительно всесторонне изучить теорию. Не забывайте: причина номер один всех аварий на дорогах – неопытные водители.
Блистательный итог
• Скрам популярен, потому что он работает. Не думайте, что вы можете игнорировать важные составляющие и все еще добиваться нужного результата.
• Вам нужны четкое видение и журнал требований проекта; убедитесь в том, что только Владелец продукта определяет их содержание и расставляет приоритеты.
• Выпускайте продукт с бизнес-ценностью в конце каждого спринта. Единственное мерило успеха – работающий продукт.
• Разрабатывайте рабочие практики, требования, критерии успеха как одна команда. В идеале эта команда должна состоять из специалистов различных профилей.
• Избегайте чрезмерного давления на команду разработки продукта. Команда, работающая в щадящем режиме, выдает лучшие результаты, чем команда, находящаяся в постоянном напряжении.
