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

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

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

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

与过程相关的人员

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