敏捷项目管理中的软件成本估算

介绍

软件开发中最难做的事情之一是确定交付新软件产品需要多长时间和多少。 应该这么难吗？ 答案并不简单。

软件成本估算本质上是困难的，人类在预测绝对结果方面非常糟糕。 没有两个项目是相同的； 每一个在它所要实现的目标上都是独一无二的，在形成其存在的无数参数中也是独一无二的。 通常，表面上看起来很简单的问题在现实中实施起来要困难得多或在技术上具有挑战性。 而且，毫无疑问，该项目将存在“未知数”，只有在它们出现时才能确定。

此外，没有两个人是相同的，无论您是客户、开发人员还是用户。 我们预装了自己的一套知识、经验、价值观、期望、对风险的态度和适应能力。

编写高质量的软件是高级工程师的生计； 对于所有相关人员来说，创建出色的软件产品可能是一项艰巨的工作。

但在软件方面，了解持续时间和成本是制定战略业务决策的关键，无论您是创建一家初创公司、实现新的业务机会，还是让您的业务表现更好，这都是正确的。 时机、投资回报和交付的收益可能会成就、动摇或破坏您的业务。 你会问自己：我们的钱能得到什么？ 我们可以预测我们的成本吗？ 创造我们想要的产品需要多少成本？ 我们什么时候可以启动？ 我们的投资能否获得优质产品？ 它会随着我们的业务增长吗？ 它会带来商业价值吗？

那么，您如何估算项目的规模、持续时间和成本呢？ 让我们探讨一下敏捷项目估算和软件开发成本，以及我们在 Toptal 是如何做到的。

传统合同定价和估算

传统上，使用非敏捷实践，软件项目试图修复功能或范围，并让时间和成本成为变量。 这会导致问题：

1. 你怎么知道你在项目开始时修复的功能真的是最适合你的业务或客户的功能？ 通常情况下，功能或范围会发生变化，这就是为什么我们会听到“范围蔓延”，即通过项目生命周期确定所需需求的结果，并确定为必要或强制

2. 当成本成为一个变量时，我们就会失去对我们正在寻求实现的投资回报 (ROI) 的控制。 成本增加通常是未知风险或需求变化的产物，这意味着我们必须增加团队成员才能在同一时间框架内完成更多工作或让团队成员保持更长时间。 两者都不可取

3. 当时间是一个变量时，我们就会失去对市场头寸的控制。 也许我们错过了一个重要的行业日期，或者我们的竞争对手在我们之前推出了他们的产品，从而失去了我们项目可能拥有的任何竞争优势。

还有许多其他时间和成本可变的结果，这些结果通常是负面的和不可取的。

当然，许多客户和组织都试图修复这个“魔力三角”的所有三个组成部分。 不幸的是，它几乎不可能真正实现。 有太多因素共同破坏了这一理想，最终导致产品无法满足需求，需要太长时间才能使客户受益或成本太高才能实现商业价值。

软件项目的敏捷合同

成本是时间和人员（团队成员）的产物。 增加更多的时间，就会增加雇用人员更长时间的成本。 添加更多团队成员，您会增加交付相同业务价值的成本。 我们真正想要避免的事情。 这就是为什么敏捷原则相信固定时间和团队成员并允许范围成为可变组件的原因。

哪个听起来更好，并增加了利益相关者的信心，固定成本还是可变成本？

当然，产品兑现其承诺和客户需求是很重要的。 如果最终您拥有一个没人想要或无法有效使用的产品，那么花费确切数量的时间和确切数量的金钱是没有好处的。

所以敏捷合约关注以下内容：

• 固定价格工作包- 整个项目被分解为有助于完整产品成果的合乎逻辑的“迷你”版本。 每个版本都是一个相应定价的工作包。 随着工作包的完成，未来的工作包将根据我们从前一个工作包中学到的知识重新估算。 这避免了不必要的意外事件，并允许客户定义一定程度的重新优先级和新/修订的功能。

• 提前终止——如果已经交付了足够多的产品，并且通过保留一个只会继续提供边际收益的项目团队来实现进一步的投资回报率，客户可以寻求提前终止项目。 该条款通常在任何时候都可以使用，只要项目团队和客户保持牢固、信任和密切的工作协作关系，该条款就有效。 对客户的好处是项目将提前完成，并交付了使产品可行所需的所有有价值的功能。 作为回报，供应商将获得剩余合同价值的 20%，并抵消留住员工的风险。

