【IT168 专稿】

    一个有实际应用价值的敏捷过程并不是简单地照章办事就可以实现。敏捷方法的采用，既要使敏捷方法适应一个环境，也要调整环境使其有更好的敏捷性和响应性。

　　一个有实际应用价值的敏捷过程并不是简单地照章办事就可以实现的。它需要根据环境有意识地对非常好的实践进行调整，使之适应这个环境并充分发展。其中，还要考虑对这个过程有引导作用的三个关键问题：

• 怎么保证工作完成时有充分的完整性？
• 怎么保证所做工作有合适的透明度？
• 企业层面上有什么约束条件能避免中途发生变化？   

　　注意解决这些问题不但可以使IT企业掌握新的工作方式，还能使业务方面受到的损失减小到最低程度。

设计非常好的实践：保证完成时的完整性

　　敏捷开发的一个特点是它不会增加将来的负担，也就是说它不会把一些诸如构建、集成和测试的活动推迟到下一阶段。在敏捷过程中，这些活动几乎都是和代码编写同步完成的：在编写可执行的代码之前做出项目成功的标准，即时将所编写的代码提交到构建和自动测试中，并让开发人员结对工作以更好地保证所做工作产生满意的结果。这样，如果有什么需要通过敏捷项目来完成，那么它便只需要走一个客观的过程，从而减少主观因素的影响。

　　虽然已有一系列敏捷实践可以用来开始这一过程，但这个过程不能简单依靠任何实践直接完成。每个项目的情况和特点决定了各个实践的应用程度。过分的应用可能只实现很小的价值；而应用得太过保守，又无法产生可验证的效益。

　　比如一个持续集成的过程，C++和COBOL等技术可能对此并不支持，但并不因为它们不支持持续集成，就意味着敏捷构建实践毫无用处。减少代码提交与构建之间的时间差显然是有好处的。所以，在此情况下，即使是一天即可完成的工作，也能最大程度地提高构建效率，从而增加效益。CruiseControl这类构建工具可以支持各种非典型的敏捷技术和构建循环。

　　构建的实现能对代码质量的监督起到多大作用还取决于团队的特点。对于一个掌握各种技术、在地理位置上分散的大型团队来说，如果能在每次代码提交时都进行测试和代码质量分析，其价值将是无法估量的。相比之下，对于地理位置分布较集中的小型团队来说，这可能就只是一种时间上的浪费，因为这种团队通常只需要一个构建信息入口。

　　一味追求更高的单元测试覆盖率并不是好事。比如，在一个需求经常发生急剧变化的、高度动态的业务领域中，必须在有限时间内完成一个项目。这种情况下，相比时间与功能，质量可能会处于一个较低的优先级。这时，过高的单元测试覆盖率将是一种精力上的浪费，因为有大量代码会被直接处理掉。而根据需求编写最贴切的单元测试会更为有效；然后在对业务领域有了更好的了解之后，再考虑增加单元测试覆盖率的问题。另外，技术上也会有所限制，比如当前开发语言可能并不支持单元测试，而使之支持单元测试的第三方机制又稍显尴尬（比如在CICS系统中使用.NET包装器对MQ进行包装以调用COBOL程序）。因此，所能达到的覆盖率也是有限的。尽管如此，创建一个可测试的架构、并取得一定程度的单元测试覆盖率总比什么都不做要好。     

　　很显然，无法给任何实现敏捷过程的活动做出广泛通用的定义。因为每一种活动都是在不同程度上实践的，而其实践程度又决定了项目完成时的置信度。