超入门者的敏捷估算之道，蒙古汤面告诉你

这是is开发者网站Advent Calendar 2024第13天的文章。

对于初次接触敏捷开发的人来说，“估算”往往是他们首先遇到的苦恼之一，这一点应该会得到许多人的认同。
本文将超入门层级地介绍如何与敏捷估算相处，希望可以让读者无需过度纠结，从而迈出下一步。

……我首先想告诉你们这件事。为了那些困惑于“故事点到底表示什么”的朋友们，我想先提供一些安心材料。

（虽然这不是is的官方网站，不过就算了，姑且接受吧。）

是否感到安心了？
“无论问谁，都没有一个坚定且一致的完美定义”，明白了吗？

因此，不需要完美地理解也无妨。

比起这些，还有更重要的事情。

关于敏捷估算的特点，通常被讨论的以下主题，我们可以一边回顾一边整理，并确认如何更好地与估算相处：
1）相对估算
2）开发者负责估算
3）抽象的单位

在敏捷估算中，通过设置“基准”，然后以“是基准的几倍”的方式进行比较与数值化。用于说明这个概念的例子有很多，例如：

• 比较相邻建筑物的大小（“建筑物B的高度是A的多少倍？”）
• 将地图摊在面前，比较两地点的距离（“东京站到品川站的距离是东京站到秋叶原站的几倍？”）
  等等。

通过这些例子，我们可以学习到，“即便无法以绝对值的方式估算单独的对象，通过比较也是可以数值化的”。
不过，需注意的是，这样的例子并不意味着“因此就可以完成估算”。
因为这些例子中，“被比较的对象是存在眼前且可视的事物”。
然而我们真正想要估算的是“尚未完成的事物”，因此，眼前并不存在这些对象，对它们进行估算似乎比上述“建筑物的高度”或“地图上两地间的距离”要困难得多。

这时，需要开发者登场了。

“一个简单的登录功能和一个连接多个系统的单点登录功能，哪个更难开发？”如果有人问你们，大部分人会回答后者，即使他们没开发过单点登录功能。
开发者通过以往的开发经验，当被提示某功能时，可以大致推测出需要怎么实现，需要做哪些工作。
虽然一个人所参与过的系统数量并不多，存在局限性，但这并不妨碍他们类比。或许，也存在对所提示的功能完全没有任何概念的情况。
不过，一旦聚集了很多人，那么这个团队中就会积累起多样化的系统开发经验与知识。

即使没有具体详细的需求说明，只需“想实现这样的功能”这一级别的信息，开发者就可以通过找到与过去开发过的功能的相似点，或者根据它们的延长线进行推测和比较，从而判断“工作量的大或小”。
这种基于经验累积的“直觉”，正是进行估算所必要的。
换句话说，“没有这种直觉的人是无法进行估算的”，“没有直觉的人估算出的结果也不值得参考”。

“直觉听上去太模糊了，依赖这种模糊的信息，无法继续推进下去。”如果你这样想的话——
别担心，没事的。
因为我们平时都在用这样的方式。

作为“以模糊信息为基础，并预先接受其误差，然后以此决策后进行行动”的示例，请允许我分享大家喜爱的“蒙◯汤面 北极拉面”的攻略过程。
※不过，不需要多说，我们公司和蒙古汤面没有任何资本关系（虽然有就好了）。这只是因为我个人很喜欢而已。而且，喜欢得不得了。

我非常喜欢吃辣的东西。但是，当我还是蒙古汤面的新手时，凭借内化的敏捷精神，我终于成功完成了北极拉面的挑战。以下是当时我采取的战略分享给大家。
※如果一边浏览蒙古汤面的官方主页，一边阅读本文，或许可以体验那种身临其境的感受。

……已经是上了年纪的我，内脏也不如年轻时那么强劲，“直接挑战北极”是非常冒险的选择。所以我决定先进行基准测量。通过基准测量，培养对“辣度指数”和“实际感受到的辣味”之间的关系的“直觉感受”。

