SCRUM 精髓-敏捷转型指南

第一章 引子

1. Scrum是一种用于开发创新产品和服务的敏捷方式；在每个迭代结束时，团队应当得到一个潜在可发布产品；
2. Scrum适用于复杂域，因为不可预测性多于可预测性；在这种环境下，大量的互动和交流必不可少（繁杂域适合通过专家找到最优解决方案；简单域适合采用标准流水作业方式；混乱域需要能够快速响应立即采取行动的方式；无序域则需尽量摆脱这个域）；
3. Scrum不适用于事务性的工作环境，如客服支持类；这一类型更适合采用看板；

第二章 Scrum框架

1. 角色
   • 产品负责人：负责决定要开发什么，以什么顺序开发；
   • ScrumMaster：负责指导团队在Scrum框架上建立并遵循自己的过程；
   • 开发团队（由几种职位组成的团队，负责产品设计、构建和测试）：负责确定如何交付产品负责人要求的产品；
2. 活动
   • 冲刺规划：故事点或理想天数；任务用小时数；
   • 每日立会：不是用来解决问题，而是检视、同步、适应性的制定每日计划的活动，帮助自组织团队更好的完成自己的工作；
   • 冲刺执行：团队要自己定义自己的任务级工作；
   • 冲刺评审：与业务部门一起，将把刚做完的特性到整体开发工作的背景下进行讨论；每个参与者都能了解现状，都有机会指导下一步的工作，以确保产出最合适的解决方案；经常收到业务部门反馈，可以使Scrum团队进一步理解产品的业务和市场；
   • 冲刺回顾：Scrum团队一起讨论哪些Scrum实践是可行的，哪些是不可行的；重点是为了持续的改进，以便下一个冲刺可以做得更好；
   • 产品列表梳理：整理未完成的待处理事项，优先级排序，为下一次的冲刺做准备；
3. 工件
   • 产品列表：产品特性列表及其优先级；
   • 冲刺列表：产品特性下的任务清单及其小时数；
   • 潜在可交付产品增量；
4. 完成的定义：
   • 最低限度：产出一个完整的产品功能，经过设计、构建、集成、测试并且编写了文档；
   • 最高程度：当业务部门想要交付（部署、发布）时，可以构建出可发布的产品；
   • 备注：不同阶段，定义可以不同；前期以最低限度为主，后期以最高程度为主；

第三章 敏捷原则

1. 可变性和不确定性
   • 积极采用有帮助的可变性：非制造业的固定工艺工序，软件中的每个实例特性的独特性，都可能导致可变性时时发生；
   • 采用迭代和增量开发：迭代-因为可能做错，需要快速调整；增量-可以快速得到验证，而非等到最后一刻；
   • 通过检验、调整、适应和透明来利用可变性：参与创建产品的每一个人都必须能够得到与WIP相关的所有重要信息，透明->检视->调整；
   • 同时减少各种形式的不确定因素：不知道做什么、怎么做、为谁做；通过构建-展示-响应-修改，四个环节的循环来减少不确定；
2. 预测和适应；
   • 不到最后时刻，不轻易决定：做决策有成本，不做决策有成本；当后者成本大于前者时，才做决策；
   • 承认无法一开始就把事情做对；
   • 偏好适应性、探索式的方法：通过快速构建原型来获得知识；
   • 用经济合理的方式接受变化：减少库存，一开始不要做太多事，而是做刚好够用的事即可；这样当出现变更时浪费的东西最少；
   • 在预测型事前工作和适应型刚好及时的工作之间做出平衡：前期工作有帮助，但不宜过度，只要能够确认大方向和几个重要的特性即可；
3. 经验认识
   • 快速验证重要的假设：重要的假设力求最少；
   • 利用多个认知循环并行的优势：假设-构建-反馈-检视-调整；
   • 组织工作流程以获得快速反馈；
4. WIP
   • 使用经济合理的批量大小：如果可以的话，尽量偏小一点，即一次性处理的需求应少一点；
   • 识别并管理库存以达到良好的流动：不要制造大量库存，否则可能会是浪费；
   • 关注闲置工作（工作停滞，没人干），而非闲置人员（没活儿干）：关注接力棒，而不是跑步的人；CPU如果100%工作反而降低效率；
   • 考虑延期成本：如果该做的工作未做，导致整个项目延期，其成本远大于闲置人员的浪费，时间也是金钱；
