devops - 工作流

2.1使工作可见

在制造业的价值流中,工作在不同工作中心间的转移通常是显而易见并且缓慢的,因为必须真正地转移库存产品。

技术工作的流转通过单击一次鼠标就可以完成,譬如将工单重新指派给另一个团队。由于点击的操作太过容易,所以不同团队可能会因为信息不完整而将工作“踢来踢去”，存在的问题也会被传递到下游工序,而这些问题完全是不易察觉的,直到无法按时向客户交付产品,或者应用程序在生产环境中出了问题。

为了能识别工作在哪里流动、排队或停滞,就需要将工作尽可能地可视化。

通过将每个工作中心的所有工作都放进队列中,并且可视化地展示出来,利益干系人更容易从全局目标出发,确定各项工作的优先级。这样,每个工作中心都能采用单任务的处理方式,从优先级最高的任务开始,依次完成所有工作,以增加工作中心的吞吐量。

2.2 限制在制品数

制造业的日常工作通常是由生产计划决定的,根据客户订单货日期、交货日期、零件库存等条件,确定执行哪些任务。（相对应自己的工作，应该由任务的日期，完成时间，资源等条件决定）

生产中断在制造业里很显眼,且代价极高,当正进行中的工作戛然而止时,所有的半成品都将报废,然后再启动一批新作业。这种高昂的代价,让人们不希望中断频繁发生。

但是技术工作者很容易被打断,因为对所有人而言,这个中断的后果似乎是不可见的,即便它对生产效率的影响比制造业更甚。例如,将一个工程师同时分配到多个项目里,他不得不在多个任务、认知规则和目标之间来回切换,付出重新进入角色的成本。

研究表明,即便是完成简单任务,如将各种几何形状分类,当同时执行多个任务时,效率也会显著降低。从认知上看,技术价值流中的工作,显然要比分类几何形状复杂得多,所以多任务会导致更长的处理时间。

当使用看板管理工作时,可以限制多任务的出现,例如对看板的每一列或每个工作中心设置在制品数量的限制,并把卡片数量的上限标记在每一列上。

例如,将测试工作的在制品数量上限设置为3。当测试队列中已有3张卡片时,除非某张卡片完成了,或将3张中的一张退回到前一个队列(左侧的那一列),否则禁止添加新卡片。另外,在把一项工作用卡片的形式显示在看板上之前,任何与之相关的工作都不能开展,这强调了任何工作都必须可视化。

Dominica DeGrandis是在 DevOps中运用看板的专家之一,他指出:“控制队列的长度(即在制品数)是一个非常强大的管理工具,因为这是影响前置时间的重要因素之一对于大多数的工作条目而言,在它们完成以前,其实并无法预测到底需要多长时间。”

通过限制在制品数,还能更容易地发现工作中的阻碍。例如,当限制在制品时,可能会发现居然没什么工作可干的,因为要等待其他人。虽然进行一项新工作(即“干点什么总比什么都不干强”)可能很诱人,但此时更好的做法是查明导致等待的原因,并协助解决那个等待的问题。实际上,糟糕的多任务处理发生的原因,通常是同时给一个人分配多个项目,造成了很多优先级冲突问题。

正如《看板方法:科技企业渐进变革成功之道》的作者 David j.Anderson所说:“停止开始,开始结束。”

2.3减小批量大小

大批量代表的是一次的开发目标比较大，完成多种功能，所以在单独开发的环节就需要较长的时间，其他工序也是在等待的状态，另外，大批量的内容较多，把力量分散在各个功能，当后面工序，如测试发现问题，将会发现难于调整。

相反，小批量代表把大的开发目标分解可逐步完成的若干小目标，面对每一个小目标，开发就可以聚焦更多的资源在一个小目标上，确保目标的完成质量和完成速度，后续部门发现的问题也更容易解决，因为小目标相对来说的轻量化，初步的小目标完成后，后续的目标在这个基础上，不断添砖加瓦，因为初步的架构是良好的（如一个大目标同时开发，会出现赶工的情况，导致走捷径，影响架构稳定），便于加功能，功能形成模块化，符合管理便利的目标。

大批量开发出所有功能后的时间太长，可能真正投入生产时，功能已经没用。小批量可以不断将开发出来的功能投入到生产，而且可以将需要的功能不断投入开发，更符合经济效益。

2.4减少交接次数

队列等待时间会随着交接次数的增加而延长,因为队列是由于交接而产生的。图A2显示了个工作中心资源的繁忙程度与等待时间的关系。渐变的曲线显示了为什么“一个30分钟的简单变更”通常却需要几周的时间才能完成。某些工程师和项目组若过于繁忙,通常就会变成瓶颈当一个项目组满负荷时,任何需要它完成的任务都会被淹没在队列里,如果没有人进行催促或提高优先级,该任务将永远也不能完成。

在图A2中,横坐标表示在一个项目组里某特定资源的繁忙百分比,纵坐标是等待时间(或
者更准确地说是队列长度)曲线的形状表明,在资源利用率超过80%以后,等待时间会急速攀升到顶点。

《凤凰项目》一书描写了比尔和他的团队是如何意识到这个关系对他们向项目管理部门承诺的交付周期产生了灾难性的影响的。

我告诉他们,埃瑞克在MRP对我说过,等待时间取决于资源使用率。“等待时间是‘忙碌时间百分比’除以‘空闲时间百分比’。也就是说,如果一个资源的忙碌时间是50%,那么它的空闲时间也是50%。等待时间就是50%除以50%,也就是一个时间单位。就说是一小时吧。所以平均来说,一个任务在处理前的排队等待时间为一小时。
如果一个资源90%的时间是忙碌的,等待时间就是‘90%除以10%’,也就是9小时。换言之,我们的任务排队等待的时间,将是资源有50%空闲时的9倍。”
我得出结论:“因此,对这个凤凰任务来说,假设我们有7个交接步骤,而且每一个资源都有90%的时间是忙碌的,那么任务排队等待的总时间就是9小时乘以7……
什么?只是排队等待的时间就要63小时?”韦斯仍然一副难以置信的表情,“这不可能!”
帕蒂似笑非笑地说:“哦,是啊。因为输入字符只需要30秒,对不对?

2.5持续识别和改善约束点

为了缩短前置时间、提高吞吐量,我们需要不断地识别系统中的约束点,提高工作产能。
drat博土在 Beyond the Goal一书中提到:“在任何价值流中,总是有一个流动方向、一个
束点,任何不针对此约束点而做的优化都是假象。”如果我们优化约束点之前的那个工作中心那么工作必将在这个约束点上更快地积压起来。

反之,如果优化约束点之后的工作中心,那么它还会处于饥饿状态,等待约束点处工作的结
束。对于这种现象, Goldratt博士给出了解决方案,定义了如下“5个关键步骤”：

第一步，找出系统中存在哪些约束。

第二步，寻找突破（Exploit）这些约束的办法。

第三步，使企业的所有其他活动服从于第二步中提出的各种措施。

第四步，具体实施第二步中提出的措施，使第一步中找出的约束环节不再是企业的约束。

第五步，回到步骤1，别让惰性成为约束，持续不断地改善。