介绍

软件开发中最困难的事情之一是确定交付一个新软件产品需要多长时间和多少时间. 有这么难吗? 答案并不简单.

软件成本估算本身就很困难, 人类在预测绝对结果方面非常糟糕. No two projects are the same; each is unique in what it sets out to achieve and unique in the myriad of parameters that form its existence. 经常, 表面上看起来很简单的问题在现实中实现起来要困难得多，或者在技术上具有挑战性. 和, 毫无疑问, 项目中会有“未知”，只有当它们出现时才能被识别.

此外，没有两个人是相同的，无论你是客户、开发人员还是用户. 我们生来就有自己的一套知识, 经历, 值, 预期, 对风险的态度, 以及适应能力.

Writing good quality software is bread and butter for senior 工程师; creating awesome software products can be a much harder endeavor, 对于所有相关人员.

但是说到软件, 了解持续时间和成本是做出战略性商业决策的关键，无论你是在创业，这都是正确的, 实现新的商业机会, 或者让你的企业表现得更好. 时机、投资回报和收益可以成就、动摇或摧毁你的企业. 你会问自己:我们花的钱换来了什么? 我们能预测成本吗? 创造我们想要的产品需要多少成本? 我们什么时候发射?? 我们的投资会得到高质量的产品吗? 它会随着我们的业务增长吗? 它会带来商业价值吗?

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

传统合同定价与估算

传统上, 使用非敏捷实践, 软件项目试图确定功能或范围，并让时间和成本成为一个变量. 这会导致问题:

1. 您如何知道在项目开始时修复的功能确实是最适合您的业务或客户的功能? 通常, 功能或范围将发生变化, 这就是为什么我们会听到“范围蔓延”这个词,在项目的整个生命周期中确定的预期需求的结果，并确定为必要的或强制性的

2. 当成本成为一个变量时，我们就失去了对我们所追求的投资回报率(ROI)的控制. 增加的成本通常是未识别的风险或不断变化的需求的产物, 这意味着我们必须增加团队成员，以便在相同的时间框架内完成更多的工作，或者保留更长时间的团队成员. 两者都不可取

3. 当时间是一个变量时，我们就失去了对市场地位的控制. 也许我们错过了一个重要的行业日期，或者我们的竞争对手在我们之前推出了产品, 因此，我们的项目可能失去了任何竞争优势.

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

当然, 许多客户和组织试图修复这个“魔三角”的所有三个组成部分。. 不幸的是，这几乎不可能在现实中实现. 有太多的因素共同破坏了这一理想, 这些产品最终无法满足需求, 花费太长时间才能使客户受益，或者花费太大成本才能实现业务价值.

软件项目的敏捷合同

成本是时间和人(团队成员)的乘积. 时间越长，雇佣员工的成本也就越高. 增加更多的团队成员，您就增加了交付相同业务价值的成本. 我们真正想要避免的事情. 这就是为什么敏捷原则相信固定时间和团队成员，并允许范围成为可变组件的原因.

固定成本和可变成本，哪个听起来更好，更能增加利益相关者的信心?

当然，重要的是，一个产品交付它的承诺和客户的需求. 花费确切的时间和金钱是没有用的, 最后, 你有一个产品，没有人想要或可以有效地使用.

因此，敏捷契约关注以下方面:

• 固定价格工作包 -整个项目被分解为逻辑上的“迷你”版本，这些版本有助于完整的产品成果. 每个版本都是一个定价相应的工作包. 当一个工作包完成时, 未来的工作包将基于我们从前一个工作包中学到的东西进行重新评估. 这避免了不必要的偶然性，并允许客户重新确定优先级和定义新的/修订的特性.

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

• 灵活的变化 变化是贯穿敏捷软件交付血脉的主题. 我们不希望从一开始就知道让一款产品成功所需要的一切. So, 我们提倡改变, 根据相关数据和反馈, 确保交付正确的产品. 在迭代结束时, 更改可以替换为不再被认为是必要的或优先级的旧功能. 只要改变的价值相等，就没有进一步的成本. 如果更改值较低, 额外的工作可以从剩余的待办事项中确定或提前完成. 只要项目团队和客户保持了牢固的关系，这一条款就有效, 信任和密切的工作合作关系贯穿整个项目.