• 灵活的变化——变化是贯穿敏捷软件交付脉络的一个主题。 我们不希望从一开始就知道使产品成功所需的一切。 因此，我们根据相关数据和反馈推动变革，以确保交付正确的产品。 在迭代结束时，可以将更改替换为不再被认为必要或优先的旧功能。 只要变化的价值相等，就没有进一步的成本。 如果更改的价值较低，则可以从剩余的积压中识别或提取额外的工作。 只要项目团队和客户在整个项目过程中保持强大、信任和密切的工作协作关系，本条款就有效。

• 额外工作——在项目的整个生命周期中，可能会发现更多在现有固定价格合同下无法实现的功能。 对于这种情况，可以将额外的新定价工作包添加到项目的末尾或恢复到时间和材料。

• 范围估算——在敏捷项目合同中有两种估算范围的方法：持续时间范围或功能范围。 一个持续时间范围允许估计说项目或工作包对于给定的范围将需要 12 到 16 周。 但是，增加持续时间会增加成本，因为您可以让项目团队成员保留更长时间，或者这意味着他们不能被释放以从事其他开发项目。 在 Toptal，我们更喜欢在一系列故事点中划分功能，将范围保持为变量，但承诺在工作包或整个项目的固定时间范围内为客户提供最低水平的价值。

值得记住的是，您以后总是可以添加更多范围。 也许您已经开始赚取收入，您增加了用户或降低了成本。 无论哪种方式，如果您已经证明了回报或改进并且正在提供商业价值，那么要求更多的金钱和时间会容易得多。

我们的软件成本和定价方法

在 Toptal，我们与客户和工程师密切合作，采用能够提高利益相关者对项目持续时间和成本的信心的技术。 我们致力于在适当和必要的情况下，从最初的高层次不断细化和调整计划，从而避免浪费并实现可管理的变更。

在制定估算和固定价格项目时采取以下步骤：

1. 初始高层范围

在项目开始时，我们对其最终结果知之甚少。 想象从一开始就可以准确地知道我们的客户和用户需要哪些功能是愚蠢的。

因此，我们从一个项目章程和一套高水平的“史诗”特性开始，这些特性基于一个合理的愿景和目标来指导项目的方向

一种。 愿景和目标设定我们需要构建什么？ 您需要实现什么以及您的业务目标是什么？ 了解这些问题使我们能够设定项目的规模。 您是否需要原型来测试最初的想法、概念或技术？ 您是否已经确定了一个经过市场测试的明确主张，并且准备好构建您的第一个最小可行产品 (MVP)？ 或者，您是否正在扩展您现有的业务或产品以将其提升到一个新的水平？

湾。 高级“史诗”功能无需过多详细说明，您需要定义产品必须满足客户需求的功能。 这是一个结构化的“购物清单”，描述了您产品的基本要素； 通常这些被称为“用户故事”或史诗

C。 MoSCoW 分析MoSCoW 分析是一种技术，简而言之，它有助于确定使产品可行的真正必要条件以及拥有什么是好的。 那些被确定为“必须”的内容满足了鼓励用户参与和采用您的产品的内容。 那些被确定为“应该”的功能会让您的客户感到惊讶和高兴，但可以在以后构建。 “可能”项目通常不会增加显着的商业价值，可能不会增加回报，并且是您的最低优先级。 “不会”的特性有朝一日可能很重要，但超出了本次项目迭代的范围。 但是，现在确定这些有助于牢记未来产品的潜在规模和规模。

2. 提案

要决定是否继续进行项目，有必要根据充分知情的数据做出决定：成本和持续时间。 这些是您需要问自己的最低要求：创建我们想要的产品需要什么？ 我们什么时候可以启动？ 这是否符合我们的业务战略和财务状况？

有了上面的细节，我们可以提供一个建议。 我们的工程师根据具体的项目要求精心挑选，并与项目经理一起制定至少一种技术解决方案、提供已知范围的估计持续时间和完成项目的估计成本。

正如我们之前提到的，在项目开始时，我们对交付的内容知之甚少。 我们故意使功能和范围模糊不清，因为否则表明我们确切地知道需要什么。 此阶段的估计将是最不准确的，但可以指导是否值得继续该项目。

该提案是详细说明项目持续时间和成本的第一个工具。 一旦提案被接受，我们就可以继续提供固定价格的报价。

3. 发布计划

下一个级别的估算细化是创建一个发布计划，该计划将在给定的时间范围内提供一系列功能。 我们从功能列表、项目规模、我们的团队开发满足客户期望的高质量软件的速度以及管理不确定性风险的技术中得出这一点。

