第9章 我们怎样进行sprint演示

• sprint演示（有人也叫它sprint回顾）是Scrum中很重要的一环，却常为人们低估

为什么我们坚持所有的sprint都结束于演示

• 一次做得不错的演示，即使看上去很一般，也会带来深远的影响

1. 团队的成果得到认可。他们会感觉很好
2. 其他人可以了解你的团队在做些什么
3. 演示可以吸引相关人的注意，并得到重要反馈
4. 演示是（或者说应该是）一种社会活动，不同的团队可以在这里相互交流，讨论各自的工作。这很有意义
5. 做演示会迫使团队真正完成一些工作，进行发布（即使是只在测试环境中）。如果没有演示，我们就会总是得到些99%完成的工作。有了演示以后，也许我们完成的事情会变少，但它们是真正完成的。这（在我们的案例中）比得到一堆貌似完成的工作要好得多，而且后者还会污染下一个sprint

• 如果一个团队或多或少是被逼着做演示的，尤其是他们实际没有完成多少工作的状况下，演示就会变得令人尴尬。团队在做演示的时候会结结巴巴，之后的掌声也会显得勉勉强强。有人会为团队感到有点儿难过，也有人感到很不爽，因为他觉得宝贵时间被浪费在了一场很烂 的演示上
• 这会伤害一些人。但它是苦口良药。等到下一个sprint，这个团队就会真得试着做完一些事情！他们会想：“也许我们下个sprint可以只演示2个功能 ，而不是5个。但这次这些该死的功能一宿地正常工作！”

sprint演示检查列表

1. 确保清晰阐述了sprint目标。如果在演示上有些人对产品一无所知，那就花上几分钟来进行描述
2. 不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。把那些玩意儿扔一边去，集中精力演示可以实际工作的代码
3. 节奏要快，也就是说要把准备的精力放在保持演示的快节奏上，而不是让它看上去好看
4. 让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”
5. 可能的话，让观众自己试一下产品
6. 不要演示一大堆细碎的bug修复和微不足道的特性。你可以提到一些，但是不要演示，因为它们通常会花很长时间，而且会分散大家的注意力，让他们不能关注更加重要的故事

处理“无法演示”的工作

团队成员：“我不打算演示这个条目，因为它没法被演示。这个故事是‘提高系统的可扩展性，能够容纳10000个用户的并发请求’”。我豁出命去也没法邀请10000个用户同时来做演示，不是吗？“ ScrumMaster：”那你做完了吗？“ 团队成员：”当然“ ScrumMaster：”你怎么知道 呢？“ 团队成员：”我在性能测试环境中搭好了系统，启动8个负载服务器，用并发请求做了测试“ ScrumMaster：”但是你有没有迹象可以表明系统能够处理10000个用户呢？“ 团队成员：”是的。测试机器挺烂的，不过在测试时还是能处理50000个并发请求“ ScrumMaster：”你怎么知道的？“ 团队成员（被折磨得要抓狂）：”我有报告啊！你可以自己看，报告上都有怎么配置测试环境，发出了多少个请求！“ ScrumMaster：”那太好了！那就是你的‘演示’啊！给大家看看你的报告就行了。这比什么都没有强，不是吗？“ 团队成员：”哦？这就够了吗？不过报告挺难看的，得花点时间美化一下“ ScrumMaster：”好的，不过不要花太多时间。不用很好看，只要能传递信息就行“