Скрам - Когда вы оцениваете усилия по продукту незавершенного производства? [закрыто]

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

Оценка Проекта / Конструкция Дорожной карты (Уровень Истории)

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

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

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

После того, как это, которое 1-й раунд оценки истории, мог бы хотеть владелец продукта вместе с командой, повторно присваивает приоритет отставанию для оптимизации отношения стоимости/преимущества, таким образом, сила быть некоторыми назад и вперед, пока нет соглашение.

необходимо закончить с чем-то вроде этого:

PROJECT ACME ROADMAP

SPRINT 1 (38 points) <= estimated velocity
--------
Story 1 (21 points)
Story 2 (13 points)
Story 3 (4 points)

SPRINT 2 (40 points)
--------
Story 4 (13 points)
Story 5 (13 points)
Story 6 (8 points)
Story 7 (5 points)

SPRINT 3 (39 points)
--------
...

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

прогресс на этом уровне должен быть видим заинтересованным сторонам, использующим диаграмму burndown, где ось X является спринтами, и ось Y точки истории.

Оценка Sprint (Уровень Задачи)

2-я часть стадии планирования для каждого спринта потрачена, ломая каждую историю в задачи. Здесь, задачи должны быть очень техническими по своей природе и оцененные часы использования. У нас есть политика что, если задача оценивается дольше, чем 8 часов, то она должна быть разломана на более подробные задачи несмотря ни на что. Результатом будет отставание спринта с задачами, сгруппированными историей и спринтом burndown диаграмма, где ось X/Y должна быть днями спринта и часы соответственно.

Это должно быть похожим на это:

Sprint 8
--------
Story 17
  Task 1: 8 hours
  Task 2: 6 hours
  Task 3: 2 hours

Story 18
  Task 1: 8 hours
  Task 2: 6 hours

Story 19
  Task 1: 6 hours
  Task 2: 3 hours
...

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

В данный момент мы производим подробную разбивку задачи и оценки, прежде чем спринт запустится. Это по 2 причинам:

1) Наш бизнес хотят, чтобы оценки помогли им решить приоритет.

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

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

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

2) запись вниз строит диаграмму, должен рассматриваться как руководство по тому, как проект прогрессирует, чтобы указать, отбрасывается ли потребность большего количества PBI, которая будет добавлена или более низкие приоритетные, и не как твердая 'цель' того, что будет завершено.

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

мне будет интересно получать комментарии к этому, прежде чем у меня будет сражение с моим бизнесом.

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

Наше планирование спринта обычно упаковывается временем к 2 часам в начале нового спринта. Это - когда мы встречаемся с владельцем (владельцами) продукта и выбираем объекты от отставания, большинства из них примерно оцененный и правильно расположенный по приоритетам. Недостающие оценки сделаны на месте, и затем мы делаем "мелкомодульное" управление задачами историй в этом окне времени (который является обычно довольно интенсивной работой), усиление того, что остальная часть компании знает об этом и НА МЕСТЕ ПРОДАЖИ и заинтересованные стороны доступны для разбираний в неучтенных деталях.

, Конечно, иногда последовательность задачи реализации будет отличаться от запланированного управления задачами, затем это должно быть скорректировано, и диаграмма burndown, возможно, должна была бы быть повторно настроена.

Burndown в задачах
Мы просто используем количество задач для нашей меры по burndown. Обычно Вы делаете что-то как фактические часы или идеальные часы, но это было достаточно хорошо для нас и достаточно по-видимому интересно нуждаться в некотором разъяснении.

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

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

В конце мы обработали x сумму точек истории и получаем наш фактор фокуса от этого относительно фактических доступных дней человека в команде тот спринт.

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

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