第八章 每日例会怎么进行
站在看板前，这样你才是有针对性的开会。
每次控制在15分钟内，每个人都不需要讲，也不需要听太多的细节，因为不是技术研讨会。
每天开会的目的，是更新看板上的卡片。每个人都讲述昨天做了什么，今天要做什么，同时更新卡片，挪动卡片。
ScrumMaster会更新燃尽图，然后更新一下sprint backlog。
怎么处理那些不愿意参加会议的成员呢，弄个存钱罐，来晚的都要往里扔5块钱，用来买零食给大家吃。
如果钱不够，ok，老板自己往里先扔200作为基金。
很多时候，有那么一批人会说：我不知道今天干啥
简单，让别人都讲完，然后把那些没人做的分配给他们。
当然，有时候并不是没有任务做，只不过他们还不太明白他们究竟在这个任务中做点什么，那么就需要相关的人会后讨论一下细节，以便让他们知道真正要做的。
如果真的没事可做，那就拉他们过去结对编程。
还有极端的是，提前完成了，ok，从backlog中，拿出几个合适的故事，加进来。
如果是那种懒人，就是不想干点什么的时候，怎么办呢？
1. 羞辱他们
2. 直接派活
3. 让其他人给他们施加压力
4. 奴役他们，干点体力活
如果还是不能解决问题，干掉他们，不要因为他们影响整个团队。
第九章 怎么进行Demo
很多人都不重视Demo，相当于干了很多事，却没人知道。
其实Demo意味着sprint要成功的结束了，带来的好处有很多：
1. 团队的成果得到了认可，感觉很爽
2. 别人终于能看到你的团队实际做出了个什么东西来
3. 演示能让很多关注度比较高的人提前参与验收，并能在我们没有正式结束前即使的反馈，有一个临门磨枪的补救机会。
4. Demo是你让你的团队和其他团队进行交际的重要方法。
5. Demo意味着你的团队必须让产品真正的跑起来，而且问题还不能太多，等于push他们
6. 一个失败的Demo会让团队成长
Demo之前，做个检查列表：
1. 确保Demo能够清晰的阐述你这次sprint的目标。因为有些人不知道你的产品，你不得不花时间讲述一堆他们完全不懂的功能，浪费彼此的时间。所以最好有个简单的背景描述。
2. 不用浪费时间做什么PPT，直接开讲就行。
3. 节奏要快，要快速的通过，而不是像买产品那样自卖自夸半天。
4. 演示的是业务内容，而不是技术架构。所以要串场景，而不是一个个功能的描述。
5. 允许的话，让参与Demo的外人，现场试验一下。
6. Demo的主题是唯一的，就是演示你做了什么，不要跟人去讨论细节。
7. 如果出错，那就说这个正确的实现是怎么样的
8. 不要企图去展示那些非功能性的需求，太技术性的东西，无法获得认同感。
第十章 怎么做sprint的回顾
怎么回顾的前提是：你能够组织回顾，或者说你有东西可以进行回顾。
很多人不愿意做回顾，因为觉得都做完的，何必要再折腾一次。
实际上回顾是最重要的事之一，另一个是sprint会议，回顾就是要校验你的sprint会议的完美程度，以便下次sprint会议的时候进行调整。
前事不忘，后事之师。
回顾的组织都是看情况而定，一般可能会有这些：
1. 设置要回顾的内容范围，设定一个时间段
2. 确定参与者，产品负责人，团队和你都参加
3. 封闭的空间，避免外界干扰
5. 找一个人当秘书，做好会议记录
6. 演示sprint backlog，指出当时出现了那些问题，如何弥补的，带来了那些危害，下次怎么避免等等
7. 每个人都发言，说说自己的得失和对团队的想法
8. 对预估的工作量和实际的工作量，以及燃尽图进行讨论，分析下原因
9. 对大家表示感谢
10. 聚餐
11. 发送一个会议记录
12. 发送一个收集的那些典型问题，处理方法，风险控制，作为知识进行分享
真正的主题其实只有一个：下一次，怎么做的更好
所以，会分类。一般有：很好，下次还这么干。一般，其实怎样怎样干效果更好。有点遗憾，下次应该避免怎么怎么样。
然后，每个人把自己的想法列出来，投票，各选三个。在下一个sprint里分别跟踪一下，看看是不是好转或者变坏。
回顾有个很重要的作用是在团队之间传播经验。
回顾还有一个很重要的输出是：那些需要变，那些不能变。
常见的问题有：
1. 当时需求没说清楚
2. 干扰太多
3. 时间估计的少了
4. 承诺的太多
5. 细节考虑的欠缺了
6. 办公环境不好
7. 浪费了很多不相干的经历
8. 团队配合不好
9. 沟通成本太高
