哈Ha！我叫Artyom，是Skyeng的团队负责人。我的开发团队有一个客户，他是产品经理，他只是Vanya。Vanya认为我们的任务评估方案并不理想。例如，一个2天的成绩不会给他任何东西。他将在一周或十天甚至更长的时间内在产品上看到他的任务。或更少。
这不是因为我们失败了任务，而是因为实际上使用传统的Estimate，我们只评估开发人员编写代码的时间。但是仍然有测试和代码审查。好的，我们将其全部纳入评估。但是也：
- 在开发和测试之前，我们有一个队列，
- 有进步，我们并非没有罪，
- 紧急任务飞入
- 当实施影响几个服务时，我们期望相关团队进行审核。
如何学习回答“何时”问题。，如果没有可预测性？
我们如何质疑估算
就像公司中的许多人一样，在我们的团队中，有一个非常有用的会议-技术评审（或简称为tehrevyu）。它需要大量的时间和精力，但是却增加了可预测性：我们为问题预涂了技术解决方案，同时对其进行了评估。
由于我们始终处于远程状态，因此JIRA中的所有事情都会发生：在一块板上可以看到工作阶段。在我们描述并评估了所有内容之后，该卡即离开了“技术评论”状态，并移至“准备开发”状态。正是在这一刻，我们致力于完成工作。
“开发就绪”有一个在制品限制-一次最多只能完成8个任务。还有一条相反的规则：只要某列中的任务很少，我们就会启动新的技术审查。
事实：我们花费大量时间进行评估。技术评审通常每周进行两次；详细说明和评估的4项任务可能需要1.5到3个小时。但！然后，我们仍然可以花时间找出为什么超出了估算值。
但是，评级和汇报都无法为我们的产品增值。相反，我们在浪费时间。还有钱 很长时间以来，我对这些程序的必要性表示怀疑，并且有一段时间，我逐渐与产品进行了认真的交谈。我们俩都意识到了这个问题。
“衬衫完全干了……”不是XS
决定：让我们尝试评估方法。我建议坚持使用T恤尺寸-这种技术将T恤尺寸用作度量单位。您需要找到必须做的最小任务，并将其误认为XS。之后，将根据“ XS大多少”来评估剩余的任务-并据此为它们分配大小S，M，L或XL。
贿赂机会以“肉眼看”的方式进行评估。这个想法很简单：我们将收集开发完成一个或另一个维度的任务所需的统计数据，计算平均值并能够预测时间。
客户可以原谅一两天的错误-这意味着不再需要汇报。而且您不必花时间在技术评论和互动投票上。一切都很顺利！
我们已经以这种方式工作了几个月，收集了统计数据。只有伊万对我们ask之以鼻。
事实证明，XS和S一样，我们在1天之内完成，然后在10天完成。在L上，我们花费5或15天。因为实际上我们先进行一些工作，然后再进行一些工作，然后再进行第五次工作-并且相同维度的任务在等待状态下花费的时间不同。糟糕，这里有中间人。
简而言之，这里的分散时间不是几天-对于Vani来说，变化不大。我们发现实验没有成功，但是仍然可以以某种方式对任务进行分类的想法一直困扰着我。我开始朝这个方向进一步思考。
“每个人都喜欢蛋糕。吹！” 史瑞克的驴
我爱。另外，孩子的生日是个好机会！我转到我最喜欢的网站并开始选择：
- 有可能，但不可能，
- 您可以装饰，但不能装饰，
- 可能是2公斤，也可能是5公斤。
我不会透露自己的口味偏好，但我选择了一块蛋糕。他们把他带到了约定的日期。接下来是吃了太多蛋糕的团队负责人的哲学。
当然，我不是牛顿，蛋糕也不是苹果，但是灵感就来了。
我可以从许多选项中选择，但是无论我选择什么，交货日期都没有改变。我一个星期需要蛋糕。我已经准备提供这项服务。蛋糕的大小，重量以及各种钟声都没有太大影响最终结果-更确切地说，在这种情况下，根本没有影响。正如他们所说，这与大小无关。在什么呢？在价格上。
例如，这些家伙有一个明确的命令：要多花些钱，他们会在短短几天内（而不是在5天之内）给我带来相同的花式蛋糕。我的命令是与其他人相比最有价值的命令。基本上，面包店有两个SLA：一个用于常规订购，另一个用于VIP。有一些事情要考虑。
触发SLA的想法是因为我在《看板指南》中阅读了有关它的内容
从看板方法的角度来看，一切都是服务。尽管我们不提供蛋糕，并且无法感觉或食用我们的产品，但开发也是一种服务。而且我们也以不同的方式对待任务。
回想一下我们的董事会：
服务包括几个阶段（开发，代码审查，测试），“准备开发”一栏是我们对客户的承诺。
我们按照通常的节奏做一些事情，但是当刻录任务到达时，我们放弃了一切。有待了解我们拥有什么SLA，并且有可能与Vanya达成协议。
如何评估团队的SLA：建立光谱图（简单）
为了了解我们拥有哪些服务等级以及它们拥有哪些SLA，看板建议构建以下时间表：
- Lead Time (LT) — . « » «».
- Y — LT1, LT2, LT3 ..
我们接受了过去几个月中关闭的任务，并收到以下信息：
我们一天完成3项任务，每2项完成6项，大部分完成5项，并且在某个地方我们为该任务苦苦挣扎了两个多星期...
好了，现在该分析一下了。这些任务是什么？他们为什么到这里来？为什么我们在某些LT中比在其他LT中做更多的事情？您可以深入研究客户和表演者，以及研究对任务的评论。
这就是我们要挖掘的东西。这是我们的常规工作。
差异很大，但是可以进行分析。
通常，大部分任务是在7-14天的时间间隔内分发的，并且有几架飞机飞得很远-在这条尾巴中，有几项（不是全部）从PR到其他服务的任务。在3-4天之内完成的那些任务是例外，而不是规则。
, , , 75% 10 .
并且有90％的概率，将需要14天。好吧，如果开发影响到公司的其他服务，您将不得不等待更长的时间-我们需要另一个团队的代码审查，然后是另一个部署。
让我们走得更远。我们将此类称为“重要”。
由于某些原因，这些任务比其他任务更早地工作：价值更高，或者延迟成本更高。
在这里，我们还可以表达SLA：以75％的概率在5天内售出任务，在7天以90％的概率售出任务。让我们继续吗？
我们放弃一切而看见，看见，看见的任务就是阻碍者。
在100％的情况下，这些是次要的改进，在实现主要功能时我们没有考虑到这些改进，或者是影响生产中至关重要功能的错误。
尽管我们设法在2天之内解决了所有此类情况，但我们仍将宣布第90个百分位。首先，您不应该承诺100％-绝不向任何人承诺：)其次，您需要设置可变性：请记住正常工作的情况，因为在20天内，有几项任务消失了，因为这依赖于其他团队。
做完了！我们可以就所有服务等级与Vanya达成SLA协议：
就条款而言，我们选择了恰好90％的客户-实际上，这是客户对违规行为的容忍度。也就是说，如果10个任务中有1个不适合SLA，我们准备原谅。
如果您的客户不是那么友善，例如最好说第95个百分点。
而不是结论
-是什么阻止Vanya仅招募重要任务或阻止者？
-水平在制品限制。
我们同意对服务类中的任务数量进行限制：您不能接受两个以上的阻止程序，您不能接受两个以上的重要任务。您可能还有其他号码-这是与客户达成协议的问题。没有插件就无法在JIRA中设置此类限制，因此绝对需要口头协议。工具是工具，但是没有人的参与，无处不在。
感谢您的关注和成功的计划！