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

本文概述

• 介绍
• 传统合同定价和估算
• 软件项目的敏捷合同
• 我们的软件成本和定价方法
• 技术估算
• 一些总结性想法
• 摘要

介绍

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

软件成本估算本质上是困难的, 并且人类在预测绝对结果方面非常糟糕。没有两个项目是相同的。每种方法在实现目标上都是独特的, 并且在构成其存在的众多参数方面也是独特的。通常, 表面上看似简单的问题实际上很难实施或在技术上具有挑战性。而且, 毫无疑问, 项目中将存在”未知”, 只有它们出现时才能被识别。

此外, 无论你是客户, 开发人员还是用户, 两个人都不相同。我们预先充满了自己的一套知识, 经验, 价值观, 期望, 对风险的态度以及适应能力。

对于高级工程师而言, 编写高质量的软件是必不可少的。对于所有相关人员而言, 创建出色的软件产品可能会更加艰巨。

提供出色的软件是一项平衡法

鸣叫

但是在软件方面, 了解持续时间和成本是制定战略业务决策的关键, 无论你是要创建一家初创公司, 实现新的商机还是使你的业务表现更好, 这都是事实。时机, 投资回报率和所提供的收益可以使你的业务成败, 动摇或中断。你会问自己：我们从钱中得到什么？我们可以预测成本吗？创建我们想要的产品将花费什么？我们什么时候可以发射？我们会为投资获得优质的产品吗？它会随着我们的业务发展吗？它会带来商业价值吗？

那么, 你如何估算项目的规模, 持续时间和成本？让我们探讨敏捷项目估算和软件开发成本, 以及我们在srcmini的做法。

传统合同定价和估算

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

1. 你如何知道在项目一开始就确定的功能确实是为你的企业或客户提供最佳服务的功能？功能或范围通常会改变, 这就是为什么我们听到”范围蠕动”的原因, 即在项目的生命周期中确定所需需求的结果, 并将其确定为必要或强制性的

2. 当成本变为可变因素时, 我们将失去对我们寻求实现的投资回报率(ROI)的控制。成本增加通常是不确定的风险或需求变化的产物, 这意味着我们必须增加团队成员才能在同一时间范围内完成更多工作或使团队成员更长的时间。都不可取

3. 当时间可变时, 我们将失去对市场地位的控制。也许我们错过了重要的行业日期, 或者我们的竞争对手将产品推向了我们的面前, 从而失去了我们项目可能拥有的任何竞争优势。

时间和成本的变化还有许多其他结果, 这些结果通常是负面的和不希望的。

当然, 许多客户和组织都希望修复此”魔幻三角”的所有三个组成部分。不幸的是, 要实现这一目标几乎是不可能的。太多的因素共同企图破坏这一理想, 最终导致无法满足需求的产品, 花费太长时间才能使客户受益或花费太多成本来实现业务价值。

软件项目的敏捷合同

成本是时间和人(团队成员)的乘积。增加更多的时间, 并增加雇用员工更长的时间的成本。添加更多的团队成员, 你将增加实现相同业务价值的成本。我们真正想要避免的事情。这就是为什么敏捷原则相信固定时间和团队成员并允许范围成为可变组成部分的原因。

哪个听起来更好, 并提高了利益相关者的信心, 固定成本或可变成本？

当然, 产品兑现其承诺和客户需求非常重要。最终, 如果你拥有没人想要或不能有效使用的产品, 那么花确切的时间和金钱是没有用的。

因此, 敏捷合同专注于以下方面：

• 固定价格的工作包-整个项目分为逻辑的”迷你”发布, 这些发布有助于整个产品的结果。每个版本都是一个工作包, 其价格相应。工作包完成后, 将根据我们从上一个工作包中学到的知识来重新估计将来的工作包。这避免了不必要的意外情况, 并允许客户定义一定程度的重新优先级和新的/修订的功能。

