Comments 12
А почему вы пользуетесь spent-left вместо required-left? Тогда ведь не будет фантомного прогресса. А в плане итерации сроки уже прописаны. Вобщем я что-то не уловил суть и получилось, что вы сами себе создали проблему, а потом решали.
hours_left и required_left — мне кажется одно и то-же.
Давайте посчитаем. Пусть первая (плановая) оценка задачи — 16 часов.
Разработчик рапортовал такие оценки: 12 8 8 8 8 8 0. Тоесть, например он был переключен на другую задачу. Посмотрим какой процент получается на Гантте на 6й день: 6*8/(6*8 + 8) — это 86%.
Чтобы этот эффект не наблюдался, мы должны каждый день перерисовывать Гантт.
Давайте посчитаем. Пусть первая (плановая) оценка задачи — 16 часов.
Разработчик рапортовал такие оценки: 12 8 8 8 8 8 0. Тоесть, например он был переключен на другую задачу. Посмотрим какой процент получается на Гантте на 6й день: 6*8/(6*8 + 8) — это 86%.
Чтобы этот эффект не наблюдался, мы должны каждый день перерисовывать Гантт.
Нет, я имел ввиду что вместо (spent)/(spent+left) использовать (spent)/(required)
То есть первая формула лучше когда у нас нет оценки времени, но вторая на спринте будет корерктна, потому что оценка времени как раз есть. Причём spent это время прошеднее с начала спринта, а время потраченное на задачу.
Ганта перерисовывать придётся, но зачем же его рисовать если потом работать не по плану? Это уже плохое планирование спринта.
То есть первая формула лучше когда у нас нет оценки времени, но вторая на спринте будет корерктна, потому что оценка времени как раз есть. Причём spent это время прошеднее с начала спринта, а время потраченное на задачу.
Ганта перерисовывать придётся, но зачем же его рисовать если потом работать не по плану? Это уже плохое планирование спринта.
Если я правильно вас понял, предлагается зафиксировать длительность задачи… Тогда в нашем случае мы получим на 6й день 6*8 / 16 = 300%… не работает…
Во время спринта делается каждодневная оценка оставшегося времени по задаче. И некоторые задачи могут улетать за их первую оценку, сделанную во время планирования спринта. Это жизнь.
Вот несколько примеров, чтобы выйти на общую точку понимания:
задача сделана раньше плана:
план — 24. Отчеты — 24 12 0
задача совпала с планом:
план — 24. Отчеты — 24 16 8 0
задача не вписалась в план:
план — 24. Отчеты — 24 28 20 12 4 0
обычно такое случается, если находятся непредвиденные проблеммы с логикой или архитектурой.
Во время спринта делается каждодневная оценка оставшегося времени по задаче. И некоторые задачи могут улетать за их первую оценку, сделанную во время планирования спринта. Это жизнь.
Вот несколько примеров, чтобы выйти на общую точку понимания:
задача сделана раньше плана:
план — 24. Отчеты — 24 12 0
задача совпала с планом:
план — 24. Отчеты — 24 16 8 0
задача не вписалась в план:
план — 24. Отчеты — 24 28 20 12 4 0
обычно такое случается, если находятся непредвиденные проблеммы с логикой или архитектурой.
Блин, по-моему у Вас где- в консерватории проблема…
как минимум
— если задача приостановлена, то ее надо разрывать в ганте. Фактически появляется одна подзадача выполненная на 100% и новая на 0%.
— если активные изменения в назначенных на задачу, то это излишняя детализация в WBS.
как минимум
— если задача приостановлена, то ее надо разрывать в ганте. Фактически появляется одна подзадача выполненная на 100% и новая на 0%.
— если активные изменения в назначенных на задачу, то это излишняя детализация в WBS.
и да, Вы постоянно путаете человеко-часы и просто часы, например для формулы
progress% = 100 * hours_spent / (hours_spent + hours_left) это все человеко-часы, то есть обьем проделанной работы, и если месяц ничего не делалось, то hours_spent как был так и останеться 0
progress% = 100 * hours_spent / (hours_spent + hours_left) это все человеко-часы, то есть обьем проделанной работы, и если месяц ничего не делалось, то hours_spent как был так и останеться 0
>> Вы постоянно путаете человеко-часы и просто часы,
Вот я тоже это написал, только по-деревенски :-)
Вот я тоже это написал, только по-деревенски :-)
Задача состоит в том, чтобы один бэклог автоматически трансформировать в один Гантт.
Именно такая операция невозможна.
В этом примере меденжер должен перерисовать изначальный Гантт, перенеся или разорвав приостановленную задачу. Тоесть один беклог отображается на несколько Гантт диаграмм.
Здесь рассматривается логика приложения. Представте, что мы находимся на странице плана итерации в режиме беклог. Что мы должны увидеть, если на этой странице пользователь нажимает кнопку «Gantt»?
Не получится просто ему показать одну Гантт диаграмму. Ему таких диграмм нужно сгенерировать столько, сколько рабочих дней показано в одном бэклоге. Поскольку в Скраме каждый день мы все планируем заново.
Именно такая операция невозможна.
В этом примере меденжер должен перерисовать изначальный Гантт, перенеся или разорвав приостановленную задачу. Тоесть один беклог отображается на несколько Гантт диаграмм.
Здесь рассматривается логика приложения. Представте, что мы находимся на странице плана итерации в режиме беклог. Что мы должны увидеть, если на этой странице пользователь нажимает кнопку «Gantt»?
Не получится просто ему показать одну Гантт диаграмму. Ему таких диграмм нужно сгенерировать столько, сколько рабочих дней показано в одном бэклоге. Поскольку в Скраме каждый день мы все планируем заново.
Эээ, опять же гант — это не столько форма отображения сколько форма планирования. Если у вас 10 задач и 10 программеров тусуются между ними постоянно, то гант будет выглядеть как 10 параллельных задач.
вам нужно отображать прогресс? Ну так делайте это для задач независимо ото всего, не надо мучить гант для этого.
вам нужно отображать прогресс? Ну так делайте это для задач независимо ото всего, не надо мучить гант для этого.
Несколько запоздало влезаю в дискуссию :-) Но уж очень интересна показалась тема.
Прошло уже 2 года с поста, скажите, были ли реализованы какие-то интересные решения по скрещиванию ганта со скрамом?
Я сейчас работаю над близкой тематикой, интересуюсь, кто что придумал.
В качестве комментария хочу добавить, что, на мой взгляд, неправильно относиться к диаграмме ганта как к чему-то статическому и неизменному. Это лишь способ показать на шкале времени информацию о фактически выполненных и запланированных задачах. В начале итерации это только планируемые задачи, в конце итерации — все должно быть выполнено. И это логично приводит нас к утвверждению, что да, действительно, диаграмма Ганта каждый день должна быть новой. В идеальном случае (когда все идет по плану) она отличается от исходной только процентами выполнения задач. Но в реальности все не так и я не вижу смысле так цепляться за неизменность диаграммы Ганта. Это же не какая-то священная корова, а всего лишь инструмент визуализации.
Прошло уже 2 года с поста, скажите, были ли реализованы какие-то интересные решения по скрещиванию ганта со скрамом?
Я сейчас работаю над близкой тематикой, интересуюсь, кто что придумал.
В качестве комментария хочу добавить, что, на мой взгляд, неправильно относиться к диаграмме ганта как к чему-то статическому и неизменному. Это лишь способ показать на шкале времени информацию о фактически выполненных и запланированных задачах. В начале итерации это только планируемые задачи, в конце итерации — все должно быть выполнено. И это логично приводит нас к утвверждению, что да, действительно, диаграмма Ганта каждый день должна быть новой. В идеальном случае (когда все идет по плану) она отличается от исходной только процентами выполнения задач. Но в реальности все не так и я не вижу смысле так цепляться за неизменность диаграммы Ганта. Это же не какая-то священная корова, а всего лишь инструмент визуализации.
Sign up to leave a comment.
Gantt против Backlog