Как Вы оцениваете гибкий проект впереди? [закрытый]

Большая предварительная оценка - это просто большой предварительный дизайн с приложенными $$$

Вы этого не делаете, это полностью противоречит всей парадигме гибкой разработки.

Agile может быть о фиксированных затратах

Что вы можете сделать, так это установить дату, а затем работать над ней в итерациях / спринтах, и позволить владельцам продукта (-ам) решить, что важно сделать к этой дате. Таким образом, спринт продолжительностью 1 или 2 недели является фиксированной стоимостью , как и в случае Big Up Front Design , но это только меньшая фиксированная стоимость.

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

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

Итак, есть как минимум два задокументированных способа сделать это: оба описаны в книге Майка Кона «Гибкая оценка и планирование» , которую я настоятельно рекомендую прочитать всем.

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

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

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

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

Итак, на самом деле вам не следует делать предварительные оценки. Это будет означать фиксированный объем, который является полной противоположностью Agile или анти-Agile, если вы предпочитаете.

Agile так не работает, вам нужен новый вид контракта, как указано в другом ответе. См., Например, 10 Agile Contracts и / или google .

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

Итак, на самом деле вам не следует делать предварительные оценки. Это будет означать фиксированный объем, который является полной противоположностью Agile или анти-Agile, если вы предпочитаете.

Agile так не работает, вам нужен новый вид контракта, как указано в другом ответе. См., Например, 10 Agile Contracts и / или google .

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

Итак, на самом деле вам не следует делать предварительные оценки. Это будет означать фиксированный объем, который является полной противоположностью Agile или анти-Agile, если вы предпочитаете.

Agile так не работает, вам нужен новый вид контракта, как указано в другом ответе. См., Например, 10 Agile Contracts и / или google .

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

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

Предположим, ваши пользовательские истории в сумме составляют 150 баллов, и вы прогнозируете, что ваша команда сможет набирать 15-20 очков истории в месяц, тогда работа займет 7,5-10 месяцев (посредством простого разделения).

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

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

5–10 месяцев (через простое деление)

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

Помните, что скорость работы команды колеблется по ряду причин. Обычно он ниже в начале проекта, когда команда еще только формируется. Кроме того, команда, скорее всего, на данном этапе сосредоточится на проблемах инфраструктуры, а не на предоставлении функциональности.

5–10 месяцев (через простое деление)

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

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

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

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

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

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

Обычно он ниже в начале проекта, когда команда еще только формируется. Кроме того, команда, скорее всего, сейчас сосредоточится на инфраструктуре, а не на предоставлении функциональности.

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

Вместо того, чтобы стремиться к контракту для «всего» проекта, вы должны создать контракт, который действует всего месяц или два.

Установите несколько очень низких целей, возможно, только два или три особенности.

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

Клиент получает следующие выгоды:

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