TIP
本文主要是介绍 研发效能提升-进度看板(2) 。
# 从看板方法说提升研发效能
# 1.从看板三原则说起
看板方法公认是各种转型导入最小侵入性的方法，它尽量不改变价值流、工作角色和职责的现状，具有很强的暴露问题和提示改进机会的能力，能有效提高组织在整个价值流上的关注程度和整体研发效能。
# 可视化
工作可视化实现信息透明和信息共享，并将规则显式化。
不要把信息隐藏在“信息冰箱”，电子工具需要你知道这个入口，需要去找到它，一般情况下，如果不是分布式团队的话，都会推荐从物理看板入手，根本原因是如果你不能看到，你就不能改进，看到就是战斗的一半。
# 限制在制品（停止启动，聚焦完成）
使用可视化技术明确工作项中的限制。我们需要选择一个最大值来限制能同时开展的工作数量。这个限制将帮助我们将焦点放在工作的完成和帮助工作快速流动上。
在制品不仅仅是指并行的工作项数量，只考虑并行工作数量是一种简化方式。
- 尚未实现的需求规格说明
已经编写但被搁置起来等待实现的规格说明是你的在制品。
- 未被集成的代码
频繁签入并集成代码是个好办法，这样避免累计过多的集成工作，并能对当前工作的质量获得快速反馈。
- 未测试的代码
在软件开发领域，未测试的代码是在制品的另一表现形式。编码但没有一个快速的方式证明它是否工作，这是构建未完成工作堆的“绝佳”途径。
- 尚未发布的代码
生产环境的代码也可能是在制品，代码上了生产环境并不一定是说明就“完成”了。用户是否接收到这些特性，他们是否从中受益，软件是否实现了所期望的（商业）影响。如果用户的行为并没有被影响，能说真正完成了吗？
限制在制品能够帮你应对最开始提出的一些挑战。首先，工作将开始流动，因此不用时时监视大家的工作。当工作在整个系统中以稳定的速度进行时，准确地评估和预测就不再需要了。第二，不会再有被工作淹没的感觉，因为现在已经有了你能同时开展工作的上限。如果要新加一个新的工作进来，他需要决定把某项工作替换掉。
通过设置在制品限制，将在工作流中创造些许紧张，它能暴露系统中的问题，或者未曾意识到的改善机会。限制在制品将把改进的机会呈现在表面。通过工作流观察，流动可能迟滞（即时贴在白板上的移动非常缓慢），可能积压（在某列中有很多即时贴），也可能完全停止（工作项一直等待）。这些都可以作为你改进整个系统的指标。你用于解决这些问题的做法，取决于是否带来了改善。
在制品过高会导致上下文切换（多项工作之间的切换），延迟带来额外的工作，减慢反馈圈，质量下降，增加风险，团队会缺少动力。
在制品规模过低导致大量人员闲置，这对降低前置时间虽然有好处，但大多数公司可能不会愿意给无所事事的人员支付薪水。
需要在这两者之间进行平衡（总的来说过低比过高好）：快速流动和每个人都有工作。这个需要团队自己决定并且不断调整以便于达到持续向好的趋势和更快速的流动。
在制品限制不是一个严格的规定，它是用来引发讨论的，能促使改进机会浮出水面，（回顾会议）。只有有限资源的环节或者你希望将等待和进行中的区别可视化出来的地方，可以在看板上加入缓冲区（等待列），比如有固定上线点的。
对每一列设置单独的在制品限制，如果不知道限制多少，可以由团队决定一个数字先开始，看板会逐步显现问题，然后进行调整即可。
# 管理流动（从工作进入团队到离开团队）
“一件出去，一件进来”，由在制品（WIP）驱动，是一个持续流动的状态，理论上看板的样子几乎是一成不变的。看板对应的是流程，不必非得是一个团队。前置时间是看板上一个任务从开始到结束需要的时间，前置时间可以预测团队交付能力，从而做出相对合理的发布计划。看板通过可视化流动，经过不断调整，从而改进价值流。持续的流动才能提供价值，流动可以消除浪费。
促使工作快速流动起来，可以做很多事情来达到这个要求。当基于这一原则开展工作时，可以从精益思想中找到灵感来消除过程中的浪费以便工作能够顺畅流动起来。也可以浏览一下约束理论，并尝试识别、拓宽和缓解系统中的瓶颈。从敏捷软件开发运动中产生的实践可以帮助你提升协作和质量，从而改进系统的流动。到底选择哪条路改进你的系统完全取决于你。最重要的一点是当你的工作向你发出改进信号时，你要响应并改善它。
在实际中，三个原则其实是互相关联的。如，为了取得工作的快速流动，你设置了限制，并且把它可视化在看板上。
下面是一个简单的流动例子：
上面的白板展示了这样一种情况：开发人员（Development列）和分析人员（Analysis列）正被阻止开展任何新工作（在制品数量已到最高限制），这种情况会持续直到测试人员空出了一个卡片位置并将下一个工作项拉到测试步骤中。这种情况下，开发人员和分析人员要跟团队一起开始寻找能够帮助测试人员减轻负担的方法。
注意，Development列和Analysis列被细分成了两列，这是为了用来说明正在进行中的项与哪些已经完成并准备好被下游工序拉走的项。也可以用一些不同的方式来布局白板。一旦测试人员完成了一个特性的测试，就会将卡片移走，并且在Test列空闲出一个卡片位置。
现在，Test列中空出来的位置可以用开发Done列中的一个卡片补充进来。这时，Development列就会空闲出一个卡片位置，下一张卡片就可以从Analysis列中拉进来，其他列也是这样。
瓶颈的影响：
一个软件开发的流程可以看作是一段自来水管道，特性需求从一端进入，经过改进的软件从另一端涌现出来。
在管道内部，存在着各种各样的工序在管道中的瓶颈会限制工作的流动。管道的整体吞吐量被限制为瓶颈的吞吐量。
用我们的开发管道为例：如果测试人员每周只能测试5个特性，而开发人员和分析人员每周能够生产10个特性，整个管道的吞吐量就只有每周5个特性 ，因为测试人员扮演了瓶颈角色。如果分析人员和开发人员不知道测试人员是瓶颈，那么测试人员的待办工作就会越堆积越多。
影响就是前置时间增加。并且，就如同库存一样，位于管道中的工作会套牢投入的资金、产生与市场的距离、以及随着时间逐渐失去价值。
最终，影响到质量。为了能够跟上进度，测试人员开始抄近路。最终bug被发布到产品中，导致给用户带来问题，从而影响未来的管道产能。
# 2. 度量
度量本身并不重要，其目的是为了指导改进。度量指标帮助你知道自己是否在改进。
利特尔法则
平均前置时间leadtime =在制品数量wip/平均吞吐率throughput
L=W/R
前置时间是一个工作项从开始到结束用的时间。
吞吐量是一定时间段内团队完成的工作项计数。
可以看到，限制在制品，提升团队吞吐率，可以缩短平均前置时间。平均前置时间缩短，则能提升团队交付频率，加快反馈循环，提高团队研发效能。
度量指标就像是对流程的健康状况的可视化，常用的看板度量指标有：
周期时间（研发时效）：完成部分流程所需的时间；
前置时间（交付时效）：完成全部流程所需的时间；
吞吐量：每周（或每月）完成工作项（故事）数量；
看板上的问题和阻碍的个数；
价值需求和失效需求的对比：因为系统的某个错误而导致的需求，或者为满足客户价值而做的需求。
# 3. 持续改进才是根本目的
有一句话叫只工作不玩耍，聪明孩子也变傻，看板最终会变得无聊乏味，只有排成队的工作项，而没有自然的中断、庆祝活动或者节奏，所以需要建立持续改进的团队节奏：
比如：建立庆祝节奏，利用回顾会议或者评审showcase会议举行轻松的团队聚会，定期的技术分享形成团队学习文化；尝试时间盒：定期的缓冲时间盒处理技术债务或者技术研习等。
建立持续改进的节奏，聚焦流动效率，根据团队能力拉入需求，改善协作，提升整体研发效能。
# 参考文章
- https://www.jianshu.com/p/eadf6fbd1b0f
