本文要点
软件项目估算并未消亡实践中, 即便是对于那些已经采用敏捷方法的企业, 估算依然十分有价值
团队总是倾向于对自己的估算过于乐观而在事情发生变化时, 团队无法做出重新估算另一方面, 团队常采用单点估算, 而非范围估算
为使软件估算步入为组织增加价值的正轨上, 利益相关者可使用多种最佳实践这些最佳实践包括采用自顶向下的方法给出估算聚焦于五个核心度量, 以及使用球场方法估算规模
谨记, 估算仅是一种估计团队应该给自身留出一定的灵活空间, 而非拘泥于某一点 R
软件估算不一定是难以实现繁琐或是无效的如果做事方式正确, 估算将成为一种有助于项目经理为组织提供价值的高效工具
当前人们日渐疏远传统的瀑布式开发, 并转型为敏捷开发方法有观点认为, 开发中已不再需要做软件项目估算这个观点看上去合情合理许多敏捷实践者已经采用了小增量和 Sprint 并梳理 Backlog 在他们看来, 软件估算是一个毫无意义的过程
但是, 这一观点并不正确
用 Kafka Streams 搭建实时的广告消费系统 OpenResty 十年开源的历程和思考 阿里巴巴 Blink 流计算平台介绍与实践 Apache Kafka 的过去, 现在, 和未来
在近期的一次采访中, Scrum 的创始人 Ken Schwaber 和 Jeff Sutherland 就 #NoEstimate 运动发表了自己的看法在 Schwaber 看来, 更适用的标签应该是 #NoMeaningfulCommitments 他认为人们总是将估算与承诺混为一谈事实上, 估算是用于作出承诺的 Sutherland 提到了 Rally(即现在的 CA)最近开展的一次调查调查对象包括了 7 万名 Scrum 团队的成员, 调查问题涉及他们所使用的估算技术, 目的是将所使用的估算技术与交付的速度关联起来该调查发现, 那些回避估算的人, 交付时间最慢; 而那些根据项目范围作出估算的人, 交付速度最快
组织不应该放弃软件估算, 而是应聚焦于如何给出更好的估算施行自顶向下宏观层面的估算, 并专注于一些核心指标, 这有助于管理人员更好地控制他们的项目, 并制定出切合实际的开发方案这样所生成的项目, 将符合管理人员的期望, 并可按时按预算交付
在仔细研究一些最佳实践之前, 我们首先应了解为什么团队应继续花费一些精力去完成软件估算事实表明, 有多个原因会导致项目经理在估算过程中遇到困难
他们可能会过于乐观
项目经理和软件开发人员总是倾向于对他们正在开展的项目持乐观态度看上去, 一个自然而然的趋势是高估了自身对首次创建交付和执行项目的能力他们会认为凡事顺利, 一路坦途
不幸的是, 总是不可避免地会突然出现一些障碍物它们会导致项目中断, 产生意料之外的进度变更, 以及其它一些影响项目进展的不可预见情况
进而, 管理人员会犯两个错误
首先, 他们将无法利用类似项目所给出的历史数据, 尤其是在人员方面人员情况可用于准确地估算项目的规模和进度我们的研究表明, 当管理人员仅依靠一些开发方法学, 而非去理解和优化他们的可用资源时, 项目最终会出现人员配备过多预算过度和缺陷显著增加的问题 QSM 公司对敏捷性能的十五年研究一贯表明, 成功开发软件的关键在于良好的规划, 而非开发方法历史数据在有效的规划和评估中发挥着不可或缺的作用这就是为什么我们在不断创建并更新软件项目数据库的原因所在这将为我们的客户提供最高质量的历史信息和趋势, 以便他们在软件开发过程中做出明智的决策, 无论他们使用何种方法
其次, 管理人员倾向于将估算与承诺价值目标或最终成就混为一谈价值目标是人们想要促成的事情相反, 估算是根据对可能发生事情的一种定量分析两者绝对不能混为一谈应该对目标和估算进行独立的评估, 确认它们是否一致这有助于团队保持更现实的乐观情绪在做出成本和时间表承诺之前, 应始终以估算为输入
未能在事情发生变化时给出重新估算
如前所述, 难免会发生一些改变开发工作进程的事情例如, 团队可能会在开发周期中发现需要对项目的范围和要求做出调整这些改变可能会对进度产生影响, 也可能会影响其它一些因素, 诸如项目工作所需的团队成员规模总成本等在此类情况下, 管理人员必须准备给出重新估算, 以更准确地衡量项目的状态
不幸的是, 很多人并不会这样做他们继续遵循原来的估算一旦估算出现了偏差, 例如项目落后于计划或超出了预算等, 他们就会将责任推脱到软件估算过程上但这并非估算过程失败了, 而是由于团队固守了原有的估算
项目经理必须谨记, 估算并非一成不变的当开发过程发生变化时, 他们可以也应该对估算做相应的调整这是敏捷从业者很久以前就接触到的原则, 也正是促使他们改变开发方法的潜在因素
做出的是单点估算而非范围估算
来源: http://www.infoq.com/cn/articles/software-estimation-important