玩转Scrum（下）
原创：刘峥编辑：蔡玉蕊
嘉宾刘峥老师已经通过2期的课程为大家介绍了Scrum方法的1个流程，详细讲述了2个活动：站立会（Standup Meeting）和规划会议（Planning Game）的规则、实施要点以及2个活动中所运用到的方法和工具。本期课程中将继续为大家讲述Scrum方法中4个活动中剩余的2个非常重要的活动实践：演示会（Demo Meeting）和回顾会（Retro Meeting）。
演示会（Demo Meeting）
1. 演示会（Demo Meeting）的基本规则（Ground Rules）
1）一定要做Demo
为什么Scrum中一定要实施？主要有两个原因：
① 促使Team真正完成工作
Scrum方法中一直强调不能Demo的工作，往往是没有完成的工作。
② 让其他团队了解你们团队的成果
Scrum团队一般是以5～9人的小团队为主的协作方式，所有做的事情团队内部都非常清楚，但是弊端就是与其他团队的沟通较少，其他团队所做的事情就不太了解。所以这也是Scrum方法的一个副作用。在演示会上，不仅可以让每个项目的相关干系人参加，还可以邀请其他团队成员，让其他团队了解自己团队的工作。
Scrum方法中的理念，本质上是崇尚信息公开的一种文化，任何环节任何活动，只要遵循鸡与猪原则都可以参加。在Demo会上出席人员都可以发言。
2）用尽量少的功夫准备Demo
敏捷宣言中有提到“可用的软件胜于完备的文档”。主要展示的是可用的软件，所以不用花太多功夫准备华丽精致的PPT去展示。
3）演示过程中注意力应放在我们做了什么而不是我们怎么做的
在演示会上我们应该重点展示做成了什么功能。类似唐僧师徒西天取经回来后举行赏经会时，在会上应该展示取回了什么经文，而不是介绍西天取经的途中所经历的九九八十一难是怎么渡过的。如果要说也可以，但需要组织一个其他的会进行说明。在Scrum方法实践过程中很多团队会在这个原则上走偏，所以一定要在Demo会上聚焦重点内容。时间尽量压缩。一般周期为2周的Sprint的Demo会控制在30’～1H之间比较合理。
2. 怎么做演示（Demo）
1）阐述Sprint的目标
一般在每个Sprint开始时都要设定本期Sprint的目标。同样在传统的项目中，计划阶段也都会确定项目的目标。目的都是为了统一团队所有成员的思想。
2） 不要做太过花哨的演讲，演示可以实际运行的代码
3） 不要演示一堆细碎的BUG修复和微不足道的特性
研发人员很多都是耿直的细节控，但是在Demo会上不能太过细节。(如果真有严重的BUG还能Demo什么呀，大家得赶紧修复BUG去了……)另外，Demo会要集中在主要的功能特性的介绍上，那些微不足道的特性不用详细介绍。（如果真有残留BUG可以说明一下还有一些微不足道的BUG需要再修复一下就可以了。）
回顾会（Retrospective Meeting）
回顾会通常会被简称为Retro Meeting。
1. 回顾会的基本原则
1） 一定要做正式的Retro
在Scrum中Standup Meeting一定会做。但是因为迭代周期短，开发工期紧，Demo和Retro常常容易被大家忽略。如下图：
（图片来源网络）
两个人很努力地在推车，但是后面一位老司机正拿着轮子给他们，但是他们总是太忙，以至于都没有回头看一眼。如果他们能够停下来看一下，老司机给的是什么，或许他们的效率会更高。
回顾会是为了让团队、团队成员变得更好。我们在传统项目中会有收尾阶段，一般也需要进行回顾总结。但是传统项目的经验总结的价值可能无法完全发挥作用，上一个项目结束后团队已经解散了。一般与下一个项目的时间间隔太大，新项目的团队成员、项目环境都可能发生了变化，原来的经验总结未必都适用。即使看了经验总结，未必能有当时情景的带入感。但是，如果是固定的团队在固定的环境下，这种回顾总结的作用就会很大。所以Scrum方法中Retro的设计还是很有科学性的。
回顾会的作用主要有三点：
① 让团队充分的表达自己
Scrum中的理念是公开、民主的一种文化，每个人都可以通过这个渠道充分表达自己的意见
② 总结妨碍团队更高绩效的原因
③ 促使团队有进步的机会
Retro是定期实施的，一般1～2个Sprint会进行一次Retro，最长也必须1个月至少做一次Retro。对于上一次在回顾会上提出的回顾点的改善情况进行跟踪。
2） 鸡和猪的原则
与站立会一样，根据Scrum的文化，高层如果不是以一个项目支持者的身份出席的话，不建议参加。
3）一定要在下个Sprint落实决议
这里指在回顾会上总结的内容一定要有进展。光总结没有改善进展，这个Retro就是失败的。所以，要把总结内容的决议贴在白板上作为下个Sprint中要落实的第一个行动。同时，在站立会的时候Scrum Master可以提醒团队上一个Sprint的回顾点在本次Sprint是否落实。
2. Retro的实施步骤
为了真正落实团队中的Retro，嘉宾根据自己那么多年的敏捷落地经验，为大家推荐了3个步骤。
Step1：画心情曲线
上图就是一个心情曲线实例。坐标轴的横轴是时间，指Sprint中的各个时间点。纵轴是表示情绪。中间的一根直线把象限分为上下两部分，我们把上面部分定义为正象限，表示积极的情绪。而下面部分定义为负象限，表示消极的情绪。而每一根曲线代表着某一个团队成员的在整个Sprint过程中心情的变化情况。
在会上的每一个团队成员都需要上台画出自己的心情曲线表达自己的真实想法。然后汇总起来看，就可以看出Sprint中的哪个时间段大家情绪比较低落，哪个时间段情绪高涨。然后做进一步的分析这些时间段中分别发生了什么事情。
Step2：头脑风暴总结Good/Need Improve
Retro一般定期去做，逐渐成熟的团队在每次反省中做的不好的点会逐渐减少，但是永远都会有改进点。这正体现了敏捷的精益求精的精神。很多人运用了敏捷方法后，自己也会逐渐养成了在日常生活中、工作中不断寻求改进以进一步提升自我的思维方式。
在实践中建议大家每个人用一张便签写一个Good或一个Need Improve，同时也要让每个人上台说明自己写的内容。Scrum Master或PM可以再对这些总结点进行合并同类项，一样的点单独列出来。
这里要提醒大家注意在实施过程中很多人会比较极端只讲不好的或好的，还有可能因为别人已经讲过了自己就不讲了。遇到这种情况时，Scrum Master应该提醒各位要充分表达自己，好的和不好的都要进行总结，即使重复也要自己讲一下以加强自己的印象。（一般一个团队氛围比较好的话，大家会一起吐槽的。）
Step3：投票决定下个Sprint的关注改进点
一般2～3个关注点即可，不能太多。而这2～3个改进点要通过团队投票决定，每个人都必须要轮流上台投票。
Step4：感谢
这里的感谢不是那种客套的、泛泛而谈的感谢，而是每个成员需要表达到具体人、具体事。通过这个过程可以增进团队彼此的感情。一方面鼓励大家在工作中互相帮助，另一方面进一步提升团队成员在这个过程中自己工作成果被认可时产生的自我成就感。这里的结果在Step1中的心情曲线中会有所体现。
说到这里不得不再强调一下，Scrum方法毕竟是个框架并不是方法论。没有一本书告诉我们Scrum是怎么做的，大家可以在看完嘉宾的做法后，根据自己公司、团队的情况来实施，未必要照本宣科，按部就班地完全按照嘉宾的指导步骤。
Q & A
今天的课程的内容已经基本结束。接下来一起来分享一下在Demo&Retro Meeting中大家常遇到的问题以及嘉宾的解惑。
Q1：如何演示“无法演示”的工作？
A：之前提到无法演示的工作不能算完成的工作。这里无法演示的工作可以通过其他的方式展示出来。例如，有个需求是“200万用户同时在线登录”，演示时无法现场演示。工程师在研发过程中是通过工具在系统上模拟200万用户同时在线登录。演示会上可以把测试时模拟器中或数据库中的测试情况或系统的response time等信息数据甚至log显示出来就是很好的演示了。
Q2：细节太多，Demo演示不完怎么办？
A：这种情况常出现在图形界面设计或UI设计的演示建议平时多于PO沟通。不一定要在Demo会上完整的演示研发的所有成果。
Q3：一边Break，一边Retro可以吗？
A：虽然没有标准的说法，有些人认为这种做法可以缓解紧张的气氛，有些人不予赞成。这还是由团队的文化决定。但是，嘉宾在自己实践中不建议这样做。Retro还是一个比较正式的场合，Break可以在Retro后开吃。
Q4：如果总是因为团队外部的因素影响Sprint结果怎么办？
A：一般在Retro中总结的关注改进点中有些是由团队自己内部可以解决，还有一些只有外部才能解决的。此时就要Scrum Master或PO能够把这些改进点传达到高层寻求帮助。但这里“总是”表示之前提了还是没得到解决，这种情况下就只能反复地提，直到改进点被解决。俗话说的好，会哭的孩子有奶吃。
到这里为止今天的课程内容已经全部结束。对于Scrum方法成功落地的关键数字143：1个流程和4个重要的活动的实践，通过这三期的课程已经全部介绍完毕。大家可以通过回顾《玩转Scrum》上、中、下再一次体会Scrum方法中的敏捷理念和实施方法。下期将最后由嘉宾再为大家介绍Scrum方法中3个角色（PO，Scrum Master，Team）如何协同合作，使整个团队更高效的完成工作的。敬请期待吧～～
页:
[1]