Как вы берете своего клиента в проекте с использованием гибкой методологии?
В час? Тогда перед проектом должно быть создано большое доверие.
За итерацию? Там будет много бюджетных решений, которые могут занять некоторое время.
В проекте? Как вы можете это сделать, когда не знаете рамки? Сама суть гибкости заключается в том, чтобы не писать большой предварительный дизайн/спецификацию.
Вы берете своего клиента на основании условий, определенных вашим контрактом, которые будут немного отличаться от традиционного контракта с фиксированной ставкой. Позвольте называть это Agile-контрактом.
Некоторые варианты обсуждаются Алистером Кокберном в Agile контрактах.
Еще один отличный ресурс - 10 контрактов для вашего следующего Agile Software Project от Peter Stevens.
Мэри Поппендик также имеет большой материал по этой теме. См. agilecontracts, agilecontractsworkshop, Контрактный отрывок из Lean Software Development, Lean Contracts. Подробнее здесь.
Короткий ответ, вы не будете. Есть несколько компаний, которые продвигаются вперед, но это сложный путь. Ваша способность продавать методологию и убеждать клиента, которого вы можете доставить, будет высокой.
Клиенты не хотят рисковать платить за решение, которое никогда не будет доставлено.
Типичные подходы к этой проблеме заключаются в том, чтобы поставить "не превышать" стоимость. Тем не менее, если вы не можете контролировать область действия, вы рискуете тем, что рискуете.
Короче говоря, вы ищете клиентов, которые подписались на контракты T & M (время и материалы) до того, как Agile стала последней причудой (я часть этой причуды, но это всего лишь одна длинная строка процессов развития. Аспекты этого будут продолжать расти, и некоторые перестановки будут иметь другое название через несколько лет).
Если ваш клиент уже купил использование гибкой методологии, у вас есть разумная основа для переговоров по цене за итерацию. Например, вы знаете:
Это намного больше доказательств того, на какие основополагающие решения о ценах, чем доступно для большинства контрактов с фиксированной ценой.
Если гибкая методология - это просто внутренний процесс разработки, который не связан с клиентом, то он вряд ли сильно повлияет на переговоры о ценах между поставщиком и клиентом. Существует аргумент, в котором говорится, что процесс, который не включает клиента в настройку области видимости и ожиданий хотя бы один раз за итерацию, вообще не является проворным.
Что касается комментария к Mark, существует очень распространенная модель ценообразования, основанная на контрактах с фиксированной ценой с четко определенной областью и оптимистичными графиками. Общим результатом является то, что как поставщик, так и клиент обнаруживают, что их первоначальный оптимизм был неуместным. Оба заканчивают переговоры о слабых позициях над вещами, которые действительно важны для них, и оба заканчивают недовольство.
Некоторые из методов, которые хорошо работают при управлении этим типом контракта, очень похожи на те, которые используются для управления гибкими контрактами (частая доставка, торговля лошадьми по объему, приоритетам и цене, откровенная связь,...) основное различие заключается в том, что они не встроены в первоначальное соглашение, и контракт может быть недостаточно гибким, чтобы удовлетворить все их.
Мой 2c как непроницаемый практик... в квесте узнать больше...
Если вы выполняете конкретный проект для клиента, вам необходимо знать объем проекта, чтобы обеспечить стоимость и временную шкалу. Стоимость создания этой сферы работы чаще всего не является частью открытия проекта, вы либо получаете удар по этому, чтобы получить работу, либо взимать плату за это (явно или неявно). В этом случае стоимость проекта может быть разработаны и согласованы. В этом случае проект обычно разбивается на несколько этапов.
Хотя проворство может быть итеративным и не требует полной спецификации; цель, по крайней мере, обязательно необходима. Должна быть какая-то базовая спецификация/требование. Возможно, вам нужно разбить проект на более мелкие цели и соответственно применить затраты.
Итерации, которые, как я подозреваю, больше связаны с методологией разработки, то есть для достижения целей?
Если спецификации недостаточно для получения окончательно точной стоимости, я бы сказал, что нужно дать "оценку", но работу следует оплачивать почасовой ставкой, так как я бы предположил, что будут внесены большие изменения в принимаемые решения на проекте по каждой итерации.
Я видел, что он хорошо работает, когда его приближают в 2 этапа:
Фаза 1) Начало (время)
Временной период с клиентом для охвата проекта. (Одночасовая интенсивная разработка для проекта, рассчитанная на последний год, примерно соответствует действительности). Выходы на эту фазу - это полное отставание в размерах пользовательских историй, оценка скорости потока на одну пару dev и параметры для оценки затрат по проекту на основе количества разработчиков и накладных расходов на наличие более крупных команд.
Вначале представлена полезная бюджетная оценка, которая может быть отслежена во время фазы 2, четкое общее видение как для клиента, так и для поставщика, а также возможность для любой стороны уйти. Это не предварительный дизайн, в рассказах достаточно деталей для ведущего разработчика/тестера для назначения относительных размеров.
Фаза 2) Доставка (время и материалы)
Договор поставки, основанный на времени и материалах, с бюджетной оценкой, основанной на результатах с начальной фазы. Доверие, созданное на первом этапе, имеет жизненно важное значение для выполнения этой работы. Поскольку фаза 1 обеспечивала относительное измерение всего отставания, регулярно измеряя фактический поток, можно легко и часто сообщать прогнозируемый расход для остальной части отставания со все более точными оценками бюджета и датой поставки. Поставщик должен быть заключен контракт, чтобы сообщать об этой статистике не реже одного раза в две недели, с возможностью для клиента уйти в любой момент.
Платя за время и материалы, клиент может изменить сферу действия и преемственность отставания и, следовательно, контролировать бюджет. Они призваны уделять первоочередное внимание их наивысшим приоритетам/наивысшим рискам в первую очередь, а также позволяя им уходить, когда им нравится, что они всегда должны иметь положительную отдачу от инвестиций.