Burn Down Chart: как определяется работа, выполняемая в Scrum

Как определяется работа, выполняемая в Scrum

Работа, которая удовлетворяет определению «Готово», определяемому Командой.

Проблема в том, что работа, закрывающаяся ежедневно, не отображается на диаграмме Burndown.

Это правильное поведение. С точки зрения Scrum незавершенная история не имеет ценности, поэтому выгорание показывает нулевой прогресс.

создается впечатление, что мы не достигнем цели спринта.

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

Может ли кто-нибудь дать представление о том, как определяется работа?

Это зависит от того, для чего вы используете эту отслеживаемую работу. Burndown, в частности, используется для отслеживания скорости, а это означает, что он касается только работы, которая соответствует определению «Готово».

Работа выполнена или не выполнена

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

При этом широко распространенные agile-фреймворки обычно рассматривают работу либо как выполненную , либо как невыполненную . Элементы Журнала Продукта и Спринта никогда не являются «частично выполненными», поэтому они не сгорают до тех пор, пока не будут соответствовать определению «Готово».

Правильно определите степень детализации

Если вы хотите получить более четкое представление о том, что сделано/не сделано, вам, вероятно, потребуется реорганизовать журнал спринта и диаграмму выработки, чтобы отслеживать задачи , а не пользовательские истории. Если вы сделаете это, вы сможете сжечь каждую задачу, поскольку она выполнена на 100%, что даст вам более тонкую линию тренда.

Однако обратите внимание, что «более тонкий» не означает «лучше» или «точнее». Дополнительные накладные расходы на декомпозицию и отслеживание работы на значительно более детальном уровне (в идеале с учетом критериев INVEST ) часто превышают выгоду от этого. Чрезмерная детализация редко приводит к улучшению доставки пользовательских историй или целей спринта. Другими словами, это обычно создает иллюзию большей точности, но на самом деле не делает процессы оценки или доставки более эффективными.

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

Линии тренда: функция размера элемента невыполненной работы

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

С другой стороны, если Скрам-команде действительно нужна дополнительная видимость, то вся команда должна взять на себя дополнительные накладные расходы на планирование и отслеживание на более детальном уровне. Только Скрам-команда может определить, является ли это полезным компромиссом или нет.

Вопрос, который следует задать себе:

Какую информацию мы хотим получить от Burndown?

Разные команды будут использовать выгорание по-разному.

Популярным подходом является сжигание завершенных историй. Это дает понять команде, что они «загружают» спринт, т. е. что истории выполняются только ближе к концу спринта, а не последовательно на протяжении всего спринта. Это может указывать на такие проблемы, как то, что истории слишком велики или что тестирование имеет тенденцию смещаться к концу спринта.

Другие команды любят экономить на усилиях, поэтому они могут использовать задачи (или подзадачи, используя терминологию JIRA). Это позволяет команде отслеживать усилия, которые они оценили для выполнения задач, по сравнению с фактическими усилиями, которые они вкладывают. Это может дать раннее предупреждение о том, что команда может не выполнить всю работу, которую они ожидали выполнить в спринте.

Я использую TFS уже 4 месяца, поэтому я еще не эксперт. Но я думаю, что Burndown, предоставляемый TFS (насколько я понимаю), работает плохо. Сначала вам нужно сохранить доступность всех членов команды и количество времени, которое они будут доступны для спринта. Затем вам также необходимо зарегистрировать количество времени, оставшееся на задачу.

Мне кажется, что это много работы, которая не нужна. Я только что создал график на основе запроса и создал собственное выгорание на уровне задачи. Это показывает команде достаточно информации о задачах, которые находятся в состоянии «выполнить», «в процессе» и «выполнено».