5. 进度
   • 适应实时的信息并重新制定计划；计划用于参考，但更注重实时信息并对计划进行调整；
   • 通过验证工作结果来测量进度：重要的不是开始了多少工作，而是完成了多少对客户有价值的工作；
   • 专注于以价值为中心的交付：价值是通过向客户交付可工作的资产、验证重大假设、获得有价值的认知来实现的；
6. 执行
   • 快速前进，但不匆忙：稳定的节奏往往跑得更快和更远；
   • 以质量为魂：将测试与质量把控内置于每一次冲刺周期中，而非放到最后关头；
   • 选用最小、够用的仪式：
     • 文档要作为产品的一部分交付；
     • 保存重要的讨论、决定或协议，以便大家今后能够想起讨论过的内容和决议；
     • 文档是很有价值的，可以帮助新的团队成员迅速跟进；
     • 行业监管要求提供文档（受监管的行业的业务）；

第四章 冲刺

1. 限定时长，优点：
   • 设定WIP数量限制；
   • 强制排列优先顺序；
   • 展示进度；
   • 避免不必要的完美主义；
   • 促进结束；
   • 增强可预测性；
2. 持续期短，优点：
   • 容易规划；
   • 反馈快；
   • 错误有限；
   • 投入产出比高；
   • 有助于“满血复活”；
   • 检查点多；
3. 一致的持续期，优点：
   • 有节奏感；
   • 简化规划活动；
4. 锁定冲刺目标：
   • 共同承诺；
   • 澄清，而非变更；
   • 注重实效；
   • 异常终止及下一个冲刺的相应调整；
5. 完成的检查列表；
   • 设计评审完成；
   • 代码完成；
     • 代码重构完成；
     • 代码是标准格式；
     • 代码已加注释；
     • 代码已提交；
     • 代码已检查；
   • 最终用户文档已更新；
   • 测试完成；
     • 完成单元测试；
     • 完成集成测试；
     • 完成回归测试；
     • 完成平台测试；
     • 完成语言测试；
     • 零已知缺陷；
     • 完成接收测试；
   • 已在生产服务器上线；
6. 完成的定义：需包含接收标准，产生一个潜在可发布的产品增量，达到大家所认可完成定义相一致的程度；

第五章 需求与用户故事

1. 事实：需求一开始无法全部清楚，如果一开始投入太多时间整理需求，可能在后面变更的时候，发现前面的时间浪费掉了；所以，更建议让需求在过程中逐步细化；
2. 用户故事的目的是为了帮忙业务人员和开发人员都能理解需求，如果目的能够达到，格式反而次要；
3. 故事的3C：
   1. 卡片：做为（角色），我想（目标），这样可以（利益）（注：写出需求的目的很重要，因为同样的目的，实现的方式有多种）；
   2. 对话：口头交流进一步探讨确认需求的细节；
   3. 确认：需求的满意条件，或者接受标准；（写出来有利于开发人员评估实现难度，以及测试人员清楚验收标准）
4. 需求的几个抽象级别：史诗（月）、特征（周）、主题（周）、故事（天）、任务（小时）；
5. 好故事的INVEST原则：独立、可协商、有价值、可估算、大小合适、可测试；（如果一个技术故事产品负责人认为没有价值，则不应列入产品列表）
6. 非功能性需求更多应列入完成定义或者接受标准中；
7. 知识获取型故事：获取该信息的成本vs失败重来的成本*0.5；快速失败策略；
8. 收集故事
   1. 用户故事写作研讨会：
      • 定义角色–史诗–故事；
      • 直接头脑风暴；
9. 总结：故事是一种占位符，提供了对话的起源；故事有抽象级别，随进度从大往小细化；

第六章 产品列表

