回顾会议中的 5 种坏味道

Ethan. L

已于 2023-04-11 13:57:53 修改

阅读量362

点赞数 1

分类专栏：敏捷开发文章标签：敏捷流程 scrum

于 2023-03-28 15:24:21 首次发布

本文链接：https://blog.csdn.net/gang544043963/article/details/129811930

版权

敏捷开发专栏收录该内容

2 篇文章 0 订阅

订阅专栏

前言

敏捷开发中，Retro 回顾会议是很重要的一个环节。其初衷是，通过回顾前一个 Sprint、找出需要改进的方面、制定改进计划，使得 Scrum 团队在下一个 Sprint 中更高效更愉快。然而我发现我们经常会把 Retro 搞成低效率低收益的会议，甚至发展成夸张的“夸夸大会”，充满负能量的“吐槽大会”，或者让人压抑的“检讨大会”。本文通过列举一些常见问题和注意事项，希望能帮助大家更好地运用 Retro 提升团队效率。

何谓 Retro

Retro = Sprint Retrospective. 它是 Scrum 团队检视本次 Sprint 并创建下一个 Sprint 改进计划的会议。

一般在上一个 Sprint 评审会议结束之后，下个 Sprint 计划会议之前，长度一般在 1~2小时。由 Scrum master 组织，如果实际情况中没有 Scrum master，可以轮流或者指定。

它的主要目的就是逐渐提升 Scrum 团队的工作效率。

关注点在于团队的角色关系、协同方式、人员状态、工具、流程等等。

团队成员一起列出在上一个 Sprint 中做的好的方面，和需要改进的方面，然后进行讨论，最后列出改进的 Action。Action 作为会议输出，也是最重要的部分。

常见坏味道

1. 吐槽抱怨

我们的目的是发现问题，然后一起想办法解决问题。而不是发泄不瞒、抱怨。然而这是最常见的问题，也是符合人性的。

例如：

⛔ 示例1：我们的开发效率太低了

⛔ 示例2：Android 开发体验差极了

⛔ 示例3：我不喜欢站会的形式

我们应当尽可能地用“非暴力沟通”的方式阐述具体问题，避免输出带有浓烈个人情绪的概括性信息。

以上三个示例均属于个人主观感受，不能明确说明具体问题，更不容易形成 Action。

改进后：

✅ 示例4：这个 Sprint 中开发任务只完成 80%

✅ 示例5：Android 模拟器平均 10 分钟卡顿一次，这降低了我们的开发效率

✅ 示例6：大家在站会上只是工作汇报，这并没有给团队带来价值

2. 关注个人而非流程

如果有人对我们说：“我对事不对人啊”，那么接下来他很有可能要开始责备一个人了。

由于“事”是“人”做的，那么“事“有问题的时候，就很容易殃及”人“。

例如：

⛔ 示例7：由于 XXX 提交的代码有问题，导致其他人员更新代码后运行不起来。（提交代码前你最好多自测一下）

⛔ 示例8：由于 XXX 没有按照预定时间提供设计图，导致开发两天实践处于等待状态。（你该提高效率了）

要知道，Scrum 关注的团队，而不是个人。大多数的个人错误都可以用更好的流程避免，例如银行严谨规范的操作流程可以避免工作人员的失误。

所以必须记住关键的一点，即大家不要从团队中找一个人当成责备的对象，而是要将注意力集中在流程上。并且我们要遵守一个“最高指导原则”： “无论发现什么，我们完全理解并且相信每个人在当时状况下，基于他的能力和资源，做出了最大的努力”。 只需要认真分析以下几个问题：为什么会发生那件事？为什么我们当时忽略了？怎样才能加快工作进度？作为一个团队，大家要对自己的流程和结果负责，要集思广益，共同寻求问题解决之道。这一点是至关重要的。

改进后：

✅ 示例9：上个 Sprint 出现了主分支上的代码不能运行的情况，我们可以考虑代码提交流程和 CI 是否需要改善，来避免这种情况再次发生

✅ 示例10：上个 Sprint 发生了开发等待 UI 设计图的情况，大家讨论一下从流程上怎样才可以避免这种情况发生，比如建卡的时候把 UI 开发和逻辑部分分开，如果 UI 设计组人手不够，可以考虑增加人手，要不要额外设立一个会议专门讨论任务排序问题。

与此同时，团队必须有勇气把真正的障碍摆到台面上来，这样做是为了解决问题，而不是为了指责某个成员。团队成员必须能认真探讨问题，并虚心接受他人反馈的意见和建议，以便寻求问题解决之道，而非只想着为自己辩解。

3. 粗犷的 Action

行动”（Action）环节，也就是改善环节才是关键，这样才能真正改变流程，使其变得更好。只分享自己的感受是不够的，还必须采取行动去解决问题。

这里建议大家在提问题之前，最好自己先尝试想想解决方案，而不是只抛出问题，这样有助于快速形成有效的 Action。

制定 Action 时，可能会犯的几个错误：

太宽泛：例如“提高前后端协作效率”，怎么提高？怎样才算提高了？应该具体点，例如“后端团队利用 Swagger 平台输出 API 文档”，“制定 API 时邀请前端人员参与”。

太大：一个 Sprint 往往时间很短，Action 如果太大，会影响整个 Sprint 计划。而且也不符合 “小步快跑” 的基调。

太多：同样会影响 Sprint 计划，并且容易被忘记，只需要挑出两三个最紧迫或收益最大的即可。

4. 冗长的讨论/争论

我们很容易进入细节讨论，技术人员尤其如此。这就需要 Scrum Master 或其他主持会议的人来把控会议节奏和方向。

5. 忽视 “快乐指标”

Retro 中我们一般以 1-5 分来量化每个人的快乐指标。但很多时候大家也就是打打分数，并没有认真对待这个事情。而且我们在打分数的时候是有顾虑的，不那么诚实的。

我们都需要快乐，《敏捷革命》中认为 “快乐便是成功”，里面提到：

“关于 ‘快乐’ 的重要性，研究结果是非常清楚的。快乐的人往往表现更优秀，在家里、在职场以及在生活中都是如此。他们收入较高，工作较好，接受过大学教育，寿命也比较长。这是非常值得关注的”，“几乎在人生的方方面面，快乐都能促使我们取得成功，包括婚姻、健康、友谊、社区活动、创造力，尤其是在工作、职业生涯和商业上”。

所以，“快乐” 不能被忽视。

敏捷提倡 “信任” 和 “透明” ，所以有什么事情影响了你的心情，说出来，大家帮忙解决。我们不是冷冰冰的机器人，我们都有快乐工作的诉求。所以，我们应该一起努力，形成一个快乐的团队氛围。

延续 “快乐指标” 的话题，有几个小点子可以帮助我们建立团结快乐的团队：