Scrum Burn Down Charts: задачи или истории? [закрыто]

Есть несколько способов сделать записи в Scrum.

Некоторые люди предлагают использовать сюжетные точки незавершенных историй, оставленные в качестве ваших выжигательных таблиц в Scrum.

Pro : Только законченные истории опускают график

Против : Диаграмма вначале не движется вниз, а затем быстро падает

Другие предлагают использовать количество оставшихся задач

Pro : Диаграмма сместится вниз, вы можете увидеть, находится ли она выше финишной линии

Против : Вы могли бы перейти, чтобы сказать 10 заданий, оставшихся (сложные задачи), в конце концов, и при этом еще ни одна история не была закончена. Вы потерпели неудачу, потому что только законченные истории хороши для вашего владельца продукта.

Является ли решение иметь как точки не законченных историй, так и график незавершенных задач?

15.12.2008 19:46:56
9 ОТВЕТОВ

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

Если на завершение истории уходит 2 дня, то у вас есть ровная линия на 2 дня, и нет никакого способа определить, сидит ли команда на своих пальцах, или эта работа увеличилась (таким образом, скачок рабочих часов).

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

0
15.12.2008 19:51:19
По моему опыту, вы не можете точно знать, насколько задача на самом деле способствует истории. Нанесение их на карту ожогов способствует иллюзии.
Ilja Preuß 15.12.2008 21:11:58
О, и, конечно, есть способ определить, сидит ли команда на своих пальцах: находиться в комнате команды. Или, по крайней мере, посещать ежедневные Scrum.
Ilja Preuß 15.12.2008 21:12:46

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

Вы не должны попадать в ситуацию, когда команда выполняет десять задач и не имеет элемента отставания (на самом деле, это возможно, если у вас десять разработчиков): каждый разработчик не должен выбирать задачи из другого элемента (истории) отставания, пока он не завершит отставание. относится к первым рассказам, которые он сделал, - событие, если задание из другого рассказа сложнее, чем остальные задания из начавшегося сотри.

0
15.12.2008 20:35:23

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

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

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

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

4
15.12.2008 21:21:30
+1 Отслеживание часов - пустая трата времени. Все, что имеет значение, - законченные истории. Если вы не сожгли историю, вы не добавили никакой ценности для бизнеса.
DancesWithBamboo 5.03.2009 06:15:32

Мы используем оставшееся время для спринта - команды могут видеть прогресс каждый день. Если есть плоские части, то они действительно произошли.

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

Количество заданий бесполезно . Это число можно менять каждый день, особенно если вы даете «свободу» разработчикам. Они могут разбить задачу на меньшую часть без изменения общего времени. Такая статистика бесполезна. На что это указывает? Влияет ли это на цель спринта?

7
16.12.2008 20:13:47
мы также отслеживаем оставшееся время (в часах). Каждая история разбита на задачи, которые (в идеале) меньше 16 часов.
M4N 3.01.2009 19:31:24
Узнайте больше о различных ситуациях на графиках выгорания
Dusan Kocurek 24.11.2011 10:41:24

Обычно мы должны отслеживать часы (оценка против фактической и окончательная) для сравнения с историями для клиентов, которые их просили. Это позволяет нам делать несколько вещей:

  1. Отслеживайте прогресс для потребностей этого клиента, чтобы его руководитель проекта имел некоторое представление о том, что происходит.
  2. Проверьте оценки относительно фактической работы, необходимой для улучшения нашей способности оценивать.
  3. Выписывать счет клиентам за фактически потраченное время, если оно является частью почасовой ставки.
  4. Дайте разработчикам обратную связь о своем прогрессе, чтобы они могли должным образом управлять отвлечениями.

Мы также отслеживаем законченные истории для нашего собственного выгорания, но, как уже было отмечено, это может привести к эффекту плато в начале спринта, который служит для того, чтобы сообщить нам очень мало полезной информации (кроме того, что мы не делаем достаточно параллельно ).

3
27.12.2008 12:58:28
мы также отслеживаем оставшееся время (в часах). Каждая история разбита на задачи, которые (в идеале) меньше 16 часов.
M4N 3.01.2009 19:31:56

Мы используем задачи, потому что это обеспечивает гораздо больше детализации. Графики только завершения историй (которые мы делаем 5-10 за двухнедельный спринт) будут показывать только изменения каждый день или два и, как вы упоминаете, не будут сильно двигаться в начале спринта.

Еще одна полезная вещь, которую нашла команда, - это использование составной линейной диаграммы с одной линией для каждого из «To Do», «In Progress», «Ready for QA» и «Validated». Таким образом, легко увидеть любой этап процесса создания резервной копии.

-1
3.01.2009 19:13:28

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

Я использую набор задач (общее количество задач, новые задачи, выполненные задачи). Гораздо лучше. Это правда, что вы не видите размер выполненных или новых задач. Но команда встречается каждый день, и именно здесь вы ловите проблемы. Кроме того, я тренирую команду, чтобы не создавать больших задач (максимум 4-6 часов). Кроме того, я добавил другой график с новыми задачами и выполненными задачами по дням. Команда обнаружила, что сгорание задач имеет больше смысла, чем использование часов.

После того, как команда поймет значения разбивки историй в заданиях, я хочу попробовать выгрузку историями. Таким образом, имея небольшие истории с максимум 5 или 8 баллов истории. Из блога Джеффа Сазерленда, это большой шаг к тому, чтобы команда достигла высоких результатов.

Кроме того, я хотел бы упомянуть, что выветривание - это просто «краткое представление о прогрессе». Наиболее важными и даже более важными для команды и ПО являются: то, что ежедневно упоминается о задачах + проценты прогресса сюжета + список препятствий. Через некоторое время менеджмент и члены команды не заботятся об обвале (или сгорании).

0
19.08.2009 21:29:22

Откат (или даже «выгорание») должен указывать только на оставшуюся работу.

Если вы наполовину написали историю, вы не можете ее отправить, и это не считается. Если вы заканчиваете весну наполовину законченной историей - задачи, которые были в ней выполнены, не учитываются, если вы измеряете скорость.

Просто нарисуйте истории, которые нужно завершить.

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

2
4.12.2009 00:47:39

Используйте оставшееся количество часов для спринтов в спринте. - Во время планирования спринта оцените всю работу, чтобы завершить историю, в соответствии с вашим определением выполненного. - Каждый день разработчики и тестировщики переоценивают часы, оставшиеся для всей своей работы (с изменением в сторону увеличения или уменьшения) - отслеживание выжигание спринта за оставшиеся часы - отличный показатель того, насколько хорошо или плохо идет спринт

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

-1
11.08.2011 09:14:45