如何在敏捷软件开发项目中收费/预算？

Question

如何使用敏捷方法在项目中向客户收费？

每小时？然后在项目之前建立起很大的信任。

每次迭代？会有很多预算决定，这可能需要时间。

每个项目？如果你不知道范围，你怎么能这样做？敏捷的本质是不写一个大的前期设计/规范。

Answer 1

您将根据您的合同中定义的与传统固定投标合同略有不同的条款向您的客户收费。我们称之为敏捷合约。

Alistair Cockburn在Agile contracts中讨论了一些选项。

另一个很好的资源是Peter Stevens的10 Contracts for your next Agile Software Project。

Mary Poppendieck也有很好材料在这个题目。见agilecontracts，agilecontractsworkshop,Contracts Excerpt From Lean Software Development,Lean Contracts。更多here。

Answer 2

如果您的客户已经购买了敏捷方法的使用，那么您有一个合理的每次迭代谈判价格的框架。例如，您知道：

1. 迭代将会持续多长时间。
2. 有多少人会致力于迭代（及其费率）。
3. 大致的工作范围。
4. 交货和验收流程。

对于大多数固定价格合约而言，定价决策的依据更多。

---

如果敏捷方法纯粹是内部开发的过程，不涉及客户，那么就不太可能对供应商和客户之间的定价谈判太大的影响。有一种观点认为，在每次迭代中至少一次不涉及客户设定范围和期望的流程根本不灵活。

关于马克的评论，有一个非常普遍的定价模式，基于固定价格合约，定义范围宽松且乐观。一个共同的结果是，供应商和客户都发现他们最初的乐观主义错位。最终都是从弱势立场谈起对他们真正重要的事情，而最终都不高兴。

在管理这种类型的合同方面效果很好的一些技术与管理敏捷合同（频繁交付，涉及范围的马交易，优先价格，坦率交流，...）主要使用的技术非常相似不同之处在于这些内容并未纳入原始协议中，合同可能不够灵活以适应所有这些协议。

Answer 3

我作为一个非敏捷实践者2C ......在寻求了解更多...

如果你正在做一个具体项目的客户，你需要知道该项目的范围提供成本和时间表。生产这个工作范围的成本往往不是项目发现的一部分，你要么在这个项目上受到打击，要么为此获得工作或收费（明示或暗示）。在这种情况下，项目成本可能是制定并达成一致。在这种情况下，这个项目通常会分解成不同的阶段。

虽然敏捷可能是迭代的，不需要完整的规范;一个目标，至少是肯定需要的。必须有某种形式的基本规范/要求。您可能需要将项目分解为更小的目标并相应地应用成本。

我怀疑的迭代更多与开发方法论有关，即实现目标？

如果没有足够的规范来产生明确的准确成本，我会说应该给出一个“估计”，但应该按小时计费，因为我认为决策会有更大的变化在每次迭代时都在项目上进行。

Answer 4

简短的回答是，你不会。有几家服务公司正在取得进展，但这是一条艰难的道路。您销售方法并说服客户可以交付的能力很高。

客户不希望冒险支付永远不会交付的解决方案。

这个问题的典型做法是把“不会超过”成本。但是，如果您无法控制范围，那么您就是承担所有风险的人。

总之，您正在寻找在敏捷成为最新时尚之前签署了T & M（时间和材料）合同的客户（我是该时尚的一部分，但它只是一个长一系列的发展过程，它的方面将会继续发展，并且它的一些排列在几年内会有不同的名称）。

Answer 5

我见过两个阶段走近时，它工作得很好：

一期）启（timeboxed）

一个timeboxed成立期间与客户范围的项目。 （对于一个估计持续一年的项目，一个月的激烈启动是正确的。） 这一阶段的输出是大小不一的用户故事积压，每个dev对的流量估计，以及基于拥有较大团队的开发人员数量和开销。

初始阶段提供了一个有用的预算估算，可以在整个第2阶段追踪，为客户和供应商提供清晰的共同愿景，以及任何一方都可以走开的选择。这不是前期设计，故事对于领导开发人员/测试人员来说只是分配相对大小的足够细节。

阶段2）交付（时间和材料）

基于时间和材料的输送合同，与概算基于从初始阶段的输出。建立在第一阶段的信任对于开展这项工作至关重要。由于阶段1通过定期测量实际流量来交付整个积压的相对大小，因此可以通过对预算和交付日期的更准确估计，轻松且频繁地报告剩余积压的预计流量。供应商应至少每两周报告一次这些统计数据，客户可随时选择离开。

通过支付时间和材料，客户可以自由改变积压的范围和过程，因此可以控制预算。他们受到保护，首先优先处理他们最高优先级/最高风险的故事，让他们随时随地离开，只要他们喜欢他们应该总是获得正面的投资回报。