敏捷实践之Scrum冲刺

任志强 Roger

2019年02月

序  言

敏捷开发近些年在国内软件公司中越来越流行起来，越来越多的公司开始采用敏捷方法并投入精力去研究推广敏捷方法，因此也造就了国内一批又一批敏捷实践者和爱好者，我想当初Kent Beck等敏捷宣言的创始人也未必预见今天敏捷遍地开花的景象吧。

本人从2011年开始在IBM开始接触敏捷开发到后来做Scrum Master到现在的做敏捷教练，在敏捷的学习和实践中受益匪浅。我欣赏甚至是崇拜精益思想和敏捷方法，也特别希望能总结一些想法和心得来记录在这敏捷之路上遇到的困难和问题，从而分享给那些已经或者正准备踏上敏捷之路的朋友们用于个人学习、研究和欣赏，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。

系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。如内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。

目录

序  言... 2

1       概述... 4

2       冲刺计划会议... 4

3       冲刺执行... 4

4       每日例会... 5

5       冲刺评审会议... 5

6       冲刺回顾会议... 5

1        概述

The Scrum Guide中这样描述冲刺：“冲刺是Scrum的核心，其长度（持续时间）为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，冲刺 的长度保持一致。前一个冲刺 结束后，下一个新的 冲刺 紧接着立即开始。冲刺由冲刺计划会议、每日 Scrum 站会、开发工作、冲刺评审会议和冲刺回顾会议构成。”

2        冲刺计划会议

冲刺计划会议发生在每个冲刺的开始由整个Scrum团队协作完成。通常，冲刺计划会议包含如下过程：

1. 确定团队当前的速率

团队能在当前冲刺创造多少价值取决于当前这个冲刺团队的生产能力，要考虑其他冲刺活动如四大会议、其他承诺、个人休假、冲刺缓冲等影响因素。

2. 选取产品列表条目

如果我们有明确的冲刺目标，就选取与目标一致的产品列表条目。如果没有正式的冲刺目标，就默认从产品列表的顶部选取，注意约束条件和完成的定义，直到填满团队的生产力。

3. 获取信心

团队选择完产品列表条目后，要预测团队是否能在冲刺内完成所有产品列表条目需要检查一下团队是否做出了合理的承诺，检测的方法一般是历史对照或者生产力对照，也有产品负责人向团队发问得到团队自己回答这样的方式来确认团队的信心指数。

4. 细化冲刺目标、敲定承诺

初始的冲刺目标可以在冲刺期间重新优化，在完成冲刺规划之后开发团队对冲刺目标做出承诺。

3        冲刺执行

冲刺执行在一个冲刺中占大部分时间，开发团队成员自组织达成冲刺规划期间确立的目标。执行的过程是开发团队创造价值的过程，但为了使用环境的变化可以持续进行任务规划、调整。团队成员自组织要做哪些工作，谁来做。产品负责人和Scrum Master不会为团队分配工作。

我和很多Scrum Master或者项目经理聊过，他们很多人有人员利用率和成本的压力所以他们很自豪的说我们团队的每个人都是100%忙碌，加班是常态，这才是拼搏奋斗精神。其实这个思想是违背敏捷原则的，如果一个团队100%忙碌甚至超负荷工作，短期也许没什么问题但长此以往这个团队的创造力和交付质量肯定值得怀疑，可持续的、固定节奏的工作是敏捷原则之一。

冲刺执行是否能高质量的达到目标一方面是在文化上团队自组织的能力，另一方面是在工程上团队的技术实践的能力，包括团队的技术实践能力（例如持续集成、持续部署、自动化测试、结对编程测试驱动开发等）。

冲刺执行期间，进度跟踪尤为重要，一般我们会采用“燃尽图”。燃尽图是一个二维关系图，纵轴是故事点或者理想天，横轴的单位是时间。

4        每日例会

每日例会也称“每日站会”是一个关键的每天检视、调整的活动，每天在同一时间同一地点站着开，会议简明扼要轮流回答三个问题：

1. 上次例会后我完成了什么工作?

2. 下次例会前我计划完成什么工作?

3. 有什么问题阻碍我取得进展?

以上三个问题可以确保每个人了解全局，检视所有人的工作并根据最新情况进行调整。

经验告诉我们每日例会不是用来解决问题的，不能陷入无休止的群里讨论会。如果确实需要可以小范围在例会结束后单独讨论，或者单独报议题再约时间讨论。至于例会的参与者，我经历的项目一般产品负责人不参与或者偶尔参与，没有严格的限制，如果产品负责人每天都想了解团队的进展和状态，他是随时受欢迎的，只不过他一般不需要回答上述三个问题。

5        冲刺评审会议

冲刺评审一般发生在每个冲刺的最后一天，参与人是整个Scrum团队和利益相关者（比如领导、客户、出资人等），目的是检视工作成果（潜在可发布产品增量），会议中得到的反馈将是“调整”活动的重要输入。在评审会议里，Scrum团队有机会向利益相关者展示潜在产品增量，一般是通过演示软件的功能，与利益相关者当前的增量是否符合现阶段的业务和市场方向，是否有遗漏的特性，是否有镀金的现象等。

6        冲刺回顾会议

回顾会议一般是在评审会议之后，这样可以全视角完整的回顾整个冲刺的执行过程。回顾会议需要全体Scrum团队参与，目的是识别人、过程和工具需要改进的地方。在回顾会议里面团队成员要讨论如下三个问题：

1.本轮冲刺哪些地方做的好，需要继续发扬？

2.这个冲刺哪些地方做的不好，今后要避免？

3.我们在哪些地方需要做哪些改进？

在我过去的经验中，有时候大家会像完成任务一样努力去想3个问题，没有真正的去思考到底哪里做的好、哪里做的不好、哪里需要改进，我觉得造成这种现象的原因大致有二点，一是这个团队成员平时没有去关注和思考改进的因素，二是没有定义回顾重点，范围太大反而不容易有答案。

回顾会议需要团队成员多参与、多开口，目的是让团队基于共同背景和目标提出对团队未来切实可行、有价值的改善点（需要归类整理）和针对改善点的行动。我个人的经历中曾有过对回顾会议执行的时间控制提出改善的情况，这一点也提示我们回顾会议也是Scrum框架的一部分，本身也应该检视和调整。

回顾会议常见一些问题，树立远大不切实际的改善目标，比如在项目开始时就提出要90%去覆盖自动化测试，这不应该作为合理的建议。还有回顾会议开成指责挥着吐槽大会，有些人会借此机会互相指责和推诿，甚至是抱怨人和内外部环境因素。再以上几种情况需要Scrum Master很好的引导并制止回顾会议中不该出现的现象。

最后我想提一点就是，待改善的点大家都很清楚，但是却在每个回顾会议中反复被识别却得不到落实。造成这样的原因我个人的总结是有两个，一是没有贯彻落实，因为没有对应责任人或者责任人不作为。二是因为这个改进点工作量很大，造成责任人在短时间没有办法将其解决，这种情况会比较复杂，个人觉得要衡量这个改善点（有可能是个用户故事）的优先级和价值到底如何，要综合考虑整个产品列表条目和交付目标。