登录
只要业务书架上装满了书，我们就会可以不断地从管理领导者和成功CEO的例子获得新的思想观念。那么是什么使得这个精益的概念有所不同呢？怎样才能概括精益对我们组织积极的影响呢?下面有几种方法：
缩短周期时间。正如它能够大量缩短制造业中的周期时间从而可以在更多的存货周转中运用一样的道理，精益思维也可以加速交付高质量的软件。软件并不能真正意义上等同于存货，但是一个软件构建或者配置组件可能比较类似。它们表现在软件交付供应链中的“物理”层面。在文章接下来的部分，我将讨论精益思维和支持性开发基础架构是如何促使这个软件提高存货周转率的。
高品质的解决方案。获得一个能够满足涉众业务需求的软件解决方案——尤其是当这些需求仍然在增长时——很显然是一个很有挑战性的问题。采用了精益思维和相应的管理系统的组织发现在缩短周期时间和成本的同时还可以交付高品质产品。
销售敏捷迭代开发的价值。迭代和敏捷开发方法的提倡者经常极力向他们的业务对应者解释迭代和敏捷的概念。假设业务和开发之间需要紧密协调，双方涉众的联合讨论会对成功采用这些实践将会产生十分关键的作用。然而，反抗也是非常激烈的。我曾经亲自遇到这种场合，开发者脑子像被施了魔法一样不断想象出“敏捷”和“迭代”这样的词语，他们争论一直到达到最后的一致。幸运的是，精益和敏捷有很多共同之处，如我下面所讲到的。“Lean Lingo”在本国业务中提供了一个传输敏捷开发概念的方法。它的功能很强大，因为它在沟通业务与软件组织的桥梁作用中有重要的价值。它帮助表达迭代和敏捷方法究竟是指什么——软件交付中的敏捷性、控制和效率。
我们知道精益思维现在已经在制造业开始运用，跟精益相关的很多原则已经在软件开发中以各种不同的体现形式已经应用了一段时间。软件交付与跟其它类似也是一个供应链。它们是输入、输出以及附加价值活动。寻找过程中不能增加价值的步骤并将其减少到最低的方法是软件交付的一个有效的目的，跟制造业或者服务业一样。也就是说，不是所有精益的概念都运用在软件中，有些概念与制造业中所运用的是不相同的。这个部分将介绍精益最重要概念中的几个，并且讨论它们在软件世界和系统交付中是如何证明它们自己的。
一个精益思维的完整概念就是价值流，或者流。最简单的说法是，流所寻求的是通过生产和交付产品和服务以即时的方式尽早消除这其中详细描述的浪费。精益思维的作者们提醒我们注意。为了真正理解价值流您必须“重新安排您的智力资源”。这简直是违反直觉的，因为这对我们所接受的教育是一种挑战。理解流需要我们努力寻求改善软件交付步骤之间的相互作用关系——不仅仅是对每个步骤本身的最大效率化。
这个概念很难立刻理解，因此让我们将它置入一个熟悉的环境。通常的工作都是在各个部门中履行被组织成系列的具体的活动。多年来，就会产生这样一种信念：这就是从您的操作中获得高效和经济实惠最好的方法。一个部门通过优化他们自己的工作来使他们这块产品的效率达到最高，接下来的部门也会这样做。工作是一步一步按部就班列队进行的，直到下一个部门准备好接受上一个部门的输入并使工作继续进展。
比如您正在生产一辆汽车，想象由一个工作团队来负责生产车门，另一个团队负责装配整辆车。传统意义上说，负责生产车门的管理团队应该通过生产车门改进获得更高的效率。他们为了以最低的单元成本生产更多的门需要申请更好的设备。他们最大程度优化他们的工作从而保证他们的团队有剩余的生产。为了使他们团队的工作保持连续不断，他们可能不知不觉就生产了比附加在车门上的框架更多的产品。为什么会发生这种情况呢？不要太愤世嫉俗，但是管理者通常以数字效率为目标来奖励他们。增加这些数字最好的办法是“通过大批生产使过程中的单元步骤达到高资产利用和低单元成本目的。” 8
在软件开发世界中，这种大批生产的精神实质的结果是软件资产的“生产过剩”。这些软件资产是用来开发软件的中间产品，比如文档、报告、模型和原型——所有的都不是完成的产品中直接使用到的。很多情况下，我们生产这些工件，但是它们对下游的开发团队成员来说没什么用处。比如，产品管理和分析者花费时间写的需求可能由于各种原因（可行性，成本等等）从不会被执行。时间花在会议、讨论以及归整这些详细的需求是一种浪费。分析者经常花费相当多的时间在他们对文档的审美理论上。开发者为了可测量性和适应性而执行的复杂的方案或者计划从来就不会有什么用处。测试人员为了功能性而进行的测试也都是多余的。所有的这些都是生产过剩，因此是浪费。
减少这些浪费需要看到整个价值链，而不仅仅是每个功能的职责。这里的“看到整体”是完成流的需求。正如 Poppendiecks 所指出的，“一个成熟的组织应该看到整个系统，而不是集中优化分散的部分。 9
流还需要一个产品节奏。在 Toyota 公司，一辆新车的装配是由很多个55秒单位组成的。每辆车的装配在各个部分完成前20小时内开始。意思就是没有时间来等候供应者或者不同的部门，上游的任务不能延迟。 10 这个沿着产品线的连续的资产流要求浪费被消除。
流在软件业务中同样存在。从 IBM Rationa 的角度来看，迭代开发的最佳实践是能够成为软件流的必要元素的。一次次的迭代就像是功能性的短跑，可以预先在构建更多功能时利用最终用户团体进行测试。由于软件的迭代交付，有两个流的维度：代码贯穿开发周期的方法，对单个迭代的时间和范围的限制。
早期评审和易测性
在第一个维度中，这个解决方案从概念到基干或者架构的解决方案水平移动，经过完全地开发然后部署方案（请看图1）。代码经过开发周期就像一辆汽车经过一个产品生产线一样。这样使得产品的可测试版本在开发周期中很清晰地显现出来。这个早期版本不是为完全使用而部署的，而是作为软件后继层的基础被涉众共享的。就像您可以将一辆不完整的的车从产品生产线上取走进行驾驶测试一样，即使它还没有车门，没有已经着色的框架，或者甚至连座椅都没有，早期版本的应用不必具有完全的功能，但是它们是可以检测的，并且是可测试的。
图1：迭代开发过程中的软件流
