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

来源：徐东伟敏捷教练

作者：徐东伟

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

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中故事的相对优先级会动态调整。

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

注意事项

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

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

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

总结

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

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

本课程主要讲述敏捷项目管理理念与方法实践，主要介绍规划与设计中的影响地图、用户故事地图，敏捷需求管理以及团队与协作；并以华为云敏捷项目管理企业实践，阐述了敏捷项目管理的理论、方法与模型。

本期训练营第三模块【协作模块】邀请到华为云DevCloud 高级产品经理 张军胜老师带来3小时大时段课程分享，主题是《敏捷项目管理实战》

6月7日（周二）和6月8日（周三）晚上19:00-20:30，线上直播，扫码立即报名，精彩内容，不容错过