一种。 产品待办事项产品待办事项只是“史诗”或“用户故事”的有序列表，代表产品所需的功能。 这个列表开始于之前讨论的史诗，但是在分配的项目团队、项目经理和客户之间，我们现在将它们分解成更有意义的项目。 每个项目都代表客户的商业价值的一部分。 在这个阶段我们不做更多的细节，我们不需要知道验收标准，我们不需要知道按钮是蓝色还是绿色，我们只需要知道有一个按钮可以完成一些任务要执行。

湾。 估计现在我们已经将特征列表描述为用户故事，该团队使用一种称为“规划扑克”的技术来估计这些离散的特征项。 这是一种有用的技术，可确保基于专家意见和类似尺寸的快速、可靠的结果。 Planning Poker 为每个项目分配一个约定的数字，代表其大小和复杂性。 这称为故事点。 其他敏捷估计技术和规模，例如“理想天数”，也是可用的。

这个过程的结束将决定项目的大小和特性之间的依赖关系。 大小是通过将产品积压中的项目中的所有故事点相加来确定的。 如果这个数字等于 120，那么我们项目的规模就是 120 个故事点。

C。 优先级既然我们有项目的积压和规模，我们就可以与客户一起确定优先级。 这实际上是关于确定什么对客户最有价值，以实现预期的结果。 列表顶部的项目被认为是最重要的，第二个项目不如第一个项目重要，依此类推。 没有两个项目可以像另一个一样重要，每个项目的优先级对于其他每个项目都具有相对重要性或价值。

这种确定优先级的方法是规划软件项目的一个重要里程碑。 我们现在知道什么对客户很重要，以及以何种顺序完成工作、处理依赖关系、交付满足期望的产品。

d。 发布计划迄今为止，我们已经确定了我们认为的产品是什么以及它有多大。

现在，我们确定交付可发布产品需要多长时间。 客户和团队，包括设计师、工程师、测试人员、scrum master 和项目经理，共同确定可以实现什么以及可以多快完成工作以创建发布计划。

发布计划还可以深入了解项目将如何与客户的战略计划保持一致。

最后，该计划确保项目团队拥有指引方向的指路明灯，并定义了开发的逻辑终点。

在开始之前，我们确保我们理解“完成”的商定定义。 这是一组给定的标准，客户将接受它作为完整的标准，并且还满足所有被视为可发布的工程要求。

以一个基本的场景为例，我们将我们从积压工作中获得的故事点总数除以我们团队的预期速度。 （NB 速度通常表示为一个范围，但为简单起见，我们将在此处使用单个数字。）我们在两周的迭代中工作，因此我们的速度将反映在我们可以在两周周期内完成多少可用可用的团队的能力。 如果我们的故事点总数为 120，并且我们预计每次迭代完成 20 个点，那么总开发持续时间将是 12 周或 6 次迭代。 我们添加了一个为期 2 周的 sprint 0 和一个为期两周的发布准备 sprint。 总的来说，我们的项目长度为 16 周。 我们可以使用一些技术来帮助在我们的计划中建立适当的风险缓冲，我们将在稍后讨论。 但简而言之，我们使用缓冲来管理不确定性的风险，并就要交付的预期故事点达成最低限度的协议。 结果可能是交付了 90 到 150 个故事点，其中 90 个是创建可行产品可接受的最小值。

或者，如果项目必须在给定日期前完成，比如 10 周，团队将确定在该时间内可以完成多少积压工作。 如果我们预计每个 sprint 有 20 个故事点，加上 Sprint 0 和发布 sprint，我们的目标是在项目结束时完成 60 个点。 同样，我们希望通过添加适当的缓冲区来管理风险，这可能会导致完成并准备发布 45 到 75 个故事点的目标。 45 个故事点将与交付可行且有价值的产品可接受的最低要求一致。 在这种情况下，您可能希望在适当的情况下添加团队成员以提高速度。

当然，以上所有这些都得到了各方之间良好沟通和协作的支持，以得出一个可实现的、现实的和客户可接受的发布计划。

4. 固定价格合约

一旦就发布计划达成一致，我们就可以为固定价格项目合同创建报价。 如前所述，建议保持项目持续时间和团队固定以及范围可变。

固定价格合同的报价与工作说明和商定的付款时间表一起交付。

只要有信任、沟通、协作并愿意进入敏捷软件项目的精神，上述所有步骤都使我们能够以现实程度的信心交付报价，即项目将按时交付并在预算上。 当然，有时项目会提前或延迟交付，我们会以最大的透明度处理这些变化。

估计技术

敏捷规划和估算得到了许多技术的支持，开发团队可以使用这些技术来获得对其规模、工作量、持续时间和成本的信心。 以下是我们的团队用来估算软件项目规模和成本的一些指标。