• 提前终止-如果已经交付了足够的产品, 并且保留一支只会继续带来边际收益的项目团队, 那么客户就可以尽早终止项目。只要项目团队和客户保持了牢固, 信任和紧密的合作关系, 通常就可以随时使用此条款, 并且该条款有效。对客户而言, 好处是该项目将尽早完成, 并交付了使该产品可行的所有必要功能。作为回报, 供应商将获得剩余合同价值的20％, 并抵消了留住员工的风险。

• 灵活的变更-变更是贯穿敏捷软件交付脉络的主题。我们希望从一开始就不了解使产品成功所需要的一切。因此, 我们会根据相关数据和反馈来推动变革, 以确保交付正确的产品。在迭代结束时, 可以将更改换成不再被认为是必要或优先级的旧功能。只要更改的价值相等, 就不会产生任何其他成本。如果更改的价值较小, 则可以识别其他工作或从剩余的待办事项中撤出。只要项目团队和客户在整个项目中保持牢固, 信任和紧密的合作关系, 此条款即有效。

• 额外的工作-在项目的整个生命周期中, 可能会发现更多的功能, 而这些功能是现有固定价格合同无法实现的。对于这种情况, 可以将其他新定价的工作包添加到项目的末尾, 也可以还原为时间和材料。

• 范围估计-在敏捷项目合同中可以通过两种方法对估计进行范围调整：持续时间范围或功能范围。持续时间范围可以估算, 对于给定的范围, 项目或工作包将花费12到16周。但是, 增加工期会增加成本, 因为你需要保留项目团队成员更长的时间, 否则就无法释放他们来从事其他开发项目。在srcmini, 我们更喜欢在多个故事点上扩展功能, 将范围保持为变量, 但希望在工作包或整个项目的固定时间内为客户提供最低水平的价值。

值得记住的是, 你以后总是可以添加更多范围。也许你已经开始赚钱, 增加了用户或降低了成本。无论哪种方式, 如果你已经证明了回报或改进并正在实现业务价值, 便可以轻松地要求更多的金钱和时间。

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

在srcmini, 我们与客户和工程师紧密合作, 采用可提高利益相关者对项目工期和成本的信心的技术。在适当和必要的情况下, 我们将不断地制定和调整计划, 从最初的高层到更细致的细节, 以避免浪费并实现可管理的变更。

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

1.最初的高级范围

在项目开始时, 我们对其最终结果知之甚少。幻想可以从一开始就确切了解我们的客户和用户需要什么功能, 这是愚蠢的。

因此, 我们从一个项目章程和一系列高级的”史诗”功能开始, 这些功能基于良好的愿景和目标来指导项目的方向

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

b。高级”史诗”功能无需过多讨论, 你将需要定义产品必须满足客户需求的功能。这是一个结构化的”购物清单”, 描述了你产品的基本内容；通常这些被称为”用户故事”或史诗

C。 MoSCoW分析MoSCoW分析是一种技术, 简单地说, 它有助于确定使产品可行的真正必要条件以及具有的优点。那些被认为是”必须”的产品满足了鼓励用户使用和采用你的产品的要求。那些被标识为”应该”的功能将使你的客户感到惊讶和满意, 但可以在以后构建。 “可能”项目通常不会增加任何可观的业务价值, 可能不会增加回报, 并且是你的最低优先事项。有一天, “不会”功能可能很重要, 但超出了此项目迭代的范围。但是, 现在识别这些可以帮助记住未来产品的潜在规模和尺寸。

2.提案

要决定是否继续进行项目, 必须根据明智的数据(费用和工期)做出决定。这些是你需要问自己的最低要求：创建我们想要的产品需要什么？我们什么时候可以发射？这是否符合我们的业务战略和财务状况？

通过上面的详细信息, 我们可以提供建议。我们的工程师经过精心挑选, 可以满足特定的项目要求, 并与项目经理一起工作, 以得出至少一个技术解决方案, 估计的持续时间(可提供已知范围)和估计的成本来完成项目。

