敏捷项目管理：如何开好回顾会议
2023-11-30 12:28:02 0 举报AI智能生成
敏捷项目管理：如何开好回顾会议
作者其他创作
大纲/内容
回顾会议（retrospective meeting）是来自敏捷方法scrum
鼓励团队对自己的开发过程进行改进，并确定什么样的调整可以使下一迭代的效率更高、结果更令人满意和更易于工作
更快地得到大家对团队工作问题和改进点的反馈，帮助团队内部的工作效能和能力的不断提升
目的
团队管理者事先完成了整个回顾分析，会上只是面向团队成员做一个回顾结论的宣讲和说明。很明显，这种层次的回顾会议不仅很有可能不能发现团队最重要的问题，更不利的是很难让结论取得团队成员发自内心的认同。
单向宣讲式的回顾会议
团队成员没有真的想敞开内心参与回顾会议，往往只是迫于会上的点名而击鼓传花式地各自讲自己的内容和观点，对其他人的观点没有回应，也没有质疑。这是明显的团队成员害怕冲突的表现，团队成员之间没有真正的融合，背后真正的问题可能是没有建立团队成员之间的信任
各自表达式的回顾会议
大家抢着发言，但是气氛紧张，经常有不礼貌地打断他人讲话的情况出现，大家都极力避免责任被认定到自己的头上，往往需要老板在最终的时候决策。定责式的回顾会议是我们需要极力避免的，这个不是我们回顾会议的目标，定责的行动往往会导致大家关闭沟通的门，导致真正的问题被掩盖
争论推责式的回顾会议
回顾中抛出的问题很多，讨论的的过程中往往还会从一个问题跳跃到其他问题上，导致会议中涉及的论点不断发散，最终往往由于问题过多，没有时间也没办法形成能落地的结论。没有结论的会议，也就没有办法拿到最终的会议价值
发散讨论式的回顾会议
明确回顾的目标是通过团队共创的方式发现团队持续进化的机会，鼓励大家用坦诚、合作、成长的心态挖掘团队改进的机会，并通过区分优先级以在最有价值的机会点上切实落地改进的行动。这个层次才是我们理想的情况，是我们追求的目标
聚焦共创式的回顾会议
五个层次
直接声明这个会议的目的，绝对没有想追究任何人的责任的意思。不仅如此，我们还需要在会议过程中避免讨论任何个人责任的问题
设定一个安全的环境
渴望发现新的想法和见解，想要了解有关迭代/发布/项目尽可能多的内容
Explorer （探索者）
将了解所有可用的信息，并乐意带走一个有用的新想法
Shopper （推销者）
对回顾会不感兴趣，但很高兴暂时可以不用做日常辛苦的工作
Vacationer （度假者）
觉得他们被迫参加，宁愿做别的事情
Prisoner （囚犯）
ESVP
了解与会人的心态
简单常用的方法是让大家按座位顺序轮流用一个词形容他/她对这个迭代的感受
激活大家的发言欲望
让大家画一条基于时间轴（标注团队的关键时刻或里程碑）的心情曲线
心情曲线法
把大家带到这个迭代历史的回忆中来
准备
通过视觉化的、隐喻性的方法做引导，比如帆船回顾法
模拟论坛接力留言的方式，一个问题一张A4纸，大家按顺序传递加上自己的简介，通过书写来收集数据
收集数据
分类需要花一点时间，但这个过程也是刚好让大家都了解其他人写了什么的好机会，所以我往往会邀请组员上来和我一起来做分类，一个人做卡片宣读，允许大家讨论，一个人把相同意思的卡片贴到一起
分类
对做得好的部分，我们需要提出来鼓励大家，希望我们能坚持下来，甚至做得更好
对待改进的部分，这个是本次会议的核心内容，不过很不幸，往往团队总结出来的待改进方面会比较多（>5个就算多吧），可会议时间有限，对这个部分，我们首先要做的就是确定优先级最高的核心问题（不超过3个）。确定的办法最常用的就是投票，比如每人两票。
产生见解
鱼骨图或5W的方法寻找问题根源
讨论寻找问题根源的的过程往往非常费时，这里常用的一个方式是把组员分组，每个小组专门讨论一个问题，我们可以限时让他们讨论出问题的根源和推荐出改进计划，这样我们一个能节省时间，更有价值的是可以调动每一个成员的积极参与度
分组讨论
一个老调重弹的就是所有的改进计划都必须是SMART的，SMART原则也不介绍了。这点说得容易，但做起来往往困难很大，大家非常容易产出一些类似建议一样的东西，完全没办法执行。这里给大家一个小窍门，在每产出一个action的时候就问一下大家“这个action可以执行吗？能判断是否完成吗？”，这样往往就能帮忙准确判断是否SMART。
SMART的改进计划
当然还有一个陷阱就是改进计划过多，到时候团队根本没有时间完成这么多的改进计划，这个也需要排优先级；还有超出团队能力范围的改进要避免，不然也没法落实。
避免产出过多改进计划
确定改进项
结束会议如果有必要的话我们可以简单对本次会议的组织做个总结建议，可以帮助我们提高下次回顾会议的组织能力
子主题
让大家每个人通过一张纸片的形式感谢团队里的一个人，并附上理由
结束会议
可参考的回顾会议流程
这有悖于准备环节中提到的设立一个安全的环境，大家会担心在会议上暴露团队问题会对他们绩效产生不好的影响。但也有一种情况我们需要经理在场，那就是团队已经积累了很多非常严重的问题，但是经理可能都不大了解情况，大家都期盼的经理在场能听到并推动解决这些问题。
一般情况不建议团队的经理参加回顾会议
一般我们建议把这些action之间放到团队下个迭代的工作列表中，和普通开发工作一样对待跟踪，只有这样才能有效地使得改进落地。
会议产生的改进计划怎么有效地跟踪？
这说明老问题一直没有解决，有的时候会发现每次改进计划都完成了，但是老问题仍然还在。一般如果想改进能力或是外部依赖的问题往往会导致这样的情况，这些不像团队自己的流程那样能立竿见影，面对这样的问题，团队最好能计划一些长期的（周期跨迭代的）改进计划，下次回顾会议可以监控进展，而不是提重复的问题。
前后回顾会议产出相同或类似的改进计划
如果需要，别忘了在回顾会议前面简单过一下上次回顾会议产出的改进计划完成情况
需要注意的地方
如何开好『回顾会议』
0 条评论
回复 删除
下一页
