主流敏捷开发方法极限编程

　　eXtreme Programming 极限编程-XP
　　XP概述
　　XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。在以前的开发过程中，很多规则已经难于遵循，很多流程复杂而难于理解，很多项目中文档的制作过程正在失去控制。人们试图提出更全面更好的一揽子方案，或者寄希望于更复杂的、功能更强大的辅助开发工具（CaseTools），但总是不能成功，而且开发规范和流程变得越来越复杂和难以实施。XP就是在这样的情况下诞生的，它是灵巧的轻量级软件开发方法，它跳出复杂的流程和文档，而是以轻量的框架和极限的思想为核心进行开发。
　　这里讲的极限编程更像是一套理论知识，面向开发人员的指导，甚至是考核开发人员素质或者说优异程度的一个思想指标。虽然以下理论看起来难免枯燥无味，但是真正想了解敏捷开发的一些知识的还是需要好好阅读一下。我个人甚至觉得，XP提出的一些价值，原则，实践，可以用来培训一些开发新手，成为一套有理论依据的准则。当然，这样的准则还是需要根据情况调整，而不是生搬硬套。
　　（文章理论上的东西比较多，不好消化，需要思考理解，如果读者是快餐式阅读，建议不要浪费时间）
　　4大价值
　　沟通
　　XP方法论认为，如果小组成员之间无法做到持续的、无间断的交流，那么协作就无从谈起，从这个角度能够发现，通过文档、报表等人工制品进行交流面临巨大的局限性。因此，XP组合了诸如对编程这样的最佳实践，鼓励大家进行口头交流，通过交流解决问题，提高效率。
　　简单
　　XP方法论提倡在工作中秉承＂够用就好＂的思路，也就是尽量地简单化，只要今天够用就行，不考虑明天会发现的新问题。这一点看上去十分容易，但是要真正做到保持简单的工作其实很难的。因为在传统的开发方法中，都要求大家对未来做一些预先规划，以便对今后可能发生的变化预留一些扩展的空间。
　　反馈
　　反馈在团队合作中是非常重要的，不仅是客户与项目负责人之间的反馈，还应该包括开发人员在内，做到项目所有相关人自觉的反馈，让他人知道项目进度，每个开发人员任务完成情况，做到人人都能及时知道项目的情况，人员的情况。这样所有人都能心里有数，才能做到相互配合，有效的沟通。
　　勇气
　　要知道，XP是提倡拥抱变化的，那么要积极响应变化就需要相关相关人员，特别是开发人员有勇气来面对快速开发，重新开发，代码重构等情况，快速开发需要勇于面对更多h3ug，将一些h3ug留到下一版，重新开发要敢于废弃之前的努力，不要因为已经开发出来了即使没有什么用处也要使用，重构则是要勇于改变现状，让代码脱胎换骨。
　　5个原则
　　快速反馈
　　及时地、快速地获取反馈，并将所学到的知识尽快地投入到系统中去。也就是指开发人员应该通过较短的反馈循环，迅速地了解现在的产品是否满足了客户的需求。也就是需要我们持续交付，调整功能，这也是对反馈这一价值观的进一步补充。快速反馈同样适用于开发人员之间，团队人员之间，及时反馈，有效沟通。
　　简单性假设
　　类似地，简单性假设原则是对简单这一价值观的进一步补充。这一原则要求开发人员将每个问题都看得十分容易解决，也就是说只为本次迭代考虑，不去想未来可能需要什么，相信具有将来必要时增加系统复杂性的能力，也就是号召大家出色地完成今天的任务。这点下文还会继续说明。
　　逐步修改
　　就像开车打方向盘一样，不要一次做出很大的改变，那样将会使得可控性变差，更适合的方法是进行微调。而在软件开发中，这样的道理同样适用，任何问题都应该通过一系列能够带来差异的微小改动来解决。
　　提倡更改
　　在软件开发过程中，在解决最重要问题时，尽量为下一次修改做好准备。开发不息，h3ug不断，我们都要打从心里明白，h3ug是不可能有完全修改完的一天的，所以需要不断进行更改，也不要守着最初的方案，不敢做任何变动，要为随时可能到来的改动做好心里准备。
　　优质工作
　　在实践中，经常看到许多开发人员喜欢将一些细小的问题留待后面解决。例如，界面的按钮有一些不平整，由于不影响使用就先不管；某一两个成员函数暂时没用就不先写等。这就是一种工作拖泥带水的现象，这样的坏习惯一旦养成，必然使得代码质量大打折扣。而在XP方法论中，贯彻的是＂小步快走＂的开发原则，因此工作质量决不可打折扣，通常采用测试先行的编码方式来提供支持。
　　总结
　　优质工作这点是个人自觉问题，特别体现开发人员的个人素质，拖泥带水这个问题经常出现在进度比较赶的情况下，但PM或者leader也不能在这点上面妥协，而且一般这种问题也不会消耗很多开发时间，都是一两句代码的事，有时只是开发人员懒得去修改而已。一旦妥协，以后这种情况必然反复出现。逐步修改这点除了开发人员实现，同时还需PM来配合，在迭代中进行微调，将更改控制在可控范围，不会造成太大影响。
　　13个最佳实现
　　计划游戏
　　计划游戏的主要思想就是先快速地制定一份概要的计划，然后随着项目细节的不断清晰，再逐步完善这份计划。计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。
　　编写故事：由客户或者PM谈论系统应该完成什么功能，确定需求。
　　进行估算：开发人员对每个用户故事进行估算，先从高优先级开始估算。如果在估算的时候，感到有一些故事太大，不容易进行估算，或者是估算的结果超过2人/周，那么就应该对其进行分解，拆成2个或者多个小故事。
　　迭代周期：接下来就是确定本次迭代的时间周期，这可以根据实际的情况进行确定，不过最佳的迭代周期是2~3周。
　　小型发布
　　XP方法论秉承的是＂持续集成，小步快走＂的哲学，也就是说每一次发布的版本应该尽可能的小，当然前提条件是每个版本有足够的商业价值，值得发布。
　　由于小型发布可以使得集成更频繁，客户获得的中间结果也越频繁，反馈也就越频繁，客户就能够实时地了解项目的进展情况，从而提出更多的意见，以便在下一次迭代中计划进去。以实现更高的客户满意度。
　　隐喻
　　创造心照不宣的词汇和列子，更形象有趣的沟通。比喻有时候更能让人更快更好的理解你的意思，而不是一堆晦涩专业术语。
　　简单设计
　　简单设计这个实现是一个很容易让人误解，也让许多批评者诟病的一条实现，因为它秉承＂够用就好＂的思路，尽量地简单化，只要今天够用就行，不考虑明天会发现的新问题，明明是拥抱变化，怎么又不考虑明天的问题了呢。而在传统的开发中，需要我们考虑后期可能的需求，让代码做到高可扩展性，要求我们经常考虑后期需求。这样看起来，传统开发在这个方面似乎比XP更贴近拥抱变化的思想，我们再仔细看看。
　　这里的简单设计提出没有重复代码，尽量少的类和方法，使用迪米特法则等，只是针对今天而言，不要因为后期可能会用到，就添加了一个现在不用的类或者方法，而不是不做可扩展性，这两者并不冲突。即使因为没有考虑很多，而可拓展性没有做到很好，XP提倡重构也能将扩展性提高一个档次，而且更精确更符合现在的需求。而传统的方式将一切考虑到位也不见得扩展性就完美，毕竟变化是不可预测的，现在考虑的扩展性在几个月后可能也用不上了，到时必然也是要重构。
　　简单设计从本质上来说扩展性就很强，就像一张白纸，要怎么画都行，就看你能不能体会到其中的深度了。
　　测试驱动开发
　　这个是常规思维难以理解的概念，测试先行，程序都没写出了，怎么测试？参考资料的例子非常好：
　　工匠一：先拉上一根水平线，砌每一块砖时，都与这跟水平线进行比较，使得每一块砖都保持水平。
　　工匠二：先将一排砖都砌完，然后再拉上一根水平线，看看哪些砖有问题，对有问题的砖进行适当的调整。
　　工匠一代表的就是测试驱动开发的方法，当然为了有效的实现它，需要我们借助一些自动化测试工具。
　　XP鼓励程序员原意甚至喜欢在编写程序之前编写测试代码，所以提供了以下一些理由：
　　如果你已经保持了简单的设计，那么编写测试代码根本不难。
　　如果你在结对编程，那么如果你想出一个好的测试代码，那么你的伙伴一定行。
　　当所有的测试都通过的时候，你再也不会担心所写的代码今后会＂暗箭伤人＂，那种感觉是相当棒的。
　　当你的客户看到所有的测试都通过的时候，会对程序充满前所未有的信心。
　　当你需要进行重构时，测试代码会给你带来更大的勇气，因为你要测试是否重构成功只需要一个按钮。
　　这样的尝试还是需要勇气的，这也是XP的核心价值，不真正去使用去理解，一般人都会觉得天马行空。
　　重构
　　重构时一种对代码进行改进而不影响功能实现的技术，XP需要开发人员在闻到代码的坏味道时，有重构代码的勇气。重构的目的是降低变化引发的风险，使得代码优化更加容易。重构有时并不是需要做很大的修改，不用谈虎色变，对于XP来说，它只是一个常规操作。
　　结对编程
　　简单来说就是两个人坐在一起写程序，结对编程也是一个饱受质疑的举措，一般认为它过于耗费人力资源，自尊心较强的开发人员也比较排斥结对编程。
　　当然结对编程也有结对编程的好处：
　　所有的设计决策确保不是由一个人做出的。
　　系统的任何一个部分都肯定至少有2个人以上熟悉。
　　几乎不可能有2个人都忽略的测试项或者其他任务
　　结对组合的动态性，是一个企业知识管理的好途径。
　　代码总是能够保证被评审过。
　　而且XP方法论集成的其他最佳实践也能够使得结对编程更加容易进行：
　　编码标准可以消除一些无谓的分歧。
　　隐喻可以帮助结对伙伴更好地沟通。
　　简单设计可以使得结对伙伴更了解他们所从事的工作。
　　结对编程还是要视情况使用，并不是有理论支持的就一定适用，如果觉得使用结对效率不高，还可以通过Leader审核代码来替代。
　　集体代码所有制
　　由于XP方法论鼓励团队进行结对编程，而且认为结对编程的组合应该动态地搭配，根据任务的不同、专业技能的不同进行最优组合。由于每个人都肯定会遇到不同的代码，所以代码的所有制就不再适合于私有，因为那样会给修改工作带来巨大的不便。
　　也就是说，团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。同时，XP强调代码是谁破坏的（也就是修改后发生问题），就应该由谁来修复。
　　由于在XP项目中，集成工作是一件经常性得工作，因此当有人修改代码而带来了集成的问题，会在很快的时间内被发现。
　　由于每一个类都会有一个测试代码，因此不论谁修改了代码，都需要运行这个测试代码，这样偶然性的破坏发生的概率将很小。
　　由于每一个代码的修改就是通过了结对的两个程序员共同思考，因此通常做出的修改都是对系统有益的。
　　由于大家都坚持了相同的编码标准，因此代码的可读性、可修改性都会比较好，而且还能够避免由于命名法、缩进等小问题引发经常性得代码修改。
　　持续集成
　　持续集成是指团队每天尽可能多次的进行代码集成，保证团队获取的代码都是近期统一过的代码，避免太多不一致造成冲突。而上文说的小型发布则是更多的发布测试版本，中间版本，让客户或者PM审核，确认功能开发没有错误。需要我们引入代码管理工具，版本控制工具。
　　可持续的速度
　　简单来说，就是反对加班，将进度控制在合理的范围，让开发人员保持一个健康高效的状态。
　　做到让开发人员享受开发，而不是让他们感受到了煎熬。
　　现场客户
　　为了保证开发出来的结果与客户的预想接近，XP方法论认为最重要的需要将客户请到开发现场。就像计划游戏中提到过的，在XP项目中，应该时刻保证客户负责业务决策，开发团队负责技术决策。因此，在项目中有客户在现场明确用户故事，并做出相应的业务决策，对于XP项目而言有着十分重要的意义。特别是在发布中间版本后，需要客户进行体验，确保业务功能正确。
　　编码标准
　　如果你的团队已经拥有编码标准，就可以直接使用它，并在过程中进行完善。如果还没有，那么大家可以先进行编码，然后在过程中逐步总结出编码规则，边做边形成。当然除了这种文字规范以外，还可以采用一些如自动格式化代码工具之类的方法进行代码规范。事实上，你只需要很好地贯彻执行其他的实践并且进行通，编码标准会很容易地浮现出来。
　　配合是关键
　　有句经典名言＂1+1>2＂最适合表达XP的观点，Kent h3eck认为XP方法论的最大价值在于在项目中融会贯通地运用12个最佳实践，而非单独地使用。你当然可以使用其中的一些实践，但这并不意味着你就运用了XP方法论。XP方法论真正能够发挥其效能，就必须完整地运用12个实践。你甚至可以跳出XP开发方法，和其他开发方法进行结合，只要是遵循敏捷宣言的方法，必定有它们共同之处，也有能够相互配合，更加完善的地方。