• 额外的工作 -贯穿项目的整个生命周期, 可以确定在现有固定价格合同下无法实现的更多特性. 对于这个场景, 可以将附加的新定价的工作包添加到项目的末尾，或者恢复到时间和材料.

• 远程估计 在敏捷项目合同中有两种估算范围:持续时间范围或功能范围. 持续时间的范围允许估计项目或工作包将在给定的范围内花费12到16周. 然而, 增加持续时间会增加成本，因为项目团队成员的工作时间更长, 或者这意味着他们不能被释放去从事其他开发项目. 在Toptal, 我们更喜欢在一系列的故事点上划分特性, 将范围作为变量，但承诺在工作包或整个项目的固定时间框架内向客户交付最低水平的价值.

值得记住的是，以后总是可以添加更多的作用域. 也许你已经开始盈利，你增加了用户或者降低了成本. 无论哪种方式, 如果你已经证明了回报或改进，并且正在交付商业价值，那么要求更多的资金和时间要容易得多.

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

在道达尔，我们与客户和工程师密切合作，采用技术提高利益相关者对项目工期和成本的信心. 当需要避免浪费和启用可管理的变更时，我们会从最初的高层持续地细化和调整计划，直至更细粒度的细节.

在制订估价和固定价格项目时，应采取下列步骤:

1. 初始高级范围

在一个项目开始的时候，我们对它的最终结果知之甚少. 从一开始就知道我们的客户和用户需要什么功能的想法是愚蠢的.

So, 我们从项目章程和指导项目方向的高级“史诗”特性集开始, 基于良好的愿景和目标

a. 愿景和目标设定 我们需要建造什么? 你需要实现什么，你的商业目标是什么? 理解了这些问题，我们就可以确定项目的规模. 你是否需要一个原型来测试最初的想法、概念或技术? 你是否确定了一个明确的主张，并经过了市场的测试，你准备好构建你的第一个最小可行产品了吗?最有价值球员)? 或者，你是在扩展现有的业务或产品，让它更上一层楼吗?

b. 高级“史诗”特性 不用讲太多细节, 您需要定义产品的功能，以满足客户的需求. This is a structured “shopping list” that describes the bare bones of your product; often these are referred to as “用户故事或史诗

c. 莫斯科的分析 莫斯科的分析 是一种技术, 简单地说, 帮助你确定什么是使产品可行的必要条件，什么是值得拥有的. 那些被确定为“必须”的满足将鼓励用户参与和采用你的产品. 那些被确定为“应该”的功能会让你的客户感到惊喜和高兴，但可以稍后再构建. “可能”项通常不会增加显著的业务价值, 可能不会增加回报，是你的最低优先事项. “不会”的特性可能在某一天变得很重要，但是超出了这个项目迭代的范围. 然而, 现在确定这些因素可以帮助你确定未来产品的潜在规模和大小.

2. 建议

决定是否继续进行一项工程, 有必要根据充分了解的数据做出决定:成本和持续时间. 这些是你需要问自己的最低限度:创造我们想要的产品需要什么? 我们什么时候发射?? 这是否符合我们的业务战略和财务状况?

有了以上的细节，我们可以提出一个建议. 我们的工程师是为特定的项目需求精心挑选的，并与项目经理一起工作，以得出至少一个技术解决方案, 交付已知范围的估计持续时间和完成项目的估计成本.

正如我们之前提到的，在项目开始时，我们对将要交付的内容所知最少. 我们故意保持特征和范围模糊, 因为不这样做表明我们确切地知道需要什么. 这个阶段的估计是最不准确的，但它可以指导是否值得继续进行项目.

提案是详细说明项目期限和费用的第一个工具. 一旦建议被接受，我们可以向前移动，以提供一个固定的价格报价.

3. 发布计划

评估细化的下一个层次是创建一个 发布计划 这将在给定的时间框架内提供一系列功能. 我们从一个特征列表中得到它, 项目的规模, 我们的团队能够多快地开发出满足客户期望的高质量软件，以及管理不确定性风险的技术.

