Scrum 中的敏捷估计？故事点和计划扑克 - IT 观察者随笔

角色敌意：需求单位和开发单位不再是交付能够给用户带来利益的产品，而是为了各自的目的而互相攻击，以避免承担额外的责任。因此，需求单元和开发单元根本不是一个团队的情况。
责任：团队认为“我没有错，所以延迟不是我的责任”，而不是优先考虑用户需求。
需求冻结：开发者迫于期限压力而被迫更改需求，否则会被耽误，责任将落在开发者身上。因此，要么需要加班加点制作隐藏大量错误的东西，要么制作某种不符合用户需求的功能；两者都会降低用户满意度。
低质量：PM的地位往往高于开发人员。因此，为了赶上合同期限或避免处罚等，球队会被要求“先完成，后求更好”，但最终往往是“先完成，后求好” 。” 技术债务的积累越来越多，结果就是现实世界的责任链模型，在链的最末端承担着最大的责任和成本。所以团队就像stack pop，开发者一个一个都撑不住，这也是项目公司工程师经常流失率高的原因之一。
提高代码权重：为了优化效率，总是用最熟悉的人的位置来估算工时，所以最熟悉模块和流程的人会一直关心相关的需求. 到头来，只有那些人才能维护自己的代码，就像潘多拉的盒子，你永远不知道打开后会跑出哪些牛鬼蛇神。因为黑匣子经常很脏，但公司不知道如何解决这个问题。你也希望他不要离开，否则有些代码看不懂。

解决方案

这里提出的解决方案是在 Scrum 中估算需求复杂度的常用方法，但即使不是 Scrum 团队，也建议读者能够根据原则和设计目标确定估算团队的最佳方法.

请记住，如果没有灵丹妙药，其他人的最佳实践不一定适用于您的团队，因此首先要了解您的团队目前遇到的问题是什么，然后从其他人的实践中找出适合您解决问题的方法，只要不引起新问题或新问题的成本风险是可以接受的。

这里用来估计需求复杂性的单位是故事点（相对单位），而不是工作时间（绝对单位）。

这里用来估计需求复杂度的单位是故事点（相对单位），而不是工作时间（绝对单位）。这样做有几个原因：

1、比较不会因人而异：需求的复杂程度往往因人而异，实践所需的时间因人而异。

2.“相对”比“绝对”更容易评估：如果看工作时间，就需要估计绝对数，在估计过程中需要考虑实施细节。要使用故事点来估计复杂度，只需将大小与其他需求进行比较即可。

例如，很难说清楚“一座塔有几米高”，但更容易指出“这座塔比那座建筑高约 2 倍”。

3. 估计一个用户故事的故事点的压力比估计它的工作时间要小：关注需求本身，不用担心自己的资源和项目资源，简单评估需求的复杂性。在估算过程中，团队成员的压力较小，可以像游戏一样参与软件开发。

虽然需求的复杂度往往与工时成正相关，但由于实施条件的不同，还是有可能有一个故事点高的特征，对工时的需求低于故事点。但是在 Scrum 中，您可以使用迭代 sprint 来评估每个 sprint 团队可以消化多少复杂性。对于 PO/PM 来说，与其估计一个不成功的时间进程，不如估计一个更准确、更客观的时间进程，以便他们在第一时间了解，距离项目预期的时间进程还有多远。如果资源有限，如何确定需求的优先级或寻求其他支持。

接下来，解释解决方案的各个方面。

什么时候

在决定谁需要做之前进行评估：这样做的好处是最大限度地减少开发人员的个人因素。因为你不知道谁来做，所以没有必要因为你自己的任务或截止日期而高估添加缓冲区。

谁

只有做事的人才能一起评价：两个关键点：

只有做事的人才能估计。需求单元估计的时间或复杂度是不客观的，因为他们不是实际的工作人员，也没有权力影响开发团队基于工作负担评估的估计。这也使得更容易避免从截止日期开始评估需求的复杂性。
一起做事的人估计。因为你不知道谁来做，每个人一起估计的数字很容易在讨论和重新估计后达成共识。每个人都有参与，他们就会有参与感，而且因为每个人都有参与，所以估计结果是由每个人决定的，所以以后谁来做就不会抱怨了。

什么

使用规划扑克来估计故事点。

扑克牌和斐波那契数列

Fischer 级数有一个有趣的特点，每个数字都是前两个数字相加。另一方面，数字与下一个数字之间的差异越大，差异越大。

如上所示，8 和 13 之间的差距是 5，而 13 和 20 之间的差距是 7。但是，这与估计需求的复杂性有什么关系呢？我们不在数学课上。

