Баг он и есть баг, хоть как его не называй.

хочется снова вкинуть свой доклад, но лучше я его превращу в статью и буду скидывать ее))

А надо не через беклог! Надо через ПО. Разница большая

Команда оценивает в SP, чисто для метрик. Берндаун я не веду с некоторых пор. Он не показывает ничего. Точнее он будет что-то показывать, если мы примем WIP=1. Доска информативнее, смысла в берндаун не вижу.

а что за метрики без burndown? velocity? нет проблем, что берете в спринт всегда больше чем релизите в итоге, потому что в середине спринта добавляют других "высокоприоритетных" задач и багов? burndown показывает динамику движения к цели спринта и дает единый фокус всей команде, если где то узкое горлышко, чтобы вся команда могла сконцентрироваться на этом, видел команды, где никогда не анализировался burndown, но всегда была оценка в sp, по сути почти пустая трата времени ) так как все в итоге сводилось к тому, что планировали одно, а в итоге херачили все что успеется, то есть больше походило на канбан по сути, тогда зачем скрам? ))

а что за метрики без burndown? velocity? нет проблем, что берете в спринт всегда больше чем релизите в итоге, потому что в середине спринта добавляют других "высокоприоритетных" задач и багов? burndown показывает динамику движения к цели спринта и дает единый фокус всей команде, если где то узкое горлышко, чтобы вся команда могла сконцентрироваться на этом, видел команды, где никогда не анализировался burndown, но всегда была оценка в sp, по сути почти пустая трата времени ) так как все в итоге сводилось к тому, что планировали одно, а в итоге херачили все что успеется, то есть больше походило на канбан по сути, тогда зачем скрам? ))

Story points, по-моему, это прежде всего инструмент долгосрочного планирования. Их использование в построении burndownchart - скорее второстепенно. Более того построение выгорания работ через sp может быть почти бесполезным когда в спринт берут небольшое число историй среднего веса - на диаграмме первую половину будет "всё плохо", хотя это может быть не так в реальности.

Story points, по-моему, это прежде всего инструмент долгосрочного планирования. Их использование в построении burndownchart - скорее второстепенно. Более того построение выгорания работ через sp может быть почти бесполезным когда в спринт берут небольшое число историй среднего веса - на диаграмме первую половину будет "всё плохо", хотя это может быть не так в реальности.

Не совсем понял как связаны метрики и берндаун. Велосити это для команды, она его использует при планировании, да и то в нашем случае все меньше и меньше. Они и так уже понимают сколько брать, чтобы выполнить все. Релиз никак со Спринтами не связан. Команды делает инкремент, владелец Продукта решает что пойдёт в релиз. Берндаун показывает ровно столько же сколько и нормальная доска для Спринт Бэклога (а она зачастую гораздо больше). Смысла в нем никакого, если вариативность входных задач высокая и нет ограничения незавершенной работы. Стори поинты используются для планирования. Команды берут ровно столько сколько считают возможным. Если приходит срочная работа, они имеют право оценив ее командой убрать из своего Бэклога равносложную работу. При этом с Владельцем продукта это все обсуждается. Тут как раз оценка и нужна, без неё сложнее.

про берндаун как показатель правильности процессов это как-то странно ) Берндаун говорит вам, успеваете вы или нет закончить спринт, только и всего

ну если команды и без sp знают сколько брать в спринт, чтобы успеть и burndown им не нужен, т.к. они и без него умеют оперативно управлять беклогом спринта во время спринта - это хорошо, но на мой взгляд это больше исключение, чем правило. А когда вы таки использовали берндауны, они выглядели идеально? никакой информации не давали? прежде чем вы пришли к тому, что они вам не нужны? или они в принципе не зашли сначала? а кумулятивные диаграммы тоже не используете?

для меня burndown был своего рода лакмусовой бумажкой, что процессы отражают суть scrum, если же burndown не отражает прогресс, то может быть дело таки в процессах? хотя конечно догм быть не должно, в общем вы открыли мне глаза немного шире, спасибо ) но если для вас burndown не отражает прогресс, то какой вы используете аналогичный инструмент, чтобы в середине спринта понять, идет все по плану? успеете вы или нет и стоит уже думать над тем, какие фичи лучше сразу отложить?

Ну смотри. Команда на планировании берет три стори по 13 SP. И все три заканчивает их к концу Спринта. Успех? Да. Берндаун чтo покажет? Правильно, прямую линию. А на доске мы увидим прогресс. И мы их упорно рисовали, пока не поняли, что они никому не нужны. Последней каплей стала статья Гюнтера Верхеена, что доска и берндаун есть одно и тоже, а именно инструмент визуализации прогресса. Мы в командах для Спринт Бэклога используем деревянные доски и стикеры. Для управления Бэклогом Ютрек. Кумулятивные диаграммы не используем. Имхо они также имеют смысл, если вариативность элементов Бэклога низкая (например, они имеют одинаковый размер в Спринте). Но это высший пилотаж работы и команд и Владельца Продукта - так подготовить Бэклог, чтобы такое было. Возможно для каких то Продуктов это реально. Но не у нас.

я услышал, что используете доску, но как по ней понять все хорошо или плохо не посчитав количество сгоревших sp? или вы это и делаете, просто не называете это burndown?

берндаун покажет, что не хватало декомпозиции например, на доске вы и так все увидите, одно другому не замена. То что вы рисовали burndown вручную... занятие то еще конечно, если бы все было автоматом, думаю вы бы ее использовали охотней, то же и с CFD, посмотрите в сторону плагинов или Jira

а вот по поводу что лучше часы или sp, прочитал 2 книги по пользователским историям: Паттона, Бека и еще оценку Agile проектов Бека - там всезде аргументированно приводится плюсы sp, сам давно оценивал в часах, 3 года назад перешел на sp и могу сказать что это гибче, что за аргументы были и утверждения что часы лучше - все оч специфично и зависит от контекста думаю

а вот по поводу что лучше часы или sp, прочитал 2 книги по пользователским историям: Паттона, Бека и еще оценку Agile проектов Бека - там всезде аргументированно приводится плюсы sp, сам давно оценивал в часах, 3 года назад перешел на sp и могу сказать что это гибче, что за аргументы были и утверждения что часы лучше - все оч специфично и зависит от контекста думаю

что становится бессмысленным? )

я правильно понимаю в идеальных часах? у вас не бывало, что при оценке таски один чел ее может делать 1 час, а другой 4? как они договаривались на планировании? или у вас ситуация что все разработчики одного уровня?

эээ) ну ладно, каждый готовит как умеет ) когда таски распределяются в начале спринта на конкретных людей, это не айс, хотя тоже может работать, это не гибко, и каждый склонен выполнить только свои таски и считать что он свою часть работы сделал, я это тоже проходил

но если в вашем случае все ок, и команда ок, и бизнесу ок - то проблем нет просто когда я вижу что у нас скрам, но burndown нам не нужен, я как то немного удивляюсь )

но если в вашем случае все ок, и команда ок, и бизнесу ок - то проблем нет просто когда я вижу что у нас скрам, но burndown нам не нужен, я как то немного удивляюсь )

она будет и без тасков возникать, если такая тенденция в команде есть

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

конечно будет, но если этому еще будет способствовать процесс, то это еще хуже

а ну ок )

не бить стори на таски тоже плохая практика, потому что при работе они ее все равно будут неявно на них разбивать, но шанс что-то забыть и обнаружить в середине спринта будет уже сильно выше

не бить стори на таски тоже плохая практика, потому что при работе они ее все равно будут неявно на них разбивать, но шанс что-то забыть и обнаружить в середине спринта будет уже сильно выше

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