a. 产品待办事项列表 的 产品待办事项列表 仅仅是一个有序的“史诗”或“用户故事”列表，代表产品所需的功能. 这个列表开始于前面讨论的史诗, 而是在指定的项目团队之间, 项目经理和客户, 现在我们把这些分解成更有意义的项目. 每个项目都代表了对客户的一部分业务价值. 在这个阶段，我们不讨论更多的细节, 我们不需要知道验收标准, 我们不需要知道按钮是蓝色还是绿色, 我们只需要知道有一个按钮允许执行某些任务.

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

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

c. 优先级 现在我们有了项目的待办事项和规模, 我们能够优先考虑客户的需求. 这实际上是为了实现预期的结果而确定对客户最有价值的东西. 列表顶部的项目被认为是最重要的, 第二项没有第一项重要, 以此类推. 没有两件事可以像另一件一样重要, 每个项目的优先级是相对于其他项目的重要性或价值.

这种划分优先级的方法是规划软件项目的一个重要里程碑. 我们现在知道对客户来说什么是重要的，以什么顺序完成工作, 照顾好依赖关系, 交付符合期望的产品.

d. 发布计划 到目前为止，我们已经确定了我们对产品的定位以及它的规模.

现在，我们决定交付一个可发布产品需要多长时间. 客户和团队, 包括设计师, 工程师, 测试人员, Scrum管理员和项目经理, 共同确定可以实现的目标，以及创建发布计划的Velocity.

发布计划还提供了关于项目将如何与客户的战略计划保持一致的见解.

最后, 该计划确保项目团队有一盏指引方向的明灯，并为开发定义一个逻辑端点.

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

举一个基本的例子, 我们从确定待办事项的规模中获得故事点的总数，并将其除以团队的预期 Velocity. (NBVelocity通常表示为一个范围，但为了简单起见，我们在这里使用一个数字.)我们在两周的迭代中工作，所以我们的Velocity将通过我们在两周的周期内用团队的可用能力完成多少来反映. 如果我们的故事点总计为120点，我们预计每次迭代完成20点, 整个开发周期将是12周或6次迭代. 我们加上一个2周的冲刺和一个2周的发布准备冲刺. 总的来说，我们的项目长度是16周. 我们可以使用一些技术来帮助我们在计划中建立适当的风险缓冲, 我们稍后再讨论. 总之, 我们使用缓冲来管理不确定的风险，并就交付的预期故事点达成最低限度的协议. 结果可能是交付了90到150个故事点, 90是创造可行产品的最低可接受值.

另外, 如果项目必须在规定日期内完成, 比如10周后, 团队将决定在这段时间内可以完成多少积压工作. 如果我们预计每个sprint有20个故事点, 加上Sprint 0和一个发布Sprint, 我们的目标是在项目结束时完成60个点. 再一次。, 我们希望通过增加适当的缓冲来管理风险, 哪一个可能导致45到75个故事点完成并准备发布的目标. 45个故事点将与交付可行且有价值的产品的最小可接受值保持一致. 在这种情况下，您可能希望添加一个团队成员来提高Velocity, 如果合适的话.

当然, 所有这些都是由各方之间高质量的沟通和协作来支持的，以得出一个可实现的发布计划, 切合实际并为客户所接受.

4. 固定价格合同

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

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

只要有信任, 沟通, 协作和准备进入敏捷软件项目的精神, 以上所有步骤使我们能够以现实的信心提供报价，项目将按时按预算交付. 当然, 有时项目会提前或延迟交付，我们会以最大的透明度处理这些变化.

评估技术

敏捷计划和评估由许多技术支持，开发团队可以使用这些技术来获得对其规模的信心, 努力, 持续时间, 和成本. 下面是我们团队用来估算软件项目规模和成本的一些方法.

估算的尺寸

项目的规模实际上是对其范围的一种评价, 复杂性, 维, 风险, 和大小. 打个比方, 这是关于理解我们是在建造埃菲尔铁塔还是中国的长城. 埃菲尔铁塔是一座高大、沉重、复杂的建筑，建于拥挤的城市环境中. 中国的长城是比较简单的, 而是长而坚固的结构，横跨数英里的起伏地形.

