来源:徐东伟敏捷教练
作者:徐东伟
用户故事对于每个敏捷小伙伴来说,似乎是再熟悉不过的东西了。然而,虽然我们对用户故事的写法如数家珍,但大多数人写用户故事的时机却是不对的。
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,线上直播,扫码立即报名,精彩内容,不容错过