大多数人写用户故事的时机都是错的

来源：徐东伟敏捷教练
作者：徐东伟

用户故事对于每个敏捷小伙伴来说，似乎是再熟悉不过的东西了。然而，虽然我们对用户故事的写法如数家珍，但大多数人写用户故事的时机却是不对的。

What? 时机？不对？

别着急，听我慢慢道来！

你是否对以下的反模式非常熟悉呢？

反模式1：将需求文档转成故事

这种情况最常发生在团队刚刚做敏捷转型时。那个时候已经有需求文档存在了，我们总不能立刻把需求文档扔到垃圾桶，从零开始写用户故事吧，所以大多数人干的事情就是用需求文档中的信息填充用户故事。从表面上看，写用户故事的工作就是把需求文档换一个格式。

特别是在大公司，业务方和研发团队又不在一个团队，甚至不在一个部门。在研发团队把需求文档转成一堆用户故事的同时，业务方还在同时继续写需求文档。就这样，周而复始，没完没了，真的是转不完的用户故事啊！

如此一来，团队就困惑了。先写需求文档，再转用户故事，敏捷是不是吃饱了撑的，直接按需求文档写代码不就完了吗，何必“脱了裤子放屁”呢？

反模式2：只在迭代开始前写故事

马上就要开始下个迭代了，Product Backlog里还没有东西呢，怎么办？

那就写啊！一顿狂赶，终于写完了，足足一个迭代的，还奔儿详细，老有面子了！

这样做有问题吗？为啥是反模式？看完后面你自然就明白了！

反模式3：所有故事都太详细

有人说了，不管Product Backlog里的故事是打算什么时候做的，只要放进去，就一定要详细，工作嘛，一定要像样！不成熟的想法放进去是会惹祸的，也显得草率啊！这样做真的可取吗？

推荐模式

终于到正题了！下面我来聊聊推荐的用户故事书写模式。

1）找到需求的始作俑者，就是写需求文档的那个人；

2）请他从现在开始停止写需求文档，否则你还是逃脱不了需求文档转用户故事的命运；

3）请他把要做的事情一股脑全放到Product Backlog中；

把所有要做的东西都放到Product Backlog中的好处是：

4）请他为Product Backlog中的故事排优先级，优先级高的放上面，优先级低的放下面。

5）看看Product Backlog顶端大概1-2个迭代的量，故事描述得够不够详细，有没有把事情说清楚，拆分的够不够细，能不能放入一个迭代（通常建议用户故事最好能在迭代长度的一半时间内完成）。如果没有，那么就想尽各种办法去搞定，包括和利益相关人沟通，当然也包括研发人员。

以上步骤3-步骤5要高频定期或不定期进行循环（这就是传说中Product Backlog Refinement的内容了），这时你就会发现：

这样我们就能够始终在做当前最高优先级的事情，而不是当初设定的优先级，因为环境在变，我们的优先级也要随着变！敏捷性由此体现！

注意事项

千万不要在遥远的故事上花费大量的时间，切记切记！一句话标题用来占位足够，再不成可以加上怕自己忘记的几个要点。因为未来的事儿谁也说不好，也许过一段时间想法就变了，或者无限期搁置，甚至有可能不需要了，过早做就是浪费！

在Product Backlog顶端的高优先级故事，如果拆的更小，也许你会发现，拆出来的故事可能只有一部分会保持原来的优先级，其余的也许可以调到更低的优先级，为其他更高优先级的故事让路。

说明：从一个想法到一堆的用户故事，可能会用到用户画像、影响地图、用户故事地图等工具来做转化，因为不是本文说明的重点，所以就不进行详述。

总结

传统的需求和敏捷的用户故事，真的有可能在写完的时候长的差不多。我认为根本的区别是它们形成的过程和书写的时机。

用户的视角、细致的拆分、渐进明细、优先级动态调整、减少浪费、快速响应等等优势的综合体，让用户故事在敏捷世界里更具竞争力！

IDCF DevOps黑客马拉松，独创端到端DevOps体验，精益创业+敏捷开发+DevOps流水线的完美结合，2021年仅有的3场公开课，数千人参与并一致五星推荐的金牌训练营，追求卓越的你一定不能错过！

11月6-7日，深圳站，企业组队参赛&个人参赛均可，一年等一回，错过等一年，赶紧上车~👇

大多数人写用户故事的时机都是错的 | IDCF