共计 3187 个字符，预计需要花费 8 分钟才能阅读完成。
“如果一个程序员通知你他曾经实现了 90% 的工作量，那么他还须要同样的工夫实现剩下的 10%。”
软件我的项目容易延期和跳票是不足为奇的事件，其中不乏出名我的项目。
刚毕业的时候，我在一家做系统集成的公司工作，咱们定制了一套售票软件，为景区接入互联网售票计划。供应该软件的软件公司十分自信的说，这货色非常简单，最多 2 个月就能搞进去。这家公司小有名气，我老板对 2 个月交付深信不疑，于是张罗了接入的客户、市场的物料等。
不难猜到，最终还是没能逃过 90% 定律，2 个月交付的货色只能算作一个 Demo。于是花了另外一个月测试，修复问题和欠缺业务逻辑，又花了另外几个月工夫响应对接客户的要求，才逐步稳定下来。
行百里者半九十，软件开发也大体如此。开发者估不准工时常有，估准了才奇怪呢。起初本人也做了软件工程师，参加 IT 我的项目开发，我的项目延期也是十分常见的事件。
工时估算的前提是品质
IT 团队能准时交付是一项十分有价值的能力，哪怕交付工夫长一点。打算两周交付，最初能准时实现，比承诺一周工夫，然而花了三周才交付重要得多。
越是大我的项目，越是重要。大我的项目的各个组件可能会产生相互依赖。如果不能准时交付，就会付出团队期待的老本，那可是真金白银。
做过项目管理的都晓得甘特图，甘特图的每个泳道表白了我的项目各项资源的停顿和打算。然而，软件我的项目不确定性十分多，存在各种突发事件。如果能进步准时按品质交付，各个单位的期待老本会小很多。
要害的是，掂量准时交付的要害是品质，其次才是交付。先给一个 demo，而后再缓缓改 bug。这种“准时”的交付，还不如有一个明确的延期工夫，实质上还是“猛糙快”。
谈我的项目工时估算，应该是在满足品质要求的前提下，否则估时没有意义。
进步估算准确性的办法
那么能不能进步软件工程工时的估算的准确性呢？其实是能够的，刚到 Thoughtworks 的时候，参加了一个交付我的项目。在一个我的项目开始前就打算了我的项目完结的工夫，以及下一个我的项目的打算和安顿。后果让我十分吃惊，那个我的项目的完结工夫，和预期相差两周左右。并且这两周是逐渐缩小开发人员，最初只有 1-2 集体负责最初一周的交接期。
这就是业余软件团队和小作坊的差异，在业余项目经理率领下能把 3 个月的我的项目估算，准确到 20 – 30 集体天。能把我的项目工时估算到这种水平，体现了 PM 的内功。
在一个麻利团队，须要把工时估准，不在于“估”，而在于团队执行我的项目的稳定性。一般来说，精确估算工时须要思考需要剖析水平、工作拆分的合理性、技术计划的可靠性、团队成员的能力、内部依赖和环境，如果这个我的项目不是新我的项目，还须要思考遗留零碎革新的老本和数据迁徙的老本。
需要和任务分析
只有把需要剖析做的十分彻底，能力保障估算的输出条件。非专业的业务分析师，只能看到需要冰山水面上的局部 —— 软件的个性、性能的复杂性等。
业余的业务分析师，不仅须要思考性能需要，并对性能需要的逻辑性思考齐备。比方用户须要一个 APP，他实际上还须要一个后盾，对应这个后盾会有不同的用户、角色等。
依据这些业务输入、拆分出工作，麻利开发中咱们叫做用户故事，一个用户故事代表一个正当拆分的业务逻辑。能被评估工作量，而后依据这个工作量来评估工时。
除了这些性能需要之外，还有非性能需要。客户不仅仅须要一个 APP，还可能须要的是一个平安的、高性能的、国际化的 APP，而这些往往被客户当做默认选项。
一些性能优化的指标须要剖析，并思考性能优化的工作工时；平安需要可能有 HTTPS 配置，防病毒扫描等，都须要思考；国际化也是额定的工作量。
开掘用户实在需要的目标是定义怎么才算实现（Definition of Done），如果没人说得分明满足什么条件这个我的项目才算完，那么估算工时基本无从谈起。
彻底开掘客户的实在需要是评估我的项目工时的首要条件。
技术计划和团队能力
技术计划、团队能力和我的项目工夫估算有很大关系。很多我的项目的工夫估算都是由技术经理或者 Tech lead 来实现，往往是他们依照本人的教训和能力进行计算的。光是这样，很难算的准。
团队有多少人？对这套技术计划的相熟水平如何？计划是否会产生较大的调整。人一多，人员程度差距就为工时预计带来了不确定性。教训多的人来做计划，如果是他做过的类似计划，天然会估的稍准一点。但大多数状况下没有这么现实的场景。
要做好工时估算，须要联合技术计划和团队成员能力，而不是本人无能多少活儿，多快干完来算。
一方面，技术负责人须要安顿相应的技术预研，走在理论编码的开发人员后面，探探路，验证计划的可行性、施行难度、危险。就像作战的侦查人员一样，咱们把预研叫做 spike。spike 须要输入一些论断、demo，反对我的项目的工夫估算。
另外一方面，考查团队实在运作效率很好的形式是依据迭代唱工时统计。依照两周为例，10 集体的团队是 100 个工时。如果依照之前的估算，2 周内须要实现的 100 个工时的工作，实际上只实现了 50 个工时。也就是进度只有 50%。
我这个算法比拟毛糙，麻利项目管理中还有更精确的速率计算形式。通过速率，就能对下一阶段的工时估算做出调整，并在工作量、人员上做出调整。
通过计划预研和速率计算是进步我的项目工时估算准确率的良好办法。
把控遗留零碎和内部依赖
我经常花了一下午工夫实现了某个个性降级的编码，然而花了一个月的工夫才实现了线上平滑降级、数据迁徙。
真正有教训的工程师都晓得，方案设计的难点往往不在设计一个新货色，而在于演进一个老零碎。遗留零碎演进是不可避免的，这种历史包袱是造成工时估算不准的一个重要因素。
遗留零碎演进带来的估算艰难起源上面几个方面：
- 前置条件不满足或者很艰难。客户可能感觉只是增加一个小性能，然而波及数据库变更、API 降级。软件我的项目往往牵一发而动全身。
- 遗留零碎代码难以了解，没有人说得分明原委。这种零碎往往随同着重构，否则难以进行。
- 数据迁徙的老本。例如，需要只是简略要求对用户的某些数据加密，理论工作包含了对存量数据的迁徙。
- 长期代码的清理。遗留零碎往往为三个状态，原始态 - 过渡态 - 最终态，很多人估算工时要么遗记了过渡态，就是遗记了最终态的工夫老本。
不负责的猜测，有一些客户就是遗留零碎演进不上来了，而后投标做新性能，理论用意是想乙方顺便消化重构的老本。总之基于遗留零碎的二次开发都是一件艰难的事件，能不接就不接吧。
另外，社会分工意味着一个人干不完所有的事件，IT 我的项目往往一个我的项目也不是独立的。大多数状况下须要和内部条件进行集成，这部分工夫超出咱们的掌控。
集成这件事的老本须要视被动集成还是被动集成来说：
- 须要期待他人提供服务，咱们去集成。在预计工时的时候，肯定要把对方的交付工夫思考进去，提前沟通，并建设契约。
- 提供给他人服务，被他人集成。这种状况预计工时，往往只是计算到 API 上线，实际上还须要思考肯定的反对、文档工作量。很少有一次到位的状况，大多要磨合一段时间。
集成充斥了不确定性，估算工时时须要预留足够的集成空间，能力让工时估算更精确。
总结
我的项目工时估算是一个系统性工作，基本上很难有一个万能的办法。因而大多数状况下都是玄学，然而毕竟是“估”，也不能要求 100% 准确。软件工程的估时更具备弹性，绝对供应链治理的交付工夫估算老本更低。
做好估时，对缩小我的项目运行老本和危险有微小意义，工时估算的准确性也往往体现了一个 IT 团队工程能力。
起源：Thoughtworks 洞见
作者：林宁
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
玩乐高，学麻利，规模化麻利联合作战沙盘之「乌托邦打算」，2022 年 3 月 5 - 6 日登陆深圳，将“多团队麻利协同”基因内化在研发流程中，为规模化晋升研发效力保驾护航！!🏰⛴公众号回复“乌托邦”可加入
