一、敏捷宣言
12原则
最重要的目标是通过持续不断尽早交付有价值的软件使客户满意；
欣然面对需求变更即使在开发后期。为了客户的竞争优势。敏捷拥抱变化；
经常的交付可工作的软件，倾向于采取较短的周期；
业务人员与研发人员每天要一起工作；
激发个体斗志，以他们为核心搭建项目。提供所需环境和支持，辅以信任；
不论团队内外，传递信息最好的额方式是面对面交谈；
可工作软件是衡量进度的首要指标；
敏捷流程提倡可持续的开发，赞助商、开发、用户应该能够保持持久稳定的进度和速度；
对技术卓越和好的设计的持续关注有助于增强敏捷性；
尽量做到简洁，尽最大可能减小不必要的工作；
最佳的架构，需求和设计出自自组织团队；
团队要定期回顾和泛型如何更有效，并相应的调整团队行为。
对于1-3需要利用一些好的世间：
迭代（iteration）：重复完成所有项目活动来持续交付可用软件。如果计划不周，所有未完成的工作就会回到待办列表，并调整其优先级（推到下一个迭代）。
待办列表（backlog）：管理不断变化的需求。（scram sprint就是迭代的一种形式，维护当前sprint和整个产品的待办列表）
Scrum价值观
开放：知道对方在做什么，开发讨论问题和障碍
尊重：互相尊重、信任彼此能完成任务
勇气：有勇气接受挑战，为项目挺身而出（对无法达到的目标说不）
专注：专注于Sprint目标，一次只完成一个任务
承诺：承诺尽其所能交付最有价值的产品（集体承诺、公司表达承诺的方式：团队有权决定Spring backlog）
Scrum三大支柱：团队要在整个Sprint中适应变更
透明：理解所有特性，公开在做、计划和问题
检查：（每日站会）经常检查，确保知识是最新的
适应：不断寻求方法，根据新信息调整下一步计划工作
二、Scrum实践-GASP
用户故事（User stories）
帮助掌握用户对软件的需求。从而按“块“(可供用户使用)构建软件。作为一个<用户类型>，我希望<采取行动>以得到<希望的结果>
指导原则：INVEST (XP)
Iudependat：用户故事能相互独立描述
Negotiabe：产品的所有特性都是协商结果
Valuable：有价值的
Ectimatalble：可估计的规模或工作量
Small：描述独立的交互而不是庞大的功能体系
Testabke：可测试验证的
故事点（Story Points）
用来描述一个用户故事需要的工作量，强调每个故事的相对规模
规则扑克（Planning poker）
团队在确定各个故事的故事点时解释他们做出的估计，最终对于方法以及估计达成一致。
任务板（Tack boards）
保证所有故事状态对团队透明
燃尽图（Burn down charts）
帮助确认还有多少工作要做
燃烧图（Burn up charts）
将进度和范围分开
故事地图
确认待办列表的优先顺序，使团队直观地看到发布计划。
产品待办列表细化会议（PBR）：当前Sprint即将结束时，下一个Sprint开始计划之前。
主干：产品的核心特征，地图上所有特性的高层分组。
行走的骨骼：主干最重要的用户故事。
用户画像（Person）
更好的了解用户和利益相关者
回顾
可以帮助团队改进他们的工作方式
准备：回顾的目标和重点（签到、ESVP技术：Explorer shopper、Vocatiover Prisoner）
收集数据：时间表（Timeline）、色码点（Color code Dots）对时间表事件的态度
产生见解：找出问题的根本原因（鱼骨图）
决定做什么：小标题（停止/开始/继续）
三、极限编程（XP）
拥抱变化，关注团队具体如何构建代码，侧重软件开发与编程
XP团队使用用户故事跟踪用户需求（规则扑克）作为一个···我希望···这样就能···
利用季度循环（Quarterly cycle）计划待办列表
使用松弛（slack）为每个迭代增加额外的工作量 加入少量‘可有可无’的用户故事以预留空间（<20%）
季度会议：
开会反思过去季度发生了什么
讨论全局问题
计划本季度主题，明确长期目标Vs.Scrum中的Sprint目标，使用主题雀稗没有以偏概全
计划本季度待办列表，与用户与利益相关者会面
季度循环分解为周循环（Weekly cycle）：选择用户故事，并构建这周结束时“完成”的可用软件
每个循环开始时：
演示可用的软件
审查进展
与客户一起选择本周的用户故事
将用户故事分解成任务
XP价值观
勇气：有勇气接受挑战，有勇气说NO
尊重：信任彼此能完成任务
简单：XP团队不会牺牲简单性来得到可重用性
沟通：
反馈
敏捷团队综合使用Scrum和XP，将Scrum的经验过程控制和XP对团队凝聚力沟通、代码质量和编程的关注结合起来
XP实践
XP团队没有固定或指定的角色，最终要建立一个支持性环境，信任、允许队友犯错误。
