1 怎编写backlog
常用字段，也可以根据实际需要补充字段
类别、来源、bug、价值
ID、Name、Important、Initial、estimate、How to demo、Notes
唯一标识简短、描述性的故事名重要性，po给评分，分越高越重要，无上限，最好分数间留出间隔初步估算，最小单位是story-point，一般理想1人\天简单的测试规范相关补充说明
2 PO需要参加Sprint计划会吗
需要参加，再范围和重要性中做取舍
（计划会主要事宜，po介绍story，dev拆分task估算，确认范围，定义测试规范，估算生产率、绘制燃尽图等；实际情况可拆为三个小会，需求评审、研发估期、用例评审）
3 Story的大小
不该太长也不该太短，一般要求再2-8个人\天，拆分task后给估期
Story是可交付的东西，是po关心的；task是dev团队拆分的结果，用于过程管理
4 技术故事
1 尽量避免，把技术故事转换为可衡量业务价值的普通故事，po做决策
2 当作普通故事中的其中一个task
3 上述都不可行，定义为技术故事，单独存放，po可看不可编辑，和po协商从sprint抽出时间解决
5 如何让别人了解我们的Sprint
1 Sprint信息页
2 dashboard
3 纸质打印
6 任务板
使用上有几个受限：
1 跨地区团队
2 不想花精力维护，有在线工具
3 story没有按照3C进行，卡片上内容不好写
7 估算用人天还是人小时
建议人天，符合传统认知，避免微观管理，统一估算单位
8 Sprint结束于演示
1 好处：
团队成果得到认可，感觉很好；
其他人了解团队在做什么，吸引干系人注意，并得到重要反馈；
团队之间相互交流；
迫使团队真正完成一些工作
2 重点：
阐述sprint目标
不需要花过多时间准备，集中经理演示可以实际实际工作的代码
节奏要快
关注业务层次，而不是实现细节；注意力放在“我们做了什么”，而不是“我们怎么做”
可以的话，让观众自己试一下产品
不要演示细碎的bug和微不足道的特性，可以提到；关注更重要的故事点
实际情况，迭代主要产研在验收，没有拉需求方；如果这个人员范围，可和回顾会一起；或者每隔几个sprint统一演示
9 回顾会
Scrum master 像大家展示sprint backlog，在团队帮助下，对sprint做总结
包括重要事件和决策等
轮流发言，机会均等，不被打算，指定秘书记录
对比预期和结果，分析差异原因
Scrum master做建议总结，得出下个sprint需要改进的地方，先脑暴→再投TopX（少即是多）
形式不限，目标“怎么在下个sprint中做的更好”
如果场面比较冷清，SM可以主动抛一些问题进行引导
Good、Could have done better、Improvements
10 Sprint之间的休息时刻
一个月安排一天，和Sprint没有关系
选择两个sprint之间
11 定义验收标准
必须完成、应该完成、也许可以以后完成
估期粗估，不做绝对承诺，后续分析偏差率
估算生产率，永远不要寄希望100%
实际情况，尤其是早期，大部分都是必须功能，并且承诺需求方
12 调整发布计划
敏捷三角，调整范围或时间，一般建议调整范围，保持节奏
13 Scrum和XP
Scrum注重的是管理和组织实践，XP关注的是实际的编程实践，结合使用
1 TDD
测试驱动开发，先写一个自动测试，然后编写恰好能用的代码，让它通过测试，接着对代码重构，主要提高代码的可读性和消除重复。整理一下，然后继续。
问题：需要一定时间才能掌握方式
2 增量设计
开始保持设计简单化，不断改进，而不是一开始就努力保证正确性，冻结不再改变
3 持续集成
尽早的做集成操作
4 代码集体所有
频繁交换结对，保证backup
5 充满信息的共工作空间
共享信息
6 代码标准
定义代码标准，缩写等
7 可持续的开发速度/精力充沛的工作
加班降低生产率
14 把验收测试阶段缩到最短
1 全体提高Scrum团队交付的代码质量
把测试人员放到Scrum团队中
每个Sprint少做点工作，会带来质量提升、验收测试周期短、影响终端用户的bug减少，短时间提高生产力
2 全力提高人工测试工作的效率
多抽点实际，做自动化，来简化测试工作
3 如果最后测试成为瓶颈怎么办
把所有人分配给测试当助手
不完美的方案，不把验收作为sprint的一部分（起因：验收时间不太可控；理想情况：不验收可交付；实际不建议，打破了对完成的定义）
15 怎么管理多个Scrum团队
1 项目人员太多，需要分割团队
3-8 人最佳团队人数
2 是否同步多个Sprint
yes，建议逐步同步
3 怎样再团队中分配人手
总负责对齐目标，具体事宜单独安排
4 跨组件团队
已组件创建团队，问题story跨团队
跨组件团队
5 是否在sprint中重新组织团队？
不建议，“团队凝聚力”是Scrum的核心要素之一
同时不建议兼职人员
6 如何进行Scrum-of-scrums
常规会议，让所有Scrum Master聚到一起交流，协调资源讨论问题
定期召开，说明上周完成事宜，下周计划事宜，遇到障碍；跨团队问题（如集成）
16 救火团队（支持团队）
1 救火
2 保护Scrum团队远离各种干扰，包括挡开不知从何而来的、增加临时特性的需求
团队成员，不过分依赖某个核心成员
17 Scrum Master检查列表
1 Sprint 开始阶段
整理Sprint 问题，更新到dashboard
2 每一天
主持scrum会议，确保按时开始结束
为保证sprint如期完成，适当增删故事，确保PO了解变化
团队成员及时得知Sprint backlog和燃尽图的状况
确保问题和障碍被解决，并报告给PO或dev leader
3 在Sprint结束时
Sprint演示、协调会议、更新sprint数据文档