1. 概述：有优先顺序的一些特征、在团队成员中共享；
2. 类型：特性、变更、缺陷、技术改进、知识获取；
3. 四个特征DEEP：详略得当、经过估算、有优先顺序、涌现的；
4. 梳理：确立PBI、细化PBI、估算PBI、排序PBI；
5. 由谁梳理：团队成员一起，包括内部/外部利益干系人、产品负责人、开发团队；最终决策者：产品负责人；
6. 何时梳理：定时梳理，减少协调时间的成本；其次考虑冲刺过程中穿插进行；确保梳理活动紧密集成到SCRUM过程中更重要；（在冲刺评审后梳理较好，这样团队从业务成员那边得到的反馈，有助于梳理的进行）
7. 就绪的定义：
   1. 清楚的表达业务价值；
   2. 有开发团队能够理解的足够细节，以便能针对是否能够完成PBI做出明智的判断；
   3. 已经识别出依赖关系，不存在阻碍PBI完成的外部依赖关系；
   4. 完成PBI所需要的人手齐备；
   5. PBI估算后足够小到很容易在一个冲刺中完成；
   6. 接收标准定义清晰并且是可测试的；（或者叫满意条件，听起来更生动易理解）
   7. 性能标准定义清晰并且是可测试的；
   8. SCRUM团队很清楚在冲刺评审的时候如何演示PBI；
8. 版本工作流：将PBI分成必须有的、最好有的、不会有的等三类；
9. 冲刺工作流：需求通过管道流入冲刺；如果团队在每个冲刺可以完成5个PBI，则任何时刻需要有10-15个PBI是准备就绪的；（如果没有意味着什么？涌没有出现？用户需求和用户体验没有进一步调研与改善？）
10. 产品列表原则：一个团队、一个产品列表；产品是有价值、客户愿意花钱购买、我们也愿意打包出售的；如果团队成员可交换，那么可以多个团队一个产品列表；如果一个团队多个产品，那么也是一个产品列表；

第七章 估算与速率

1. 估什么：
   1. 产品组合规划：以尺码数来估，用于评估大致需要投入的资源，S/M/L/XL；
   2. 产品列表估算：以理想天数或点数来估，用于安排冲刺；估算的首要价值是在估算交流过程中获得的认知（暴露假设和不同意见）；
   3. 任务估算：理想小时；
2. PBI估算的原则：
   1. 团队估算：产品负责人不估，而是负责阐释说明PBI；Scrummaster主持会议不估；实际动手设计、构建并测试的开发团队成员来估算；
   2. 估算不是承诺：估算应该靠谱，不能因为外因而人工放大；
   3. 要准确，而不是精确：为了获得精确而付出的努力是一种浪费时间；
   4. 使用相对值，而不是绝对值：人们在有参照物的情况下，更容易评估相对值，而非绝对值；
3. 规划扑克的规则：
   1. 产品负责人选择一个PBI，阐释给团队听；
   2. 团队成员开始讨论，并提出问题，产品负责人回答问题；
   3. 每个估算者选择一张牌代表他的估算；
   4. 所有人都做出自己的选择后，一起同时亮牌；
   5. 如果大家的牌一样，表示达成共识，共识的数字就是PBI的估算；
   6. 如果估算不同，成员开始讨论；通过让最低和最高的人解释说明他们的估算是合理的；
   7. 讨论之后，返回第3个步骤；重复上述步骤直到达成共识；
4. 规划扑克的好处：激发的PBI相关热烈讨论更有价值，因为要确保团队成员充分了解PBI；
5. 速率最好用范围来表示，不必要过于精确；
6. 提高速率的方法：
   1. 引入新工具；
   2. 加强培训；
   3. 改变团队组成；（谨慎，随意调换很可能导致速率下降）
7. 速率的目的是为了准确计划和自我改进，千万不要将其与团队考核绑定在一起，不然会导致失去准确性和估算膨胀；（团队考核应该以什么做为依据呢？是否可以以交付的客户价值？）（或许我们应该反过来思考，什么样的团队才是一个好团队？按时、按质的交付客户价值？良好的沟通、令人开心的氛围？成就感？互相支持？）

第八章 技术债

1. 技术债的概念：既指我们有意选择的捷径，又指许多损害软件系统的不良实践，具体如下：
2. 技术债的分类：
   1. 低级的：一般可以通过培训加强能力来解决；
   2. 不可避免的：因为项目本身不可预测性而产生的；
   3. 策略性的：明知故犯的，因为某些短期利益而造成的；
3. 技术债的后果：
   1. 爆发点不可预期；
   2. 交付时间延长；
   3. 缺陷数量可观；
4. 技术债的原因：
   1. 如期完工的压力；
   2. 试图以错误的方式提高速率；
   3. 试图减少测试以提高速度；
