如何避免Scrum敏捷开发团队反思会形式化？
迭代压力很大，根本没时间，而且，反思会上大家都在互相推脱责任，会议成了“批斗大会”，所以团队的人都觉得这个会很鸡肋。
很多团队在开反思会时是这么干的：产品经理提前做好各种分析和总结，然后召集大家开会一条条过，其他人有一搭没一搭地听，最后反思会就变成“你讲我听”的形式化存在。
因为大家没有什么参与感，更别提对问题有什么共识或者讨论了。
开反思会时应该极力避免这种情况的发生。
反思会目的很简单：1. 让团队每个人都能平等地发表自己的想法；2. 团队对问题要有共识，并能一起探讨解决方案；3. 团队反思氛围比较积极。
要达到这样的效果，需要有一个合适的方法论框架，而我采用的是“海星”法。
这种反思方法是基于“海星”的框架来收集意见并让团队共识问题的，框架结构如下：
【五个角的解释】
- 不要做（Stop）：接下来不能继续的，对团队完全没价值的事；
- 少做一些（Less）：要少做的，对团队价值不高的事；
- 多做一些（More）：要多做的，对团队有意义的事；
- 继续保持（Keep）：团队做的好的，要保持的；
- 新尝试（Start）：以前没做过的，但可能给团队带来高价值的新点子。
在实际操作中，可以这么做：
- 在白纸上画出海星，写好各个角的标签，然后把它贴到墙上；
- 给团队中的每个人发便签纸，让大家先花2～3分钟的时间写团队应该马上停止做的事（每个人写1～2条）；写完的人就把便签贴到白板上。到时间后，再继续花2～3分钟时间写团队要少做些什么，以此类推，直到五个角都写完；
- 请团队里的人轮流读一下各个角的便利贴，在读的同时将相似的内容归类到一起；
- 大家对问题都有了共识之后，就开始投票。每个人有3票，按投入产出比投出自己认为最重要，最需要解决的条目；
- 三个重要的改进项出来后，大家一起讨论，针对每个改进项制定一套可行的解决方案。这个部分非常重要，这部分讨论的时间至少会占到我们团队整个回顾会议时间的25%；
- 为了保障解决／行动方案能被执行起来，把方案拆解为任务放到敏捷看板中，避免大家又一头栽到工作中而忽略了调整。
一些建议：
- 为了活跃气氛，可以在写便签时播一些音乐；
- 让大家轮流读便签很重要，它也是提升参与度的一部分；
- 在大家读便签时，我一般会打开团队文档协作工具，在上面做记录，等到投票时，就直接让大家在上面匿名投票（如下图）；
- 共识优先级最高的3项就好。由于在敏捷中，迭代周期很短（通常是2～4周），所以即使存在很多问题，也无法一一解决，因此，能在短期迭代中解决优先级最高的三个已经很棒了！
海星反思法的好处：
- 团队成员被赋予了表达和决策的权利（平等、自组织是敏捷的核心理念，与传统的领导一人拍板相对）；
- 共同的讨论让团队对问题有更为深刻的共识；
- 由于是团队在共同做决定，所以这种方法也提升了团队改进问题的积极性；
- 积极活跃的反思氛围。
心得体会：
在实践敏捷的过程中，我开始一点点体会到“参与感”这个词的意义。“海星”法虽然是一个很小的方法，看起来挺简单的，但对我的团队来说，它却起到了很好的反思效果，至少每个成员在开会时都很投入，每个人都愿意表达。
此外，我们会在每个迭代结束后都开一次迭代反思会。这个很重要！
如果开反思会时，采取的是“三天打鱼两天晒网”的态度，想起来就开，太忙就不开，会让团队失去节奏感，而且减少了及时发现问题，解决问题的机会。因为有了这样定期反思的机制，我的团队也在集体反思中不断进步，做出来的东西也越来越好。
推荐大家在工作中定期地用这个方法去做团队反思，及时解决问题。坚持下来，会有意想不到的收获。