级别： 初级 Clay Nelson, 技术经理, IBM
2006 年 12 月 14 日 本文来自于 Rational Edge：制造一辆好车和构建一个好的软件有什么关系呢？这篇精益制造的经验总结为我们提供了很多提高潜在的软件供应链的方法，这些供应链是当今所有业务都以之为依赖的。这些精益思维 (Lean Thinking) 的原则提供了一个利用 Rational 来改变软件交付过程的有实际经验且可测量的方法。
为什么 Toyota，世界第二大汽车制造商能够不断稳定发展呢？
1
美国军事机构是如何改善设备维护并突然有一个令人吃惊的15000％的增长呢？
2
同样可以让越来越多有远见的公司消除他们供应链中的无效率成分，取而代之的是向消费者提供了质量更好价格更廉的产品的方法：精益思维。精益思维（也被称作“精益”）是一套革命性的原则，它可以引导我们重新检查我们自己对质量的定义，而不是把目光聚焦在消费者对价值的定义上。
Mary 和 Tom Poppendieck 所著的书 Lean Software Development
3
将面向制造的精益原则转换成软件开发术语。在这篇文章中，我将介绍这些原则并讨论正在指导一些制造者的精益课程是如何能够在软件交付组织中运用的。我还将进一步探究 IBM Rational 统一过程®，或者 RUP®是如何在您的软件开发组织中执行精益步骤需求时提供技术支持的。
生产线中的效率
自从生产线的出现，这个世界的制造业就一直在最好的实践思维中经历着演变和革命。严格控制资源和核心操作的生产力，将产品开发与消费者连接起来，以及提高质量都是企业不懈的目标，这些都是最新最好的实践想要努力实现的。精益思维也是这样一种概念，多年来的发展已经实现了这种管理等级。利用它已经使企业发生了转变，向消费者交付了更高质量的产品和服务，还使 Toyota 成为世界上第二大汽车制造商。精益集中于消除生产供应链中不经济的活动。从价值创造过程一直到产品交付给消费者，根除日本人所说的muda（浪费）是精益的主要针对的目标。这对许多其它制造业的概念来说也同样正确，精益的原则对那些被委派有提高软件交付任务的人来说都是有所启发的。
精益思维的定义
让我们看看什么是精益思维以及它是如何在软件开发中运用的。精益的运动，是由 Toyota 执行官 Taiichi Ohno 发起的，他寻求“做得更多，消耗更少 —— 更少的人力劳动、更少的设备、更少的时间以及更少的空间 —— 可以离他们真正想向消费者提供的产品越来越近。”
4
更具体地说，精益思维主要是消除七种形式的浪费（请看表格1），它们消除在达到“用更少得到更多”目标中不经济的成分。浪费被定义为在完成的产品中没有直接增加价值的活动，而价值则是最终的消费者对产品或者服务的定义。
在软件开发中，消除浪费无疑是个新概念。然而，我们通常对浪费的观点是缺陷和使用后抛弃的设计。精益思维是一种提倡把任何没有在完成的产品中直接增加价值的活动都看作浪费的思维。在这个软件开发的例子中，作者解释 Winston Royce 的观点说“在瀑布式开发模式中，除了分析和编码任何步骤都是多余的。”
5
这句话的实质很显然，是指运用精益思维是为了将验证执行代码所需求的人力降低到最少。的确，我们需要测试和构建管理，但是其它在发展过程中由于技术、沟通和管理局限性的影响而产生的活动和实践也是必然是有害的的。
6
表 1：七种形式的浪费| 生产中的浪费 | 软件开发中的浪费 |
|---|
|
详细目录
| 部分完成的工作；例如：中间工作产品，经常性的文档和计划，没有整合到整合流程中的组分 | |
额外的处理
| 额外的处理；例如，文书工作，状态报告 | |
生产过剩
| 额外的特性；例如：消费者没有利用的功能，并不是在真正必须的，没有增加业务价值。 | |
运输
| 任务转换；例如：同时进行很多项目的工作。 | |
等待
| 等待；例如：等待工作结束，等待一个架构，等待完整的测试结果 | |
移动
| 移动；例如：从一个开发工具移动到另一个 | |
缺陷
| 缺陷；例如：需求，设计，或者代码相关的缺陷 |
为什么要对软件进行精益？
只要业务书架上装满了书，我们就会可以不断地从管理领导者和成功CEO的例子获得新的思想观念。那么是什么使得这个精益的概念有所不同呢？怎样才能概括精益对我们组织积极的影响呢?下面有几种方法：
缩短周期时间。正如它能够大量缩短制造业中的周期时间从而可以在更多的存货周转中运用一样的道理，精益思维也可以加速交付高质量的软件。软件并不能真正意义上等同于存货，但是一个软件构建或者配置组件可能比较类似。它们表现在软件交付供应链中的“物理”层面。在文章接下来的部分，我将讨论精益思维和支持性开发基础架构是如何促使这个软件提高存货周转率的。
高品质的解决方案。获得一个能够满足涉众业务需求的软件解决方案——尤其是当这些需求仍然在增长时——很显然是一个很有挑战性的问题。采用了精益思维和相应的管理系统的组织发现在缩短周期时间和成本的同时还可以交付高品质产品。
销售敏捷迭代开发的价值。迭代和敏捷开发方法的提倡者经常极力向他们的业务对应者解释迭代和敏捷的概念。假设业务和开发之间需要紧密协调，双方涉众的联合讨论会对成功采用这些实践将会产生十分关键的作用。然而，反抗也是非常激烈的。我曾经亲自遇到这种场合，开发者脑子像被施了魔法一样不断想象出“敏捷”和“迭代”这样的词语，他们争论一直到达到最后的一致。幸运的是，精益和敏捷有很多共同之处，如我下面所讲到的。“Lean Lingo”在本国业务中提供了一个传输敏捷开发概念的方法。它的功能很强大，因为它在沟通业务与软件组织的桥梁作用中有重要的价值。它帮助表达迭代和敏捷方法究竟是指什么——软件交付中的敏捷性、控制和效率。
软件交付中的关键精益原则
我们知道精益思维现在已经在制造业开始运用，跟精益相关的很多原则已经在软件开发中以各种不同的体现形式已经应用了一段时间。软件交付与跟其它类似也是一个供应链。它们是输入、输出以及附加价值活动。寻找过程中不能增加价值的步骤并将其减少到最低的方法是软件交付的一个有效的目的，跟制造业或者服务业一样。也就是说，不是所有精益的概念都运用在软件中，有些概念与制造业中所运用的是不相同的。这个部分将介绍精益最重要概念中的几个，并且讨论它们在软件世界和系统交付中是如何证明它们自己的。
价值流和软件流
一个精益思维的完整概念就是价值流，或者流。最简单的说法是，流所寻求的是通过生产和交付产品和服务以即时的方式尽早消除这其中详细描述的浪费。精益思维的作者们提醒我们注意。为了真正理解价值流您必须“重新安排您的智力资源”。这简直是违反直觉的，因为这对我们所接受的教育是一种挑战。理解流需要我们努力寻求改善软件交付步骤之间的相互作用关系——不仅仅是对每个步骤本身的最大效率化。
这个概念很难立刻理解，因此让我们将它置入一个熟悉的环境。通常的工作都是在各个部门中履行被组织成系列的具体的活动。多年来，就会产生这样一种信念：这就是从您的操作中获得高效和经济实惠最好的方法。一个部门通过优化他们自己的工作来使他们这块产品的效率达到最高，接下来的部门也会这样做。工作是一步一步按部就班列队进行的，直到下一个部门准备好接受上一个部门的输入并使工作继续进展。
比如您正在生产一辆汽车，想象由一个工作团队来负责生产车门，另一个团队负责装配整辆车。传统意义上说，负责生产车门的管理团队应该通过生产车门改进获得更高的效率。他们为了以最低的单元成本生产更多的门需要申请更好的设备。他们最大程度优化他们的工作从而保证他们的团队有剩余的生产。为了使他们团队的工作保持连续不断，他们可能不知不觉就生产了比附加在车门上的框架更多的产品。为什么会发生这种情况呢？不要太愤世嫉俗，但是管理者通常以数字效率为目标来奖励他们。增加这些数字最好的办法是“通过大批生产使过程中的单元步骤达到高资产利用和低单元成本目的。”
8
在软件开发世界中，这种大批生产的精神实质的结果是软件资产的“生产过剩”。这些软件资产是用来开发软件的中间产品，比如文档、报告、模型和原型——所有的都不是完成的产品中直接使用到的。很多情况下，我们生产这些工件，但是它们对下游的开发团队成员来说没什么用处。比如，产品管理和分析者花费时间写的需求可能由于各种原因（可行性，成本等等）从不会被执行。时间花在会议、讨论以及归整这些详细的需求是一种浪费。分析者经常花费相当多的时间在他们对文档的审美理论上。开发者为了可测量性和适应性而执行的复杂的方案或者计划从来就不会有什么用处。测试人员为了功能性而进行的测试也都是多余的。所有的这些都是生产过剩，因此是浪费。
减少这些浪费需要看到整个价值链，而不仅仅是每个功能的职责。这里的“看到整体”是完成流的需求。正如 Poppendiecks 所指出的，“一个成熟的组织应该看到整个系统，而不是集中优化分散的部分。
9
流还需要一个产品节奏。在 Toyota 公司，一辆新车的装配是由很多个55秒单位组成的。每辆车的装配在各个部分完成前20小时内开始。意思就是没有时间来等候供应者或者不同的部门，上游的任务不能延迟。
10
这个沿着产品线的连续的资产流要求浪费被消除。
迭代开发中的流
流在软件业务中同样存在。从 IBM Rationa 的角度来看，迭代开发的最佳实践是能够成为软件流的必要元素的。一次次的迭代就像是功能性的短跑，可以预先在构建更多功能时利用最终用户团体进行测试。由于软件的迭代交付，有两个流的维度：代码贯穿开发周期的方法，对单个迭代的时间和范围的限制。
早期评审和易测性
在第一个维度中，这个解决方案从概念到基干或者架构的解决方案水平移动，经过完全地开发然后部署方案（请看图1）。代码经过开发周期就像一辆汽车经过一个产品生产线一样。这样使得产品的可测试版本在开发周期中很清晰地显现出来。这个早期版本不是为完全使用而部署的，而是作为软件后继层的基础被涉众共享的。就像您可以将一辆不完整的的车从产品生产线上取走进行驾驶测试一样，即使它还没有车门，没有已经着色的框架，或者甚至连座椅都没有，早期版本的应用不必具有完全的功能，但是它们是可以检测的，并且是可测试的。
图1：迭代开发过程中的软件流
通过审查决定价值
相同的节奏在Toyota公司的产品生产系统中通过一系列的这种迭代可以完成，在这些迭代中功能的层次是逐渐增加的。关键的问题是这些迭代都是有严格时间限制的。换句话说，每块功能（比如每个架构的详尽细节）必须在预先计划好的时间内完成。在迭代的末尾，您要么达到了迭代的目标（一定数量已经测试过的功能在代码中被执行）要么没有。您可以对真实性和切实的进度有即时的确认。正如Toyota公司的系统，您无法掩饰欠缺的过程。要么是装好门的汽车从生产线上移下来，要么就没有完成。我们要么使功能代码通过了测试用例，要么就没有。
这种方法确保我们能够增加价值——这就是精益思维执行者所关心的问题。我们总是可以通过审查产品的状态来回答这个问题，“我们增加了什么价值？”这与传统的通过决定哪个非价值增加活动已经完成来决定产品状态的方法是相反的。比如，“这个需求规范是否已经被标记？”或者“这个设计文档是否已经完成？”这些对解决方案没有直接增加价值。
强制问题传达到高层
迭代有强制问题传达到高层的额外优势，日本人所了解的精益思维的另一个重要的概念是jidoka。在制造业，如果出现一个错误，这个生产线就会停下来处理这个问题。传统的观点认为将装配线停下来是极不好的做法。通常，我们消除重要的设计问题或者技术风险是为了保证这个项目看起来还是在向前进展的。由于迭代开发，这种错误的过程是不可能的，因为在迭代这个较短的时间内，您必须工作，为了验证交付的结果您必须测试代码是增加了价值或者清除技术风险。这里的逻辑很简单。在开发和其它下游活动完成之前处理问题是很容易的事情。
小批量生产
在迭代开发周期中第二个维度的流与汽车流生产线中必须交付到下一过程的组成部分的供应有点类似。这些用来构建软件部件的元素包括业务需求、技术需求、一个适合的企业架构标准的详细设计，以及用来确认组件操作的测试。每个团队在每次迭代中都会获得有限的需求。因此，他们仅仅执行业务需求在当前迭代范围中的任务，从而减少了开发和测试工作量。制造业称这为小批量生产。
问题的关键是团队工作仅仅为了当前迭代的需求，为了工作产品能及时交付给交付链中的下一个团队。记住在开发过程中唯一增加价值的事情就是迭代方法的面向结果的任务，交付给下游活动的信息应该表现为下游团队最容易消费的形式。在绝大多数组织中，生产的都是静态的——通常是纸制的——文档。从一些成熟的行业经验中我们知道静态的文档并不是很好的通信方式。首选的方法是利用一套动态的模型：在整个开发团队中共享数字化资产。对象管理组织 (OMG)称它为开发的模型驱动方法。
11
模型驱动流
在没有对语义和由 OMG 以及 IBM Rational Unified Process 规定模型的各个层次进行深入钻研前，让我们先看看这些模型是怎样被典型地运用并描述软件架构的。（请看图2）。
架构师会在用例模型中构建一个软件需求的代表，从最终用户的角度来看这些需求是一套用自然语言编写的需求。这些用例模型会被架构师用来驱动分析和设计模型。这些模型可以明确地使用来自用例中的内容驱动架构。接下来，开发人员将采用这些数字化的模型并将它转变成一个执行模型或者代码。所有这些模型都构建在其它模型之上，最终驱动功能代码的交付。
图2：模型之间的关系在软件开发中的应用
因此怎样区别从一个部门到下一个部门的数字化资产的流与文档和规范呢？记住在软件交付价值链中只有两件事情来驱动价值，它们是面向结果的任务：分析、编码、测试、变更管理和架构。当一个分析师花费时间用一种方式来证明需求不能直接被开发者使用，那么这个活动就不能增加最终产品的价值。如果架构师创建了一个设计文档，开发人员随后就必须人工将它翻译成架构决定的代码。类似地，测试人员必须通过需求和设计文档来创建最适合他们需求的测试案例。
要创建一个真正的流，分析师、架构师、开发人员和测试人员都应该使用与他们工作相联系的工作产品。简言之，他们应该构建他们之间的数字化资产流，而不是生产那些有点用的文档，并且这些文档必须手工转换成每个团队必需的行为、首选的方法以及选择工具。
均衡生产
精益促使流形成的的另一个概念是heijunka, 它涉及到在您的需求量和产品之间均衡生产或者平衡产品价格，从而缓和产品的生产。在传统制造业中，产品的数量根据需求量的波动而变化。一天，这个公司可能因为100辆XYX型号汽车的订单而做出反应，下一次需求可能飙升到400辆。这种随着供应链而发生的波动，使预测劳动力需求的问题很难决定。利用精益方法，公司可以设法管理订单流程，使其基本与稳定的产品生产水平相匹配。
在软件中，均衡生产可以通过选择能够在单个迭代中完成的工作量来实现。项目经理和架构师选择一个可达到一定数量的案例场景，这个场景在迭代范围内应该可以详细说明、设计、编码以及测试。一次迭代由于多个因素的原因通常需要六到八个星期的时间。以这种方式创造的工作节奏可以使团队成员避免摇摆不定和混乱的工作进度。
拉力
精益思维的作者暗示拉力这个概念仅仅是确保在一个价值链中，如果下游消费者没有需求，上游就没有任何其它东西要做（比如，下游的请求服务以从上游资源中“拉动”产品）。由于这个流的缘故，在软件领域有几个重要的维度。
首先，项目经理需要确保究竟要交付给消费者什么才是真正的价值。根据全面阅读 Standish CHAOS 的报告可知，65％以上的软件特性要么从来没用过要么很少被利用。
12
这些特性被详细描述为次要的需求，然后被开发和测试，然而它们所交付的很少或者几乎不交付价值。它们为什么会脱离价值链呢？这里有几个普遍的原因。最终用户与产品管理之间不够良好的合作对开发来说是一种“广撒网，多种地”方法。我们集体讨论的结果是，取消他们的开发工作而促使他们投身于市场， 希望用户从新的功能获得价值。软件项目如何投资是另外一个因素。一种试图一次解决太多的问题的激进方式使得从开放过程中引出真正的价值是十分困难的。
13
拉力的另一个维度与软件开发团队之间协同工作来交付功能有关。正如以上所解释的，开发团队经常为了交付一批批的工件而工作。分析师以规范的形式提出大量的需求，并交付给开发部门。开发部门为那些需求交付一个完整的工件供测试。每个团队成员都花费大量的时间来等待一些上游做出的决定或者交付的工作产品。这些等待的时间是一种浪费。迭代开发支持拉动并且减少浪费。
即时需求
我的同事 Murray Cantor
14
在一篇 Rational Edge 的文章中指出， “在一个项目的开始，任何事情都是不确定的。比如，成本、工作量和这个项目的持续性都是根据历史数据和经验所做出的推测。”它包含了最终将满足的业务需求和将匹配需求的正确设计。传统的观点告诉我们首先应当尝试在合适的地方获得所有的需求，然后做出设计和产品的决策。但是在项目的开始对并不可预知的需求做出强制性的决定会使项目不可避免在一定范围遭到延缓。项目团队就会花费大量的时间来对变化做出回应，重做需求文档的工作、测试用例、以及校验代码。
精益方法对付这种顽疾的手段是“尽可能晚地做出决定”。
15
延迟做出决定直到最后合适的时间。让我们来看一个例子：20世纪80年代在美国密根歇的三大汽车制造商做出一个设计的更改的成本是这个模具成本的30-50％。在日本是10－20％。由于这个原因，日本的工具和模具制造商事实上在粗略制造模具的同时对汽车进行设计，而不提前设计。设计工程师与制造工程师之间应该保持持久的合作关系。如果您很早就试图严格控制变化或者试图在最开始就纠正，那么您不可能得到相同的结果——在软件开发中有太多的变化。
通常情况下，这是一种巨大的浪费，因为设计“与生产线下游专家的需求不一致”。
16
在制造业中，这种问题的结果就像一个收音机与一个波段不完全匹配一样。在Toyota公司，设计与制造团队之间的对抗是通过严格查找技术上的风险来解决的。然后他们在对方认可的范围之内按他们的设计规范来制造。这样就设置了一个可接受的分歧，使下游团队的工作更有灵活性。
在软件开发中，超量计划通常会导致需求在执行一定的技术限制时不符合成本高效原则。比如，“我们无法交付实时的数据，是因为受到了批量系统的阻碍。”真正的协同工程会建议将部分需求的开发与部分设计工作结合起来，这样就可以得到一种经济交付的解决方法。
让我们继续汽车例子的分析，开发软件需求的传统方法就相当于在开发的开始就询问消费者，他们想要什么颜色的汽车，应该安装什么类型的音响系统，需要安装什么样的车轮，以及这些轮胎的气压标准等等。所有这些问题必须得到回答——但是并非一次性回答，也并非都要在设计开始之前得到回答。这样极大地限制了变更的灵活性。
最好的办法是首先了解汽车的用途。这辆车仅仅是为了上下班之用？还是用来拉十个小孩去练习足球？因为这对汽车架构的设计工作相关所以必须尽早得到这个问题的答案。
更密切的合作
正如设计与制造工程的紧密合作为日本汽车制造业带来良好的效应一样，IBM Rational开发中心的方法也赞同这种观点，认为最终用户与开发团队之间的紧密协作将会使软件最大程度上满足消费者的需求。认为这种协作将会产生“有用的团队知识”，在项目的某个方面可以直接并且系统地减少技术和执行的风险。他从数学的眼光看待这个问题，宣称这种紧密协作创造的知识可以重新利用创造新的知识。换句话说，价值以更纯净的状态从一个团队转移到另一个团队。
17
这种方法表明它本身在用例的严格执行中是一种促使这种协作的方法。用例和用户场景是从消费者或者系统最终用户的角度给软件系统编写需求的途径。
执行精益软件交付
采取什么样的方法来执行精益软件的交付呢？这里，我提出了一系列优先方法来适当转变您的组织，并讨论了支持 IBM Rational的技术。
关于我提出的一系列优先方法，有一个十分重要且值得注意的是，将执行的命令会随着不同的组织机构而变化。例如，每个开发团队为了提供透明度在所有的利益关系者之间需要建立拉力。
优先级1：建立拉力
在您的组织中开始精益的第一个步骤是从您的最终用户和关键涉众中建立拉力。在组织级别上，意味着选择合适的项目组合来执行。在项目水平上，意味着确保您选择的特性匹配能够产生真正的价值。最后，意味着建立一个高水平的协作来确保上游团队成员不会生产一些下游团队成员不需要的中间工作产品。
选择正确的项目
不管您是为了业务目的而交付软件还是在一个IT开发团队工作，对您开发的软件进行战略联盟是有必要的。选择一个正确的软件项目，这个项目应该能够交付最多的价值、最大限度地减少成本，或者使消费者获得快乐就是最终的目的。这个战略联盟是良好管理实践的最初目标。IBM Rational Portfolio Manager®(请看图3)以某种方式通过帮助项目建议和批准过程的自动操作来支持这些实践，采用这种方式可以帮助以客观标准来寻找合适的项目组合，而且这种项目组合能够向涉众交付最大的价值。
图3：IBM Rational 项目组合管理
将业务价值与软件功能结合起来
一旦选择了正确的项目，您就不得不为一个产品寻找合适的功能或者一种能够交付最大价值的解决方案。这就是软件工程师所谈到的需求管理。IBM Rational的方法是力求通过减少没有利用价值的文档来管理软件需求。可以有几种实现的途径。
首先，这些需求必须以非技术的方式编写，以至于消费者和非技术的涉众们能够理解。当消费者在他们并不理解的技术性需求规范上签署时，软件开发中会出现的一个非常普遍的问题，因为他们实际上被告知“如果您不同意，我们将不能进展。”为了保持项目的继续（或者至少支持错觉的轨迹），于是他们签署了。这就产生了一种不信任，更糟糕是，经常会交付一个并不能产生价值的结果。IBM Rational的方法之一是包含了从用户的角度编写的需求，而不是从系统的角度。这些以用户为中心的需求采取了用例的形式。这些用例推动项目的进展。它们被用来计划工作，衍生系统架构，以及有效快速地测试用例。
第二，我们需要确保技术需求能够以用例的形式连接回到到他们所驱动的价值。这被称作需求可追溯性。IBM Rational 的软件需求管理产品，IBM Rational RequisitePro®（请看图4）允许产品团队自动操作这种追溯。这种自动化操作使团队更容易发现过剩生产的情况，这种情况通常是逐步演进功能的形式。
图4：IBM Rational RequisitePro 中的一个追踪能力矩阵
优先级2：用迭代和数字化模型创建价值流
一旦组织某种程度上执行了拉力，并通过使用用例正确选择项目和项目价值来提高他的顾客价值，就是时候确保价值流贯穿交付周期了。
正如先前所建议的那样，在软件交付过程中，流是通过迭代化开发软件而产生。IBM Rational Unified Process 规定了一个在内部组织能够执行迭代软件开发项目的框架。像上面所指出的那样，为了使在不同角色之间转换的可消费产品能够最大价值化，团队应该交付能够被下游角色很好利用的中间工作产品，也就是，数字化模型。统一建模语言（UML）为交互提供了一个标准的方法。RUP 规定了一种方法，通过这个方法能够为集成交付数字化资产。
IBM Rational 软件开发平台建在开放源代码的 Eclipse 集成开发环境之上。这个平台提供的技术可以使数字化资产更方便地从一个角色传递到下一个角色。
在图5中描述了利用迭代开发连接拉力与流的概念。从用户中拉动需求并以他们的角度来编写需求。那些被选择的需求是为了在单个的迭代中实现的，而这个迭代是基于交付价值被执行的。下游的拉力维持着这条“装配线”。当正确的需求及时地交付给了交付团队，而且这个团队构建了数字化资产而不是基于说明的文档，那么我们就能够获得真实的流。
图5：用迭代开发支持拉力和流
优先级3：通过协作和自动化来减少浪费
采取精益实践要求在您的顾客与涉众之间有不同方式的协作。为了使精益的概念制度化，尤其是流和拉力，涉众之间的密切协作是必不可少的。为了能够建立这种协作，组织应该执行一个支持价值开发的平台，而不是创造更多的管理费用和浪费。正如精益制造业通过在他们的制造过程中部署合适的设备来清除非价值活动的行为一样，软件项目团队需要等价的基础设施。IBM Rational 软件开发平台是集成的、使不同的团队成员可以自动获取关键项目信息的平台。比如，分析师没有明确地告诉测试员其中的一个需求已经变更——这个平台却可以提供这个标记。一个集成的交付平台能帮组您消除非价值增加的行为，如果您希望完成流，这就是这个游戏的名称。
优先级4：为软件交付过程提供透明度
对产品过程的可视化控制是精益的必要条件。IBM Rational 通过通过管理人员观察当前正在开发或者维护项目的技术和性能指标的方法提供了产品明晰的可见性。利用 IBM Rational Portfolio Manager®（请看图6），执行官、计划经理以及项目经理，通过快速访问实时数据可以减少手工生成状态报告的时间。
图6：IBM Rational 项目组合管理组合仪表盘展示了日程表、财政预算以及范围信息
优先级5：加速“库存”的周期
如先前所讨论的那样，软件并没有真实的库存，但是构建就是软件的物理层表现，这就是我们拥有的最相近的事物。IBM Rational Build Forge®使完成软件构建和将这些构建部署到集成和测试环境的操作实现了自动化。这种自动化使顾客能够在一周内从十个到十五个，最后发展到三百多个构建。构建周期时间的减少意味着在开发早期就发现并处理了缺陷。这意味着消除了几种类型的浪费。
结论
精益思维对您组织中交付的软件开发速度和质量有巨大的影响。虽然它需要人们改变对开发生产力的传统（比如，瀑布式开发）观念，但是在其它领域运用的结果可以证明它们自己是有价值的。您的组织可以利用 IBM Rational Unified Process (RUP) 和 IBM Rational 软件开发平台提供的技术来真正开始实现精益思维 —— 因此可以从理论走向实践。
特别感谢 Murray Cantor、Jesse Tilly、 Kurt Bittner 以及 Rachael Rusting 对这篇文章的思考和建议。
注视
1 M. Duvall，出自于 Baseline (http://www.baseline.com)，2006年9月。
2 S. B. Donnely，所著的“Lean and Mean”，发布在2006年8月的时代杂志上。
3 M.A. Poppendieck 和 T. Poppendieck 所著的Lean Software Development: An Agile Toolkit，于2003年在波士顿 Addison Wesley 出版。
4 J.P. Jones 所著的Lean Thinking，于2003年在纽约的 Free Press 出版。
5 Poppendieck，2003 出版
6 B. Boehm 所著, 2005 Some Future Trends and Implications for Systems and Software Engineering Processes。Wiley Interscience，Hoboken，New Jersey，2005 年版本的第2－3页。
7 Poppendieck，2003 出版。
8 J. Womack 所著的Lean Enterprise Institute。来自 www.lean.org，2006年9月(http://www.lean.org/WhoWeAre/LEINewsStory.cfm?NewsArticleId=38)。
9 Poppendieck, 2003出版。
10 Duvall, 2006 出版。
11 OMG 模型驱动架构，对象管理组织。出自http://www.omg.org/mda/，2006年9月。
12Standish 团队 1994年编写的 CHAOS Report。请查看下面网址(http://www.standishgroup.com/sample_research/chaos_1994_1.php).
13 M. Lines 所著，“Effective Governance Practices for Iterative Development”，出自 Rational Edge 2005年2月版本的第1－7页。
14 请看 Murray Cantor 所著的“估算偏差及管理”，发布在Rational Edge2006年4月刊中，可在下面网址中找到http://www.ibm.com/developerworks/cn/rational/rationaledge/content/apr06/cantor/index.html
15 Poppendieck，2003 出版。
16 Jones，2003 出版。
17 Murray Cantor，前面引用的。
参考资料
关于作者  | 
| | Clay Nelson 是一名技术服务专员，目前在 Rational 服务团队工作。他的软件开发经历包括工作于通用电器、佛罗里达蓝十字蓝盾公司、可口可乐公司、福特公司，以及克莱斯勒汽车公司。 |
对本文的评价
| 
