精益看板核心实践大作战 - 看板管理知识

摘要：通常一个迭代的状态墙上反映了某一个迭代的计划和任务进展情况。状态墙上按照一个迭代内团队的典型开发活动分成几栏，例如“待开发”、“开发中”、“待测试”、“测试中”、“测试完成”等。

通常一个迭代的状态墙上反映了某一个迭代的计划和任务进展情况。状态墙上按照一个迭代内团队的典型开发活动分成几栏，例如“待开发”、“开发中”、“待测试”、“测试中”、“测试完成”等。在一个迭代之初，我们会将计划在本迭代完成的故事卡放到“待开发”这一栏中。可视化状态墙的一个好处就是所有团队成员都可以实时地了解到本迭代的计划和进展情况。开发人员领取任务时，就将他领取的故事卡片从“待开发”移到“开发中”，同时贴上带有自己名字的小纸条。当他开发完成之后，就将故事卡片移到“待测试”一栏。我们的测试人员看到这一栏里有待测的故事卡时，就取下一张，移动到“测试中”，开始这个用户故事的测试，测试完成后，就将故事卡移动到“测试完成”一栏。如果测试人员发现了一个bug，那么他可以用红颜色的卡片记下这个bug，然后放到待开发这一栏中。在状态墙上，除了用户故事、bug之外，还会有一些诸如重构、搭建测试环境这样的不直接产生业务价值的任务，这三类任务用不同颜色的卡片，放到状态墙上统一管理。
这样一个简单的工具，是如何帮助我们消除浪费、解决项目管理中的问题的？让我们逐条分析一下看看。

2.1 如何减少返工带来的浪费
返工是软件开发过程中的一大严重浪费。比如说开发人员开发完成的任务交给测试人员测试的时候，关键流程不能走通，阻碍了测试进程；交付给客户的东西被客户说“这不是我想要的东西”；分析人员将还没分析透彻的任务交给开发人员，在最后验收的时候发现开发人员加入了自己的一些“发挥”。这些都会造成返工。返工意味着没有一次性将事情做对，意味着流程中的上游没有交付高质量的工作，也可能意味着团队成员间的沟通出了问题。

在传统的瀑布流程中，我们往往是期望通过前期细致入微的工作来确保一个阶段的工作被高质量完成之后才移交到下一阶段。后来我们慢慢从失败的经验中学习到，这种方法在变化的需求环境下实在是太过脆弱，不仅不能如愿保证质量，而且会造成更大的浪费，交付周期也不能满足要求。于是我们引入了迭代式开发方法，一个需求的分析、开发、测试、验收成了一个小粒度地更连续的过程，在这个小的交付循环中，看板帮助我们以更细节的粒度来管理一个任务每个阶段的工作质量。
通常我们是这么做的。当我们把一张故事卡从“待开发”移动到“开发中”时，这张卡片必须是已经分析完成的。也就是说，当开发人员准备真正开始开发这张故事卡之前，我们的需求分析师们必须保证这张卡片所包含的所有内容和细节已经被分析完成，不再有模棱两可的细节，不再留给开发人员过多的自我发挥和想象空间，而且这些细节必须和客户确认过，而不只是团队自己“设计”的结果。

这一道关看似很寻常，实际上很多项目会在这里出问题。很多时候开发人员开始开发的时候，需求还没有分析完成，很多细节尚须澄清确认，实现上的技术风险还没有被完全排除。也有的分析师善于给开发人员留有大量自我发挥空间，需求过于言简意赅。开发人员开始开发这样的需求时，要么做不下去，要么按照自己的理解做下去。做完了之后分析师一看发现不对，和我想的不一样，于是开发人员返工。最糟糕的情形莫过于最后被客户发现说，这不是我当初想要的东西。
由此可见，确保开发人员挪卡的时候，这张待开发的用户故事已经被真正分析完成，是我们准确实现用户需求的第一步。通过规定这一挪卡的前提，同时辅以用户故事的澄清（由分析师向开发人员澄清）或者反向澄清（由开发人员向分析师讲述自己的理解），可以很大程度上将返工减少到最低。

还有一种浪费发生在测试过程中。测试人员经常会发现，处于“待测试”状态中的一些故事卡，在测试的时候主要的流程都走不通，根本无法进一步展开测试，于是乎不得不将故事卡
打回到开发人员手中。而往往这个时候开发人员已经工作在另一个用户故事上了。要么他停下手中的任务解决测试的问题，要么让测试人员等到这些问题修复过后再测。无论哪种都是不好的选择。

这种问题的一个主要原因是因为开发人员声称他已经“开发完成”，将故事卡从“开发中”挪到“待测试”时，实际上自己并没有对这部分功能进行测试。或者是因为疏忽，或者是因为懒惰，或者是因为过于自信。通过在这个状态转换阶段引入用户故事初验，让分析师在挪卡之前先到开发人员机器上看看是否该故事卡包含的功能被实现了，可以很大程度上提升效率，减少浪费。若分析师在初验过程中发现了问题，那么开发人员马上能以最小的成本进行修复，而不用等到之后测试人员发现时再来修复。而且，分析师初验也提供了一个判断实现是否良好的反馈点，这是我们能够看到一个需求是否被实现并能够真正工作的最早的时间点。

2.2 如何避免多任务并行

多任务之间的频繁切换是一个常见的问题。表现在团队里的成员，特别是开发人员，会在不同的任务间切换。就像前面的故事中提到的，可能这一刻还在实现某一个需求，而下一刻马上就会被叫走去修复某一个遗留版本的缺陷。又或者该人手头被分配了多个任务，每个任务都在进行中，而没有一个处于完成状态。任务切换是导致效率降低的一个重要原因，不同任务间的上下文的切换会导致频繁地将任务当前状态在头脑中“压栈”和“出栈”，这些操作会耗费时间。如果完成一个任务需要一个人一天时间，那么两天内这个人可以完成两个任务，但是如果他在第一天同时开始并行工作在这两个任务上，那么完成这两个任务会需要大于两天的时间。

大家可能已经注意到了，在前面的看板图中，处于“开发中”的所有任务卡片上都有一个小纸条，上面标记着正在这张卡片上工作的人的名字。如果说有两个人结对在一个卡片上工作，那么这张卡片上应该有两个名字。这一小小的实践可以帮助我们随时发现团队内某一时刻，是否每个人只工作在一个任务上。

联系人：	阿道
电话：	17762006160
地址：	青岛市黄岛区长江西路118号青铁广场18楼