虽然它们都是要交付的大项目, 他们的范围, 复杂性, 维, 震级和大小是不同的.

用估计来管理期望是很重要的. 它们从来不是预测、承诺或保证. 当讨论总尺寸时, 总持续时间, 总成本, 我们总是在一定范围内工作, 从而降低风险, 不确定性, 和未知.

代表产品特征的故事是单独大小的，并使用故事点或理想天数进行估计. 这些单元的总数决定了项目的总规模.

故事点

故事点是表示用户故事总体大小的度量单位. 一个故事的大小, 当估计, 包括设计的各个方面, 工程, 测试, 代码评审, 集成, 等.

每一个故事的大小都是相对于另一个故事的. 例如，故事A可能是1分，故事B是2分，故事C是3分. 在这里，故事C至少是故事A的三倍大，至少是故事B的一半大.

如果我们的产品待办事项列表中的以下故事具有相关的大小:

项目的总规模是12个故事点.

理想的天

这是一种以天为单位的尺寸度量. 它消除了诸如中断之类的开销概念, 敏捷计划活动, 阅读邮件和其他非项目活动. 它只关注如果你连续不间断地做某件事需要多长时间, 而不是从开始到结束所经过的时间.

通常, 当我们对项目了解最少的时候，在高层次上进行评估, 我们会在理想的日子里进行估计，因为这是一个更容易与过去的历史和经验联系起来的概念，而不是一个抽象的数字，如故事点. 特别是当高水平的故事本质上更像是史诗，很少有细节，并且在以后的日期中可能包含额外的元素时.

在更细粒度的级别上进行评估时, 说一个既定产品待办事项列表中的故事, 任何一种方法都可以使用，并将由工程团队决定. 这两种方法都有好处，每个团队都有自己的偏好.

估算技术

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

类似的估计 这是我们考虑两个离散特征并决定其中一个相对较小或较大的地方. 我们可以看到一个给定的故事，并同意它的规模很小, 如果使用故事点，我们可能会给它一个2的大小. 下一个故事可能被认为比第一个故事更大, 我们会给它一个5的大小. 这表明大特征至少是小特征的两倍大小.

我们会用所有的故事继续这个练习. 一旦完成, 然后我们可以把所有的小的, 媒介, 大型和超大的故事并排并交叉检查我们的大小，以确保在我们的估计中有一致的水平.

规划扑克 Much has been written about 规划扑克; I also mentioned it in my previous 博客. 理解它最好的资源之一是 在这里.

在本质上, 它结合了专家意见, 类比, 与团队合作一举两得, 快速可靠的过程.

它汇集了最适合基于技术和领域经验构建评估的多个专家, 生动的对话和合理的辩护.

Velocity

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

它被表示为一个范围, 例如, 每个sprint有23到32个故事点, 尤其是在项目的早期阶段. 一般, 这是因为，除非同一个团队以前解决过同样的问题, 很难准确地描述团队的Velocity. 注意，我们指的是团队的Velocity，而不是个人的Velocity!

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

当我们开始的时候，我们被迫用很少的数据来定义一个Velocity范围. 如果团队和问题空间相同，我们可以使用历史值，这通常是最不可能的. 我们可以运行一次迭代，从实际从事项目的团队中获得Velocity的概念, 但这是昂贵的，如果还没有决定是否开始一个项目，这是行不通的. 或者，我们可以做一个预报.

预测Velocity涉及到将一个sprint的故事分成任务，并执行这些任务来完成这个故事. 我们将估算每项任务将花费的小时数, 包括设计, 发展, 测试, 等等......, 并评估团队在给定的冲刺中有多少能力. 对于一个不受阻碍的团队来说，70%的容量是一个很好的基线. 所以，在一个简单的情况下，如果团队可用的总时间是:

• 4名组员* 2周*每周40小时= 320小时
• 乘以70%的容量等于224小时
• 把所有功能任务加起来，数到224就停止了
• 把所有已完成的功能，加上它们的故事点，你就得到了Velocity，比如36
• 两边各加20%，得到最低值和最高值的范围, 达到29到43个故事点的估计Velocity.

