精益思想和软件开发

在现在的快速和敏捷软件开发中已经使用了很多的精益思想，比如准时制生产，看板管理，TQM，零缺陷，团队和并行工程等都可以在敏捷软件开发中找到影子。前面我写过TPS和项目管理，而这篇重点描述TPS和软件开发。

整洁和明亮的办公环境是很重要的，好的环境产生好的心情，好的心情产生高质量的产品。而敏捷开发强调的办公环境都需要为高效沟通服务，办公是集中办公，办公位之间最好是没有阻隔板等开放环境。墙面预留来做看板和状态管理，有个1-2个专门的小会议室方面2-3个人下范围的进行问题的讨论和评审。工作时间每个人最好能够专注，不受太多外界的干扰，只有休息和工作时间完全分开才可能高效率产生高质量的产品。

精益里面的看板管理在敏捷软件开发中有明显的体现，比如用户故事墙，贴在白板上的小纸条(TODO,DOING,DONE)，涉及进度的S曲线等。这一切都是为了进度在整个团队是可视化的。只有明确知道你现在的位置和偏差，才知道如何改进以达到目标。在这里我们推荐的仍然是基于特征值和功能点的快速迭代开发模式，FDD特征驱动开发应该成为后续快速软件开发的主流。

在敏捷和极限编程中的测试驱动开发TDD应该是精益思想中关于拉式生产很好的体现。同时我们基于用户场景和Story进行的用例驱动开发也是拉动生产很好的体现。首先针对用户需求我们会编写UserStory，而在UserStory出来后我们不会先开始设计和编码工作，而是要通过编写测试代码来驱动开发，同时也驱动对需求的检验和细化。

说到交付能力，一定会提及到精益思想和柔性生产里面谈到的小批量和多批次的概念。我们的交付需要进行多次交付，使用户能够尽快的拿到他们需要的产品。而要做到尽早的交付，并非所有功能都全面完成了才交付就引入了迭代开发和持续集成必须要引入到我们现在的软件开发中，每一次迭代都是可以向用户独立交付的产品。所以也可以讲：

准时化开发 = 持续集成 + 迭代开发 + 多次交付。
零库存 = 用户故事驱动 + 每次提交都不产生半成品。

根据软件开发的生命周期模型，一个功能的开发需要经过需求，设计，编码和测试等多个工作单元或工序。在精益思想里面的自主工作单元就强调产品能够一件一件的生产，各工序的工作人员都能够一起工作而且工序之间没有库存。在软件开发中，上下游各个环境的密切配合就显得更加重要的，工序之间有库存说明了在整个流水线中存在了瓶颈，整个开发生产线是没有达到一种最优的。因此在快速软件开发中我们必须要考虑上下游角色之间如何更好的衔接，工序之间如何减少等待和浪费等问题。

 

丰田生产方式（Toyota Production System，TPS）中用来支持非集中“拉动式”生产控制（non-centralized "pull" production control）而使用的卡片。作为精益生产的工具，它现在已经应用于世界各地的制造企业之中。如今在敏捷软件开发中，项目的可视化（例如在墙壁上放置任务卡片就是常见的实践）往往被叫做“软件看板”，或者“任务看板”。

软件开发中的看板

现在，让我们将视线回到我们自己的工作领域——软件开发。在敏捷软件开发中，通过在项目工作场所的墙上张贴卡片来呈现和分享项目状态已经成为一种常见的实践。我已经在我的上一篇InfoQ文章《用“看板图”实现敏捷项目的可视化》[Hiranabe07]给出了很多例子。特别是，贴在墙上用来展示当前项目状态的任务卡片有时也被称作“任务看板”或者“软件看板”[Poppendieck03]。图5是Change Vision公司的JUDE6开发团队所用的任务看板。

图5 敏捷看板

在面板上，工程任务用卡片（即时贴）来代表，并通过把卡片贴在在面板中的不同区域来象征任务的状态，这些区域被标注为“ToDo”、“Doing”和“Done”（标注的名称可能因地而异，比如“进行中（In Progress）”、“已测试（Tested）”、“已验收（Accepted）”、“停滞中（Blocking）”等等。）。这样的看板面板有利于可视化地通知任务并限制在制品（处理中的任务）数量。不过在这里并没有出现“工序”（上游或者下游），新出现的概念是“迭代”。对于每一次迭代，通过分解用户故事识别出任务，并且将其张贴在面板的ToDo区域中。

这是一个拉动式系统吗？在制造业中，零部件由上游工序传递至下游工序。而在图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中的“敏捷看板”（在当今敏捷项目中随处可见）仅仅可以看到价值流中的一个子流。当你考虑从客户到客户的完整价值流，经常由处于同一流中的某个团队递交给你需求，而另一个团队则交付你的工作结果给客户。这篇文章的目的之一，就是要设法让看板的应用超越“敏捷看板”，扩大看板在价值流中的应用范围。

Scrum of Scrum 其实也是一种精益方法，不比看板差。

作者：mysqlx

来源：https://www.cnblogs.com/hzci/archive/2011/12/12/2285195.html