5. 技术债管理办法：
   1. 使用良好的技术实践，例如：简洁设计、测试驱动开发、持续集成、自动化测试、重构；
   2. 使用强完成定义；
   3. 正确理解技术债的经济成本；
   4. 让技术债在业务层面和技术层面都可见；
   5. 有债就还，分期偿还，优先偿还高利息的债务、边交付客户价值边偿还；

第九章 产品负责人

1. 主要职责：
   1. 管理经济效益（版本层面、冲刺级别、产品列表）；
   2. 参与规划（组合规划、产品规划、版本规划、冲刺规划）；
   3. 梳理产品列表（PBI的建立、细化、估算、排序等）；
   4. 定义接受标准并验证（PBI是否满足要求，最终应当由产品负责人判断）；
   5. 与开发团队协作（必须经常与开发团队保持紧密协作）；
   6. 与利益干系人协作（集思广益、形成一个统一的愿景来指导产品开发工作）；
2. 特征和技能：
   1. 领域能力（有预见性、能有效建立愿景）；
   2. 人际交往能力（擅长谈判以达成一致意见、有效传递信息、易于沟通）；
   3. 决策力（必须放权让产品负责人制定决策）；
   4. 责任心；
3. 日常工作内容：
   1. 规划、构想、获批资金；
   2. 制定概要产品列表；
   3. 与团队估算PBI；
   4. 给产品列表排序；
   5. 制定版本计划；
   6. 制定冲刺计划；
   7. 回答团队成员疑问；
   8. 梳理产品列表；
   9. 参加冲刺评审和冲刺回顾；
4. 谁来当产品负责人：
   1. 内部开发：受益的业务部门的代表；
   2. 商业开发：用户的内部代理人，一般是产品经理；
   3. 外包开发：甲方的业务代表；
   4. 组件开发：开发团队的技术代表（能够排序）；

第十章 ScrumMaster

1. 主要职责：
   1. 教练：辅导团队成员更好的开展Scrum实践；
   2. 服务型领导；
   3. 过程权威：带领团队成员定义、遵守流程；
   4. 保护伞：保护团队免受外部干扰，让团队成员可以集中精力应付冲刺；
   5. 清道夫：扫除妨碍团队生产效率的一切障碍，比如一些服务器问题等等；
   6. 变革代言人：带领大家转变思维和突破观念障碍；
2. 特征和技能：
   1. 见多识广：懂一点技术，懂一点业务；
   2. 善于提问：运用教练技能，结合流程、业务和技术方面的知识，提出重要的和有启发性的问题；
   3. 有耐心：即使知道答案，也懂得保持沉默，让团队找到解决方案；
   4. 有协作精神；
   5. 保护团队：防外部干扰，防内部成员掉队；
   6. 公开透明；
3. 日常工作内容：
   1. 组织会议：包括规划会议、冲刺计划、冲刺评审、冲刺回顾、每日例会；
   2. 教授技能：辅导不熟悉Scrum流程的队员；
   3. 梳理产品列表：与产品负责人一起；
   4. 扫除障碍；
4. 谁来担任这个角色：来自有技术背景的人，最好全职投入（如果不行，可兼职多个产品的Master）、避免让产品负责人担任（避免利益冲突）；

第十一章 开发团队

1. 由于每个冲刺都会产生一个或多个功能切片，所以它需要涉及到所有岗位职责的人员，包括设计、开发、测试等；偶尔的少数时候，才需要专门成立团队外的测试小组，但大多数都不需要；
2. 主要职责：
   1. 冲刺执行：设计、开发、测试等工作；
   2. 每日检视与调整；
   3. 梳理产品列表（协助产品负责人，但不占用超过10%的时间）；
   4. 冲刺规划；
   5. 检视与调整产品与过程（冲刺评审、冲刺回顾）；
3. 特征与技能：
   1. 自组织；
   2. 跨职能的多样化与全面化（关注不要让事闲着，而不要关注人；让有经验的成员教授无经验的成员来处理闲着的事情）；
   3. T型技能：广度与深度的结合，加强团队内的技能培训，让每一个人成长为广度层面的多面手；
   4. 火枪手态度：塑造集体荣誉感，出了问题，全员负责，没有谁可以置身事外；
   5. 沟通广泛：从多角度倾听意见，有利于更清楚的分析问题；
   6. 透明沟通；
   7. 规模适中（一般是5-9人，小团队效率更高，协调时间较少，弱化社会惰化现象，避免过分专业化，全员参与）；

