Как вы оцениваете проворный проект?

Ответ 1

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

Итак, есть как минимум два документальных способа, которыми вы можете это сделать, и оба они описаны в "Agile Estimating and Planning" book by Майк Кон, я настоятельно рекомендую всем прочитать.

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

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

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

Ответ 2

Big Upfront Estimation - это просто большой внешний дизайн с прикрепленным $$$

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

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

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

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

Короткие спринты с обратной связью и одобрениями клиентов

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

"вы этого не сделаете, это полностью противоречит всей парадигме гибкости": я думаю, что это совершенно неверно. Agile основан на здравом смысле, и никто не будет инвестировать в проект, если они понятия не имели, сколько это будет стоить примерно: они понимают, что им, возможно, придется сократить объем, чтобы соответствовать срокам или увеличить бюджет и/или продлить сроки, чтобы доставить весь объем. В проектах моей компании мы оцениваем проекты, сравнивая их размер, а также оцениваем эпосы с помощью планирования покера. Используя конус неопределенности и, не торгуя качеством, мы почти на 50% удалим по нашим оценкам до начала первого спринта по сравнению с реальностью. И мы будем улучшаться по мере наращивания нашей гибкой экспертизы (по точности и времени, чтобы получить первые оценки). Вы не можете ожидать, что маркетинг будет спонсировать проекты в течение 3 спринтов (так что до 3 месяцев), чтобы иметь представление о том, сколько это будет стоить.

Ответ 6

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

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

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

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

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