用户故事对于每个敏捷小伙伴来说，似乎是再熟悉不过的东西了。然而，虽然我们对用户故事的写法如数家珍，但大多数人写用户故事的时机却是不对的。
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中的故事会随着时间推移增加甚至是删除（如果发现确实不需要了）；
- Product Backlog中故事的相对优先级会动态调整。
这样我们就能够始终在做当前最高优先级的事情，而不是当初设定的优先级，因为环境在变，我们的优先级也要随着变！敏捷性由此体现！
注意事项
千万不要在遥远的故事上花费大量的时间，切记切记！一句话标题用来占位足够，再不成可以加上怕自己忘记的几个要点。因为未来的事儿谁也说不好，也许过一段时间想法就变了，或者无限期搁置，甚至有可能不需要了，过早做就是浪费！
在Product Backlog顶端的高优先级故事，如果拆的更小，也许你会发现，拆出来的故事可能只有一部分会保持原来的优先级，其余的也许可以调到更低的优先级，为其他更高优先级的故事让路。
说明：从一个想法到一堆的用户故事，可能会用到用户画像、影响地图、用户故事地图等工具来做转化，因为不是本文说明的重点，所以就不进行详述。
总结
传统的需求和敏捷的用户故事，真的有可能在写完的时候长的差不多。我认为根本的区别是它们形成的过程和书写的时机。
用户的视角、细致的拆分、渐进明细、优先级动态调整、减少浪费、快速响应等等优势的综合体，让用户故事在敏捷世界里更具竞争力！
IDCF DevOps黑客马拉松，2021年度城市公开赛，11月6-7日，深圳站，企业组队参赛&个人参赛均可，一年等一回，错过等一年，赶紧上车~公众号回复“黑马”加入