内在关联 敏捷实践
开篇：润墨网以专业的文秘视角，为您筛选了一篇内在关联 敏捷实践范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
敏捷实践易造成松散的错觉。但事实上，敏捷方法的实践具有很强的内在关联性。成功地实施/剪裁敏捷方法，首先必须搞清楚敏捷实践的内在关联，综合实施相关的最佳实践才能发挥出其应有的威力。
某日，我碰到一位敏捷爱好者A君，寒暄过后...
A君:我们最近在推行结对编程，但是总也进行不下去，不知道你有什么好办法没有？
我并没有直接回答他的问题，反问到:那么你们为什么要推行结对编程呢？
这个句话打开了他的话匣子...
A君:因为结对编程可以解决……
又日，我碰到一位敏捷爱好者B君，寒暄过后...
B君:我们最近在推行测试驱动开发，但是大家很难坚持，不知道你有什么好办法没有？
我并没有直接回答他的问题，反问到:那么你们为什么要推行测试驱动开发呢？
这个句话打开了他的话匣子...
B君:因为测试驱动开发可以解决……
再日，我碰到一位敏捷爱好者C君，寒暄过后...
C君：我们最近在推行持续集成，但是效果不是很理想，不知道你有什么好办法没有？
我并没有直接回答他的问题，反问到:那么你们为什么要推行持续集成呢？
这个句话打开了他的话匣子...
C君:因为持续集成可以解决……
作为一位敏捷咨询师，笔者几乎每天都会遇见如此的敏捷爱好者，久而久之，发现一个问题:大家倾向于将敏捷看作一组松散的最佳实践，认为只要有选择的实践其中一些实践，即使不能获得敏捷的全部好处，这些实践的便宜总是能占全的。
图1 著名的Jeffries XP Model
图1为著名的Jeffries XP Model模型，揭示了极限编程方法之间的关联性。
在这张图表中，Don Jeffries将XP的十三个基本实践分成了三组。从内而外为开发人员个体实践 、XP团队写作实践和XP软件交付实践，每一组实践都具有极强的内在关联。下面笔者以最内层的实践为例，介绍敏捷实践的内在关联性。
最内层蓝色的实践为开发人员日常使用的实践，分别为Test-First Design、Pair Programming、Simple Design和Refactoring。
简单设计
简单设计（Simple Design）是敏捷开发中的一个基础实践，因为敏捷强调节约，不为没有出现的需求做过多的设计，不去承担不必要的风险，而仅仅专注于解决当前存在的问题。这个实践在被广为推崇的同时也备受争议，因为其使用了一个很暧昧不清的形容：简单。那么就紧接着出现了一个问题：怎样才算简单？
这个问题仅仅依靠简单设计自身并不能解决，需要依靠Test-First Design和Pair Programming论证。一般认为，如果5分钟之内不能完成当前设计的测试，那么这个设计就不简单。要么需要重新设计，要么缩短设计步骤，将设计分解为一些更小的步骤。
而如果5分钟完成了测试，但是pair不能在5分钟之内使测试通过。那么同样的结论产生了，设计不够简单。 要么需要重新设计，要么缩短设计步骤。结合Test-First Design和Pair Programming，空泛的简单设计就变成一个可度量可操作的实践。而不是一句空洞且充满争议的口号。
测试先行
测试先行或者测试驱动是大家都非常认可的做法，普遍认为这是一个可以极大的提高软件质量的实践。有很大一部分敏捷爱好者是通过测试先行或测试驱动开发而对敏捷产生兴趣的。
但是仅仅使用测试驱动开发，并不能保证一定可以获得高质量的软件。Kent Beck对于测试驱动开发曾有一句名言，“测试驱动开发不能避免愚蠢”，对于需求固执的偏见引起的软件质量问题是不可能通过测试驱动开发修正的。因此，测试驱动开发往往和结对编程（Pair Programming）一起使用，一起对需求进行探讨，并通过测试表述对于需求的理解，一起高质量地实现功能。
除了结对编程以外，测试驱动开发将软件开发的节奏很清晰地分为“测试－开发－重构－测试”的循环，因此重构（Refactoring）本质上也是和测试驱动开发密不可分的实践。
重构
重构也是大家比较推崇的一个实践，但这也是一个不能单独实施的实践。如果仔细审视重构的定义，会发现重构指的是“在不改变代码功能的前提下，修改代码的结构，从而获得更好质量的代码”。
于是问题就出现了，如何保证代码的功能没有变化？难道每修改一行代码都要对所有的功能进行测试？若真是这样，那么重构的成本将会增大许多。因此重构的前提是测试自动化，而取得自动测试的最佳途径就是测试驱动开发。在开发的过程中，直接将得到测试代码，同时自动化的测试代码也成为了重构的回归测试。可以说没有测试驱动开发，几乎不能进行任何有效的重构。
此外，重构和简单设计也有很大的关联。在开发过程中，很可能在某一个阶段，代码中所蕴含的设计并不够简单。这就需要使用重构，将代码重构到一个更为紧凑和简单的设计。因此简单设计是重构的目标，重构是保持简单设计的必要手段。甚至可以说，若不是为了简单设计的缘故，重构的价值也会大打折扣。
结对编程
结对编程是颇受争议的一个实践，大家广泛地质疑其会对开发效率产生负面影响。但是仍有一些颇具眼光的敏捷爱好者看到了其价值，认识到其对于知识传递、沟通的重要性。结对编程依然是一个不能独立实施的实践。
结对编程不是简简单单地将两个程序员组织在一起，必须提供必要机制增进程序员间的交流。一个广泛采用的结对编程方式称作PING-PONG Programming，在PING-PONG Programming中，结对的两个程序员中的一个负责编写测试，当测试完成之后，另一个程序员负责通过测试，如此反复。实际上PING-PONG Programming就是测试驱动开发的结对版，因此想要有效地实施结对编程，配合实施测试驱动开发是不二门法。
到此，诸位看官大约要抚掌：“妙哉，妙哉”，转过身去便将敏捷实践齐齐测试，将旧世界的碟儿碗儿砸得粉碎。慢着，过犹不及，敏捷实践的使用本身也是一个敏捷的过程，既在正确的时间、正确的地点使用正确的实践。敏捷实践最核心的内容是大家以最有效率的方法作正确的事情。在进行实践的时候，时刻提醒自己以下几个问题并及时进行调整:
客户是否满意；
团队成员是否满意；
交付是否及时；
运作是否顺利。
小步的即时调整对于敏捷项目极其重要。如果团队成员对于某项实践不适应，不要强迫开展。以结对为例，尝试一下在比较困难的几个Task让成员进行结对，集体决策的感觉一定会使团队成员心满意足，从心里喜欢这个实践，信任这个实践。
实际上敏捷的任何时间都不是孤立的，必须相互配合才能达到预期的效果。大家在实施敏捷方法的过程中，必须仔细审视各个实践间的关联，才能有效地发挥敏捷的作用。