Richard Durnall谈个精R益开发和敏捷实施缺陷.doc

Richard Durnall谈精益开发和敏捷实施缺陷.txt鲜花往往不属于赏花的人，而属于牛粪。。。道德常常能弥补智慧的缺陷，然而智慧却永远填补不了道德空白人生有三样东西无法掩盖：咳嗽 贫穷和爱，越隐瞒，就越欲盖弥彰。 InfoQ中文站：越来越多的公司开始关注敏捷和精益。作为十分资深ThoughtWorks顾问，您曾经帮助过很多大型组织导入精益和敏捷。能不能跟我们分享一下这方面的经验。应该怎样迈出导入敏捷的第一步？有哪些策略可以保证把试点团队的成功经验复制到更多的团队中？您觉得最大的挑战是什么？能不能给我们一些建议？ Richard Durnall：在任何一个有一定规模的组织内确定从何处着手引入敏捷以及精益都是一个不小的挑战。很多公司会从一个敏捷试点项目入手。通过这个试点项目评估在组织中引入新的敏捷工作方式的有效性。这种策略比较有效，但也存在风险。选择试点项目时应该先想想如何避开一些常见陷阱。敏捷过程有比较好的风险管理控制。借助敏捷过程，我们能够把困难的问题分解，使得团队能够有效地去控制，解决。引入新的工作方式肯定会有不少困难，项目有可能会失败，因此选择一个低风险，低价值的试点项目可能会降低对业务的影响。但是这类的项目实施不太可能给我们在整个产品线上引入敏捷工作方式所带来的影响提供多少有价值的经验。选择合适的试点项目其实既是一种艺术，也是一门科学，必须要做出权衡。 另一种最近越来越流行的方式是确定一个试点团队而不是一个试验项目。但是与试点项目方式类似的是，也需要根据我们期望从试验中获得的什么样的反馈在整个公司内部来确定一个合适的团队。基于我自身的经验，最有效的方式是在启动时同时选择合适团队和项目。 在大的组织中，我的建议是它们在引入敏捷之前作一个“成熟度评估”。这个评估会包括组织内部的现有能力，IT部门的目标，给出一个过程改进路线图，然后根据情况制定一个合适的改革方案。根据自己在过去五年中帮助大型组织的经验，我总结了一套评价体系。具体来说，我会用精益工具中的价值流图（Value Stream Mapping）去评估该公司现有软件发布方法的有效性，发现现有流程中的要害以及可取之处，对当前组织架构以及运行模式进行建模，重点评估一些跟项目有关的领域比如：需求管理、交流和系统架构。实施这种评估能帮助我们确定一个可行的出发点，还可以估算出在改进过程中可能遇到的挑战。另外，它还可以提供一条基线，用以衡量和跟踪改进与投资间的平衡。不同企业在引入敏捷和精益时可能遇到的挑战略有不同，但是一般都会涉及组织结构、系统架构、预算、计划以及管理方法等方面。历史经验告诉我们，这些问题并不是不能解决的。虽然没有必要从开始就做计划解决这类问题，我们还是有必要开始讨论，寻找潜在的解决方案，从而在等到问题真正出现的时候，我们就不再是毫无准备。 把敏捷试点项目的成功复制到企业级也有不少好的方法。我们可以把成功的试点团队分拆，成员作为种子队员组成多个新团队。我们也可以采取成员轮换的方法，定期把人员轮换入（出）试点团队。我很喜欢在引入敏捷的早期阶段就向系统支持以及维护团队介绍这些新的概念。而项目团队常常是随着项目的启动而建立，随着项目的结束而解散，通过及早了解敏捷，这些支持和维护团队不会因为项目团队的工作方式变化而陷于被动。 支持团队的及早参与能够减少不稳定因素；确保这些支持团队了解并掌握敏捷开发团队的一些基础设施包括自动化测试和持续集成构建环境。从而继续充分利用这些系统的基础设施，减少浪费。由于跟支持团队的沟通合作得到加强，项目团队也会更加关注软件项目的整体成本。 近年来，精益以及它的管理模型--系统管理理论，为在企业级范围内提高敏捷性提供了强有力的支持。在转变的初期，我通常把极限编程（XP）和 Scrum结合。因为极限编程有很强的工程类实践，而Scrum更偏重于项目管理以及与业务相关的领域。把两者结合能够给团队提供一些在早期学习阶段可以借鉴和使用的模式和框架。在团队熟练掌握了这些基本实践之后，我会开始向他们介绍精益中的一些概念和原理。这样就保证团队不会盲目地照搬教科书上的模式，专注于利用新的方式方法提高团队的产出以及给最终客户带来的价值。团队也会开始从关注工具和实践转向背后的概念以及原理，而这种理论对团队长远的发展进步十分必要。接下来，团队会自然而然地开始关注控制正在进行的工作量（Work-In-Progress WIP），理解生产和制造周期（Lead and Cycle Time），持续改善和根据整个价值流工作。 尽管极限编程和Scrum在软件项目团队中能够很好地促进合作，促进给客户带来更大的价值。它们很少涉及企业级的问题（虽然在Scrum社区内很多人不承认这一点）。而精益不仅能够指导我们第一线的工作，也会帮助我们解决