与斐波那契数列相关的估计特征

估计也有一个特点，就是越大越准确，把需求或任务切得越细粒度越大，往往估计得越准确。就像杯子里装了一块不规则的大石头，中间会出现更多的缝隙，就是不对齐或者浪费的部分。如果安装尺寸更细、不规则度相同的石材，缝隙会比较小，而且容易调整，可以更方便地填补缝隙。

即使前面的数字相差比较小，也无所谓，因为数字小，说明动作灵活，风险低。如果由于某些因素导致时间估计不准确，那么前面小数的任务就是加班20分钟左右。而不是加班2、5天。

因为大的数字差距很大（费米级数前后两个值的差异比接近1.618），可以避免“这个复杂度是20还是21”的估计。“如果你想要 13，你想要 20，你想要 40。

这样的差距可以突出对相同要求的估计差异，因为几乎所有这些要求都差 1.5 倍以上。这个比率很容易让人类判断相对大小，因此可以减少许多细微差别和不必要的重新估算过程成本。

扑克牌中的特殊号码

另外，上图可以看到几个特殊的数字，分别是0、无穷大和问号。

0可能表示这个需求根本不需要做，或者已经完成了。
无穷大意味着需求是明确的，但是超过最大数量的则表明需求需要细分为多个更小的需求。
问号表示需求不明确，需要PO/PM解释或澄清。

如何

1.首先定义复杂度单位1，比如单表综合查询的功能。因为我们的估算过程是基于相对规模的，所以我们首先定义了比较基准的单位，团队估算后就有了比较的依据。

2. 主持人大声说出要求（例如用户故事卡），以确保每个人都理解要求，并且每个人都提出自己估计的复杂性。使用计划扑克的原因是因为您评估的数字可以同时呈现，而不是轮换您评估的数字。很容易把数字翻出来，导致后面的人的结果受到前面的数字的影响。

3.如果团队中有不同的估计，这两个估计是最小的和最大的，他们会评估为什么它们是复杂的或简单的。在上面的例子中，在估计过程中，如果一个人估计故事点是13，大多数人估计20，另一个人估计40。13和40几乎差了3倍，所以基本上肯定有一些重要的信息有没有被同步。

比如估计13的人认为这个需求和过去的一个需求几乎是一样的，而且这个需求并没有想象的那么复杂。估计 40 的人可能会觉得比较复杂，因为他对这个要求或过程不够熟悉。

4. 完成评估理由的最小和最大数字，并进行进一步的投票。如果仍然有不同的票数，并且绝大多数人有共识，并且没有一致认为估计的复杂度与共识复杂度只有一个级别，你可以询问估计不同的成员是否他们可以接受您评估过的数字。

5. 如果数字在一个水平以上仍有差距，或者无法达成共识，重复步骤 3 到 5，直到达成共识。

同样，只有真正执行任务或完成要求的人才可以参与投票过程，PO/PM 不能干预。

为什么

这种估算方式有几个优点：

一起工作的人决定一个合理客观的估算结果，有参与感，没有抱怨。
决策的结果是 PO 和 Team 之间的共识，这将减少未来以牙还牙的情况发生。
每个人都可以理解需求。未来，每个人都可以充当满足要求的人。当需要支持时，人们也可以互相帮助或支持。
在你这样做之前，你可以澄清需求中不清楚的部分和有疑问的部分。
在你做这件事之前，你可以找到在团队中工作的最佳和最有效的方式。
除非整个团队都是一个不靠谱的人，否则这个数字反映了估算是团队共享的，PO可以理解需求和评价之间的差距。
通过比较需求之间复杂度的相对大小，未来的PO就能承诺一个迭代能完成多少工作，就有了比较的依据。

结论

通过上述估算过程，这样的决定是公开、透明、客观和自愿的。对于两个角色：

采购订单/下午：

不要担心某些成员会高估缓冲区的任务。
了解在评估过程中实施要求或任务的潜在困难。
了解需求中是否有需要明确说明或误解的部分。

对于团队：

对于不再做事的人，按照期限给予不合理的时间限制。
开发人员在开始处理任务之前进行知识交流。不管预估数量是增加还是减少，需求更清晰，预估也更客观。
因为你仍然不知道谁在认领这个任务，所以可以客观地完成估算过程，并在团队共识的情况下，通过这个过程你知道谁熟悉这个任务。当你真正做到这一点时，你可以结对编程或知道向谁寻求帮助。

本文提出的解决方案是一种常见的解决方案。重点不在于形式，而在于敏捷估算过程中各个环节的设计目的，以解决什么样的问题。

问题

PM/PO 的矿

结果