🤖 Deploying to gh-pages from master 3ef4969

_posts/2024-08-21-data-driven-software-estimation-draft-v2.md → _posts/2024-08-21-data-driven-software-estimation-draft-v3.md

@@ -9,15 +9,15 @@ category: data-driven-sdlc estimation software-estimation fix-bid statistics
 
 > **太长不读：本篇以笔者已经结束的一些项目及其统计数据，来谈谈如何做固定金额（Fix Bid）项目的成本估算。在估点侧，我们需要的工具是一个估点基线、一个打开细节的框架；在报价侧，我们可能需要把常用的系数从1.2/1.5根据情况上调到2.5/3。这就是笔者依据一个两百万左右的项目回测和一些数据分析出来的经验结论。**
 
-估算是我们每天的工作中一个司空见惯的话题，尤其是在软件开发行业：在敏捷开发中，我们会[每周定期做业务故事梳理和估点][Backlog Refinement Meeting]，以更好地安排未来两周的工作量；在/**thought**works作为乙方公司，打固定金额（Fix Bid）订单时估算的准确性决定了成本的准确性，进而影响收入的可预测性。就算是在每天的个人工作中，我们常常也需要[估算手头上多个工作的工作量][My TL Experience]，根据它们带来的价值判断每日每周的工作优先级。可以说，估算做的越准，对个人和生意的帮助就越大。
+估算是我们每天的工作中一个司空见惯的话题，尤其是在软件开发行业：在敏捷开发中，我们会[每周定期做业务故事梳理和估点][Backlog Refinement Meeting]，以更好地安排未来两周的工作量；在/**thought**works作为乙方公司，打固定金额（Fix Bid）订单时估算的准确性决定了成本的准确性，进而影响收入的可预测性。就算是在每天的个人工作中，我们常常也需要[估算手头上多个工作的工作量](https://ethan.thoughtworkers.me/#/post/2023-08-05-my-tech-lead-journey-iv)，根据它们带来的价值判断每日每周的工作优先级。可以说，估算做的越准，对个人和生意的帮助就越大。
 
 同时，估算又很难。对于低层级的工作，人们常常容易高估自己、低估未知的工作量；对于高层级的工作，人们又常常因为打开的细节不够，导致估算结果与真实执行成本相去甚远。在固定金额项目或某些生意模式中，成本估算是我们需要面对的一个问题。本篇我们就来聊聊估算相关的那些事。
 
 ## 估算的目的与难点
 
 估算有许多不同的种类，但是从要求和目的上讲，大体可以分为两类：不需要那么精确的估算，和需要尽可能精确的估算。
 
-有一些估算不需要那么精确，这是由它们的目的决定的，这类估算往往只需要一个大概的**量度或范围**来做一些快速的决策，比如优先级排序、预算估算等。比如在[SAFe][]框架下的产品增量计划会（PI Planning）[^1]上，产品经理会希望团队对某几个大功能进行估算，以便综合功能的价值进行未来三个月的业务功能优先级排序；又比如在售前过程中，~~（一些成本敏感的）~~ 甲方 ~~（谁不是呢）~~ 有时需要知道某个服务项目的报价范围，以确定有没有远远超出他们的预算。在这些情况下，估点的目的是提供一个**量度或范围**——比如A功能比B功能大很多、某个项目20万而不是200万——而不是一个过分准确的数字，以便受众可以根据这个范围快速地做出一些早期决策。
+有一些估算不需要那么精确，这是由它们的目的决定的，这类估算往往只需要一个大概的**量度或范围**来做一些快速的决策，比如优先级排序、预算估算等。比如在[SAFe](https://scaledagileframework.com/)框架下的产品增量计划会（PI Planning）¹上，产品经理会希望团队对某几个大功能进行估算，以便综合功能的价值进行未来三个月的业务功能优先级排序；又比如在售前过程中，~~（一些成本敏感的）~~ 甲方 ~~（谁不是呢）~~ 有时需要知道某个服务项目的报价范围，以确定有没有远远超出他们的预算。在这些情况下，估点的目的是提供一个**量度或范围**——比如A功能比B功能大很多、某个项目20万而不是200万——而不是一个过分准确的数字，以便受众可以根据这个范围快速地做出一些早期决策。
 
 有一些估算需要尽可能地精确。这类估算往往涉及成本计算💰💰，或者会产生相应的责任或承诺。比如打固定金额的SoW时需要根本成本算出报价 ~~（还要保持40%的margin）~~，又或者每周的[敏捷会议上][Backlog Refinement Meeting]为下个迭代的故事进行估点——这是一个软性的承诺，等等。
 
@@ -29,7 +29,7 @@ category: data-driven-sdlc estimation software-estimation fix-bid statistics
 
 在涉及估算的场合，估算单位的选择也代表了估算方法本身所做出的假设。来了/tw，目前接触过最常见的两种估算单位，一个是点数，一个是人天。也有一些小伙伴，在估算的时候会纠结，我是应该用点数，还是用人天？简短的回答是，it depends（逃。应该说，视估算的场景和目的不同，选用的单位不同。
 
-很多时候作为管理角色，最希望得到的当然是人天估算，这样时间和人数就都可以作为资源进行项目管理。但人们很容易忽略的是，人天这个单位本身就隐含了精确性、确定性，而软件工作的本质就蕴含了一些不确定性[^2]——这不仅是整个敏捷和XP方法论的假设[^3]，同时也得到了很多实践和数据的检验[^4]。这不是说人天估算不好，或者我们不应该使用人天估算，而是我首先希望大家意识到人天估算中被隐藏的不确定性，是需要你有意识地去处理的。
+很多时候作为管理角色，最希望得到的当然是人天估算，这样时间和人数就都可以作为资源进行项目管理。但人们很容易忽略的是，人天这个单位本身就隐含了精确性、确定性，而软件工作的本质就蕴含了一些不确定性²——这不仅是整个敏捷和XP方法论的假设³，同时也得到了很多实践和数据的检验⁴。这不是说人天估算不好，或者我们不应该使用人天估算，而是我首先希望大家意识到人天估算中被隐藏的不确定性，是需要你有意识地去处理的。
 
 使用点数进行估算呢，正是基于软件工作不可完全预测、但具有可对比性这一信息：比如改字工作就比CRUD“工作量更小”，诸如此类。使用点数时，有很多具有对比性的度量单位被提出，比如斐波那契数列（1/2/3/5/8/...）、T-shirt估算（XS/S/M/L/XL/..）等。使用点数估点时，最重要的是确定可用来作为对比的基线，比如1个点、2个点或XS的用户故事分别意味着什么，有什么例子，写出来公示给团队，等等。
 
@@ -61,11 +61,12 @@ category: data-driven-sdlc estimation software-estimation fix-bid statistics
   />
 </p>
 
-以上图这个常见的React前端架构为底本[^5]，并以笔者一个过往项目的具体数据进行测算[^6]，可以得到这样一份具体任务的估点基线：
+以上图这个常见的React前端架构为底本⁵，并以笔者一个过往项目的具体数据进行测算⁶，可以得到这样一份具体任务的估点基线：
 
 <p align="center" >
   <img 
-    src="https://cdn.jsdelivr.net/gh/EthanLin-TWer/blog@gh-pages/_images/2024-08-22-estimation-baseline.png" 
+    src="https://cdn.jsdelivr.net/gh/EthanLin-TWer/blog@gh-pages/_images/2024-08-22-estimation-baseline.png"
+    width="500"
   />
 </p>
 
@@ -127,7 +128,7 @@ category: data-driven-sdlc estimation software-estimation fix-bid statistics
 
 经过上面一通操作，你应该已经得到编程任务部分的估点了，而且有希望是一个不算偏差太大的估点版本。接下来，我们就要处理一下整个软件项目剩余部分的估算和报价部分——很显然，因为软件项目不仅只有编码工作，甚至可以说，真正与代码打交道的工作占其中的不到50%——很快你就会看到，这又是一个真实的数据。
 
-让我们把一个开发者日常编码以外的时间拼凑出来，可以得到这样一个时间比例图[^7]。
+让我们把一个开发者日常编码以外的时间拼凑出来，可以得到这样一个时间比例图⁷。
 
 <p align="center" >
   <img 
@@ -181,17 +182,22 @@ $$\; \; \; \; \; \; \; , or = Rate \times (Dev\space Estimation \div 0.47 + Non\
 ## Work in Progress
 
 * 再快速浏览润色一遍。
-* 手动修正一下引用。用右上角的1 2 3就好了
 * 快速润色一下，发表。不纠结。补全一下艾特来金的部分
 
 [Backlog Refinement Meeting]: https://www.agilealliance.org/glossary/backlog-refinement/
-[My TL Experience]: https://ethan.thoughtworkers.me/#/post/2023-08-05-my-tech-lead-journey-iv
-[SAFe]: https://scaledagileframework.com/
-
-[^1]: 产品增量（Product Increment，PI）计划会一般比Scrum/敏捷中的迭代更长。一个PI计划会往往包含4-6个敏捷迭代，通常是2-3个月的时间。这个协作模式往往是为了提前协调多个相互紧密合作的中小团队的工作、依赖和优先级，常见于拥有较大体量的IT团队的大公司。
-[^2]: 比如需求变动、方案变动、沟通、流程、梯队培养、人员离职与更替、单位绩效考评等等。
-[^3]: 事实上，敏捷与极限编程实践中有许多实践正是基于这样的假设来减少浪费并变得“敏捷”，比如避免过度设计、迭代开发、小步前进等。
-[^4]: 后文引用的数据也会体现这一点。
-[^5]: 这里略去了与本架构对应的测试策略最佳实践，因为与本文的核心内容相关性不强。感兴趣的读者可以前往笔者文章[React单元测试最佳实践与前端TDD](https://ethan.thoughtworkers.me/#/post/2023-12-10-react-unit-testing-best-practices-v2)及[相关系列](https://ethan.thoughtworkers.me/#/post/2023-12-25-react-testing-strategy-and-best-practices)查看。
-[^6]: 数据集基于个人日常编码时间采集与Git提交时间统计，精确到小时/半天。
-[^7]: 这里，我用的都是我在项目上的真实数据——来源涉及三个项目，但交叉对比过基本可靠：做卡时间中的编码、非编码与Tech Huddle时间的分布，采用的是我在最近一个时长约四个月的项目中作为Senior Developer时的工作内容；参加敏捷三大会议10%（不包括故事卡相关的Kick-off/Desk-check等）这个数据是我在[另外一个10个人团队的项目做TL时采集的数据](https://ethan.thoughtworkers.me/#/post/2023-08-01-my-tech-lead-journey-i)，这与八叉在黑马计划与敏捷101课程中提到的健康团队敏捷时间应该在10%左右的数据是相互印证的；公司层面事务11%也是我在去年作为TL在同一项目上的数据，不同时间段可能有出入；其他项目事务14%是采用我在2019年当Senior Developer时总有效工时82%作为参考，减去(31.5+9+6.5+10+11=68)所得到的推测数据；最后的18%“其他”是扣除82%以外的部分。
+
+---
+
+¹: 产品增量（Product Increment，PI）计划会一般比Scrum/敏捷中的迭代更长。一个PI计划会往往包含4-6个敏捷迭代，通常是2-3个月的时间。这个协作模式往往是为了提前协调多个相互紧密合作的中小团队的工作、依赖和优先级，常见于拥有较大体量的IT团队的大公司。
+
+²: 比如需求变动、方案变动、沟通、流程、梯队培养、人员离职与更替、单位绩效考评等等。
+
+³: 事实上，敏捷与极限编程实践中有许多实践正是基于这样的假设来减少浪费并变得“敏捷”，比如避免过度设计、迭代开发、小步前进等。
+
+⁴: 后文引用的数据也会体现这一点。
+
+⁵: 这里略去了与本架构对应的测试策略最佳实践，因为与本文的核心内容相关性不强。感兴趣的读者可以前往笔者文章[React单元测试最佳实践与前端TDD](https://ethan.thoughtworkers.me/#/post/2023-12-10-react-unit-testing-best-practices-v2)及[相关系列](https://ethan.thoughtworkers.me/#/post/2023-12-25-react-testing-strategy-and-best-practices)查看。
+
+⁶: 数据集基于个人日常编码时间采集与Git提交时间统计，精确到小时/半天。
+
+⁷: 这里，我用的都是我在项目上的真实数据——来源涉及三个项目，但交叉对比过基本可靠：做卡时间中的编码、非编码与Tech Huddle时间的分布，采用的是我在最近一个时长约四个月的项目中作为Senior Developer时的工作内容；参加敏捷三大会议10%（不包括故事卡相关的Kick-off/Desk-check等）这个数据是我在[另外一个10个人团队的项目做TL时采集的数据](https://ethan.thoughtworkers.me/#/post/2023-08-01-my-tech-lead-journey-i)，这与八叉在黑马计划与敏捷101课程中提到的健康团队敏捷时间应该在10%左右的数据是相互印证的；公司层面事务11%也是我在去年作为TL在同一项目上的数据，不同时间段可能有出入；其他项目事务14%是采用我在2019年当Senior Developer时总有效工时82%作为参考，减去(31.5+9+6.5+10+11=68)所得到的推测数据；最后的18%“其他”是扣除82%以外的部分。