第二章
经过实践，Backlog中会一直保留下来的字段P6-7
还有一些扩展字段 P8
让backlog仅停留在业务层面，当描述到技术故事时，多问为什么，会挖掘出背后的业务价值。
第三章
只能有一个PO和一个backlog
要排优先级，并且只能由PO来统一排序
第四章
1、为什么PO必须参加
计划会可能对范围、估算、优先级做出调整，有PO在场便于决策。
2、为什么不能在质量上让步
质量分为内部质量和外部质量。
内在质量的让步，会花费更多时间来补救。在计划时，不能通过在质量上让步为代价，以保证范围不变化。
3、控制计划会议的时间
为会议设定时间盒。
4、确定sprint长度
产品人员希望短，可以早交付早反馈；开发人员希望长，可以有时间准备，压力小。最终的选择是两方权衡的结果。
5、确定sprint目标
6、PO如何对迭代放哪些故事产生影响
改变优先级；缩小某个故事的范围；拆分出某个故事优先级更低的部分，排在后面。
7、估算的方法
直觉反应、昨日天气、基于可用人天和估算投入程度的生产率计算
8、为什么每个人都要参与估算
不确定谁回来做；可能多人协作；为互助打下基础；参考多方意见。
9、预先拆分故事的任务
有点像瀑布的做法；拆分过程中能发现估算需要修改的方面。
10、技术故事
包括重构、持续交付环境搭建、开发测试环境维护等
优先级较低
尽量避免技术故事。转变为可衡量业务价值的普通故事；转变为某个故事下的任务。
第五章 我们怎样让别人了解我们的sprint
发送迭代开始邮件，包含迭代目标；可视化迭代计划wiki；通知演示会。
第六章 我们怎样编写sprint backlog
Scrum master应该从燃尽图中发现什么？
燃尽图下降太慢，需要缩小迭代范围
燃尽图下降太快，需要多填充一些故事
没有按优先级开发
计划外的故事太多了
第七章
让团队坐在一起
互相听到，互相看到，不会和其他团队互相干扰
产品负责人不应该与团队坐在一起，否则容易关注到细节
经理和教练，先贴近团队，然后远离他们，让他们凝聚在一起，自我组织。定期参加演示、晨会、看板。
第九章 我们怎样进行sprint演示
1、为什么演示作为sprint结束
增强开发团队的成就感；迫使他们真正完成一些工作，而不是99%的工作。
2、如何演示
简单描述迭代目标；节奏要快；演示关注业务层次，不演示技术细节；不要演示bug修复和微不足道的特性。
3、如何应对无法演示
从如何验证的角度进行简单的演示。
第10章 我们怎样做sprint回顾
1、在团队间传播经验：作为桥梁，分享传播其他团队解决同类问题的方法
“如果时间倒流，重新做这个sprint，有哪些方法？”
2、变，还是不变
有些问题，提出之后，会自动消失。比如迭代规划超过实际容量，下个迭代自然会少规划一些。
如果每个小问题都要有改进措施，团队可能不愿意再吐槽了。
第11章 休整时刻
回顾会结束后，需要时间来调整下个sprint计划。
回顾会和计划会不要在同一天进行。
第12章 怎样制定发布计划
1、产品backlog按优先级排序
2、估算重要的故事
3、估算团队生产效率（一个迭代的故事点总数）
4、生成并调整发布计划（选择延迟发布所有计划，还是先发布一部分计划）
第13章 结合scrum和xp
1、结对编程
2、TDD
在旧代码上想要引入自动化测试代替手动回归很难，先考虑如何简化手工测试。
3、代码集体所有权
增强团队健壮性，不会因为某个人的离开而无法运转。
第14章 我们怎样做测试
1、把验收测试阶段缩到最短：
1）提高代码质量
a.把测试人员放到scrum团队
按照完成的标准，进行验收测试和演示。如果没有测试任务，可以做测试准备（环境准备、案例编写），可以做TDD结对编程，可以做非编码类工作。其他团队成员也可以帮助测试人员做测试。
b.在每个迭代少做工作来提高质量
方法一：在旧版本发布前，不做新特性的开发（破坏sprint节奏）
方法二：可以构建新特性，但是发布旧版本优先级更高
糟糕的方式：只关注构建新特性
应该根据测试能力安排迭代，并解决测试瓶颈
2）提高测试效率
第15章 我们怎样管理多个scrum团队
1、创建多少个团队：宁可团队数量少，人数多。保证团队不会相互干扰。
2、虚拟团队：观察，团队之间不会彼此干扰。
3、最佳团队规模：3-8人
4、同步多个sprint；方便调整团队人员，目标相同，管理压力更小。
5、团队领导负责团队拆分重组，人员安排。
6、人员分配：集中式控制决定初始规划，分散式优化尊重个人意愿。
7、组成跨组件的团队，减少团队间的依赖。
8、重组团队：团队需要长期协作，产生凝聚力。重组时要考虑是长期的还是短期的，如果是短期则不建议。敏捷初期，可以多试验几次调整最适合的组织结构，持续优化。
9、尽量不使用兼职人员。
10、scrum of scrums
产品级scrum会议，由各团队SM参加。每周一次，讨论做了什么，计划做什么，有什么问题；讨论跨团队协作问题。
团队级scrum会议，与产品级会议相同，所有人参加，控制时间，只做情况介绍，不深入讨论。
11、交错每日例会
便于多个团队的leader参加每一个团队的例会，了解情况。
12、救火团队
负责解决故障，不做预先计划，包含核心技术人员。有时会需要scrum团队核心人员甚至整个团队帮助。系统稳定后，救火团队会重新加入scrum开发。
13、是否拆分产品backlog
1）一个PO，一个backlog
安排好列表，由各团队自己决定自己的迭代列表
2）一个PO，多个backlog
没有必要，团队会自己讨论出结果
3）多个PO，多个backlog
如果代码库相同，会有严重的冲突问题。如果代码库不同，可以完整分割，每个PO的情况与1）相同。
14、代码分支
主干持续集成，尽量减少分支，减少复杂性。
15、回顾会
多个团队一起演示，然后各自开回顾会。下一个迭代计划会前，每个团队找代表介绍回顾会改进点。互通信息，简单讨论10-20分钟，再开始计划会。
感想：多团队管理，信息互通透明；没有团队协作的事项，各团队内部讨论解决，解决结果互通信息。
第16章 如何管理分散团队
能够一起结对编程；
能够面对面交流；
对迭代产品信息有一致理解。
在家工作：在家可能效率较高，但是团队物理在一起协作也很重要。
第17章 SM检查列表
1、sprint开始阶段
发邮件通知团队，sprint已经开始。
更新生产率估算、迭代范围。
2、