Velocity通常在最初的两到四次迭代中变化，然后在一个小范围内稳定下来. So, 冲刺前的初始范围是29到43, 冲刺四, 可能会稳定在34到38之间. 这让我们在预测最终完成日期时更有信心.

风险缓冲计划 & 不确定性

所有的软件项目都带有一定程度的不确定性. 随着项目的进展，我们对技术的了解越来越多，这种不确定性就会减少, 环境, 性能与客户和用户的需求.

我们通过计划中的缓冲来减轻这种不确定性或风险, 在开发开始之前，我们无法确定的估算误差和未知因素是什么.

通常，有两种缓冲区类型:Feature和Schedule. 因为我们经常在固定的交货日期确定固定的价格, 最好使用Feature缓冲区.

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

缓冲特性

有一个特征缓冲区, 我们预测，我们将交付一组给定的功能，但理想情况下将完成另一组功能. 这应该至少反映客户认为发布可行产品所必需的最小功能集, 但是，如果各种内部和外部影响允许，在时间框架内可能会交付更多.

So, 客户可以从产品待办事项列表中决定优先级最高的特性, 加起来有100个故事点, 是最重要的. 然后，他们可能会考虑额外的功能，这些功能加起来又增加了30个故事点. 这个团队, 因此, 计划是否基于交付130个故事点, 在给定固定价格合同的预定完工日期结束前，至少完成100个.

一些结束语

敏捷是一个很难完全掌握和采用的概念. 在管理价格、范围和持续时间等敏感话题时也是如此. 不幸的是, 我亲身体会到，要求苛刻的客户希望所有的事情都能提前解决，当一切开始破裂时，他们急于责怪供应商. 同样, 我知道有些供应商很固执, 变得反应迟钝，无法对客户需求做出回应. 采用敏捷的道路从根本上是建立在信任、良好的关系和良好的沟通之上的. 这些必须是双方共同持有的价值观，以保持一个健康的项目，以获得平等的利益, 满意度, 以及所有相关人员的成功. 对合作和谈判保持开放的心态和建设性的态度是避免关系恶化的最好方法.

我曾与一些客户合作，他们发现很难接受敏捷的自适应特性，也很难放弃命令和控制的态度. 很难放手，把你所有的信心和信任都放在一个你不了解的团队里. 经常, 客户可能希望预先创建所有需求，作为将要交付的内容的规范. 这给他们一种自信的感觉，即项目的范围是明确定义的. 但最终，这并没有成为一个成功的方法. 如果我们被合同的范围和不切实际的要求所束缚，问题很快就会出现.

我们知道, 在传统方法中采用这种方法时, 范围在变化, 未知的东西被发现了，或者我们认为客户想要的东西不再是真实的，或者偏离了目标. 采用适应性定价方法, 规划, 范围允许客户真正识别他们的产品，以满足他们的市场需求. 它使供应商反应迅速，富有想象力和效率. 在合同谈判中利用客户和供应商之间的协作是关键.

供应商需要诚实，客户需要从一开始就对可以实现的目标保持现实. 一个承诺不切实际的目标，然后增加成本的供应商可能会赢得最初的合同, 但很快就会失去一位心怀不满的顾客的青睐. 很多时候，关系破裂是由于双方之间缺乏信任或信心. 信任必须从一开始就建立起来，并在项目的整个过程中保持. 供应商必须灵活并配合不断变化的需求. Customers always want more; it’s a natural consequence of doing business. 双方必须进行平等、有益的价值交换. 对于客户来说，他们希望为自己的企业创造价值. 为供应商, 他们应该寻求通过与客户建立长期的关系来创造价值. 遵守敏捷宣言的价值观和指导原则是形成强大的基础, 平衡和长久的关系.

Summary

我希望这能给你一些关于计划，估计和定义价格的见解 敏捷 软件项目. 上面所有的方法和技术都是为了在团队中建立信任，并在客户心中建立信心，让他们知道构建软件产品需要多长时间和多少时间. 最终，在做出决定时建立信心.

遵循这些指导方针，您将确保找到一条令人满意的路线来实现您的软件产品.