三个主要误区
第一个是重视流程忽视人。敏捷宣言开明宗义指出“人和沟通胜过过程与工具”。但是仍然有很多企业试图通过创造一个完美的流程来实施敏捷。不可否认，合理的流程对于提高团队效率有一定的作用，但是企业真正要从敏捷改进中获益必须落实到人的改变上来。
第二个是重视管理轻视工程。很多团队将敏捷等同于开开站会、做做迭代、搞搞回顾。到头来，一切流于形式。敏捷说到底是对于软件工艺性的认识回归，那么持续集成、自动化测试、设计、重构这些手艺是绕不开的。不从这些根本的手艺上解决问题，各种眼花缭乱的沟通手段实际上徒然增加了团队的成本。
第三个是重视指标轻视过程。很多团队特别是从CMM型组织转向敏捷的团队，热衷于设计所谓的敏捷度量体系。度量应该是帮助团队增强信心和持续改进，指标不应成为目的。我们要关心的不只是站在哪里，更应关心我们将走向哪里。
要解决这些问题没有任何灵丹妙药，从来也不存在一个完美的、放诸四海而皆准的流程。我们在帮助各种企业进行敏捷流程改进的过程中，总结了几种改进模式，这里跟大家分享一下。
五种改进模式
跳跃：团队作为整体从一种实践直接切换到另一个实践方式上。
有些实践我们知道其目标，并且知道这种切换对团队的影响较小，或者不适于采用逐步推行的方案，我们就采用跳跃的方式。
例如，配置管理工具切换。某团队原来使用的配置管理工具是ClearCase，为了享受到SVN的原子提交、低成本分支等好处，我们往往采取跳跃的方式，即整个团队立刻从ClearCase切换到SVN上工作。这是因为配置管理的切换总的来说对于团队的工作方式影响比较可控，而且使用简单。
并行：团队中部分组织或个人使用原有实践，而另一部分切换到另一个实践方式。
有些实践知道其目标，但在整个团队推行可能会对工作方式造成较大影响，或者团队中的某些组织或个人不具备切换到新的实践方式上的条件，我们就采用并行的方式。
例如，项目组持续集成。团队中某个项目组具备较好的持续集成基础，另一些项目组基础较差。如果在整个团队推行持续集成，就可能对团队产生较大的冲击。而且持续集成的具体方案可能需要在一个项目组内试验。这时候，先在一个项目组做起来，然后推广到其他的项目组。
有些实践有长远的目标，但还看不清达成目标需要的路径，如果知道做某件事情一定有助于达成目标，可以先完成这件事情。例如，单元测试。有时候希望在某些团队中实施单元测试，但缺少合适的测试框架，那么在确定测试框架之前，实际上很难展开后面的工作。这时就可以先全力构建这个测试框架。称这种方式为阶石。
简化：为了达到一个长远的目标，先实现一个较为容易实现的目标，但是这个目标仍然能够给我们带来好处。
有些实践我们有一个长远的目标，但是对于这个长远的目标还不太清楚，或者要达成这个长远目标，要走的路还很长。如果有些做法可以给我们带来一些好处，虽然不如长期目标带来的好处那么大，我们仍然可以先做起来。
系统测试和低成本测试的拉通。系统测试和低成本测试拉通是个长期而艰巨的任务，比如可能需要良好的基础设施的配合。但是我们可以做一些简单的事情来获得相似的好处。
暂停：暂不实施某个实践。
有些实践，团队不具备实施条件，或者对团队的冲击较大，可选择暂不实施。例如TDD。实施TDD需要较高的条件。如果团队不具备这样的条件，贸然推行难度非常大，这个时候常常选择暂停。
上面的5个模式所在维度并不相同。比如，并行是从组织的维度考虑的，而阶石和简化是从目标维度考虑。另外，在不同范围内看，同样的实践也可能属于不同的模式，需注意模式的目的是为帮助参与者清晰把握问题本质，认识解决方案在时间和范围上的局限性。所以把实践与模式绑定的做法也不提倡。
作者简介：
肖鹏，ThoughtWorks资深咨询师，敏捷过程教练，多次担任大中型企业敏捷流程改进咨询和培训。他关注于设计模式、架构模式、敏捷软件开发等领域，并致力于软件开发最佳实践的推广和应用。他曾参与翻译《VisualStudio2005技术大全》，主持翻译《面向模式的软件架构》第四卷和第五卷等图书。个人博客:http://designpatterns.cnblogs.com
（本文来自《程序员》杂志10年10期，更多精彩内容敬请关注10期杂志）
《程序员》10月刊最新上市：http://www.programmer.com.cn/4128/
《程序员》订阅：http://dingyue.programmer.com.cn/
.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
