Richard Durnall谈精益开发和敏捷实施缺陷
Richard Durnall：在任何一个有一定规模的组织内确定从何处着手引入敏捷以及精益都是一个不小的 挑战。很多公司会从一个敏捷试点项目入手。通过这个试点项目评估在组织中引入新的敏捷工作方式的有效性。这种策略比较有效，但也存在风险。选择试点项目时 应该先想想如何避开一些常见陷阱。敏捷过程有比较好的风险管理控制。借助敏捷过程，我们能够把困难的问题分解，使得团队能够有效地去控制，解决。引入新的 工作方式肯定会有不少困难，项目有可能会失败，因此选择一个低风险，低价值的试点项目可能会降低对业务的影响。但是这类的项目实施不太可能给我们在整个产 品线上引入敏捷工作方式所带来的影响提供多少有价值的经验。选择合适的试点项目其实既是一种艺术，也是一门科学，必须要做出权衡。
另一种最近越来越流行的方式是确定一个试点团队而不是一个试验项目。但是与试点项目方式类似的是，也需要根据我们期望从试验中获得的什么样的反馈在整个公司内部来确定一个合适的团队。基于我自身的经验，最有效的方式是在启动时同时选择合适团队和项目。
在大的组织中，我的建议是它们在引入敏捷之前作一个“成熟度评估”。这个评估会包括组织内部的现有能力，IT部门的目标，给出一个过程改进路线图， 然后根据情况制定一个合适的改革方案。根据自己在过去五年中帮助大型组织的经验，我总结了一套评价体系。具体来说，我会用精益工具中的价值流图 （Value Stream Mapping）去评估该公司现有软件发布方法的有效性，发现现有流程中的要害以及可取之处，对当前组织架构以及运行模式进行建模，重点评估一些跟项目有 关的领域比如：需求管理、交流和系统架构。实施这种评估能帮助我们确定一个可行的出发点，还可以估算出在改进过程中可能遇到的挑战。另外，它还可以提供一 条基线，用以衡量和跟踪改进与投资间的平衡。不同企业在引入敏捷和精益时可能遇到的挑战略有不同，但是一般都会涉及组织结构、系统架构、预算、计划以及管 理方法等方面。历史经验告诉我们，这些问题并不是不能解决的。虽然没有必要从开始就做计划解决这类问题，我们还是有必要开始讨论，寻找潜在的解决方案，从 而在等到问题真正出现的时候，我们就不再是毫无准备。
把敏捷试点项目的成功复制到企业级也有不少好的方法。我们可以把成功的试点团队分拆，成员作为种子队员组成多个新团队。我们也可以采取成员轮换的方 法，定期把人员轮换入（出）试点团队。我很喜欢在引入敏捷的早期阶段就向系统支持以及维护团队介绍这些新的概念。而项目团队常常是随着项目的启动而建立， 随着项目的结束而解散，通过及早了解敏捷，这些支持和维护团队不会因为项目团队的工作方式变化而陷于被动。
支持团队的及早参与能够减少不稳定因素；确保这些支持团队了解并掌握敏捷开发团队的一些基础设施包括自动化测试和持续集成构建环境。从而继续充分利用这些系统的基础设施，减少浪费。由于跟支持团队的沟通合作得到加强，项目团队也会更加关注软件项目的整体成本。
近年来，精益以及它的管理模型--系统管理理论，为在企业级范围内提高敏捷性提供了强有力的支持。在转变的初期，我通常把极限编程（XP）和 Scrum结合。因为极限编程有很强的工程类实践，而Scrum更偏重于项目管理以及与业务相关的领域。把两者结合能够给团队提供一些在早期学习阶段可以 借鉴和使用的模式和框架。在团队熟练掌握了这些基本实践之后，我会开始向他们介绍精益中的一些概念和原理。这样就保证团队不会盲目地照搬教科书上的模式， 专注于利用新的方式方法提高团队的产出以及给最终客户带来的价值。团队也会开始从关注工具和实践转向背后的概念以及原理，而这种理论对团队长远的发展进步 十分必要。接下来，团队会自然而然地开始关注控制正在进行的工作量（Work-In-Progress WIP），理解生产和制造周期（Lead and Cycle Time），持续改善和根据整个价值流工作。
尽管极限编程和Scrum在软件项目团队中能够很好地促进合作，促进给客户带来更大的价值。它们很少涉及企业级的问题（虽然在Scrum社区内很多人不承认这一点）。而精益不仅能够指导我们第一线的工作，也会帮助我们解决在整个组织引入敏捷时出现的企业级问题。
随着越来越多的大型企业开始引入敏捷，我们遇到了很多新的问题，这些问题涉及到管理方法、产品系列计划、预算和组织架构。精益包含了一系列解决这类 问题的方法、过程和模型。比如，在自上而下层次架构的组织中常常使用平衡计分法来确保组织战略和管理个人的绩效。随着我们引入敏捷和精益，我们需要废除这 种方式，转而利用一种基于团队的，面向客户的结构。因此我们往往需要废除组织层次架构以及相应的面向个人的绩效考评体系。很多情况下也会把很多决定权下放 到第一线直接面对客户的员工。值得庆幸的是精益组织发展了一个相应的工具，方针管理（Hoshin Kanri），它能有效地在高度合作的环境中确保组织战略以及过程的有效性。作为一种现成的精益组织战略工具，方针管理与我们第一线工作中使用的各种理念 十分契合。已经有无数的实例可以证明精益组织能够解决这一类组织级的挑战，我们不需要再去重复他们的探索过程（重新去发明轮子），很多有远见的组织已经注 意到这些，直接去“借用”这些已经在企业级实施中得到验证的工具、技术和过程。
在IT部门中引入敏捷和精益会遇到很多的挑战，尽管各个组织的过程都不尽相同，我们还可以发现一些通用的模式。首先遇到的挑战就是人。工作方式、团 队结构、工具和模式的都需要发生改变；作为CIO或者IT经理，你不应该因为遇到强力的“反馈”而感到吃惊。作为工程师，你可能会碰到很多来自同事的抵触 和质疑。一旦最初的质疑声平静下来，人们会渐渐地适应新的工作方式，他们会觉得旧的日常工作方式是那样得不合时宜。为敏捷开发创建基础设施，包括测试工 具、持续集成环境和其他的支持工具需要一部分投资。一段时间之后，经过新的敏捷团队和项目管理办公室（Project Management Office）之间不断磨合，他们之间的关系也会随着项目管理办公室逐渐适应并了解了敏捷团队所提供的数据以及新的计划方式而得到良性发展。与此类似，业 务部门、财务计划以及组织架构也必须要面对新的工作方式所带来的挑战。尽管不是所有的组织都能够达到这样的高度，但是至少我们可以对向组织内引入敏捷和精 益所必须经历的过程有一个大体的认识。
如果你是一个积极地希望把敏捷和精益引入所在组织的工程师，我建议你先要把这些理念推销给你的老板，获得领导层的支持。同样的，如果你身处领导层， 希望把引入这些想法，最重要的是要在第一线的员工中找到支持者，给这些员工授权和支持，从而引领这场变革。从我自身的经验来看，在组织的各个层面都有支持 者是成功实施敏捷和精益的关键。
很多组织都会宣称自己成功的引入了敏捷开发，实际则不然，绝大多数仅仅是在做表面文章。他们在“做敏捷”，敏捷社区称之为“货物崇拜敏捷”。针对这个现实状况，我们能做些什么？
Richard Durnall：“货物崇拜”（Cargo Cult） 是用来代表那种与世隔绝的社会第一次见到外部文明社会时表现出的种种行为。一个著名的故事发生在二战时期的太平洋岛屿上。岛上的居民在享受了盟军货运飞机 运来的免费食品和其他货物之后，开始模仿占领部队的种种行为，期望以后有更多的“补给品”运过来。居民们精心制作了军服，把木头雕成枪的样子，他们甚至用 最基本的原材料组装了一架与真实飞机一样大小的“飞机”。他们还模仿盟军当年训练的样子在村庄内行军。很多人都会觉得这种行为很可笑，认为他们太过于幼 稚，然而，我们应该承认的是这些人并不愚蠢。如果看一下他们做出来的木头枪和飞机，你会觉得他们是十分有才能的工匠和工程师。如果给我们相同的工具和原始 材料，我们自己绝对没有可能造得那么精美。其实他们缺少的是对他们见到的种种事件背后力量的理解。因此他们只能按照自己的逻辑，期望通过模仿他们所观察到 的一切来重新获得同样的结果。
敏捷社区也借用了这个词汇，称之为“货物崇拜敏捷”。 用它来指代某些团队，这些团队只知道使用工具和实践，只会简单地从其他成功团队或者教科书模仿照搬，而不做深入的思考，不了解这些工具和实践背后的原理。 他们“做敏捷”仅仅是因为从书上看过或者某个敏捷“专家”说过应该这样做。很显然这种情形并不仅仅出现在敏捷团队。我就曾经见到一些团队，他们使用各种各 样的正规的方法论，但是不理解为什么那样设计过程，也不理解每一步过程和每一个活动能带来怎样的价值。我觉得这种思维方式很有问题。首先，仅仅是因为手册 上的宣传，就使用一些工具、技术或者过程会导致很大的浪费。其次，这会打消团队获得知识的积极性，使团队变得懒惰，不去积极思考更好的方案去解决手头问 题。管理学家W. Edward Deming告诉我们“不光只有一种正确方法”（There is no one right way）。项目管理的科学与艺术其实就是一个了解我们掌握的工具和方法，然后设计能够有效解决问题的过程。
精益其实在很多方面使我们避免“货物崇拜”思维方式所带来的种种问题。利用精益中的很多工具和过程去理解客户的需求，我们会更加以客户为中心。我们 总是从客户开始到客户结束。接下来，我们会审视我们用来给客户发布产品或者服务（通常是一个IT解决方案）的过程。在精益里面，我们并不关注具体工具和技 术，我们更加关注产出（throughput）、流（flow），和持续改善（continuous improvement）。通过不断地消除浪费，有计划地优化工作方法，我们能够有意识地解决遇到的问题。掌握了这种思维方式，“货物崇拜”团队不再仅仅 局限于工具和技术的使用，而是关注怎样有效地为客户提供最好的成果。
