不吓唬你，一不小心Scrum就变成小瀑布

Posted 2021-04-23 PMO前沿

吃蛋糕

亲们这个蛋糕诱人吧？

提问：你觉得怎么吃更好吃呢？

A:一层一层吃

B:竖着切着吃

。

。

。

美味的蛋糕可不能一层层吃，要竖着吃才能一口尝到所有的味道。

为什么小编这么文不对题？

其实，我是想说，A的吃法很像瀑布式项目管理，而B呢则更像Scrum~~~

我们是怎么掉到小瀑布的坑里的

通常，我们会在Sprint计划会上把优先级最高的用户故事变成Sprint列表。这个Sprint列表不仅包括这些用户故事，还包括他们的衍生物，“任务”。这些具体而详细的故事是开发团队成员在整个Sprint中的工作对象，展示成五颜六色的贴纸在任务板上跟踪。（这里有一个小建议，任务大小在2~8小时之间，如果超过8小时就缺乏了灵活性）

好啦，坑来啦！让我们看一个用户故事的“栗子”：

用户故事

“作为一个新的用户，我希望登录掌阅APP，这样我就可以在书海中尽情享受了”

A:

任务1：设计端到端功能测试案例

任务2：生成测试数据

任务3：开发数据库层

任务4：开发业务逻辑层

任务5：开发用户交互层

任务6：开发端到端功能型自动测试案例

B:

任务1：开发用户名/密码功能（包括测试设计和自动化）

任务2：开发电子邮件鉴权功能（包括测试设计和自动化）

任务3：开发登录页功能（包括测试设计和自动化）

我猜想大家也认为A的拆分方法符合逻辑，而且简单易懂，并且也挺好用的吧。但是请你仔细看看A像什么？没毛病！A就是一层一层吃蛋糕。 迷你型的瀑布是开发！！！

与此相反为什么不在任务层面上也使用广泛应用于用户故事层面的纵向切片法呢？这样一来，可能几小时后就可以验证我们的工作，这多炫酷！

如B，我们把故事分成一些封装好的最终用户功能，每个包括一小块数据库工作、业务逻辑和用户界面实现。最厉害的是 迷你型瀑布变成安全的小溪流，反馈周期从按天算变成按小时计算了！

每个任务都是纵向切片，避免离散不连续的层，从而缩短反馈周期。

小问题

Q

这个问题你想过吗？如果B的任务已经拆分成了更小的功能，为什么不把这些功能叫做单独的用户故事而叫它任务呢?

A

首先，我们不要忘记“故事要对用户有价值~”虽然登录肯定有用户价值，但一个单独的电子邮件身份验证就不一定有价值。

其次，故事需要具有独立性。如果能把故事分得更小而且还能独立给他们排列优先级，那么把它们作为单独的故事而不是任务就是有道理的 。上面的例子，没有一个任务能够排列优先级，因为从客户角度来说，价值不完整，也不连贯。

应广大粉丝要求，我们建立了一个【PMO前沿交流微信群】，小伙伴们热情踊跃很快超过400人了，不能直接进群啦，想要进群的添加小编微信，小编拉你进群。两个添加其一即可！

   

我们的源文件也会不定期分享到群里哦！！！赶快加入吧！！！