如何在敏捷软件开发项目中收费/预算[关闭]

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

Agile contracts .

另一个伟大的资源是 10 Contracts for your next Agile Software Project 彼得·史蒂文斯著。

Mary Poppendieck也有 伟大的 关于这个主题的材料。看见 agilecontracts agilecontractsworkshop Contracts Excerpt From Lean Software Development , Lean Contracts here .

简而言之,你不会的。有一些服务公司在这方面取得了进展,但这是一条艰难的道路。您销售方法和说服客户您可以交付的能力将很高。

客户不想冒险购买永远无法交付的解决方案。

简言之,您正在寻找那些本应注册T&敏捷成为最新时尚之前的M(时间和材料)合同(我是该时尚的一部分,但它只是一系列开发过程中的一个)。它的各个方面将继续增长,一些排列将在几年内有一个不同的名称)。

如果您的客户已经接受了敏捷方法的使用,那么您就有了一个合理的框架来协商每次迭代的价格。例如,你知道:

2. 有多少人将致力于迭代(以及他们的速率)。
3. 大致的工作范围。
4. 交付和验收的过程。

这是比大多数固定价格合同更多的定价决策依据。

如果敏捷方法纯粹是一个不涉及客户的内部开发过程,那么它不太可能对供应商和客户之间的定价谈判产生多大影响。有一种观点认为,每次迭代至少一次不让客户参与设置范围和期望的过程根本不是敏捷的。

在管理这种类型的合同时,一些行之有效的技术与管理敏捷合同时使用的技术非常相似(频繁交付、范围上的讨价还价、优先级等);价格、坦率的沟通……)主要区别在于,这些都没有纳入原始协议,合同可能不够灵活,无法容纳所有这些内容。

我的2c作为一个非敏捷实践者…在寻求了解更多。。。

如果您正在为客户执行特定项目,则需要了解项目的范围,以提供成本和时间刻度。制作此工作范围的成本通常是项目发现的一部分,您可以点击此项以获得工作,也可以为此收取费用(明示或暗示)。在这种情况下,可以计算并商定项目成本。在这种情况下,项目通常分为不同的阶段。

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

我怀疑迭代更多地与开发方法学有关,即实现目标?

如果没有足够的规范来确定准确的成本,我会说应该给出一个“估计”,但工作应该按小时收费,因为我会假设在每次迭代中,项目决策会有更大的变化。

阶段1)初始阶段(时间框)

与客户一起确定项目范围的时间段(对于一个预计持续一年的项目来说,一个月的紧张启动期差不多是正确的。)

初始阶段提供了一个有用的预算估算,可以在整个第2阶段进行跟踪,为客户和供应商提供了一个清晰的共同愿景,并为任何一方提供了退出的选项。这不是预先设计的,这些故事的细节足以让首席开发人员/测试人员分配相对大小。

阶段2)交付(时间和材料)

通过支付时间和材料,客户可以自由更改积压工作的范围和优先级,因此可以控制预算。他们被鼓励首先优先考虑他们的最高优先级/最高风险故事,并允许他们在任何时候离开,只要他们愿意,他们应该在任何时候都能体验到积极的投资回报。