第十二章 Scrum团队结构

1. 为了组件复用，对于大型项目，很多公司倾向于采用组件团队，但考虑相互依赖的成本，SCRUM倾向于以特性团队为主，组件团队为辅；
2. 如果确实有必要设立组件团队，那么建议再设立一层特性团队，并从组件团队中安排人员一起参与其中，以便有部分成员跨两边的团队，解决沟通成本的问题；
3. 几个办法：
   1. 减少并行产品的开发；
   2. 培训更多的组件领域专长的人员；
   3. 推动共享代码所有权（培训、开源培训）；
4. 多团队之间的协调：
   1. SoS（Scrum of Scrum）：即每个Scrum团队选出一名能够表述清楚相互依赖关系的成员，参加上一级的会议；
   2. 版本火车定义：按照一个共同的节奏协调跨团队的合作，使多个团队间的愿景、规划和相互依赖关系保持一致；
      1. 发布日期是固定的（日期固定、质量固定、范围可变）；
      2. 各团队的迭代长度相同；
      3. 建立大小适中的、全局的、客观的里程碑；
      4. 在顶层、系统级以及特征和组件级做持续的集成；
      5. 版本增量可以定期提交客户进行预审、内部评审和系统级的QA；
      6. 系统级固化迭代，用于减少技术债并为特殊的版本级验证和测试提供时间；
      7. 对于构建类似构件的团队，某些特定的基础设施组件（接口、系统开发工具箱、公用的安装程序和许可证工具、用户体验框架、数据和WEB服务等）一般都必须提前准备就绪；
5. 版本火车操作方式：
   1. 准备一个大会议室，所有Scrum团队分位置做下；
   2. 产品总负责人介绍下一版本PSI的增量特性；
   3. 特性领域负责人轮流介绍各自领域的特性情况；
   4. 各SCRUM团队做特性的冲刺映射；不同团队之间进行交流，确保相互依赖关系能够解决；
   5. 执行冲刺；
   6. 冲刺结束后，对放入版本火车的所有东西进行PSI评审；
   7. 冲刺回顾，重点关注如何让今后的版本火车更加有效；

第十三章 经理

1. 经理的职责：
   1. 塑造团队：
      1. 提供鼓舞人心的目标；
      2. 组建团队、招聘解聘团队成员；
      3. 授权团队：7级授权，其中3级经理决策（告知、推销、咨询），1级共同决策（商量），3级由团队决策（建议、询问、委托）；
2. 项目经理的职责（由其他4个角色分担了各项职能，一般不必要存在，除非在非常大型的项目中）：
   1. 协助大型项目各团队之间的直接高效沟通，扫除沟通障碍；
   2. 处理后勤工作；

第十四章 Scrum的规划原则

1. 假设事先无法制定完美计划；
2. 事先规划有帮助，但不宜过度；
3. 最后责任时刻再敲定计划：可以掌握更多的信息；最后时刻：如果再不敲定，成本大于敲定；
4. 关注调整与重新规划胜于遵循计划；
5. 正常管理WIP：不要一开始就创建大量工件库存，而是需要什么再建什么；
6. 提倡更小、更频繁的发布；
7. 计划快速学习并在必要时调头；

第十五章 多层级规划

1. 战略规划：不在讨论范围；
2. 组合规划：先有产品规划后，再来确定如何组合以及开发顺序；
3. 产品规划：愿景、概要产品列表、产品路线图（可选，当采用持续部署的方法时，则可以不用； 如果没有，则有一定作用，即随着时间推移如何增量构建和交付 ）；
4. 版本规划：与冲刺规划的区别在于是否涉及交付，如果冲刺中对完成的定义是以发布为标准的，则二者作用差不多；
5. 冲刺规划；
6. 日常规划；

第十六章 产品组合规划

1. 一个活动，用以确定组合中的哪些工作需要花多少时间以什么的顺序完成；
   1. 时间：永无休止的活动，只要有产品在开发，就得做这个工作；
   2. 参与者：利益干系人、各产品负责人、高级架构师或技术主管；
   3. 流程：进度安排、管理流入、管理流出、管理生产过程；