估计大小

项目的规模实际上是对其范围、复杂性、维度、风险和规模的评估。 打个比方，这是关于理解我们是在建造埃菲尔铁塔还是中国的长城。 埃菲尔铁塔是一座高大、沉重、复杂的建筑，建在紧凑的城市环境中。 中国的长城是一个相对简单但又长又坚固的结构，跨越数英里的起伏地形。

虽然它们都是要交付的大项目，但它们的范围、复杂性、规模、规模和规模都不同。

用估计来管理期望很重要。 它们绝不是预测、承诺或保证。 在讨论总规模、总持续时间和总成本时，我们总是在范围内工作，以降低风险、不确定性和未知数。

代表您的产品功能的故事是使用故事点或理想天数单独调整和估计的。 这些单元的总数定义了项目的总规模。

故事点

故事点是表示用户故事整体大小的度量单位。 一个故事的大小，在估计时，包括设计、工程、测试、代码审查、集成等的所有方面。

每个故事的大小都与另一个故事相关。 例如，故事 A 的大小可能为一个点，故事 B 的大小为两个点，故事 C 的大小为三个点。 在这里，故事 C 的大小至少是故事 A 的三倍，至少是故事 B 的一半。

如果我们产品 backlog 中的以下故事具有相关的大小：

该项目的总规模为 12 个故事点。

理想的日子

这是以天为单位的大小度量。 它消除了诸如中断、敏捷计划活动、阅读电子邮件和其他非项目活动等开销的概念。 它只关注如果你要不间断地连续工作需要多长时间，而不是从开始到结束所经过的时间。

通常，在我们对项目了解最少的情况下进行高水平估计时，我们会在理想情况下进行估计，因为与故事点等抽象数字相比，这是一个更容易与过去历史和经验相关联的概念。 尤其是当高层次的故事本质上是史诗般的故事时，细节很少，并且在以后分解时可能包含其他元素。

当在更细粒度的级别进行估算时，比如在已建立的产品待办列表中的一个故事，可以使用任何一种方法，并由工程团队决定。 这两种方法都有好处，每个团队都有自己的偏好。

估算技术

共享估算估算不是孤立进行的。 它们由整个工程团队协同执行，包括设计、数据库、服务器、前端 UI、QA 和其他跨职能专家。 这避免了没有考虑完成功能所涉及工作的所有方面的问题，并确保没有人有高估或低估功能大小的负担或不幸。 合并后的团队都会有一个可以讨论和达成一致的观点。

类比估计这是我们考虑两个离散特征并决定一个相对小于或大于另一个的地方。 我们可以查看给定的故事并同意它的大小很小，如果使用故事点，我们可能会给它的大小为 2。 与第一个故事相比，下一个故事可能会被认为是大的，我们会给它一个大小为 5。 这表明大特征的大小至少是小特征的两倍。

我们将用所有的故事继续这个练习。 完成后，我们可以并排放置所有小型、中型、大型和超大型楼层，并交叉检查我们的尺寸，以确保我们的估算具有一定程度的一致性。

规划扑克关于规划扑克的文章很多。 我在之前的博客中也提到过。 了解它的最佳资源之一就在这里。

本质上，它将专家意见、类比和团队协作结合到一个简单、快速和可靠的过程中。

它汇集了多位专家，他们最适合根据技术和领域经验、生动的对话和合理的理由进行评估。

速度

速度是衡量团队在给定迭代（或冲刺）中完成工作的能力。

它表示为一个范围，例如，每个 sprint 23 到 32 个故事点，尤其是在项目生命的早期。 一般来说，这是因为除非同一个团队以前曾处理过同一个问题，否则很难准确描述团队的速度。 请注意，我们指的是团队的速度，而不是个人的速度！

我们使用速度来计划我们的发布，并随着项目的进展调整我们的计划和工作包，从而使我们能够通过执行定期准确地调整我们的完成预测。

当我们开始时，我们被迫用很少的数据定义一个速度范围。 如果团队和问题空间相同，我们可以使用历史值，这通常是最不可能的。 我们可以运行一次迭代，从实际从事项目的团队那里了解速度，但这很昂贵，而且如果仍然要就同意启动一个项目做出决定，那么这是行不通的。 或者，我们可以做出预测。

预测速度涉及获取一个 sprint 的故事，并将它们拆分为完成故事所执行的任务。 我们将估计每项任务将花费的小时数，包括设计、开发、测试等，并评估团队在给定冲刺中的能力。 对于一个不受阻碍的团队来说，70% 的容量是一个很好的基线。 因此，在一个简单的情况下，如果团队可用的总小时数是：

