敏捷开发是一项系统性的工作，需要根据团队特性量身定做，但仍然有一些普世的敏捷信条可以指导我们更加顺利地开展敏捷尝试。随着理解的深入，笔者会持续关注敏捷动态，为需要的好友们提供借鉴和思考。
极限编程（eXtreme Programming）敏捷方法，特别擅长于获得技术成功。
XP指导思想
1、客户也是研发团队的一员
在XP中客户不仅仅是指支付开发费用的人，有时，客户是和开发人员同属于一家公司的一组业务分析师或者市场专家；有时，客户是用户团体委派的用户代表。与客户紧密合作，时刻满足客户需求，解决实际问题。
正如笔者大学期间的一个上位机软件项目，是几周时间田导在旁边看着完成的，过程不时被打断并提出需求建议，而田导就是我的客户，与客户面对面沟通生产刚刚好的软件。
1、第一周根据田导要求实现硬件设计，调通下位机软件；
2、第二周实现网络数据上传，交付可以工作的软件，给田导演示上位机软件功能；
3、第三周田导进一步提出需求，完成上位机紧急报警功能；
4、第四周田导提出新的上位机界面需求，重构软件逻辑与界面设计；
5、田导对该项目的完成表示满意。
2、用户素材
正如上面笔者介绍的上位机项目，需求的特定细节很可能会随着时间而改变，一旦客户（田导）开始看到集成到一起的系统，就更会如此。看到可以工作的软件是关注需求的最好时刻，减少无用功，生产刚刚好的软件。
用户素材（user stories）-也有书籍称之为用户故事，就是正在进行的关于需求谈话的助记符。它是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。
用户故事虽然是非常小的特性或者部分特性，但是它体现用户价值。
3、短交付周期
开发者不断地集成代码，这使得团队可以在任何时候发布软件，只要它具有商业意义。整个团队都会集中精力去完成每一项特性，然后才开始下一项，这可以在软件发布之前防止难以预料的延期，并使团队可以随意改变方向。
发布计划不是一成不变的，客户可以随时改变计划内容。他可以取消用户素材，编写新的用户素材，或者改变用户素材的优先级别。
正如笔者之前的项目经历，每一个项目的结束，都会积累十几个版本的可以工作的软件，是不停迭代和完善的结果；
软件项目需要更多的需求、设计和测试——这就是为什么XP团队每天都从事这些活动（activity）。是的，每天。
4、结对编程
XP强调面对面协作。它可以如此有效地消除交流中的延迟和误解，以致于XP团队无需区分阶段（phase）。这使他们能够以“并行阶段”（simultaneous phases）每天从事于所有的活动。采用并行阶段，XP团队每周都产出可部署的软件。在每次迭代中，整个团队分析、设计、编码、测试和部署一部分特性。
XP开发者协同工作，这可以帮助他们跟踪大型项目的每一处小细节，并确保每一段代码都至少有两个人复查过。
5、重构
随着新特性的不断添加，软件结构会逐渐退化。如果对此置之不理的话，这种退化最终会导致纠结不清，难以维护的混乱代码。
正如笔者在华为所看到的，hisi平台代码由于长期的累积，混乱并且难以维护。但，他们也注意到了这一点，近期的代码重构确实很好地改善了这个问题，虽然还有很长的路要走。
重构就是在不改变代码行为的前提下，对其进行一系列小的改造，旨在改进系统结构的实践活动。所有这些改造叠加在一起，就形成了对系统设计和架构显著的改进。
6、文档极简原则
敏捷思想并不鼓励书写文档。敏捷宣言也宣告“可用的软件重于完备的文档”，但如果一个软件是长期更新和维护的，还是需要必要的文档来将所有有价值的历史信息记录下来的。
你如果刚加入一个敏捷团队来接手一个已经迭代了9个Sprint的软件，如果什么都没有你从哪里下手？但是不希望文档过于庞大，能把用户故事的关键点、设计的关键点记录下来就够了，特别是代码每次变更必须用注释描述清楚。
总结
敏捷的价值不仅仅在于其可以简约软件开发，更重要的是敏捷态度符合未来人性化发展需求，传播敏捷思想，探索商业价值。
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划