极限编程仅适用于小型项目，而scrum适用于大中小型项目。
可以把scrum看成是极限编程的一个加强版
-
scrum的核心内容是：团队架构和软件研发框架
scrum基本流程 scrum团队角色
产品负责人 product owner、SCRUM master、开发团队；产品负责人
职责：
提供愿景、提供需求的优先级；
需要注意的地方：
和开发团队沟通需求、考虑团队的研发能力；
- SCRUM master
职责：
类似教练的角色；没有行政的权利，不能fire掉团队的成员；训练团队成员用scrum原则做事；不代替团队成员做决定；
需要注意的地方：
不要替团队成员做决定；产品负责人和scrum master不建议是一个人；
- ”自组织“的开发团队
自组织的概念：
主动与产品负责人、SM沟通，个人能自我管理和主动协调工作，能从项目大局出发完成工作；
自组织团队的特点：
团队成员一起讨论需求、跨职能工作、自我管理、注重团队承诺；
- scrum的实践
scrum在需求方面的核心理念：
不要试图初期就细化全部需求；
通过用户故事来组织和细化需求；
所有成员都来参与需求讨论，明确细化需求；
- 用户故事
eg：作为网站的所有者，我希望可以统计网站的点击次数，以便我可以知道广告的收益情况。
由大到小将用户故事不停的拆分，然后通过讨论获得我们需要去执行的需求。
标准格式：
作为……角色；
希望系统可以……（目标）；
以便……（原因）；
难点：
发现和提炼用户故事，并对用户故事做拆分，安排故事的优先级，分派到不同的sprint中去实现；
用户故事的2大标准：
能在一个sprint中完成；
加入满意条件（用户故事的验收标准）；
满意条件：
业务流程要求；
业务数据结构要求；
可以用具体的数据、例子进行说明；
- Product backlog/Sprint backlog
product backlog:
产品代办列表，即产品需要完成的所有用户故事的合集，不同用户故事的颗粒大小有差别。
sprint backlog：
冲刺待办列表，sprint中需要完成的用户故事的合集，每一个用户故事应该对应有各自的满意条件。
- Sprint
一个sprint就是一个小版本，建议时长是一个月。
注意
在sprint中应该很难区分需求、设计、编码、测试阶段；
所有的工作都应该是基于用户故事的讨论；
测试先行、测试驱动、单元测试必不可少；
设计也是“涌现”式的；
自组织的用户团队，用户故事的完成不是以代码的完成作为衡量标准的，必须提交可以完成预期的成品，即可以交付使用，才可以算作是一个sprint的完成（即一个用户故事的完成）；
Burn down chart 燃尽图
来跟踪sprint未完成工作的情况；-
Sprint中的最佳实践
1、结对编程
A写完代码，B可以来做评审，同样B的代码A也要来做评审；
同一段代码至少有两个人熟悉；
两个人在工作中可以互相的切磋和进步；
2、持续集成
可用的软件比面面俱到的文档更优；
3、测试驱动、测试自动化
需求必须是大家一起确定的，在这个基础上我们就可以把测试看成是开发，同时把开发看成是测试；
4、每日会议
对照我们每个阶段的工作计划，说出【问题】
5、经验教训总结
