随着敏捷开发的成功案例越来越多，越来越多的公司开始关注敏捷。连IBM和微软这样的大公司也开始关注敏捷开发。IBM已经有25%软件项目开始使用敏捷。微软著名的Pattern&Practice团队很早就在使用敏捷方法和实践，甚至微软vSTS团队在全球开发VSTS 2010项目中也在使用Scrum等敏捷方法。越来越多的公司和团队开始关注敏捷，讨论敏捷，导入敏捷，敏捷渐渐成了一种时尚。于是我们听到了越来越多导入敏捷失败的案例。我听说很多公司的高层听了Scrum介绍后感觉不错，马上吩咐下属去制定计划导入Scrum。下属人员或者去参加Scrum课程，或者去读了Scrum的书，然后就开始在团队里面推广实施。不出意外，很多失败了。也有很多即使没有失败也是只是借用了Scrum的一些形式，其实实质上还是在继续原有的方法体系。我曾经面试过一个在某最著名公司里做了两年ScrumMaster的应聘者。在面试中他告诉我他们团队一直在用Scrum框架，迭代开发，有sprint 计划、每日站立会议、demo等等，可是令我吃惊的是他告诉我两年内他们的Scrum从来没有发生过变化。Scrum的一个重要的原则是”审查和调整”。而这个Scrum团队，这个ScrumMaster在做Scrum的两年中，竟然没有进步，这绝对不是Scrum，绝对不敏捷！
前几天我见到一个简历，在两年时间内，这个应征者拿到了PMP, OCP, MCTS, IBM Certified Solution Designer, Microsoft Certified Business Management Solutions Specialist。我们也不断听说很多年轻的学生获得了MCSD, MCAD证书。这能说明几个问题，首先说明经过短时间的突击就能很快的拿到这些证书，因此这些证书的价值比较低；其次，说明市场上很多公司以及老板热衷于这种证书，而很多人很热衷于获得各种证书；再次，这个人肯定不是这些方面的专家。因为这每一项技术或者理论，没有多年的实践和理论积累，不可能成为一个专家的。这反映出了整个社会和社区的浮躁。不仅仅是国内，国外也是一样，Peter Norvig（“用十年时间教会自己开发程序 ”）在Amazon用“几天或者几小时，教会自己”关键字检索，竟然找到了几百本书。知识成了一种快餐。
以上我们看到了无论软件团队在过程改进中或者是个人在自己职业技能发展中的很多问题。究其原因，我认为无论是团队还是个人都是在发展中混淆了目的和手段。Be Agile或者使用敏捷的一些实践并不应该是团队过程改进的目的，应该是建立“能够持续、快速、稳定地将客户的需求转换为可以工作的软件”的卓越团队，也就是真正的目的应该是“追求卓越”，。而敏捷或者Scrum只不过是迄今为止我们发现的一种比较有效的手段。同样的获得证书也不应该是个人学习的目的，应该是成为某个领域的专家，同样是“追求卓越”。正如莫扎特，尽管从四岁就被认为是一个音乐天才，可是经过十三年的刻苦努力，他才写出了世界级的音乐作品，真正成为一个专家。
正如老子说的“为学日益，为道日损，损之又损，以至于无为，无为而无不为矣”。同样说明了追求卓越的道理。只能踏踏实实的，不断的重复“实践->理论->实践”的过程，才能真正理解软件开发之“道”。为什么那些Scrum和敏捷的大师们(Jeff Sutherland, Ken Schwaber, Ron Jeffries, Robert. C. Martin, Martin Fowler)都强调要在运用Scrum中同时也要重视工程类的的实践(测试驱动开发，结对编程，持续集成等等)，因为XP的很多工程类实践正好弥补了Scrum在工程类实践方面的缺失。如果没有工程类实践的支持，不断的迭代会导致技术负债急剧增长，团队就会不断的疲于奔命，越做越慢。对于软件开发团队来说，同样不能仅仅关注于使用什么样的敏捷实践，而应该是不停的审视团队自身的过程，不断地调整开发过程，根据自身的特点以及通过对各种敏捷方法论的研究，合理的引入管理类以及工程类实践，使开发速度越来越快，质量（内部质量和外部质量）越来越好，只有这样才能越来越敏捷。而对于个人来说，不能只能想着速成，总是想着”Get it done”不会长久。应该脚踏实地，从写干净的代码的开始，实现模式、Clean Code、S.O.L.I.D原则、重构、设计模式提高自己对技术的理解，成为真正的专家(Craftsmanship)，真正的做到”Get it Done Well”。
