业务特性：

1、我们是内部的工具和平台部门，主要的客户群体是面向研发和交付线的同事以及领导们；

在输入队列，任务优先级排序，以及在制品的数量控制上都有一定的自主性，同时我们的交付事务成本和协调成本都很低，对于发布我们做了一键升级，自动化的发布控制和针对产品升级的优化设计（构建队列中的流程在升级后会继续运行，升级对关键特性的流程调度任务没有任何影响）

2、我们从以往的经验和上个迭代统计的数据得到，迭代中的插入任务占比：30%多

3、支撑性和维护工作占比工作量进：30%左右

4、我们有版本迭代和里程碑的固定日期交付任务

看板演进：

起始我以为我们适合scrum的时间盒（其实我自己当时不太了解），就准备用个板子按照书上的所说先做起来，然后慢慢的学习理论加实践来改进

第一次看板：

图丢失只有基本的pool，dev tested，ready，release，c&a基本环节，在设置每个环节上都没有仔细的考量（当时也不懂具体的设计），主要在于先落地实践。

第二次看板：

为什么把code review作为一个独立的流转环节（一是、一个团队成员提议的，也是为了促进大家的积极性减少落地障碍；二是、code review我们也确实认为是一个重要环节和工作）

第三次看板：

改变是 确定了Doing的事务范围，修改流转的环节，团队内达成共识，认为测试前要进行code review。并设定了testing的限额，防止任务挤压（在迭代的第二周发现我们的testing出现大量的挤压，我们只有一名测试人员，需要测试、发布版本、平时的业务支撑，所以限定测试环节的限额，强制减少转入，同时在测试挤压时研发人员介入测试）

第四次看板：

Code Review不作为一个流动环节，制约了任务的流转（一是大家认为每一个需求做一次code review时间上来不及，第二可能也不必要，但是对关键模块全员参与的代码走查带来的价值团队成员都比较认可），而是隐含在具体的事务工作中，此处的code review是做模块级别的代码走查，同时计划引入走查系统针对小的改动直接按单走查（尚未开展），按模块的code review已经达成共识并在试运行了

PS：到这里还不是一个可用或是稍微正确的看板，仅能算作是一个任务跟踪可视化板子

第五次看板：

经刘部的指导，并且也看了些书籍，仔细思考了我们自己的业务模型和工作流方式，在看书和设计看板的工作流转中都做了深入的思考，每一项为什么是这样，工作流投影过来的方式是不是这个样子，我们上个迭代和以往的工作中都有哪些具体的问题等，结合这些问题进而做了下面的这个看板。

通过前面介绍的业务模型，我们确实更加的适合看板这种拉动模式，我们也限定了我们的在制品，具体的一些做法和思考如下：

1、为什么每个人的任务预留是3个？

这个是刘部的指导和最终与大家讨论的结果，很多时候我们每个人手中同时做的任务有多个，太多了会分散大家的注意力，降低开发效率，太少可能因为相互依赖产能不好释放。

2、我们只有一个测试人员，为什么还设置测试中的限额是3，为什么不在测试中前面加一个缓冲待测试？

第一为什么不加缓冲，原因是我们的版本受控库只有一个，既是开发库又是受控库，如果转入测试那么代码一定需提交，此时如果有发布的需求，要封版本，未测试完成合入版本的功能代码回退成本高，并且团队对回退有抵触，不回退又会导致待测队列太长，迟迟无法交付。（研发模式和版本受控方式先不改变，先按既定规则，同时引入下面的方式来提高人员对质量和全流程的关注）

第二为什么只有一个测试人员限额不就是3吗，为什么还要设置为3？ 这个是为后续考虑，因为上一个迭代和以往的工作中我们发现测试这个环节成为瓶颈。敏捷也不推荐按工作类型划分职责角色，但专业的人来做专业的事还是有必要的。我们后面准备把测试的阀值设置为5或6，降低此处的瓶颈，人力从何而来，我们准备从研发人员中每个迭代周期抽调部分人员的部分产能投入到测试中，这样既让大家了解全流程的运作又提高大家对“全流程”质量的认识。

3、为什么已测试队列限额为5？

前面描述了，我们的交付事务成本和交付协调成本很低，如果按照准出规则输出的产品，只需要执行一个发布流程就可以自动的发布版本了，而且是无缝的发布，对用户来说几乎没有影响。

有了这个前提，我们希望尽快的把需求交付出去（交付等待时间越长，变更成本和质量风险就越大，比如看板书中说的一些隐性约束），设置在制品限额为5，当达到限额时就必须封版本，作为一次交付版本。

4、为什么发布这个大项中还有一个已验证的环节？

我们是对内交付，我们的一个需求交付必须得到最终的用户使用和验证后才算一个需求交付最终完成。

第六次看板：

此次的变化时测试中的在制品限制为5，当前虽然还未设置虚拟人的角色，但有部分的功能不通过专职的测试人员来完成。

以上都是任务流转的设置以及简单运作的第一阶段，还有最重要的事，准入准出规则的落地和质量内建的工作。

现在指定了测试准入和准出的规则：

1、进入测试中，比如要保证自测通过，自测说明，单元测试用例

解决办法，加强下一环节对流入的检查，测试覆盖率现在暂不强制

2、测试完成的准出规则，需求维度的测试报告，测试全流程，发布物描述，影响子系统说明

解决办法，完善对版本质量的冒烟测试建设，减少新引入需求导致的重大故障

看板准备增加和优化：

1、服务分类，看板上的最上面一个泳道是固定交付期的任务，也是一个加速泳道

2、发布次数，以及故障统计（每一次发布的故障数）

3、以用户故事为交付维度，下面的是分解任务，任务关联具体的用户故事，对外交付都是故事

4、统计每个用户故事或是任务的实际开发时间，计算准时交付率

未完待续：我们是完整的研发交付流程，在团队看板的演进过程中，看板的空间约束了一些关键价值节点的呈现，下一阶段我们主要是质量内建、关注服务分类，并持续改进的等待下一个阶段的到来。

附这段时间统计的累积流图：