• 4 名团队成员 * 两周 * 每周 40 小时 = 320 小时
• 乘以我们 70% 的容量 = 224 小时
• 将所有特征任务加起来，在 224 处停止计数
• 获取所有已完成的功能，将它们的故事点相加，您就可以得到速度，比如 36
• 在任一侧应用 20% 以获得最低和最高范围，以达到 29 到 43 个故事点的估计速度。

速度通常在前两到四次迭代中变化，然后在小范围的点内稳定。 因此，我们在 sprint 1 之前的初始范围是 29 到 43，到 sprint 4，它可能会从 34 到 38 稳定下来。这让我们对预测最终完成日期更有信心。

风险和不确定性的缓冲计划

所有软件项目都带有一定程度的不确定性。 随着我们在项目中的进展，这种不确定性变得越来越少，并且对我们的技术、环境、性能以及客户和用户的需求的了解越来越多。

我们在进度表中设置缓冲来减轻这种不确定性或风险，这说明了我们估计的误差范围以及我们在开发开始之前无法确定的未知数。

通常，有两种缓冲区类型：Feature 和 Schedule。 由于我们经常为固定交货日期定义固定价格，因此最好使用功能缓冲区。

这种方法为我们提供了可靠的风险缓解策略，并让客户对项目完成后他们应该期望看到的结果充满信心。

特征缓冲区

使用特征缓冲区，我们预测我们将提供一组给定的特征，但理想情况下会完成另一组特征。 这应至少反映客户认为推出可行产品所需的最低功能集，但如果所有各种内部和外部影响都允许，则可以在时间框架内交付更多功能集。

因此，客户可能会认为产品待办列表中优先级最高的功能（总计 100 个故事点）是最重要的。 然后，他们可能会考虑额外增加 30 个故事点的功能。 因此，团队将根据交付 130 个故事点进行计划，在给定的固定价格合同的预定完成日期结束前，至少完成 100 个故事点。

一些结束的想法

敏捷可能是一个很难完全掌握和采用的概念。 在管理价格、范围和持续时间等敏感主题时，情况同样如此。 不幸的是，我直接知道要求苛刻的客户希望所有事情都预先解决，并且当一切开始瓦解时急于责备供应商。 同样，我知道一些供应商深陷其中，反应迟钝，无法响应客户需求。 走敏捷之路从根本上建立在信任、良好的关系和一流的沟通之上。 这些必须是双方都持有的价值观，以便维护一个健康的项目，让所有相关人员获得平等的利益、满意和成功。 对合作和谈判保持开放的心态和建设性的态度是避免关系恶化的最佳方式。

我曾与那些发现很难接受敏捷的适应性并放弃命令和控制态度的客户一起工作。 很难放手将所有的信念和信任放在一个你不认识的团队中。 通常，客户可能希望预先创建所有需求，作为交付内容的规范。 这让他们有一种信心，认为项目的范围是明确定义的。 但最终，这未能成为一种成功的方法。 如果我们局限于合同中的范围和不切实际的要求，问题就会很快出现。

我们知道，当在传统方法中采用这种方法时，范围会发生变化，未知数会被发现，或者我们认为客户想要的不再是真实的或偏离标准的。 对定价、计划和范围采取适应性方法使客户能够真正确定他们的产品正是他们的市场需求。 它也使供应商能够响应迅速、富有想象力和高效。 在合同谈判中利用客户和供应商之间的协作是关键。

供应商需要诚实，客户需要从一开始就对可以实现的目标持现实态度。 承诺不切实际的目标然后增加成本的供应商可能会赢得最初的合同，但很快就会失去心怀不满的客户的青睐。 很多时候，由于各方之间缺乏信任或信心，关系破裂。 信任必须从一开始就建立并在整个项目过程中保持。 供应商必须灵活并配合不断变化的需求。 客户总是想要更多； 这是做生意的自然结果。 双方之间必须进行平等和有益的价值交换。 对于客户来说，他们希望为他们的业务创造价值。 对于供应商而言，他们应该寻求通过与客户建立长期关系来创造价值。 遵守敏捷宣言的价值观和指导原则是建立牢固、平衡和长期关系的良好基础。

概括

我希望这能让您对敏捷软件项目的规划、估计和定义价格有所了解。 上述所有方法和技术旨在建立对团队的信任，并建立客户对构建软件产品需要多长时间和多少成本的信心。 最终，要建立对继续进行的决定的信心。

遵循这些指导方针，您一定会找到一条令人满意的途径，让您的软件产品栩栩如生。