XP的极限编程（eXtreme Programming）
XP由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联， 并通过行为贯穿于整个生命期。
四大价值观：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）
五大原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作
极限编程13个最佳实现
现场客户( Customer Tests)：客户长期与开发人员在同一间办公室办公，随时解决开发人员关于需求的问题。现场客户负责编写用户故事，负责决定用户故事的优先级以及实现顺序。现场客户负责编写验收测试用例。
代码规范 ( Code Standards )：开发团队应该拥有一个编码标准。
完整团队（Whole Team）：XP的核心是其总结的沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）四大价值观，一切都建立在团队成员之间的相互关心、相互理解的基础之上。
集体所有（Collective Ownership）：团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。同时，XP强调代码是谁破坏的，就应该由谁来修复。
平稳工作 ( Sustainable Pace )：加班最终会扼杀团队的积极性，最终导致项目失败，每周工作40小时是一种顺势行为，是一种规律。
计划博弈 ( Planning Game )：客户编写故事，开发人员进行估算，确定迭代的周期。
系统隐喻 ( System Metaphor )：寻求共识，发明共享词汇，描述体系结构。隐喻是设计和沟通的辅助手段，使项目成员对于系统的实现方式达成共识。
简单设计 ( Simple Design )：只要今天够用就行，不考虑明天会发现的新问题。
测试驱动 ( Test-driven )：测试先行
代码重构 ( Refactoring ) ：时刻对代码进行重构，一直保持其良好的结构与可扩展性。集体CodeReview也是很重要的。
结对编程 ( Pair Programming )：系统的任何一个部分都肯定至少有2个人以上熟悉，好处是代码会被100%review，有效地降低代码缺陷率。
持续集成 ( Continuous Integration )：开发人员坚持随时进行提交，系统每天一次集成。
小型发布 ( Small Release )：开发周期经常发布中间版本。要做到小型发布，则必须先实现持续集成
敏捷开发之Scrum
Scrum开发流程中的三大角色：产品负责人（Product Owner），流程管理员（Scrum Master），开发团队（Scrum Team）
1、产品负责人按优先顺序排列确认一个产品需求列表（Product Backlog）
2、开发团队根据Product Backlog列表，做工作量的预估和安排
3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（任务计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog（任务列表）；
4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（任务燃尽图）；
6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；
7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
敏捷开发XP 和 Scrum的区别
| \ | XP | Scrum |
|---|---|---|
| 迭代周期 | 1-2周 | 2-4周 |
| 是否允许修改需求 | 在一个需要没有实现的时候可以使用其他的需求将其替换，但是实现的时间是要相等的 | Scrum是不允许这样做的，一旦迭代开工会完毕，不允许有改变，并有Scrum Master严格把关 |
| 需求是否严格按照优先级实现 | 是 | 不用 |
| 是否采用严格的工程方法，保证进度或者质量 | 非常严格 | 要求开发者自觉 |
无招胜有招，不用太过在意方法，只要对提高效率有用的，都可以用上。（加班除外...^_^），再推荐个不错的工具：https://www.tapd.cn/
