登录
通过审查决定价值
相同的节奏在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 这种方法表明它本身在用例的严格执行中是一种促使这种协作的方法。用例和用户场景是从消费者或者系统最终用户的角度给软件系统编写需求的途径。
