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

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

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

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

设计最佳实践：保证完成时的完整性

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

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

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

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

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

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

管理最佳实践：透明度

牵涉到完成时的完整性，尽可能详细地了解正在做的事情就变得很更要。在应用敏捷管理实践过程中，如果没有项目管理实践，那么获得的将是提交质量上的提升而不是IT响应性的提升。要获得更好的响应性，就需要使所进行的工作透明化。

敏捷方法可以通过以下途径实现透明化：需求的表达方式、团队的组织方式、协作方式和过程追踪方式。当然支持这些的主要敏捷实践，如用需求卡片表示需求、协作方式、迭代交付等，并不是全部的解决方案，其本身也需要适当的调整以适应特定的环境。

例如，一个地理位置上分散的、几百人组成的团队，通常会把项目分解到几个团队由其独立完成，而不是所有人都去研究同一类需求。这些独立的团队将影响到需求的实现方式：高层次的需求可能需要多个团队各自完成一些子部分，而各子部分之间则通过消息来传递信息。而这并不会减少需求卡片所带来的价值，这种“准需求”能使各团队完成各自独立的（至少是分离的）、可测试的需求，从而很好地实现业务价值。

此外，还要考虑到项目管理方式的模式化程度。分布集中的团队可能会体验到“需求卡片墙”生动地将需求分阶段展示出来的好处，它将包括已完成的、待定的、正在实现中的和准备解决的。然而，地理位置分散的团队无法使用真正的需求卡片“墙”。在此情况下，可以使用项目追踪报告（比如借用Mingle等工具）使团队掌握项目状态。团队的分布形式也会影响到业务的协调程度。虽然业务应该与开发团队分布于同一地理位置，但对于分散的团队来说这不可能。但这并不意味着对本地业务的了解没有用处，因此可以在本地设置一个业务代理——如请一位业务方面的分析专家，可以取得同样的效果。

版本发布计划的实践会根据环境不同而有相当大的变化。在一个高度动态的领域里，版本发布计划基本就是一种“一厢情愿”的想法。在这种情况下发布计划很可能会误导项目的利益相关人并损害团队的利益。这时，XP方法中的“昨日气象”法应该是管理发布过程最安全的方式。在一个较稳定的领域里，版本发布计划就能在很大程度上改善项目档案管理。

另一个需要根据情况考虑的是某种环境下的紧张程度。Scrum方法可能会对经常在生产中遇到故障或者发现缺陷从而急需危机管理的项目很有效，我们可以一个中等长度的时间（比如一个月）划分工作段，在各阶段每天举行站立会议。但对于无法规律地得到发布版本的客户，可能更喜欢敏捷方法中常见的、一致性更好、时间更长的迭代和发布周期。

总之，透明度并不是在做任务的时候顺便获得的，而是通过诸多在特定情况下可以最大化透明度的实践来实现的。

困难的解决与管理上的约束

以上所述并不是说敏捷实践仅仅是一种如何选择的问题，它还需要考虑更多可验证的、协作上的效益。我们需要看到，当这些实践完全实施以后，质量与响应性都会得到极大的提升。虽然不同种类的敏捷实践——Crystal、XP、Scrum等——提供了不同的敏捷实现方法，但不等于这些就是全套的解决方案。比如，在一个高度动态的领域中，XP中的“昨日气象”预测方法可能有极其重要的价值，但是由于它强调100%的单元测试覆盖率，因此即使在这样的环境下，也可能造成相当大的精力上的浪费。同样，只采用Scrum管理方法却没有相应的敏捷实践可能导致项目管理与技术执行不完全一致。不管采用什么方法，都应该对其有粒度化的了解和调整。

必须了解敏捷实践还会受到环境中各种条件的限制。敏捷实践通常是为了解决企业中的一些问题而引入，比如质量、一致性，或者响应性等问题。但如果只解决了问题，却仍然有各种各样的约束，是无法产生最佳效果的。比如，敏捷的版本发布计划会假定有一个“代码所有者群体”，整个代码库都由这个团队“掌管”。如果只采用了各团队独立的开发方式，管理方式却跟不上，就会导致“泳道”式的结果。特别是有高度耦合性的代码会产生依赖性，而使敏捷发布计划变成瀑布模式。同样，如果质量保证是由处于某一地理位置的一个团队独自实现的，那么很可能会使这个团队疲于奔命，无法及时响应来自敏捷开发团队的各种变化。这样，开发响应性将完全无法得到提升。

所以，敏捷方法的采用，既要使敏捷方法适应一个环境，也要调整环境使其有更好的响应性。这可能需要重新调整应用架构，并积极地促使开发人员结对工作以逐渐增加各团队的工作宽度，同时达到彻底消除特征化代码的目的。这还可能需要QA部门的彻底改组，研究业务领域并调查技术能力，使开发团队以业务实现为主要目标，而不是IT实践。不管最终采用什么方案，都必须以解决问题为主，而不是研究约束条件。各种约束会扼杀甚至彻底排除可能产生更好敏捷性的尝试。

与过程相关的人员

虽然敏捷实践经过调整适应了环境，环境也经过改变开始产生更高的敏捷性，但还有一个过程需要执行。只有做这项工作的人掌握了这些变化，才能说这些变化是成功的。因此，在设计敏捷过程的时候，一定要明白个体的价值不是通过上级的命令，而是通过主动参与实现的。设计过程的构建方案是一种可以提高效率的做法，而让参与者成为这个设计的一部分则是取得成功的根本。