用户故事还可以这样写

作者/分享人:刘华
向 Ta 提问
世界500强企业软件开发中层管理人员; 同时负责所在部门的敏捷以及DevOps转型,包括敏捷及DevOps培训、转型驱动、工具和实践落实; 2008年开始接触敏捷开发,起步于极限编程,公司早期敏捷布道者; 熟悉极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发等。

用户故事很重要,是实施敏捷开发和持续交付的重要开端。我们看到很多敏捷的实施,只是简单地把项目的长周期拆分成短周期,并不是真正的迭代。真正的敏捷开发必须是基于用户故事的开发过程。

但是从传统的需求转换到提倡的用户故事的写法“作为……(谁),我想要……(做什么),为了……(为什么)”跨度太大,让人很难适应。这种写法虽然指出了需求分析中的两个重点——谁和为什么(业务价值),但是其涵盖的信息其实比传统的需求写法更抽象,更难以厘清问题,特别对于To B的项目。尽管敏捷强调用户故事是说的,而不是写的,但现实中,我们还是要详细记录用户故事的具体需求,以指导开发和将来维护时追溯。

那么有没有一种更容易与传统需求衔接又能兼顾敏捷所倡导的原则呢?我将分享从实战经验中总结出来的用户故事的另一种写法,帮助大家落地敏捷开发。

已有143人预订
预订达标
文章出炉
交流日期
     
17.10.07
17.10.16
17.10.23 20:30
查看文章评论/提问
陶陶
对于一个已经存在好几年的项目,因为项目很大,当时设计就是前端和服务端是分别有对应的产品,现在他们也想采用敏捷方式,但是服务端需求如何写比较好?我是QA,每次参加服务端的需求评审,总感觉他们进展不顺利,例如产品会画服务端里各模块的业务交互图,开发总是希望产品在现有模块提供的服务上做少量改动(而产品也很难很清楚服务端内部各模块之间的所有交互逻辑),最后总是感觉在争吵中有一方勉强而不甘心的妥协,而服务端这块的需求本身就是枯燥的业务语言,我也不太懂,也没法帮助他们找到他们真正想要的,至少在一定程度上能达到共赢的方式
刘华: 实录中有对本问题的答复
Jason
对于大部分需求而言,当做到了“确认理解,问为什么,验收条件”之后,一个标准的用户故事已经呈现出来了,作为“需求方”来说,其他步骤是否仍然需要提供? 另外,需求实例化是对需求提出的关键问题的回答,可以与用户故事AC结合使用,但直接替代的话是否会令实例化的过程变得更加复杂,导致一个简单的ac就能说清楚的事,还需要用一个实例来解释。
刘华: 实录中有对本问题的答复
阿牛
1、以什么维度去拆Story比较方便(按功能点?或按页面?这样和之前拆任务的方式不就一样了么)?可否有个具体的实例。 2、拆完的AC也要单独形成一个Story吗,是否要单独估算? 3、估算具体要拿哪个当参考指标,能否具个实际的例子。
刘华: 实录中有对本问题的答复
阿牛
1、如何对待共用的AC(风控或业务逻辑检查等) 2、每个Story要写这么多东西,如何集成在一张卡片上,以便能放到白板上供每日站会使用。 3、每个Sprint做演示的时候,是否需要逐条验每个story的AC,如果需要,这样演示会议的时间太长了,而且需要花很多时间准备。
刘华: 实录中有对本问题的答复
小权
重构的用户故事咋写?本质上对用户的使用不产生任何影响,一个迭代也不能交付出来,有可能多个迭代后才能交付
你可能还喜欢
110 道 Python 面试笔试题超强汇总
嘉美伯爵
Redis 实战场景详解
驰骋
轻松搞定机器学习中的概率统计知识
Evan
架构师成长之路之服务治理漫谈
飞狐
打造高效「Mac 工具栈」,提高工作效率
易水寒
操作系统基础: C 语言实现用户态线程(实战)
Allen()
微信扫描登录
关注提示×
扫码关注公众号,获得 Chat 最新进展通知!