如前所述, 在项目开始时, 我们对交付的内容知之甚少。我们故意将功能和范围保持模糊, 因为否则建议我们确切知道需要什么。此阶段的估算值最不准确, 但会为是否值得进行该项目提供指导。

该提案是详细说明项目期限和成本的第一个工具。提案接受后, 我们可以继续提供固定价格的报价。

3.发布计划

估算的下一个层次是创建一个发布计划, 该计划将在给定的时间范围内提供一系列功能。我们从功能列表, 项目规模, 我们的团队能够多快地开发出满足客户期望的高质量软件以及用于管理不确定性风险的技术中得出这些信息。

一个。产品积压产品积压只是” Epics”或” User Stories”的有序列表, 代表产品所需的功能。该清单从前面讨论的史诗开始, 但在分配的项目团队, 项目经理和客户之间, 我们现在将其分解为更有意义的项目。每个项目代表了客户业务价值的一部分。我们在此阶段不做进一步详细介绍, 我们不需要了解接受标准, 我们不需要知道按钮是蓝色还是绿色, 我们只需要知道有一个按钮可以执行某些任务即可被执行。

b。估计现在, 我们已经将功能列表描述为用户故事, 团队使用称为”规划扑克”的技术来估计这些离散的功能项。这是一项有用的技术, 可根据专家的意见和类似的大小来确保快速, 可靠的结果。规划扑克会为每个项目分配一个商定的编号, 以表示其大小和复杂性。这称为故事点。还可以使用其他敏捷估算技术和规模, 例如”理想日子”。

该过程的结束将确定项目的大小以及要素之间的依赖关系。大小是通过将产品待办事项中各项的所有故事点相加而确定的。如果该数字等于120, 则我们的项目规模为120个故事点。

C。确定优先级现在, 我们有一个待办事项列表和一个项目的规模, 现在我们可以与客户确定优先级了。这实际上是为了确定对客户最有价值的东西, 以达到期望的结果。列表顶部的项目被认为是最重要的, 第二个项目不如第一个重要, 依此类推。没有两个项目可以像另一个项目一样重要, 每个项目的优先级相对于其他每个项目都具有相对重要性或价值。

这种优先级排序方法是规划软件项目的重要里程碑。现在, 我们知道对客户重要的是什么, 以及按照什么顺序完成工作, 照顾依赖关系, 以交付满足期望的产品。

d。发行计划到目前为止, 我们已经确定了我们认为产品的外观和尺寸。

现在, 我们确定交付可发布产品需要多长时间。客户和团队, 包括设计师, 工程师, 测试人员, Scrum管理员和项目经理, 共同确定可以实现的目标以及完成发布计划的工作速度。

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

最后, 该计划可确保项目团队具有引导方式, 并为开发定义合理的终点。

在开始之前, 请确保我们了解商定的”完成”定义。这是给定的一组标准, 客户将接受它们作为完整的标准, 并且满足所有被认为可释放的工程要求。

在基本情况下, 我们将通过确定积压量得到的故事点总数除以团队预期的速度。 (NB速度通常表示为一个范围, 但为简单起见, 我们在这里使用一个数字。)我们进行两周的迭代, 因此我们的速度将反映在可用的情况下, 我们在两周的周期内可以完成多少团队的能力。如果我们的故事积分总计为120, 并且我们希望每次迭代完成20个积分, 那么总开发时间将为12周或6次迭代。我们还添加了2周的冲刺0和2周的发布准备冲刺。我们的项目总工期为16周。我们可以使用一些技术来帮助在我们的计划中建立适当的风险缓冲, 我们将在后面讨论。简而言之, 我们使用缓冲区来管理不确定性的风险, 并就要交付的预期故事点达成最小协议。结果可能会传递90到150个故事点, 其中90个是创建可行产品所需的最低点。

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

当然, 以上所有方面都得到了各方之间的良好沟通和协作的支持, 以得出可实现, 切合实际且客户可以接受的发布计划。

