将看板应用于软件开发：从敏捷到精益(4)

图6中的“持续看板”不仅可以限制在制品的数量，还可以以“单件（one-piece）”和“拉动式”的方式控制流程，而不需要召开迭代会议。在这种方法中，它的关注点是“限制在制品的数量”、“连续流通”和“拉动式”，同时允许团队（或者管理人员）借其改进工序。

回顾一下图3，我将看板的特性和作用分成图9所示的两个关键区域，以便上面提到的两类软件看板概念的用途各得其所。图10显示了生产和开发的频谱图。生产是成功几率很高（高于99%）的工序，而开发的成功几率要低。当成功几率在50%左右的时候敏捷是理想的开发方法，而当成功几率超过90%的时候瀑布式则是理想的开发方式（依据Shannon理论，一个具有50%成功几率的项目是最有价值的项目）。通常随着开发进入到支持维护状态，修改缺陷和添加新功能的成功几率逐步提高。

看板系统的“工序控制焦点（Process Control Focus）”适合在“高于90%”的成功率下工作，而“工序改进焦点（Process Improvement Focus）”既适合在50%成功率也适合在90%成功率下工作。

值得注意的是，敏捷方法在产品维护状态（sustaining mode ）下仍能工作良好，同样看板的“工序改进焦点”特性也在维护状态下工作良好。

图9 看板的特性和作用（2）

图10 使用看板的方法频谱

KSSE——持续工程的看板系统

接下来，我介绍最近出现的一种软件开发精益应用。Agile2007会议时，我参加了David Anderson主持的关于软件看板的一个会中会（Conference-Within-A-Conference，CWAC）。他在Corbis.com管理着一个“维护状态（maintenance mode）”类型的看板系统，并发表了一篇相关论文——持续工程的看板系统[Anderson 07]。他的方法首先关注于看板的“限制在制品数量”特性——就像在图4所示的抽象图表那样——也关注“自导向”特性以使得团队自组织，减少自上而下的（top-down）管理。然后，通过看板观察流程，找出整个工序流中的驻点（stagnation point）并调整人力资源，也就是在工序间调动成员。这意味着他的方法，像图3表现的那样，涵盖了看板特性中从“限制在制品数量”、“自导向”到“改善”。

会议之后，Anderson启动了一个看板开发邮件列表2，这里已经成为将看板应用于软件开发的一个新兴知识创新讨论社区，名为“KSSE”——持续工程的看板系统，读作Kiss-ee ;-)。Aaron Sanders还着手创建关于看板的知识体系，并已经开始构建KSSE词汇表。

KSSE对于通过队列在工序间传递移交物、连续相接的多个工序运作良好。请注意KSSE不一定需要纳入“迭代”的概念。使用KSSE的方式，我看到了另一种缩放（scaling）敏捷的可能性方式并且好过“scrum of scrums”。[Ladas07]

创造价值流

当通过看板从敏捷放大到精益时，一张看板卡应该代表什么东西呢？

在敏捷看板系统中，一个卡片是一个从“用户故事”中分解出来的“任务”。在开发团队中，它作为工作的一个基本单元执行，因为团队中每个人都能明白它的意思。但是，在看板系统中它贯穿了价值流中的多个工序（多个团队），在其中流转之物应该带有客户认可的价值。既然这样，看板卡片就不是对应于“工作（work）”而是对应于“功能（feature）”，并且它不是WBS（任务分解结构，work breakdown structure）的组成部分，而是FBS（功能分解结构，feature breakdown structure）的组成部分。因此团队中的每个人，甚至是客户，都能够理解看板的含义和流转之物的价值。Jim Highsmith 在《敏捷项目管理（Agile Project Management）》[Highsmith04]书中所概述的原理也将FBS定位高于WBS。

“用户故事”，“Backlog事项”或者“用例”都被抽象为“MMF”（最小可市场化功能，minimum marketable features），用来明确地声明流转之物具有客户价值。于是精益开发就可以说成“使得MMF快速流过整个价值流。”

图5中“敏捷看板”的例子是一个工作的分解，它在团队内部工作良好。图6中“持续看板”的例子是一个功能的分解并且一张卡片代表一个MMF。图7中“精益+敏捷看板”的例子与图8一起展示了上级功能分解和下级工作分解的结合。

一旦建立起工作流程，五个“精益思想”[Womack1996]的核心概念就可直接应用于整个工序。精益工序的管理可以简单地遵循以下原则。

• 从客户的角度定义价值——确定和分类MMF
• 明确价值流并消除浪费——找出驻点（停滞的任务）
• 在客户的拉动下创造价值流——制定看板的拉动规则
• 关注员工并给予一定的权力——授权给在现场的团队
• 追求完美的持续改善——反省和改善

TPS全景视图

以下内容相当于附录，我在这一部分分享从TPS中学到，并发现可以适用于软件开发的知识。Mary和Tom Poppendieck已经发现有效的软件开发方式和精益或者TPS方法有着很多的相同点——不是在实践层面，而是在原理层面上[Poppendieck03, 07]。让我们从更高的角度回过头来再看下TPS中的看板。

读者很容易假定看板是整个TPS的中心，但其实并不是。图11展示了TPS的概念结构，有时也叫做“TPS之屋（TPS House）”。它有好几种版本，图11是基于Toshiko Narusawa和John Shook的版本[Narusawa06]。在TPS中，看板仅仅是“拉动式系统”实现准时制（Just-In-Time9）的一种方法。准时制可以解释为“仅在需要的时候生产和交付所需要的东西，并且仅完成需要的数量”。它直接瞄准的是客户的需要：“尽快以最低的价格提供最高质量的产品。”注意，准时制是TPS的两大支柱之一，另一个是Jidoka10（译注：写作“自动化/自働化”，但其含义与对应于Automation的中文的“自动化”不同，详见注释）。制造业中的“Jidoka”即自动停机（Autonomation）与软件开发中的测试驱动开发类似。Mary和Tom Poppendieck把Jidoka解释为“停止流水线文化（Stop the Line Culture）”。丰田工厂的工人真正地可以停止流水线而不是把次品推到下一个工序——它不仅是一种规定，也是丰田公司的一种文化，它的萌芽可以追溯到（丰田集团创始人）丰田佐吉时期。

原文转自：http://www.ltesting.net