2. 进度安排策略：
   1. 优先考虑生命周期利润：目标是力求利润最大化，当资源有限时，如何安排优先级，
      1. 关注两个指标：延期成本、持续时间（有3种组合，对应三种策略，最短任务，最少成本，加权最短任务）；
      2. 估算要准确，而非精确（用T恤尺码来估计即可，不管跑出一个量级）；
3. 流入策略：
   1. 应用经济过滤器：相对于成本有无更大价值的商机，如果价值不大，则不必再花时间考虑和讨论；
   2. 到达率和离开率要平衡：不要塞入太多的产品到列表中，不然会堵车，建议以更频繁的间隔来引入产品；
   3. 快速拥抱新涌现的机会；
   4. 为更小、更频繁的发布做计划：不要一下子塞一个大产品里来，而应该将它细化成更小的颗粒度；
4. 流出策略：
   1. 关注闲置工作，而非闲置人员：不要为了让人不空闲而加了一堆额外的事情进来；
   2. 设立WIP限制；
   3. 等待整个团队一起行动；
5. WIP策略：边际经济效益，之前都是沉没成本，只关注下一步会有多少边际收益； 四个方向：保留、交付、转向、终止；
6. 特别重要的策略：关注延期成本、更小更频繁发布、WIP限制、边际效益；

第十七章 构想（产品规划）

1. 构想的目的：将原始粗糙的产品想法进行细化，描绘产品的精髓，以便在构想结束后得到足够的信息来决策是否进行下一步的具体开发；
2. 构想的输入：
   1. 初始的想法；
   2. 时间跨度：即为多远的计划进行规划准备，正常只需要第1个最小特性集的版本即可；
   3. 预计构想完成日期；
   4. 预算或需要的资源投入；
   5. 信心门槛：即得到哪些够用的基本信息后，即可进行决策；
3. 构想的输出：
   1. 产品愿景：经常表述为利益干系人如何得到商业价值，有以下几种类型：
      1. 进入条件
         1. 通过竞争取得平等地垃；
         2. 交付最小必须特性；
         3. 遵循行业标准；
      2. 启动（发力）
         1. 瞄准新兴市场；
         2. 开始销售其他产品或服务；
      3. 差异化
         1. 做到与竞争对手有区别；
         2. 客户满意；
      4. 搅局者
         1. 清除与竞争对手的差异；
         2. 提高公平竞争的壁垒；
         3. 通过改变市场热点来重新定义游戏规划；
      5. 缩减成本
         1. 缩短上市时间；
         2. 减少人员或工时；
         3. 提高利润率；
         4. 更专、更精；
   2. 概要产品列表：以用户故事的形式；
   3. 产品路线图：关注最小可发布特性集；
   4. 其他一些信息：有助于达到信心阈值的活动都可以进行；
4. 构想的原则：从经济合理的角度构想产品，因为构想本身也需要投入金钱或时间，所以应尽量简化它的过程，能够获得足够做出决策的信息即可，多投入可能是浪费，因为构想获得的信息有太多不确定性；
   1. 瞄准一个实际的信心阈值：先定义好需要的最起码的信息及其类型，有了这些信息，决策者就可以有足够的信心做出决策；
   2. 关注短期利益：不要一次性做太多的构想，只想第1个版本的最小特性集的那部分内容即可；因为我们的目标是做出第1个最小版本然后让用户去验证；
   3. 动作要快：行动越快，就会越早开始构建有形的产品，越早能够进行验证；
   4. 花钱买经验认知：因为构想活动产生的信息非常不确定，基本没有经过客户或用户验证；所以花太多时间在构想上面可能是浪费；
   5. 使用递增的资助方式：不要尝试产生太多信息来获得大额资助，只需要足以支持下一步开发即可；
   6. 快速学习并调头（即快速失败）；

第十八章 版本规划

1. 版本规划是为了确认如下问题：什么时候完成？能够有什么特性？需要多少成本？
   1. 规划时间：产品构想后即可进行；每个冲刺结束后也要进行；
   2. 参与人：利益干系人、Scrum团队；
   3. 过程：根据输入（产品列表/愿景），权衡范围/日期/预算，得到一个版本规划（MRFs）；
