软件开发的精益理念

<script type="text/javascript"> google_ad_client = "pub-8800625213955058"; /* 336x280, 创建于 07-11-21 */ google_ad_slot = "0989131976"; google_ad_width = 336; google_ad_height = 280; // </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script> 精益生产是制造业领域的一大创举，而如果把精益生产的简单原则运用到软件开发上，我们称之为精益编程（Lean Programming）。有人预言，精益编程的效果可能与20世纪80年代精益生产所带来的生产改进一样重大。精益生产的10条简单原则对精益编程同样适用。实际上自适用软件开发及肯特·贝克的极限编程（Extreme Programming）中都运用了这些原则。 精益原则一：消除浪费 精益生产的第一个原则就是消除浪费。利用价值流分析可以发现流程中的所有活动，并能找出最终添加到产品中的价值，然后价值流分析会试图找到更为有效的方法去产生同一价值。 在软件开发过程中制作的文档、图表及模型是软件开发项目的一部分，但它们往往是消耗品，可以用来帮助系统的生产，但未必是最终产品。一旦系统交付，用户对这些中间过程的消耗品并不在乎。所以此类消耗品需要证明自己不仅能为最终产品增值，而且还是获得最终价值的最有效的方法。 精益原则二： 尽量减少冗余“库存” 库存太多会耗用资源、延长响应时间以及隐藏质量问题。软件开发的“库存”是指不属于最终产品的那些文档。分析一下就会发现，制作这类文档所花费的时间占据了产品周期的一大部分，而最大的浪费还是因为文档无法正确、全面地抓住用户需求而开发了不符合用户需求的系统。 我们知道用户很难依据文档去设想系统的细节；即使是在实际使用前，用户也不可能正确预测系统的运行；甚至在系统交付之后，用户还可能发现这并不是今后整个使用期间自己所期望的系统运行方式。而在评估文档的价值时，这些因素都必须考虑在内。 精益原则三： 缩短系统的响应时间 20世纪80年代，TQM（全面质量管理）原则教会我们如何在数小时而不是数天或数周之内完成产品生产；在传统软件开发需要几个月或几年时间的时候，电子商务项目往往能够在几周之内完成。 丹尼斯·弗雷利曾提议利用降低制造周期所用的技术来缩短软件开发周期。他建议充分利用“小批量”和“流畅流程”原则。 迭代开发基本上就是把这些原则运用到软件编程上。按照这种方法，在整个开发周期不断设计和交付小而完整的部分。迭代周期从几周到几个月不等，每个迭代阶段都涵盖从收集需求到验收测试的整个开发过程。 精益原则四：获取需求 延迟决策 制造行业过去常常认为，如果营销部分能够准确预测市场需求那该多好。但后来发现这种想法是不对的，相反，应该大大缩短系统的响应时间，以便系统能够对变化做出充分的反应，从而抛弃对预测的依赖。其实IBM目前所推广的E－Business On Demand正是出于这样的思路，而此前戴尔的成功也是与这个理念分不开的。 使需求保持灵活性，并尽可能贴近交付系统，将为软件开发提供更强的竞争优势。在软件开发的早期阶段敲定设计同样带有预测性，所以软件系统的设计应该随时捕获新的需求，并对变化做出响应。 精益原则五：满足客户需求 导致软件项目失败最常见的原因就是需求不全面或不正确，针对这种风险，软件开发商在继续设计系统之前，会尽量收集详细的用户需求，然后由用户确认。 但很多用户在确认需求文档时经常会拖拖拉拉，他们担心自己认可的项目到头来会是个错误，所以等待他们确认文档会浪费大量时间。从这个角度来说，获得用户的同意非但不能鼓励用户参与，反而会造成开发人员和用户之间的对立。 准确抓住用户需求的有效办法就是借助于迭代系统开发，及早开发核心特性并且通过每个迭代阶段的可用性演示获得客户反馈。 精益原则六：结合反馈　一次做好 当在生产线上发现劣质产品时，很多制造企业会对劣质品进行返工，但效果不佳。相反，如果在整个制造流程中运用测试和控制手段，确保每次移交时每个部件都是合格的，这样就很容易查明产品何时偏离了规格。 业界已经公认，软件交付后找到问题并修正的成本是早期设计阶段的100倍，所以企业需要在编写程序之前验证详细设计的合理性。当然软件的规格在不断变化，企业需要利用各种技术手段不断适应变化。 各种测试技术是整个开发过程中适应变化的最佳手段。另一种应对变化的技术就是再构，即通过受控的方式改进现有软件的设计，利用再构，初始设计可以专注于眼前的问题，以后再考虑将来的需求。 精益原则七：对员工下放权力 如果软件开发环境不如预期，主管的本能反应往往是实行更严格的流程，更加详细地明确员工如何完成任务。精益生产则建议采取截然相反的方法，如果开发出现了问题，不要引进外面的专家，而是为员工提供评估及改进各自领域的工具，给予员工足够的权力，最终自己解决问题。 跟精益生产一样，精益编程同样重视团队的协作。软件开发至少需要一次信息移交，即从用户到编程人员，但更多的时候不止一次，比如从用户到设计人员，再到编程人员。有观点认为，这类书面信息最好全部移交，但实际上在移交纸面信息时，会无形中丢失大量有效信息，而让小组成员协同工作则效率要高得多，同时还减少了文书工作。 精益原则八：取消局部优化 在过去，不让机器满负荷运作是难以接受的，但在精益生产中这却是合理的。 一些受过训练的项目经理会非常关注某些局部的管理，正如制造工人致力于尽量提高机器的生产效率一样。但精益编程是受时间和反馈的驱动，所以局部生产力的优化会削弱整个制造流程。在用户所处环境不断变化的今天，如果把局部优化放在非常重要的位置，那当用户需求发生变化时，所有优化工作都付之东流。 如果某个局部的功能有一定的框架限制，只要它不会拖延工期，就不必为它担心。 精益原则九：利用逐步采购 供应链并不是在今天才产生，让供应商相互竞争，保证以最低的成本获得原材料也是很常见的，但精益生产又一次改变了这种惯例。美国管理大师W·爱德华兹·戴明认为，与供应商基于信赖的关系创造了给双方公司带来最大效益的环境。 事实证明，减少供应商的数量，其合作关系具有更高的质量。长期的合作关系可以帮助企业改进产品设计及生产流程，而且几乎无需文书工作。 很多软件企业认识到，传统的软件开发合同造成了隐性浪费。而对软件用户来说，相对稳定的软件开发商可以专注于为用户提供更优秀的软件，并可在开发中尽可能迟地使需求稳定下来。 精益原则十：缔造精益文化 这个原则不用解释也一目了然，如今优秀的软件开发意味着能够不断适应变化。其实在类似CMM的模型中缺乏对变化迅速做出响应的灵活性。 从某种意义上来说，迭代项目环境成了运行环境，因为流程重复出现，就可以把流程改进技术从一个迭代阶段运用到另一个阶段。不过我们需要的不仅仅是涵盖某个项目的改进模型，只要学习现有的项目，就可以改进未来项目的性能。 到目前为止，精益生产的十大原则已经被普及到了多个行业，包括物流、客户服务、医疗保健、金融、建筑、软件等领域。 http://www2.ccw.com.cn/03/0312/b/0312b04_3.asp