Scrum и расчетное время проекта [закрыто]

Для данного бюджета вы знаете, сколько итераций можно сделать. Затем владелец продукта должен расставить приоритеты в работе, чтобы получить максимальную отдачу от невыполненной работы по продукту. Именно так работает Agile, фиксированное время и размер команды с переменной областью действия (Agile - это управление областью действия). И как только скорость команды известна, вы можете спрогнозировать, сколько работы (в баллах) может быть сделано (# спринтов X скорость = размер работы, которая может быть достигнута).

Часто, клиент не получает его и хочет "все, что они думайте, что они нужны в данный момент времени " (т. е. фиксированный объем). В этой ситуации вы в конечном итоге делаете какой-то предварительный анализ, чтобы разбить все на достаточно мелкие элементы, чтобы оценить их. Как только эта работа будет выполнена, вы можете спрогнозировать, сколько спринтов вам понадобится, угадав скорость (# спринтов = общий размер / скорость). Это очень распространенная ситуация для людей с водопадным фоном и часто приводит к неточной дате окончания (фиксированная область и размер команды с переменным временем), потому что вы не можете действительно угадать скорость, и начало проекта-это худший момент для оценки.

В обоих случаях вам понадобится скорость. Проблема в том, что скорость на самом деле 1) неизвестна до начала работы команды и 2) будет изменяться с течением времени.

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

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

Абсолютно, в scrum вы фиксируете стоимость и время. Затем вы позволяете функциям изменяться. Таким образом, вы можете сказать клиенту, что это будет сделано на XX/XX/XXXX по цене $YYY.YY. Затем они должны определить приоритетность функций, которые они хотят обеспечить, чтобы наиболее важные из них были выполнены в соответствии с этими ограничениями.

Да и нет. Я считаю, что Scrum-это отличный подход к вовлечению владельца в планирование спринтов.

Поэтому в случае оценки было бы трудно сказать: "мы сделаем проект за 30 дней". Вместо этого у владельца будет ожидание того, что будет сделано, скажем, в первую и вторую данную неделю, и восприятие того, что будет сделано Через 30 дней.

На мой взгляд, это более ценно, чем давать оценку 30 дней и затем быть везучим, или далеко от цели.

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

Это зависит от того, что вы хотите предсказать.

Вы можете обещать, что N-недельный спринт займет ровно n недель, а m спринтов-n*m недель. Поэтому оценка графика проста. Оценка затрат / усилий также проста, учитывая определенный размер команды и продолжительность проекта. То, что вы не можете надежно обещать, - это то, какие функции в конечном итоге будут доставлены, а какие нет.

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

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

С agile, включая Scrum, у вас есть фиксированный график (итерации или спринты) и фиксированный уровень качества (определение done). Затраты / усилия пропорциональны тому, сколько людей у вас в команде. Сфера применения является главным балансирующим фактором. Он обладает приятным свойством вести себя довольно линейно: увеличение или уменьшение объема не вызывает чрезвычайно нелинейных изменений в других драйверах. Ключом к успеху является приоритизация функций, чтобы получить максимальное значение из области, которую вы можете предоставить.

Как говорит Стив Макконнелл в оценке программного обеспечения, всякий раз, когда вам нужно предоставить оценку:

1. Граф
2. Если вы не умеете считать, то вычислите
3. Если вы не можете вычислить, то судите

"экспертное суждение" или расчет-это последний ресурс. Попробуйте подсчитать реальные вещи и/или обратиться к историческим данным, Чтобывычислить значимую цифру.

Это применимо независимо от метода, который вы используете, будь то Scrum или что-то еще еще.