【IT168 分析评论】

    我们曾举办了一次为期三天的敏捷培训，学员主要是一些知名软件公司的项目经理和资深开发人员。培训期间，我们带领学员进行了丰富的游戏，通过寓教于乐的方式让他们体验了敏捷方法学的大部分知名实践，并讲解了敏捷方法学推崇的价值和原则。从学员的回顾以及意见表上可以看出培训效果是显著的，但是在培训过程中学员也提到一些问题，主要是对敏捷方法学的实践和价值比较疑惑。在回答问题的同时，我们能感觉到随着敏捷方法学在国内被引入、被宣传，很多软件组织或人员对敏捷方法学都已经有了基本的了解，但是对敏捷方法学向软件行业承诺的价值还存在不同程度的顾虑。

    作为以“交付更多客户价值”为核心原则之一的方法学，敏捷方法学向软件行业承诺：敏捷方法学能提升软件团队交付能力，给客户交付更多商业价值。为什么敏捷方法能做到这两点承诺？软件组织如果没有实施过敏捷方法学，或者实施方法不得当，通常会对这两点产生怀疑，从而对是否决心在组织内部实施敏捷产生犹豫和观望情绪。那我们就来分析敏捷方法学是怎么做到的。

    敏捷方法学提升交付能力

    提升软件团队的交付能力，其实最好的办法就是释放团队的软件生产力，而不是试图去规范它、约束它。这里，我们用“软件生产力”来定义软件团队开发软件的能力，包括软件团队在软件开发过程中为了解决各种各样的问题而使用的开发语言、开发工具以及开发实践。

    软件生产力是不断发展的。为了解决软件开发过程中的问题，方法学才被提出来。从某种意义上讲，只有方法学积极采纳并改造新的软件生产力，而不是因循守旧地墨守成规，才能真正释放软件团队的软件生产力。

    那么问题就变成：敏捷方法学如何采纳并改造现在的软件生产力？

    现在的软件生产力

    在开发语言方面，现在JVM/C#.NET是转为平台语言，支持在其基础上多语言开发，比如Jruby，groovy，jython等语言就能在JVM上运行。原来不受重视的脚本语言，像ruby、python等也是重登大雅之堂，给软件团体提供了更多的选择。

    IDE：现代IDE不只是集成了编码、运行和调试功能的工具，而且是把应用程序开发的整个生命周期都纳入管理，从分析建模、代码编写、配置管理、构建管理，再到测试的集成，突破了原来软件过程里定义的各个环节的边界。一些大受好评的IDE无不是内建了ALM的支持，并集成了软件开发的大部分非常好的实践，如Intellij IDEA。

    Build tool：自动构建越来越受到开发团队的欢迎，Ant、nant、rake、gant……各种平台各种语言的build工具不仅提供了丰富的build task，而且给开发人员进行扩展提供了足够的自由度。至于maven，更是希望充当项目底层设施的角色，成为管理项目不可或缺的一部分。

    Revision management tool：在项目开发过程中，版本管理是非常重要的一个部分。随着技术的发展，VSS这种笨重的工具早已被冲进历史的车轮。而且除了CVS、SVN这些central server的版本管理工具，分布式版本管理工具，如git、mercurial也是日益成熟。

    前面只是简单列举了现在软件开发过程会用到的一些工具，其实，现在的软件开发实践也有非常鲜明的特征。很多在日常开发中涌现出来的开发实践，并不专属于特定的软件方法，却早已得到业界的认可。

    Developer unit test：自Kent Beck的junit框架发布以来，人们才意识到开发人员写unit test也是如此的轻巧和方便。在其他语言方面，testNG、nunit、runit等测试框架也极大地推广了单元测试的编写。

    Refactoring：重构是优化代码设计的重要手段之一，在Martin Fowler出版Refactoring之后，才真正被大家所关注。up-front design就逐渐被日常开发中的incremental design所取代。而随着对重构的研究，越来越多的相关书籍给开发人员提供了更多的实践指导，比如Refactoring to Pattern等。

    Periodic auto build：因为SCM工具和integration tools出现，自动构建越来越受到开发团队的欢迎：一方面提高了软件产品的质量，减少了产品对特定环境的依赖；另一方面减少了重复乏味的工作，也给开发团队节省了时间和精力。像Cruisecontrol这样的开源工具出现之后，自动构建就时时刻刻都在进行，并能及时给开发团队提供反馈。