4.固定价格合同

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

固定价格合同的报价以及工作说明和商定的付款时间表一起提供。

只要有信任, 沟通, 合作和愿意融入敏捷软件项目的精神, 上述所有步骤都使我们能够以切实可行的信心提供报价, 以确保项目能够按时, 按时交付。在预算内。当然, 在某些情况下, 某个项目可能会提前或延迟交付, 我们会以最大的透明度来应对这些变化。

技术估算

开发团队可以使用多种技术来支持敏捷计划和估计, 以使他们对其规模, 工作量, 持续时间和成本产生信心。以下是我们的团队用来估算软件项目的规模和成本的一些方法。

估算尺寸

项目的规模实际上是对项目范围, 复杂性, 规模, 风险和规模的赞赏。打个比方, 是要了解我们是要建造埃菲尔铁塔还是中国的长城。埃菲尔铁塔是一个高大, 笨重, 复杂的结构, 建在狭窄的城市环境中。中国的长城是一个相对简单但又长而结实的结构, 横跨起伏不定的地形。

虽然它们都是要交付的大型项目, 但它们的范围, 复杂性, 尺寸, 规模以及大小是不同的。

用估算值管理期望很重要。它们绝不是预测, 承诺或保证。在讨论总规模, 总工期和总成本时, 我们总是在一定范围内工作, 以减轻风险, 不确定性和未知数。

代表产品功能的故事会根据故事点数或理想日子分别进行大小和估算。这些单位的总数定义了项目的总规模。

故事点

故事点是表示用户故事的总体大小的度量单位。估算的故事大小包括设计, 工程, 测试, 代码审查, 集成等所有方面。

一个故事的每个大小都相对于另一个故事。因此, 例如, 故事A的大小为1点, 故事B的大小为2点, 故事C的大小为3点。在这里, 故事C至少是故事A的三倍, 又是故事B的至少一半。

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

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

理想的日子

这是大小的度量单位, 以天为单位。它消除了诸如中断, 敏捷计划活动, 阅读电子邮件和其他非项目活动之类的间接费用的概念。它只着眼于如果你不间断地连续进行工作需要花费多长时间, 而不是从头到尾所花费的时间。

通常, 当我们对某个项目了解最少时进行高水平的评估时, 我们会在理想的日子进行评估, 因为与诸如故事点之类的抽象数字相比, 这是一个更容易与过去的历史和经验相关联的概念。尤其是当高层次的故事本质上是史诗般的内容而几乎没有细节时, 以后再分解时可能还会包含其他元素。

在更精细的层次上进行估算时, 例如在已建立的产品储备中讲故事, 则可以使用这两种方法, 并且由工程团队决定。两种方法都有好处, 每个团队都会有自己的偏好。

估算技术

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

相似估计在这里, 我们考虑两个离散特征, 并确定一个相对较小或较大。我们可以查看一个给定的故事, 并同意它的大小很小, 如果使用故事点, 则可以将其大小设置为两个。与第一个故事相比, 下一个故事可能被认为是很大的, 我们将其设置为五个。这表明大尺寸至少是小特征尺寸的两倍。

我们将继续讲所有故事。完成后, 我们可以并排放置所有小型, 中型, 大型和超大型故事, 并交叉检查我们的大小, 以确保我们的估算具有统一的水平。

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

本质上, 它将专家的意见, 类比和团队协作结合在一起, 成为一个简单, 快速和可靠的过程。

它汇集了最适合根据技术和领域经验, 生动活泼的对话和合理的理由进行估算的专家。

速度

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

它表示为一个范围, 例如, 每个冲刺有23到32个故事点, 尤其是在项目生命周期的早期。通常, 这是因为除非同一个团队之前就相同的问题进行过工作, 否则很难准确描述团队的速度。注意, 我们指的是团队的速度, 而不是个人的速度！

在整个项目进行过程中, 我们使用速度来计划发布并调整计划和工作包, 从而使我们能够通过执行定期, 准确地调整预测以完成工作。

