Как заряжаться/планировать в проектах гибкой разработки программного обеспечения? [закрытый]

Если ваш клиент уже купил в использовании гибели Agile, то у вас есть Разумная основа для переговоров по цене на итерацию. Например, вы знаете:

1. Как долго будет итерация.
2. Сколько людей будет привержено на работу над итерацией (и их тарифами).
3. приблизительный объем работы.
4. процесс доставки и принятия.

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

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

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

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

Мой 2c как не-агил-практик... в попытке узнать больше...

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

Хотя гибкий может быть итеративным и не требует полной спецификации; цель, по крайней мере, безусловно, требуется. Должна быть какая-то форма базовой спецификации / требования. Это может быть, что вам нужно разбить проект на более мелкие цели и применять затраты соответственно.

Итерации, которые, как я подозреваю, в большей степени связаны с методологией разработки, т.е. с достижением целей?

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

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

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

Типичный подход к этой проблеме - поставить стоимость «не превысит». Однако, если вы не можете контролировать объем, вы берете на себя весь риск.

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