Всем привет! В этом видео мы поговорим про метрики и управления ожиданиями. Важно понимать, что работа с Scrum-командой основана на прозрачности. Это когда все участники процесса, Scrum-команда, заинтересованные лица и заказчики обладают общим контекстом о том, куда мы движемся и где мы сейчас находимся. Для обеспечения этой прозрачности очень важно уметь правильно управлять ожиданиями. В этом нам помогают метрики и инструменты. Давайте про них поговорим. Первая метрика называется скорость команды или Velocity. Это основная метрика для отслеживания эффективности работы команды и отслеживает ее Scrum-мастер. Для этого он пользуется таким инструментом, как диаграмма скорости команды или Velocity chart. Эта диаграмма строится следующим образом: каждый Sprint Scrum-мастер сначала берет все элементы бэклога, которые команда взяла для выполнения в Sprint и считает суммы их единиц истории. Я напоминаю, что все истории элемента бэклога у нас оценены в единицах истории. Это наш план, сколько команда запланировала сделать. В конце sprint Scrum-мастер берет все элементы бэклога или пользовательские истории, которые команда успела сделать, которые готовы для поставки нашим конечным пользователям и считает сумму их единиц истории, это наш факт, сколько единиц истории команда сделала в этом sprint. Эта диаграмма позволяет нам отслеживать два важных фактора: первое - это собственно продуктивность, скорость команды, сколько она успевает делать единиц историю в sprint и качество нашего планирования путем сравнения плана и факта. Следующий инструмент называется диаграмма сгорания sprintа или Sprint Burndown Chart. Она обеспечивает прозрачность прогресса работы внутри sprintа и ее строят так же Scrum-мастер. Выглядит она следующим образом, по горизонтали у нас дни sprintа, а по вертикали Scrum-мастер показывает количество оставшихся единиц истории, то есть оставшихся, это значит единиц истории тех элементов, которые еще не сделаны командой. Соответственно, по мере выполнения реализации этих элементов бэклога количество этих единиц будет уменьшаться, то есть они как бы будут сгорать, поэтому это диаграмма называется диаграммы сгорания. Вторым графиком здесь можно строить количество не сделанных задач. Помните, я рекомендовал вам дробить задачи на кусочки не более чем четыре часа. Тогда будет очень удобно строить этот график, мы просто можем посчитать количество стикеров на доске и, собственно, это количество построить на диаграмме. Есть такая штука в этой диаграмме, которая называется идеальная диаграмма сгорания. Это прямая линия, соединяющая общее количество единиц истории, которые мы взяли в sprint по вертикальной шкале с последним днем sprint. Это позволяет, это идеальная диаграмма сгорания позволяет нам взглянуть всего лишь одним глазом на эту диаграмму, сказать команда успевает в срок все сделать, то есть до конца sprint-а, отстает от плана или даже опережает его. Следующий инструмент называется диаграмма сгорания релиза, или Release Burndown Chart. Строится аналогичным образом, как предыдущая, но строят ее владелец продукта, это его основной инструмент управления ожиданиями заказчиков. Выглядит следующим образом: по горизонтали у нас уже не единица sprint-а, а sprint-ы, а по вертикали - это сумма оставшихся единиц истории в нашем бэклоге продукта. Соответственно, команда каждый sprint поставляет ценный результат, реализует какие-то элементы бэклога, и у нас сумма этих единиц истории уменьшается. Соответственно, мы можем построить прогноз, это называется линия тренда, начертите эту линию тренда прямо на графике, мы сможем построить прогноз в каком sprint-е будет завершена разработка всего продукта. Вы спросите, ну бэклог же у нас живой документ? То есть он может меняться, в нем могут добавляются новые элементы, и будете совершенно правы. Для того чтобы отслеживать добавляемую новую работу, используется такой инструмент, как расширенные диаграммы сгорания релиза или Extended Release Burndown Chart. Выглядит она точно так же, как обычная диаграмма сгорания, но под горизонтальной осью мы начинаем каждый sprint отмечать суммой единиц истории, которые у нас добавлены в бэклог. Это позволяет нам отслеживать два тренда: динамику уменьшения работы или сгорания работы, та скорость, с которой команда, собственно, выполняет работу, и второй тренд - это динамику добавления появления новой работы в каждый sprint. Соответственно, взглянув на эти два тренда, мы можем уже сделать более точный прогноз, когда будет завершена разработка продукта, но может случиться и такая вещь, если у нас добавляется работа быстрее чем мы успеваем ее делать, соответственно, такой продукт или проект, он резиновый, мы его никогда не закончим при сохранении этой динамики. Вот эта диаграмма сгорания, она на удивление дает очень точный результат с прогнозированием. Почему? Потому что она основана на реальной настоящей скорости вот именно нашей команды, которая разрабатывает продукт, а не каких-то абстрактных экспертов или абстрактных программистов, которые будут делать работу. Здесь важно сказать про такую вещь, которая называется проектный треугольник. Проектный треугольник известен всем менеджерам проектов и выглядит он так: у нас есть три вершины треугольника, это у нас scope, то есть объем работ, который нужно выполнить по проекту, это у нас бюджет, то есть ресурсы, которые мы выполняем проект, и это у нас время, которое нам требуется для того, чтобы выполнить этот проект. Идея заключается в следующем, что при изменении одного из этих параметров, он обязательно влияет на какое-то хотя бы один из двух оставшихся, соответственно, при проектном подходе очень часто, когда мы понимаем в середине проекта, например, что мы не укладываемся в срок, в deadline, что мы можем сделать? Мы можем либо отодвинуть этот deadline, либо уменьшить объем работ, либо, например, увеличить бюджет, то есть количество ресурсов, который этот проект исполняет. Так вот в классическом проектном подходе очень часто мы увеличиваем бюджет или отодвигаем deadline, переносим его. В любом Agile подходе и конкретно в Scrum тоже, основной инструмент управления у нас эта scope, объем работ. Помните, пользовательские истории в бэклоге, мы ориентировали на ценность, которую они приносят пользователю, а при планировании каждого sprint-а мы формулировали цель sprint-а, то есть то, чего мы хотим добиться в этом sprint-е. Это дает Scrum-команде определенную гибкость. Что мы можем сделать быстрее? Какую работу сократить? Но при этом, чтобы принести ценность пользователю все равно и достичь цели. Давайте представим несколько ситуаций: допустим Scrum-мастер замечает по диаграмме сгорания sprint-а, что команда не успевает все выполнить sprint из того, что она запланировала. Что он должен сделать? Правильный ответ заключается в следующем: он должен, собственно, пригласить на встречу владельца продукта и команду разработки и предложить им это обсудить. Должен обозначить, что команда действительно не успевает, давайте найдем решение. В общем случае обычно это выглядит как вопрос владельцу продукта, что из того, что мы запланировали, наименее ценное для реализации именно в этом sprint-е, что мы можем убрать обратно в бэклог с целью того, чтобы все равно выпустить релиз, ценный релиз продукта для нашего пользователя в конце sprint-а. Аналогичным образом, что если владелец продукта по диаграмме сгорания релиза замечает, что Scrum-команда не успевает реализовать все, что было запланировано, все что у нас есть в бэклоге, в каком-то deadline. Он должен пригласить заказчика и объяснить ему это, и задать такой вопрос, что из того, что в бэклоге у нас несет ценность к этому deadline, а что несет меньшую ценность, и мы можем, например, отложить до следующего deadline или вообще выбросить. То есть то, что можно в принципе не реализовывать в продукте.