用户投稿对于软件开发人员来说，这是工作中最困难的部分，即使不是最困难的部分。它必须考虑一系列因素，帮助产品所有者做出影响整个团队和业务的决策。
在软件开发过程中，团队经常会遇到一个问题：
如何估计工作时间更準确？
对于项目或产品的所有者来说，这是衡量项目资源和时间表的一个非常重要的信息，但实践这会带来许多问题。
许多开发人员总觉得PM正在使用最后期限来回推送。他们不关心功能是否可以满足质量。
“首先完成它，然后寻求更好”因此已经在软件行业中流传了很长时间。
许多PM总是觉得开发人员在评估他们的工作时最倾向于“夸大”。似乎他们都使用典型的工作估计方法：“估计实际需要时间的三倍作为缓冲”“
事实上，工作时间不能估计为“绝对準确”，但有一些方法可以估算“相对客观”。由于工作时间和要求的複杂性，通常存在正相关关係。因此，本文将首先解释响应需求复杂性的常见问题，提出一个解决方案，并解释解决方案中许多设计的目的。
问题
开发者的地雷
“这很简单。製作它不应该花太长时间吗？“PM今天对你说：“明天之前我必须把它交给你。“在寻求质量之前，先完成它”PM后天对你说：“为什么这个程序的质量如此糟糕？”当它被推迟时，其他同事说：“你怎么需要花这么长时间？这有一个现成的代码供参考。这有一个很好的底层使用。你为什么不问我？“其他同事：“我只需要一天，你为什么要花这么多天？”“这是常识！需求即使没提，你应该知道该怎么做。“PM / PO的地雷
“为什么这么简单？花了这么长时间？““为什么看到你正在访问Facebook，但你没有时间去做？”“为什么这些东西质量这么差了？”“为什么他上次一天就做出来，你要做这么多天？”由于规範或要求没有明确写入，因此开发人员被描述为需求变更。Result
角色敌意：需求单元和开发单元不再提供可以为用户带来好处的产品，而是为了自己的目的而相互攻击，以避免承担额外的责任。因此，需求单位和开发单位根本不是一个团队的情况。责任：团队认为“我没有错，所以延迟不是我的责任”，而不是优先考虑用户需求。需求冻结：由于截止日期的压力，开发人员被迫改变他们的要求，否则他们将被推迟并且责任将由开发人员承担。因此，要么需要加班来製作隐藏大量错误的东西，要么製作某种不符合用户需求的功能; 两者都会降低用户满意度。低质量：PM的地位通常高于开发人员。因此，为了满足合同的最后期限或避免处罚等，团队将被要求“先完成，然后再寻求更好”，但最后通常是“先，没有时间寻去求好” “技术债务的积累正在增加，结果是现实世界的责任链模型，它在最后的链条中负有最大的责任和成本。因此团队就像堆栈流行，开发人员无法一个接一个地维持，这是项目公司工程师经常拥有高流动率的因素之一。提高代码的重量：为了优化效率，最熟悉的人的位置总是用于估计工作时间，因此最熟悉模块和过程的人将始终关注相关要求。最后，只有那些人可以维护自己的代码，就像潘多拉的盒子一样，你永远不会知道哪些牛和鬼会在打开后什么会突然出现。因为黑匣子经常骯髒，但公司根本不知道如何解决这个问题。你也只有希望他不会离开，否则一些代码将无法理解。Solution
这里提出的解决方案是估算Scrum中需求复杂性的常用方法，但即使它不是Scrum团队，也建议读者根据原则和设计目标确定评估团队的最佳方法。 。
请记住，这个世界没有灵丹妙药，其他人的最佳实践方法并不一定适用于您的团队，因此首先要了解您的团队目前遇到的问题，然后找出适合您解决你自己实践问题的方法。 ，只要它不会引起新问题或新问题的成本风险是可以接受的。
这里用来估计需求复杂性的单位是故事点（相对单位），而不是工作时间（绝对单位）。这样做有几个原因：
1.比较不会因人而异：要求的複杂性通常不会因人而异，实践所需的时间也许会因人而异。
2.“相对”比“绝对”更容易评估：如果查看工作时间，则需要估算绝对数量，并且需要在估算过程中考虑实施细节。要使用故事点来估计複杂性，您只需要将大小与其他要求进行比较。
例如，很难估计清楚“A塔高几米”，但更容易指出“A塔比那座建筑高约2倍。”
3.估计用户故事的故事点的压力小于估计其工作时间：因为关注需求本身，而不必担心自己的资源和项目资源，只需评估需求的複杂性。在估算过程中，团队成员压力较小，并像游戏一样参与软件开发。
接下来，解释解决方案的各个方面。
When
在决定谁来做之前进行评估：这样做的好处是最大限度地减少开发人员的个人因素。因为知道由谁做，所以不需要因为您自己的任务或最后期限而故意高估去添加缓冲区。
Who
只有做事情的人一起评价：两个关键点：
只有那些做事的人才能估计出来。需求单元估计的时间或複杂性不是客观的，因为它们不是实际工作的人，并且没有权力根据工作负担评估影响开发团队的估算。这也使得更容易避免从截止日期开始评估要求的複杂性。一起做事的人估计。因为您不知道将要做什么，所以每个人一起估计的数字在讨论和重新估计后很容易达成共识。每个人都有参与，他们会有参与感，而且因为每个人都有参与，估计结果是由每个人决定的，所以谁将来会这样做不会抱怨。What
使用规划扑克来估计故事点。
Poker and Fibonacci Sequence
估计Scrum 中用户故事大小的最常用方法是分配故事点。故事点只是从设定大小的数字池中抽取的数字，例如，故事可以具有1,2,3,5,8,13,20,40或100个故事点。
在菲舍尔系列有一个有趣的功能，并且每个数字是前两个数字加。另一方面，数字与下一个数字之间的间隙越大，差异越大。
如上所示，8和13之间的差距是5，而13和20之间的差距是7.但是，这与估计需求的複杂性有何关係？我们不在数学课上。
与Fibonacci序列相关的估计特徵
估计也有一个特徵，即越大越不精确，需求或任务被削减到更精细的粒度，通常估计更準确。就像在杯子中安装一块大的不规则石块一样，中间会有更多的间隙，这是不对齐或浪费的部分。如果你安装一个更细和相同的不规则的石头，间隙将相对较小，并且它易于调整，它可以更方便地填补空隙。
即使先前数字的差异相对较小，也无关紧要，因为数量很小，这意味着搬家灵活且风险低。如果由于某些因素导致时间估计不准确，则前面的小数字的任务是大约20分钟的加班时间。而不是加班2或5天。
因为大的数字间隙很大（费米系列的两个前后值的差值接近1.618），所以可以避免估计“这种複杂性是20还是21”。“要么要想13，要么20，要么40。
这种差距可以突出相同要求的估计差异，因为几乎所有这些差异都要差1.5倍。这个比例很容易让人们判断相对大小，因此可以减少许多细微差别和不必要的重新估算过程成本。
扑克牌中的特殊号码
另外，上面的图片可以看到一些特殊的数字，分别是0，无穷大和问号。
0可能意味着根本不需要完成此要求，或者它已经完成。无限意味着需求是明确的，但超过最大数量的需求，表明需求需要细分为多个较小规模的需求。问号表明需求不明确，需要PO / PM来解释或澄清。How
1.首先定义复杂度单位1，例如单表综合查询的功能。由于我们的估算过程是基于相对规模，我们首先定义比较基準的单位，并在团队估算后有比较的基础。
2.主持人大声说出要求（例如用户故事卡），以确保每个人都了解要求，每个人都有自己的估计複杂性。使用计划扑克的原因是因为您评估的数字可以同时显示，而不是旋转您评估的数字。很容易将数字输出并导致其背后的人的结果受到之前数字的影响。
3.如果团队中有不同的估计，估计这两个估计是最小的和最大的，他们将评估它们複杂或简单的原因。在上面的例子中，在估计过程中，如果一个人估计故事点是13，大多数人估计20和另一个人估计40。13和40差不多3倍，所以基本上必须有一些重要信息没有同步。
例如，估计13的人认为这种需求几乎与过去的某个要求相同，而且这个要求并不像想像的那么複杂。估计40的人可能会感到相对複杂，因为他对这个要求或过程不够熟悉。
4.最低和最高数字完成评估的原因并进行进一步投票。如果仍然有不同的投票数，并且绝大多数人都达成了共识，并且没有达成共识，估计的複杂性只是远离共识複杂性的一个级别，您可以询问估计不同数字的成员是否他们可以接受您评估的数字。
5.如果数字仍有差距一个级距以上，或者无法达成共识，请重複步骤3到5，直到达成共识。
同样，只有那些实际执行任务或完成要求的人才能参与投票过程，而PO / PM不能干涉。
Why
这种估算方法有几个优点：
合作的人决定合理客观的估计结果，有参与感，没有抱怨。决定的结果是PO和团队之间的共识，这将减少未来针锋相对的情况的发生。每个人都能理解这个要求。将来，每个人都可以充当满足要求的人。当需要支持时，人们也可以互相帮助或互相支持。在您这样做之前，您可以澄清不明确的要求部分和有疑问的部分。在您做之前，您可以找到最佳和最有效的团队合作方式。除非整个团队都是一个不可靠的人，否则这个数字反映了团队共享估算的事实，而PO可以理解需求与评估之间的差距。通过比较需求之间複杂性的相对大小，未来的PO将能够承诺在迭代中可以完成多少工作，并且将有一个比较的基础。结论
通过上述估算过程，这样的决定是公开，透明，客观和自愿的。对于两个角色：
对于PO / PM：
不需要担心某些成员过度估计任务作为缓冲区。了解在评估过程中实施需求或任务的潜在困难。了解需求的任何部分是否需要明确说明去除误解部分。对于团队：
开发人员在开始处理任务之前进行知识交换。无论估计数量是增加还是减少，需求都更加明确，估计更客观。因为您仍然不知道谁负责这项任务，所以估算过程可以客观地实现，并且在团队一致的情况下，您知道谁在这个过程中熟悉这个任务。实际操作时，您可以基于这些资讯配对编程或知道向谁寻求帮助。本文提出的解决方案是一种常见的解决方案。重点不在于形式，而是在敏捷估计过程中每个环节的设计目的，以解决什么样的问题。最后，敏捷估计只是：估计。不是滴血为誓。
微信扫一扫打赏
支付宝扫一扫打赏