当我们开始时, 我们不得不用很少的数据来定义速度范围。如果团队和问题空间相同(通常可能性最小), 我们可以使用历史值。我们可以进行迭代以使实际在项目上工作的团队了解速度, 但这是昂贵的, 并且如果仍然需要就开始项目达成一致的决定, 那将是行不通的。或者, 我们可以做出预测。

预测速度涉及获取冲刺的故事价值, 并将其分解为完成故事所执行的任务。我们将估计每个任务将花费的小时数, 包括设计, 开发, 测试等, 并评估团队在给定的sprint中将具有多少能力。对于没有支配力的团队, 其70％的能力是一个不错的基准。因此, 在简单的情况下, 如果团队可用的总时间为：

• 4名团队成员* 2周*每周40小时= 320小时
• 乘以我们的70％的容量= 224小时
• 将所有功能任务相加并在224处停止计数
• 掌握所有已完成的功能, 加总他们的故事点, 然后说出速度, 例如36
• 左右各施加20％, 以得到最低和最高的范围, 以达到29到43个故事点的估计速度。

速度通常在前两到四次迭代中变化, 然后稳定在较小的点范围内。因此, 在第一冲刺之前我们的初始范围是29到43, 在第四冲刺之前它的初始范围可能从34稳定到38。这使我们对预测最终完成日期有更大的信心。

风险和不确定性缓冲计划

所有软件项目都带有一定程度的不确定性。随着项目的进行, 不确定性变得越来越小, 而对于我们的技术, 环境, 性能以及客户和用户的需求则更加了解。

我们使用进度表中的缓冲区来减轻这种不确定性或风险, 这可以弥补我们估计中的误差范围以及在开发开始之前无法确定的未知数。

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

这种方法为我们提供了可靠的风险缓解策略, 并且使客户对项目完成后期望得到的结果充满信心。

功能缓冲区

借助功能缓冲区, 我们预计将提供给定的功能集, 但理想情况下将完成更多的功能集。这至少应反映出客户认为发布可行产品所需的最低功能集, 但是如果所有内部和外部因素都允许, 则可以在规定的时间内交付更多功能。

因此, 客户可能认为来自产品待办事项列表的最高优先级功能(总计100个故事点)是最重要的。然后, 他们可能会考虑其他功能, 这些功能总共可以增加30个故事点。因此, 团队将基于交付130个故事点进行计划, 对于给定的固定价格合同, 至少100个故事点将在计划的完成日期之前完成。

一些总结性想法

充分理解和采用敏捷可能是一个非常困难的概念。在管理敏感主题(例如价格, 范围和持续时间)时, 情况同样如此。不幸的是, 我知道第一手要求苛刻的客户希望所有事情都预先解决, 并急于责怪供应商。同样, 我知道供应商会跟进, 变得迟钝, 无法响应客户的需求。采取敏捷之路从根本上建立在信任, 良好的关系和良好的沟通基础上。这些都是双方都必须持有的价值观, 以维护一个健康的项目, 使所有参与者都享有同等的利益, 满意度和成功。对合作和谈判保持开放的态度和建设性的态度是避免关系恶化的最好方法。

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

我们知道, 当采用传统方法采用这种方法时, 范围会发生变化, 未知因素会被发现, 或者我们认为客户想要的不再是真实的或超出预期范围。对价格, 计划和范围采取自适应方法, 可使客户真正确定其产品, 以准确地满足其市场需求。它也使供应商也能够响应, 富有想象力和高效。在合同谈判中利用客户和供应商之间的协作是关键。

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

摘要

我希望这能使你对敏捷软件项目的计划, 估算和定义价格有所了解。上面所有的方法和技术都旨在建立团队信任, 并在客户对构建软件产品所需的时间和数量方面建立信心。并最终建立起继续进行决策的信心。

遵循这些准则, 你一定会找到一条令人满意的途径, 使你的软件产品栩栩如生。