精益看板管理和敏捷软件开发

最近看了InfoQ上关于精益看板在软件开发上的一些实践和应用的文章，敏捷软件开发借鉴了很多TPS精益生产的思想，虽然没有完全提到看板的概念，但是看板在敏捷软件开发实践中是很有必要进行的。

我们都知道看板的重要作用就是把传统的推式生产转变为拉动生产，通过按需生产来减少浪费。对于看板我们一方面需要控制在制品数量，一方面是要考虑整个看板工序形成的流动速率。敏捷利用故事卡做为信息载体，采用拉动的方式组织开发。典型的信息流动过程是这样的：需求=>故事卡=>用户验收测试=>单元测试=>开发，这就是测试驱动开发的过程。故事卡是第一道看板，在开发过程中，看板是以测试的形式存在的，只有在看到失败的测试时才开始编码。故事卡既体现了客户可识别的价值，又组织了团队中所有角色的工作，这就像准时化生产中总装车间的看板（要求生产一件成品的看板）的角色一样，而用户验收测试和单元测试则类似总装之前的各个生产单位的看板。故事卡与功能需求的不同之处就在于，故事卡试图将团队中所有角色（分析，测试，开发）的工作围绕自己在一个迭代中展开，同时在迭代结束的时候完成自己的使命，而功能需求是长期存在的，需要分解转化为故事卡之后才能指导团队的开发工作。因此说，故事卡和测试驱动开发使得软件开发可以通过拉动的方式展开。

我们要意识到在软件开发中的浪费没有所谓的原材料，软件开发最大的浪费就是人力资源的等待已经我们开发完成工件的返工。对于第一个问题我们需要对瓶颈工序进行分析重新配置各工序资源的比例，对于第二个问题则需要引入一直迭代和持续交付的机制。

前面讲到了通过用户故事卡将开发中各个阶段的各个角色有机的串联在一起，同时引入测试驱动开发实现真正的拉式生产。另外就是要通过对故事卡的分类形成多个迭代版本，以实现我们期望的持续集成，迭代开发和多次交付。这是和传统瀑布开发的一个重要区别，敏捷开发强调持续、稳定地完成一个个对用户有价值的，经过集成的可用功能，而不是看是否做完了全部的设计工作，或是试图测量开发人员每天编写了多少行代码、测试人员测了多少个Bug。每个用户故事卡都是独立可以交付的，能够为创造用户价值的功能点。故事卡在由各个看板组成的工序之间流动，故事卡很好的启到了FDD特征驱动开发的作用，产品的完成是迭代的而不是传统的增量模式。

从精益看板到敏捷，除了强调故事卡为核心价值流和信息流的载体，看板管理的核心要素外。我们还需要考虑以下问题以强化对看板的应用。

• 生命周期模型是如何的，工序如何划分
• 如何通过历史生产率确定资源的配置
• 项目的完成进度是否是以各个故事卡的最终完成比例确定的
• 是否对故事卡进行了群和组的划分，以实现迭代交付
• 项目的实际进度和每个成员的在做工作在看板上都能够体现
• 一个是团队总的等待时间，一个是返工时间，如何消除浪费