🍔 ❄️ 🥫 评分。计算并满足 😖 🧝🏽 👴🏽

截止日期的可预测性在IT项目的开发中起着重要作用。而且由于过程的高度复杂性，任务评估是一个难题，没有明确的算法或简单的计划。在有关评估的交流过程中，业务，项目管理和开发可以说不同的语言，不理解也不想理解彼此的问题和价值观，这使情况更加复杂。结果是“取消订阅”，在上面花了很多精力，但没有带来必要的效果。

对于希望改进并使评估过程更适合自己的开发人员，本文将非常有用。在其中，我将分享已开发的方法，该方法可以使我们与其他部门增进相互了解，并降低我们自己进行评估的努力水平。我们将分析为什么需要估算，如何评估大型任务和分解后的子任务。而且，最重要的是，如何进行这些评估。

演示的视频版本可在此处获得。

好吧，到现在为止。

为什么要给成绩

在每个开发人员的生活中，当“他们”来到我们并要求我们：“什么时候准备好？”时，那不愉快的时刻到来了。“他们”是经理，产品，团队负责人，老板……问题是，为什么这是“他们”？“他们”将如何处理？如果我们理解这一点，我们可以为他们提供所需的确切信息并节省时间。有几种选择，这里是主要的选择。

经理需要评估工作范围（交付，发布，冲刺）：日历时间表及其总量。在这种情况下，重要的是要进行整体评估，而完成每个特定任务并不重要（某个地方花费更多，某个地方花费更少-一般都同意）。将来，其他部门的工作将以此计划，而业务管理的指标也将以此为基础。业务需要可预测性：降低风险和提高可管理性。
. , . /. , , (, , ) . : , - . , . .
( ). , . , : , . , /, , ( ), . (, , ), .

好吧，为什么这个“他们”被拆除了。但是我们需要这个吗？想象一下，您的经理去度假了。永远。这样一来，您一天，两个星期，一个星期就可以安静地坐着工作。没有人需要等级，生活是美好的。你会自我评价吗？

是否给予他们是个人的事情，但这是有根据的。

评估显示了如何完成任务。人脑是一件昂贵的事情，一个人不喜欢思考-这很困难。因此，自然而然地想尽可能少地思考。但是怎么做呢？您可以将活动划分为较窄的活动。我们共享计划和执行：首先考虑方法（在评估过程中），然后切换到执行并考虑执行（在过程中）。
, «» . , — . , () ( ) , . , - .
— . — . , , . . , . 2 . 2 , - , . . , , — . , , — . ( /), . , , : « , !!». , , . ? . «», , . , , — - .
心理影响。如果任务很复杂，则它会在开发过程中发生变化，或者我们对它的了解也会发生变化。如果我们不进行初步评估，则该过程中的任务将充满新的细节，结果我们就没有到达那里-我们不记得为什么。经过几次这样的迭代后，冒名顶替者的头就敲了。而且，如果他们进行了初步评估，其原因将是固定的：他们认为需要5只鹦鹉，但结果却是10只。为什么它是第二个问题，他们对此记忆犹新。而且原因并非总是如此（“开发人员总是无所作为” /“这些产品永远不能无所作为，然后突然出现”）。

因此，我们决定：“我们”和“他们”都需要评估。继续阅读本文是有意义的。

评估目的

猜测任务将花费多长时间是没有用的。您无法确切猜测，如果可以的话，您必须等到您才能可靠地说出来：所以我猜了还是没猜到。在此阶段，没有人对评估感兴趣。

因此，评估不是试图猜测任务将花费多长时间。评估是客户与承包商之间关于框架以及（可能）执行任务的方式之间的协议。

通常，适当的业务没有在特定时间范围内崩溃的任务；业务需要可预测性和风险限制。时间的特点不是程序员的工作速度，而是他投入任务的工作量。您也可以和同事打招呼：如果我得到的任务评估不充分，这是我思考的机会，我们的方法完全一样吗？也许他看到了一种更简单的解决方法？或许恰恰相反，没有注意到大事吗？无论如何，都是检查手表的原因。

评估程序

评估过程的基础是查看业务任务的价值，任务的主要风险和例行程序的数量。然后对它们进行评估，并将其封闭起来：确切地知道它是什么，但它肯定大于X小于Y.当然，我们以必要的准确性对其进行评估（因为确切的估计很昂贵，而且大脑很懒惰）。

