分享几个团队敏捷转型过程中的故事

关注

发布于: 13 分钟前

作为 ScrumMaster，有机会和不同的团队合作，会发现 Team 在从传统工作方式转变为敏捷开发方式的时候，会有一些相似的经历(一些弯路都会走一下)。这也是团队成长的必经之路。今天向分享几个我在多个转型团队中遇到的相似的故事，希望能够引起你的共鸣和思考。

故事 1 单件流 vs 并行工作

下面图例是从一个团队的 Scrum 电子看板中两个 Dev 的开发状态，这个团队刚刚从传统瀑布开发方式转型，当前这个项目是第一次用 Scrum 方式跑 Sprint。每个 Sprint 为期 3 周，这是第一周周五时候的 Snapshot。

从图中看到以下几点：

1/3 Sprint 即将过去，没有能开始测试的 User Story。
Dev1 同时开始 4 个 User Story(用户故事)，而 Dev2 只做一个。谁是更适合 Scrum 的方式？

Scrum 的 5 个价值观中有一条就是 Focus(聚焦)，大家应该在同一时间聚焦一个任务。因为多任务造成的上下文切换会导致效率的损失。从实际工作角度，像 Dev1 这样同时开始 4 个任务也不太可能，除非这 4 个属于一个 User Story 的子任务，否则在同一时间是无法真正并行的。肯定还是要串行来开发。那开发人员为什么还要一起开始这么多任务呢？宁可在 1/3 Sprint 时间过去都没有一个可以开始测试。如果 4 个用户故事属于一个更大的故事，而他们 4 个无法独立测试，那为什么要拆分这么多子任务？Dev2 很聚焦，只作一个用户故事，同样经过很长时间，但测试无法开始进行。按照 Scrum 的思想，我们是希望能够尽早测试用户故事，从而验证逻辑的正确性，以便能够通过反馈进行调整。所以 Dev1 和 Dev2 都需要做一些调整，例如将大的用户故事进行拆分；尽早完成用户故事并进行测试形成反馈闭环。

故事 2 Sprint Backlog Item VS Bug

下面这个截图是同一个项目的另一个团队，在 Sprint 第二周周五的早会结束后的看板状态。

从图中可以看到，Testing 状态的 User Story 已经堆积了一些，同时有一些存在明显的 Bug(验收标准没有通过)。团队虽然也在修改 bug，而同时也在继续将的 print Backlog 中的 Item 拽入 Doing 列中。和团队沟通发现大家有如下几个想法：

Sprint 中 Bug 和 Sprint Backlog Item 谁更重要？

大家普遍认为 Sprint backlog Item 更重要。可以留一些 Bug 而不能不开始 backlog 的开发。因为大家默认会认为没做和做了但有 Bug，前者客户不能接受。
虽然有 Bug，但是如果不做剩下的 Sprint Backlog 会导致一些更重要的 Story 没有做进来，无法达到 Sprint Goal。

这一点很有意思，因为团队在 Sprint 中应该先做优先级最高的 backlog，如果在 2 周过去后发现没做的 Item 里面仍然有很重要的 Backlog，那会是什么原因呢？

在 Sprint 中，我们应该保证每一个 Sprint Backlog 都能尽快够通过 AC(验收标准)的测试，同时也要达到 DoD(完成标准)，之后再开始新的 Backlog，这样才能保证当 Sprint timebox 结束的时候，得到的都是符合完成标准的，而不会有半成品。如果仍然有”Bug”剩余，而且已经通过了 AC 和 DoD，那么可以考虑真的是 Bug 还是前面的标准过低了。Bug 如果无法在当次 Sprint 完成，那么建议汇入 Product Backlog 和其他 Backlog 一起重新排序，决定是否在后续 Sprint 中 fix 掉。这个故事另一个分享点就是，Sprint 中也需要优先做最重要的事情，避免由于突然原因无法完成 Sprint 所有任务的时候，对 Sprint Goal 的影响讲到最低。

故事 3 Sprint 中发现的 Improvement 如何来做？

这个问题是同一个项目中的 BA 来问的我，因为 Team 在 Sprint 中对某些用户故事提出了更好的建议，大家希望当成 Improvement 来做，这个时候希望能有 JIRA 来跟踪，但是 BA 不确定这类 JIRA 是否应该在当次 Sprint 内完成还是在紧接着的下一个 Sprint 中。我的想法是，先确定这类 Improvement 是什么性质的：

如果是对当次 Sprint Goal 相关的，很大可能就是 Bug。例如因为进一步了解了业务逻辑，从而发现了更好的实现方式，或者之前的设计不合理了。这种如果时间允许，最好在当前 Sprint 中做完。
如果和当次 Sprint Goal 无关，可能是由于对系统的了解和业务的熟悉，团队对以往做过的功能有了新的思考，这种最好将它和剩余的 Product Backlog 放到一起，从 Product Goal 的角度来思考优先级，看放到后续那个 Sprint 中。

【欢迎关注我的博客】