您如何使用敏捷方法向项目中的客户收费？
每小时？然后在项目开始之前就必须建立起很大的信任。
每次迭代？会有很多预算决定，这可能需要时间。
每个项目？当你不知道范围时，你怎么能这样做？敏捷的本质是不要编写一个大的前期设计/规范。
答案 0 :(得分：19)
您根据合同规定的条款向客户收取费用，该条款与传统的固定投标合同略有不同。我们称之为敏捷契约。
Alistair Cockburn在Agile contracts中讨论了一些选项。
彼得史蒂文斯的另一个重要资源是10 Contracts for your next Agile Software Project。
Mary Poppendieck在这个主题上也有伟大的材料。请参阅agilecontracts，agilecontractsworkshop，Contracts Excerpt From Lean Software Development，Lean Contracts。更多here。
答案 1 :(得分：4)
简短的回答是，你不会。有一些服务公司正在取得进展，但这是一条艰难的道路。您销售该方法并说服您可以交付的客户的能力将很高。
客户不希望冒险支付永远无法交付的解决方案。
解决这个问题的典型方法是“不会超过”成本。但是，如果您无法控制范围，那么您将承担所有风险。
简而言之，您正在寻找能够在敏捷成为最新潮流之前签署T＆amp; M（时间和材料）合同的客户（我是那种时尚的一部分，但它只是一条长线中的一部分发展过程。它的方面将继续增长，并且它的一些排列将在几年内具有不同的名称。）
答案 2 :(得分：3)
如果您的客户已经购买了敏捷方法，那么您就有了一个合理的框架来协商每次迭代的价格。例如，您知道：
与大多数固定价格合约相比，这是基于定价决策的更多证据。
如果敏捷方法纯粹是一个不涉及客户的内部开发过程，那么它不太可能对供应商和客户之间的定价协商产生太大影响。有一种观点认为，每次迭代至少一次不涉及客户设置范围和期望的过程根本不敏捷。
关于马克的评论，有一个非常普遍的定价模型，基于固定价格合约，具有松散定义的范围和乐观的时间表。一个共同的结果是供应商和客户都发现他们最初的乐观情绪是错误的。两人最终都会在对他们真正重要的事情上从弱势地位进行谈判，最终都会感到不快。
在管理此类合同时运作良好的一些技术与管理敏捷合同（频繁交付，范围内的马交易，优先级和价格，坦率沟通......）中使用的技术非常相似区别在于这些不是原始协议中的内容，而且合同可能不够灵活，无法容纳所有这些协议。
答案 3 :(得分：2)
我的2c是一个非敏捷的实践者......为了更多地了解...
如果您正在为客户执行特定项目，则需要了解项目的范围以提供成本和时间表。制作这个工作范围的成本通常不是项目发现的一部分，你要么就是为了获得工作而付出代价（明确地或隐含地）。在这种情况下，项目成本可以是制定并同意了。在这种情况下，项目通常分为不同的阶段。
虽然敏捷可能是迭代的，不需要完整的规范;一个目标，至少肯定是必需的。必须有某种形式的基本规范/要求。您可能需要将项目分解为更小的目标并相应地应用成本。
我怀疑的迭代更多地与开发方法学有关，即实现目标？
如果没有足够的规格来产生明确准确的成本，我会说应该给出一个“估计”，但工作应该按小时计费，因为我认为做出的决定会有更大的变化关于每次迭代的项目。
答案 4 :(得分：1)
我认为在分两个阶段进行处理时效果很好：
阶段1）开始（时间框）
时间框启动期，客户端可以对项目进行范围调整。 （对于一个估计持续一年的项目，一个月的紧张开始是正确的。） 此阶段的输出是大量用户故事的完整积压，每个开发对的流量估算，以及根据开发人员数量和拥有更大团队的管理费用来估算项目成本的参数。
初始提供了一个有用的预算估算，可以在整个第2阶段进行跟踪，为客户和供应商提供明确的共同愿景，以及任何一方离开的选项。这不是前期设计，故事只有足够的细节，以便潜在开发人员/测试人员分配相对大小。
阶段2）交付（时间和材料）
基于时间和材料的交付合同，根据初始阶段的输出进行预算估算。第1阶段建立的信任对于完成这项工作至关重要。由于第1阶段提供了整个积压的相对大小，通过定期测量实际流量，可以轻松，频繁地报告其余积压的预计流量，并对预算和交货日期进行越来越准确的估算。应该与供应商签订合同，至少每两周报告一次这些统计数据，并允许客户随时离开。
通过支付时间和材料，客户可以自由地改变积压的范围和合理性，因此可以控制预算。他们被安排优先考虑他们的最高优先级/最高风险的故事，并允许他们随时离开，他们应该始终获得积极的投资回报。