任务组成：

- ( ). , . smoke-test . , , , « ». , ! — . , : « - , ».
, - , . «» -. , , ( , , , , ), — .
. - , , - . , ( ). : , , , (, . — - . : ( , , : , , , , ), , , , ( ) , , zero-tolerance , , , -, . , (//), (//).
其他一切。

史诗评估程序

该计划源于任何任务都可以在任何时间完成的事实。当然，这种说法被夸大了，但总体上反映了本质。例如，有一位客户来找我，说：“我想要Facebook。什么时候准备好？” 解决这个问题的最短时间是15分钟。我去facebook，截屏，用截屏图片组成一个页面，将其放到我的服务器上。满足问题的条件。您甚至可以改善实现：不拍张照片，而是与Facebook制作iframe（尽管正如我所料，facebook已经在处理这个问题）由于时间评估确定了完成任务的方式，因此您可以将完成任何任务的时间减少2-3倍（碰巧减少了5倍）。有趣的是，这种经验定律在实践中不断受到检验。

我们将任务分解为子任务。事实证明，就像这张照片（我们称其为“圣诞树”）：水平，及时，垂直地评估任务是优先事项。
我们按优先级对子任务进行排序（首先是业务价值+“负载”，然后是风险，然后是重要性顺序）。
如果需要减少估计数，我们从下面进行调整。我们为什么要减少：某些风险起作用了，而且膨胀或业务价值与他们原本应该的并不完全相同-这些都是重要的事情，没有它们，任务就无法通过。有必要修复它。然后，我们将能够通过执行任务的主要部分进入评估（取决于失败，将完成任务的更大或更小部分）。

任务评估流程

好的，史诗被分解了。以及如何评估特定任务的规模？

如果我们已经完全完成了这项任务。我们在某处有统计数据，花了多少时间完成类似的任务。如果我们不是做某事，而是一个同事，那么我们可以将其结果乘以它与现在和现在之间的差异系数（开发人员，系统知识，风险知识）。我们进入统计，相乘-得到。
. , . , 60%. , 60% , . , — , 1.5-2 .
. R&D. — , . — . (1, 2, 4 ), — . , , . , R&D, 1-2 , R&D . — R&D. - — , , . — N — - ( ). , — , . , , — .

, ( ) , , . , , .
Planning poker. , . : -, , , , -, , ,
(/ ), . . , . , , 70% .
PERT. , (-) 5 . .
min real max
<> 2 8 20 9

— , , — , ( ), — , , ( ).
:

	min	real	max
<>	2	8	20	9

据我所知，系数4和6是根据这样的假设得出的：在一般情况下，风险的概率呈正态分布，并且尾部（最小/最大）的可能性相同。

升入分数的过程

做出评估是成功的一半。最有价值的是进入评估。完成任务的过程是一个积极的过程，参与的最终结果要比一开始就成功猜测的结果更重要。并在完全不同的区域坚持相似的外观。我看到很多情况，在做出评估后，开发人员处于被动位置，“好吧，现在该去哪里-无论发生什么事”，他都会弯腰并顺其自然。现在该采取行动了。

热门的实用技巧：

6. : . — , - , . /, . ( «» - ). , , - . — . . ? N.
«».
, (- + ) — , . 30%.
.
, ( ) . ( ) — , . — , . — , . .
( ). . , , , . , , . « » — 20-30%, 50. . ( ) , , , .

对于初学者来说，可以缩短与任务评估相关的截止日期。例如，在此处进行了更详细的描述，因此，我将不再重复。当应用于评估时，如果对我们来说很重要的是在一段时间内完成任务，那么后果就是必须评估任务并监视点击。即使任务很小，并且交付之前还有很多时间（就像前面提到的开发人员那样，工作量很大，他们不喜欢给出评分）。而且，如果我们不能准确地表示存货是什么（并且我们受到存货庞大且“国家不会变得贫穷”的事实的指导），那么我们将获得不受控制的超额条件。放置哪个缓冲区也没关系：2x，5x，100x-如果您不对其进行管理，则将其全部消耗掉。

结论

使用这种方法，开发人员可以简化和简化评估过程。这样，力的消耗就会减少，压力会减少，最终结果会更好。而且，我们可以给“他们”带来不那么令人惊讶的惊喜，然后我们会发现“他们”开始用“我们”说相同的语言。

评分。计算并满足