2. 两种类型：固定日期、固定范围；（前者比较契合SCRUM原则）
3. 一些事项：
   1. 梳理产品列表；
   2. 细化最小可发布特性集；
   3. 冲刺映射（PBI归位，涉及多个团队之间协作的时候会特别有用）；
4. 沟通进展情况：燃尽图、燃烧图；

第十九章 冲刺规划

1. 概述：团队成员在一起商定冲刺目标，确定在下一个冲刺中交付哪些特性；
2. 时间一般安排在每个冲刺开始前；
3. 整个SCRUM团队的成员都一起参加；
4. 输入：已经就绪的产品列表（价值清楚、细节充分、依赖已识别、人手齐备、已估算、接收标准清晰、知道如何演示）；
5. 分解后的单个任务完成时间不超过8小时；
6. 两种方式：两段式规划（故事+任务分解）、一次性规划（只到故事）；
7. 产品列表就绪意味着团队需要共10%的时间来梳理产品列表；
8. PBI选取原则：绝对不开始做完不成的条目，能完成才开始；
9. 故事分解成任务会使得预测更加准确，从而使成员更加有信心；
10. 如果出现特定技能人员的短板：不要一开始就分配任务，而是让团队成员在兑现过程中见机行事，适时、自主地选择工作；

第二十章 冲刺执行

1. 输出：潜在可发布产品增量，一组有高度信心的已定义完成的PBI；
2. 原则：由于大量的认识来源于实际的构建和测试，故理想原则是见机行事，逐步明确任务规划；当然，要提前发现重要的任务级依赖关系；
3. 蜂拥式工作法：可以让团队和成员保持专注，从而提高效率；尽可能少的让多个PBI处于并行的状态；
4. 注重良好的技术实践：测试驱动开发、结对编程、持续集成、重构、整体代码所有权、简约设计、编码标准；
5. 每日例会：分享团队整体进度、消除等待、快速反馈；
6. 任务板/看板/燃尽图：快速沟通冲刺进度、可视化工作流程

第二十一章 冲刺评审

1. 评审的作用：让每一个参与的人，有机会检视和调整当前正在构建的产品；
2. 参与者：内部/外部利益干系人、产品负责人、SCRUM团队、销售/市场人员等；（视情况而定，围绕目的邀请合适的人员参加）
3. 评审的目的：为了获得反馈及认知，确保产品在沿着正确的方向前进；
4. 产品负责人应该在冲刺过程中即逐步验收产品，而不是等到评审的那一天，这样可以进入快速反馈的循环过程；
5. 评审过程中，如果时间允许，也让参与评审的关键人员试用一下产品；
6. 评审的好处：参与人员的深入交谈与讨论，能够提出有建设性的、实际可行的调整建议；
7. 通过评审，使得每一个人进一步了解当前开发工作的进展，从而会建立新的PBI、重新排序现有PBI、或删除不再需要的PBI；
8. 对于大型开发工作，可能存在多个SCRUM团队，则可能各个团队的成果要集成后再演示，同时这样也可以节省利益干系人的评审时间；

第二十二章 冲刺回顾

1. 回顾的目的：检视产品构建的过程，找出不足和改进办法，以便在后续落实和改进；
2. 冲刺回顾的准备工作：
   1. 定义回顾重点：成长永无止境，只是可能需要重点更明确的回顾来发掘；
   2. 收集客观数据；
   3. 安排回顾时间日程；
3. 回顾的方式：
   1. 营造氛围，让参与的人员具有安全感，而不是让其沦一场指责会或者吐槽会；
   2. 建立共同背景，即利用客观数据来对某些见解达成共识；
   3. 见解的静默分组法、点数投票法；
   4. 回顾结束时，让每个参与的成员说几句感谢的话；
4. 冲刺回顾常见的问题：
   1. 不做回顾或参加的人很少；
   2. 不着边际、空洞无物；
   3. 对重大问题视而不见；
   4. 引导者能力不够；
   5. 郁闷；
   6. 指责游戏；
   7. 吐槽会；
   8. 代替特定的过程改进；
   9. 野心勃勃；
   10. 没有贯彻执行；
5. 回顾的基本活动：营造氛围、通过数据建立共同背景、让大家达成共识、得出改进见解、确定改进措施、最后结束回顾并致谢；