• 首先注意每种拉面的辣度指数。
• 根据指数的数值，选择相对辣度较低的拉面（这次选择了辣度3的味噌汤面作为基准）。
• 实际品尝，以实际感受体验辣度3的辣味（通过经验学习→获得对辣度3的直觉感受）。

……目标北极拉面是辣度9。然而，我完全无法想象“辣度3的3倍”是什么概念。于是，我采取差分策略。“北极拉面（辣度9）”与“味噌汤面（辣度3）”的辣度差为6，这种跨度难以想象。那么，就逐步缩小差距，尝试体验“辣度增加2时，辣味会发生怎样的变化”。这一次，我迎战旗舰产品——辣度5的“蒙古汤面”。

……我的直觉已经大致培养起来了。

• 我体验了辣度3和辣度5（←通过学习经验）。
• 我对辣度差2的实际辣感有了直观了解，因此能够顺着推断出辣度差4的变化（←基于学习进行推测）。
• “能否挑战北极？＞我”（←设定假设）。
• “可以挑战！”（←做出决策）。

……不妙，太辣了，超出预想的辛辣感……不好吃，不对，好吃……却比想象中还辣……（←误差的体现）
因为是直觉，包含误差是预料之中。然而，这也太辣了。我就这样输了吗？难道我要在船桥Vivit广场店门前的街道上跪地求饶吗？＞我……
不，还没结束。因为，我点了鸡蛋和芝士配料啊！通过加入这些稍微温和的配料，我还能继续战斗！（←采取应急方案）。
……
赢了！虽然不是100分，但终究还是吃完了。

……回顾本次挑战，我明白这次策略的失误在于“我的身体还未适应辣味”。为了下一次挑战，我计划采用广为人知的“半辣策略”（注）使身体逐步适应辣味……
注：半辣策略指的是同时进食一种辣味较重的面和一种较不辣的面，以便逐步让身体适应辣味（←渐进构建法）。

通读至此，你应该明白了，“以包含误差为前提的模糊信息作为判断依据进行行动”，对我们来说是一种极为普通的行为逻辑，并非什么特殊之事。

我们往往只是把估算单独拿出来，将“传统方式”和“敏捷方式”进行对比（或许还会加以优劣的评判）。
然而，对于敏捷来说，估算比起“事先高精度地预测某事”，“为下一步行动提供决策依据”的作用更加重要。
即使存在误差，只要团队能够根据直觉进行估算，从而得出方向性并付诸行动，即便误差最终转化为某种障碍，只要有办法进行弥补或调整，最终也是能取得结果的。

并不是说单纯讨论估算就是浪费时间（因为通过这种方式你能学到更多知识）。
但比起纠结这些，不如先审视：

• 团队是否已将估算的方向性转化为行动并最终达成目标？

正如文章开头提到的那样，故事点的定义并非明确无误。
然而，与之前讲述的“一系列活动”结合起来，故事点作为“提供行动依据的材料”，已经可以发挥足够的功能。

那么，为什么不能用人月（即工时）作为单位来进行估算呢？
从根本上来说，“相对估算”并不一定否定“以人月为估算单位”。

但实际上，一旦听到“人月”这个词，你周围那些惯于瀑布式思维的人脑中，会不由自主打开“瀑布式精确估算抽屉”，并开始将你的估算值视作与瀑布式开发一样的“高精度绝对值”。
因此，我认为，故事点这种抽象单位（也就是看上去摸不着头脑的东西），其存在意义在于：

• 借此摆脱对人月的依赖；
• 锁死“瀑布式思维抽屉”，避免脑内思维被禁锢；
• 从而解放团队，使其远离不必要的瀑布式压力；

估算这个话题让许多人感到纠结，听别人解释也不见得清楚，自己解释也可能讲不明白。我也觉得我没解释清楚。
如果是这样的话，不如暂时别纠结，“关注团队运转是否顺畅”，把精力放在这上面，如何？

连那些名人也在为此苦恼，所以，你也别太在意了！