eXtreme Programming
关于极限编程在很久以前就听过了，忘记了是在大学还是刚毕业的时候，那会认为的“极限”可能就是不停的coding，随着工作时间的增长，又听说了敏捷和TDD测试驱动开发，就是上来先写测试，测试通过之后再去写业务流程，这时自己已经当野战军有一段时间了，对于这个TDD很是排斥，自己也去尝试过使用这种模式去开发，但是上手的时候才知道痛苦，还没有自己的那一套开发快，后来就放弃了。
去年很荣幸的加入了thoughtworks北京，入职培训的过程中了解到了作为以敏捷著称的公司如何在项目的交付过程中去践行敏捷，把敏捷贯穿到整个项目的生命周期。在公司工作一段时间以后，确实发现敏捷对于项目的快速交付有很好的积极作用，这次通过我的buddy推荐，我看了看《解析极限编程–拥抱变化》，简称XP的这本书，发现书中所说的一些具体实践比如站会，看板，结对编程了这些在日常的工作中已经在使用了，XP和Scrum是敏捷流程具体实践的两种方法，我在培训中了解到公司主要以Strum为主，看来也有学习XP实践中的优点。
书的前半部分感觉像是一套理论知识，就好像要给人洗脑一样，尤其面向开发人员提出的一些价值、原则和实践，我觉得对于培训一些刚入手开发的同学有很大的帮助，可以很早的养成这样的思维方式，当然不是完全的生搬硬套，根据自己的实际情况去选择。书中理论上的东西比较多，不好消化，需要思考和理解。总的来说可以有下面几个大方面。
价值观
沟通
XP方法论认为，如果小组成员之间无法做到持续的、无间断的交流，那么协作就无从谈起，从这个角度能够发现，通过文档、报表等人工制品进行交流面临巨大的局限性。因此，XP组合了诸如对编程这样的最佳实践，鼓励大家进行口头交流，通过交流解决问题，提高效率。
简单
XP方法论提倡在工作中秉承“够用就好”的思路，也就是尽量地简单化，只要今天够用就行，不考虑明天会发现的新问题。这一点看上去十分容易，但是要真正做到保持简单的工作其实很难的。因为在传统的开发方法中，都要求大家对未来做一些预先规划，以便对今后可能发生的变化预留一些扩展的空间。
反馈
反馈在团队合作中是非常重要的，不仅是客户与项目负责人之间的反馈，还应该包括开发人员在内，做到项目所有相关人自觉的反馈，让他人知道项目进度，每个开发人员任务完成情况，做到人人都能及时知道项目的情况，人员的情况。这样所有人都能心里有数，才能做到相互配合，有效的沟通。项目进行的过程中，大概二个星期做一次retry。
勇气
要知道，XP是提倡拥抱变化的，那么要积极响应变化就需要相关相关人员，特别是开发人员有勇气来面对快速开发，重新开发，代码重构等情况，快速开发需要勇于面对更多bug，将一些bug留到下一版，重新开发要敢于废弃之前的努力，不要因为已经开发出来了即使没有什么用处也要使用，重构则是要勇于改变现状，让代码脱胎换骨。
尊重
每个人在团队中都是不可缺少的一部分，我们要互相关心彼此，理解别人所做的事情，这样XP才能发挥出最大的效用。受软件开发的影响，每个人的都有自己为人的价值观，不会有某个人本质上比其他人更有价值。所以要提高软件开发的人性和生产率，每个人对团队的贡献都应该得到尊重。我是重要的，你也是。
其他
上面的几种价值观不是高效软件开发所必需的价值观，但是对于在项目中可以用来矫正团队的行为，当然也可以选择其他的价值观，比如安全、保密、可预测性和生活品质等，这些不同的价值观可以修正你的实践，把产生的浪费降至最低。
原则
人性化
软件是由人来开发的，在软件开发的过程中，如果忽视掉这个，这会对软件的开发没什么好处，会因为人员更替带来不必要的成本和断层，也失去了创新的机会。团队工作时间之外的时间可以给每个成员更多的活力和视野，并在工作的时间把他们带回给团队。限制工作时间就是为了给其他人性化需求挪出时间，从而提高每个成员在团队工作时的贡献。
经济学
要确定你正在做的这些东西有商业价值，符合商业目标和商业需求。例如首先解决最高优先级的业务需求会使项目的价值最大化。要保证我们所做的事情是明确的需求，每一次的新的功能开发和部署都是有价值的，可以得到相应的收入，不在没把握的地方投资，不做无用功。
互惠互利
任何一个问题总是有让某人付出代价而其他人获益的解决方案。计算机业务其实是人的业务，维护工作关系是很重要的。如果你想要人们接受你的意见，那你就该解决更多的问题，而不是制造更多的问题。
自相似性
在软件开发过程中，自相似性不是仅有的起作用的原则。在一个环境中起作用的结构并不意味着它在另外一个环境中也能起作用。同样的，仅仅因为一个解决方案是独特的，并不意味着它就不好。可能这种环境就是需要一个独特的方案。
改进
软件开发的卓越是通过改进达到的。马上开始行动，随着时间的推移逐步精化结果，根据经验改进长期的计划，这个可能性通过季度周期这一实践得到表现。增量式设计通过精化系统设计来贯彻改进原则。要在工作中改进，而不是等待完美。找一个起点，开始，然后改进。
多样性
团队需要将不同的技能、态度以及看待问题和缺陷的视角整合在一起，来考虑问题和实现解决方案的不同方法。也就是说团队需要多样性。在各种不同技能和视角的人组成的图队中，多样性体现在“完整团队”的实践中。为了在可用时间内创造最有价值的软件这个共同目标，不同的计划周期促使着不同观点的人相互影响。
其他的一些原则
这里还有一些其他遵循的原则，比如反省、质量、婴儿步、接受责任等。你可以用这些原则去更好的理解实践，也许理解如何在具体的环境中应用这些实践也许不是那么容易的事情，但这些原则可以更好的告诉你某个实践要达到什么目的。同样，没有一个固定的环境相关实践列表能够覆盖各种软件开发的情况，你需要不断的创造新的实践来满足特定的需求。理解这些原则，你就能够创造和过去的实践以及整体目标相和谐的新的实践。
实践
实践是一个向量，从你现在所在的地方指向你用XP能够达到的地方。在XP中，你是在朝着这种高效开发的理想状态前进。XP实践不是软件开发进化的顶点，而是改进之路上的普通驿站。XP实践一起应用时，效果会更好。一次采取一个实践可能会看到改善，但多个实践结合在一起时你将会看到惊人的改进。下面图上把实践分为了基本实践和扩展实践，无论你使用了何种做法，基本实践都是有用的，它们可以令你马上提高。并且从其中任何一个开始都是可以的。如果没有首先掌握基本实践的话，应用扩展实践可能会困难一些。
下面的一些是我在软件开发中接触或者使用到的一些方法。
重构
重构是一种对代码进行改进而不影响功能实现的技术，XP需要开发人员在闻到代码的坏味道时，有重构代码的勇气。重构的目的是降低变化引发的风险，使得代码优化更加容易。重构有时并不是需要做很大的修改，不用谈虎色变，对于XP来说，它只是一个常规操作。《重构》这本书也在看，虽然看的很慢.
小版本
为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划，我觉得这就是showcase加MVP。
TDD
极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。
持续集成
持续集成是指团队每天尽可能多次的进行代码集成，保证团队获取的代码都是近期统一过的代码，避免太多不一致造成冲突。而上文说的小型发布则是更多的发布测试版本，中间版本，让客户或者PM审核，确认功能开发没有错误。需要我们引入代码管理工具，版本控制工具。
结对编程
结对编程是一种两个人之间的对话，他们同时编程分析、设计和测试并尽量编的很好，这样使彼此都专注于任务，一起头脑风暴，讨论系统的精化，理清自己的想法，当搭档陷入困境时要主动，这样才能减少挫折，使彼此都对团队的实践负责。结对编程在刚开始很辛苦，但是后面的效果是非常好的，尤其是和一位大神级别的人物一起编程，对自己的编程能力，思考问题的方式都有很大的帮助，当然这里我们在结对编程的时候需要尊重别人，不要带着情绪或者不礼貌的行为，这样反而违背了结对的本来意义。
编码标准
如果你的团队已经拥有编码标准，就可以直接使用它，并在过程中进行完善。如果还没有，那么大家可以先进行编码，然后在过程中逐步总结出编码规则，边做边形成。当然除了这种文字规范以外，还可以采用一些如自动格式化代码工具之类的方法进行代码规范。事实上，你只需要很好地贯彻执行其他的实践并且进行通，编码标准会很容易地浮现出来。
总结
一根筷子容易掰段，但是10根100根呢，团队的力量才是最大的，兄弟同心,其利断金，要相信 1 + 1 > 2 的观点，XP在我们开发的过程中最大的价值在于在项目中融会贯通地运用实践，结合自身团队的实际情况，创造出适合自己团队的实践方法，总结出一套高效率的实践组合；同时个人积极去实践XP，不仅对自己在项目中发挥作用有帮助，而且对自己以后的工作都能提供有效的方法论支持。