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数据文档