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

这是一个拉动式系统吗？在制造业中，零部件由上游工序传递至下游工序。而在图5所示的敏捷开发中，并没有看到“移交物”。一个看板卡片对应一个任务，上面写明了如下信息：任务编号、任务名称、估计时间以及任务领取人的名字。任务有状态，可以是“ToDo”、“Doing”或者“Done”，状态信息被分享给整个团队。敏捷开发重视在一起工作，并趋向于减少团队内部的移交物。我称此为“敏捷看板”。

图6是另一个看板面板实例，由Yamaha Motor Solution有限公司所采用。

图6 持续看板（Sustaining Kanban）

在这里，看板系统被用于带有流程的传统瀑布开发模型。项目被分解成“设计”、“开发”、“验证”等连续的工序，而看板卡就在这些工序之间移动。每张卡片代表需要修改或者添加的系统需求，也代表给下游工序的移交物。注意这不是一个标准的瀑布流程——标准瀑布流程中所有的需求在同一时间内完成“设计”，而“开发”和“验证”则在另一时间，这将使得所有的卡片作为一个整体进行移动。与标准的瀑布流程不同的是，这个项目中的卡片是一个接一个地移动，就像制造业中的单件流（one-piece-flow）一样。这里表现的是产品生命周期里稳定的“持续（sustaining）”阶段，处在带有流程的瀑布状态转换模型的管理之下。在这里，你可以清楚地看到“工作流程”的概念，而不同于敏捷中的“迭代”概念。它比敏捷看板看起来更像工厂中的看板，而且通过制定规则只允许下游工序移动卡片8，可以使其成为拉动式系统。我称其为“持续看板”，这与稍后章节中讨论的David Anderson的“持续工程的看板系统”是类似的。

图7显示的是另外一个例子——在整个产品开发流程的价值流中使用看板的思想实验（thought experiment）[Poppendieck 07]。

图7 精益+敏捷看板

假设在一个产品开发流中有客户团队、产品所有人、开发团队和QA团队，他们使用队列传递移交物来协调工作，以使得团队之间能异步工作，并维持工作速度。每一个“DONE”空间是一个队列，其工作方式就像制造工厂中的“仓库”那样，并且看起来非常像TPS看板系统。同时，它看起来就像每条工序内同步地使用敏捷看板，而在贯穿各个工序的整个价值流上异步地使用持续看板。我认为看板系统可以扩展至覆盖整个价值流，在这种情况下，它是价值流的一个活生生的视觉表现。

在这里例子中，通过设定每一个区域的大小可以限制在制品的数量。而为了使其变成拉动式系统，还需要一种机制来使下游工序以某种信号通知上游工序开始工作。其中一种方法是制定一个规则只允许下游移动DONE区域中的卡片来通知上游。另一种方法是定期召开“迭代会议”，来同步团队和团队之间传递（通讯）的信息。这两种通讯方式可能对应于我们在第一章节中讨论的零部件领取的两种信号，即领取看板的数量（a）和时间间隔（b）的可视信号。一次迭代中的一组用户故事对应于迭代中托盘里的零部件，而零部件的数量对应于迭代中的项目“生产率”（昨日天气[Beck00]）。我叫它为“精益+敏捷看板”，如下一个例子展示的那样它可以与“敏捷看板”相结合。

图8中是一个小型的“便携式”看板系统，这是我在CENTRAL COMPUTER SERVICES有限公司的某个项目里发现的。在这个项目中，团队被分为了几个小型子团队（通常是一对人）。整个团队有一个与图7概念相似的工作流，还有图8所示的小型敏捷看板面板（ToDo、Doing、DONE）。 当一个子团队选取了一个用户故事，他们将其分解到任务并张贴在便携式看板面板上。在这种情况下，看板系统由两个层面组成，在项目层面一张卡片代表一个用户故事，而在团队（或者结对）层面一张卡片代表一个任务。

他们很喜欢这个便携式小型看板系统，并命名为“看板nano”。

图8 便携式敏捷看板（“看板nano”）

如你所见，将看板的概念应用于软件开发有许多方式。“敏捷看板”用来在团队中分享信息并使工作自导向，但它不支持流程。“持续看板”是另一种类型的看板，能够让小批量的维护工作在几个状态之间流转。这种结合便是“精益+敏捷看板”，使用“持续看板”贯穿价值流，同时在子流（sub-stream）中使用“敏捷看板”。

注意，图5中的“敏捷看板”（在当今敏捷项目中随处可见）仅仅可以看到价值流中的一个子流。当你考虑从客户到客户的完整价值流，经常由处于同一流中的某个团队递交给你需求，而另一个团队则交付你的工作结果给客户。这篇文章的目的之一，就是要设法让看板的应用超越“敏捷看板”，扩大看板在价值流中的应用范围。

生产与开发

软件开发是不同于生产活动或者制造活动的。软件工程师每次创造的产物都是不同的，而制造业总是周而复始的生产相同的东西。所以直接将两者等同起来是危险的。可是，让我们研究一下如何在软件开发看板中找到TPS看板中的特性。表1显示了我们在章节1中总结的看板特性在我们已经提及的两种软件看板中是否仍然有效。

图5所示的敏捷看板例子本身并没有实现“限制在制品的数量”、“连续流通”和“拉动式”特性。敏捷看板更关注于实现任务、“可视化”和“自导向”，以便帮助团队自治并改进其工序。为了使工序连续流通并限制在制品的数量，需要召开“迭代会议”交流信息。

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