用户故事对于每个麻利小伙伴来说，仿佛是再相熟不过的货色了。然而，尽管咱们对用户故事的写法一五一十，但大多数人写用户故事的机会却是不对的。
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 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
IDCF DevOps 黑客马拉松，2021 年度城市公开赛，11 月 6 - 7 日，深圳站，企业组队参赛 & 集体参赛均可，一年等一回，错过等一年，连忙上车~ 公众号回复“黑马”退出