SCRUM, 需要仪式感

《小王子》中有一段是这样写的，小王子第二天又去看狐狸。

狐狸说:最好还是在原来的那个时间来，比如说，你下午四点钟来，那么从三点钟起，我就开始感到幸福。时间越临近，我就越感到幸福。到了四点钟的时候，我就会坐立不安；我就会发现幸福的代价。但是，如果你随便什么时候来，我就不知道在什么时候该准备好我的心情…应当有一定的仪式。

“仪式是什么？”小王子问道。

“这也是经常被遗忘的事情，”狐狸说，“它使得某个日子区别于其他日子，某个时刻不同于其他时刻。例如，那些猎人就有个仪式。每逢星期四，他们会和村里的女孩跳舞。所以星期四是个美好的日子！我可以到葡萄园里散步。但如果猎人并不在固定的日子跳舞，所有的日子都是相同的，那我就没有假期了。”

很少有开发模式像scrum一样把仪式感发挥的淋漓尽致，细致到有多少次会议，会议频率怎样，谁来参加，会议最后要有怎样的产出都一一定义。

每日例会的仪式

沐浴，更衣，撒香。。。开个玩笑
例会的时间选择最好是在每天早上大家都开始进入工作状态的时候。老板们都希望早会越早越好，这样大家都能按时来上班了，要是碰上有弹性上班制度的公司，恐怕这样的老板会和员工起冲突的，毕竟员工各自情况不一样上班希望有点弹性，所以要合理适当的选择例会时间。

每日例会的真正仪式是：

• 每个工作日
  有人问我早会一定要每天都开吗？我的答案是肯定的，这是团队面对面讨论问题的仪式，不一定每一个人说的每一条信息都有用，但是只要发现两条有用的信息进行阐明或者跟进，也是每日站会的意义所在。

• 站立
  找出合适的地方保证大家能围成一圈开始站着开会。如果团队用物理看板的话，就再看板前开会，如果是电子看板的话要有屏幕，总之不能干瞪眼，要让团队看到实时的sprint情况便于讨论。
  发言顺序要适当调整，最好随机

• 每人发言回答三个问题，昨天做什么？今天有什么计划？有什么问题需要解决？
  团队成员很可能会流于形式的回到昨天做什么，今天又什么计划，不大会说出自己目前碰到了什么问题，要鼓励大家说出问题
  团队会走极端把站会当成沟通的唯一渠道，本来前一天就可以解决的问题一定要拖拉到第二天站会才提出来。好的站会是发现未知问题平台，而已知的问题应该在站会前就已经沟通解决或者有解决方案了

• 会议时间控制在15分钟以内
  有些话痨会占用很长的时间叙述昨天干了什么，来证明自己干了很多时间，工作有多认真。如果情况严重就要打断，或者硬性规定每人发言不能超过固定时间，比如一分钟
  有时候团队会就某个问题产生争执，占用很长的时间进行讨论，这时候要打断并且建议会后再进行单独讨论。不要忘记跟踪他们是不是有讨论这个问题。

Sprint计划会议的仪式： 总-分-总

• 总体陈述用户故事
  对于两周一个sprint，由产品经理花10-20分钟时间总体阐述下当前sprint最高优先级的用户故事，重点是说明“为什么”。讨论的目的是让团队对这个sprint的范围有总体印象，了解为什么要做的背景，以及排除掉一些超出此次讨论范围的用户故事，比如PO准备的用户故事太多大大超出了团队一个sprint能完成的量，又比如有的用户故事有些理解误区需要再次确认。限时避免深入讨论如何实现这个用户故事的细节，因为后边会有更多的时间来详细讨论。很多时候会跳过这一部分直接进入详细讨论的环节，省略掉这部分的后果是，团队在没有全局概念的情况下直接进入到很细的细节讨论中，不能很好的做决策。这10到20分钟的时间会起到事半功倍的效果
• 分组详细讨论用户故事
  还是两周一个的sprint，建议花一个小时在详细讨论上，并且分组讨论，每组里最好能包含不同的角色，比如一个后端开发一个前端开发一个UX和一个QA组成一组，一个组最好讨论同一个模块的用户故事，方便对用户故事重新组合或者拆分。规定讨论需要有产出，每个用户故事要有验收标准，故事点数，有必要的话需要拆出子任务。
  如果一个组讨论结束了自己分到的用户故事，可以自由加入另外的组进行讨论
  讨论的时候为了避免超时间，可以从高优先级的开始讨论，时间到后可以根据实际情况，由团队成员自行决定是要延长讨论时间还是适可而止。
• 总结sprint目标
  这一部分建议时间是至少40分钟，一是各个组向全部成员介绍讨论结果，二是对所有的用户故事整体再排优先级，最后再根据讨论结果承诺当前sprint需要完成的范围。
  可能你回质疑既然已经花一个小时分组讨论了，为何还要花这么久的时间再总结。从经验来看虽然已经进行了详细讨论，但是只是小范围分组进行的，在最后全部人员一起总结的时候很有可能会对某个细节推翻再讨论，这部分因为是全员参与讨论澄清的时间会很长

回顾会议的仪式

回顾会议的仪式多种多样，这里只列举集中常用的以供参考

• 发散和收敛，比如ORID
• 焦点问题讨论, 比如鱼骨图
• 增强团队凝聚力，比如对别人表示感谢

无论花样繁多也不要忘记最终的仪式，即团队要根据当前情况列出可执行的改进条目，列出类似的表格方便追踪改进项，如下

SPRINT评审会议的仪式

评审会议里邀请用户及利益相关者来参加会议本身就仪式感十足

• 会议前
  邀请相关人等，并且邮件告知评审会议的内容
• 会议中
  由产品负责人演示产品，有时候需要一些演示数据，团队成员有必要提供帮助。
• 会议后
  要对会中过程中的反馈进行记录跟踪，并且邮件通知利益相关者改进状态