专栏作者COLUMNIST

王欢的专栏

王欢,PMP、PMI-ACP、PMI-PBA、NPDP、信息系统项目管理师、PRINCE2、MSP。计算机专业硕士,软件行业7年经验,曾就职IBM,目前在国企就职,对外企和国企不同的项目管理方式有深入思考,关注微权利下的团队管理实践。翻译《PRINCE2 2017版袖珍指南》、校对《MSP管理成功的项目群》。

敏捷系列三——用户故事

2020年09月08日

A+A-

  敏捷需求管理包括需求拆分、需求优先级和验收条件三大方面,需求拆分是将小批量、小批次的需求按照端到端的原则进行层层分解,需求优先级是基于市场需求按照优先级高低进行排序,验收条件是各层级需求应该有明确的验收条件。


  对需求进行拆分,最终采用用户故事来呈现,用户故事可以用一个模板来表示:


  作为一个(As a)<角色>,我想要(I want)<结果>,以便于(So that)<商业价值>。


  敏捷中的用户故事是用来沟通的,用户故事促进和客户深层次的沟通,了解客户背后的需求到底是什么,而不是写文档。


  用户故事遵循3C原则:


  卡片(Card):用户故事一般写在小的报事贴卡片上,卡片上会写上用户故事的简短描述,工作量估算等。


  交谈(Conversation):用户故事背后的细节来源于和客户或者产品负责人的交流沟通。


  确认(Confirmation):通过验收测试用例确认用户故事被正确完成。


  用户故事的六个特征,采用隐喻的方式了解用户故事的价值,优秀的用户故事应该遵循INVEST这六个原则:


  I:Independent独立的。要尽可能的让一个用户故事独立于其他的用户故事,不会产生依赖,因为用户故事之间的依赖使得计划制定、优先级确定、工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。


  N:Negotiable可协商的。一个用户故事的内容要可以协商,用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述,不包括太多的细节。具体的细节在沟通阶段产出。如果一个用户故事卡带有太多的细节,反而会限制与用户的沟通。


  V:Valuable有价值的。每个故事必须对客户具有价值,无论是用户还是购买方。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。


  E:Estimable可估算的。开发团队需要去估计一个用户故事以便确定优先级、工作量、安排计划。但是让开发者难以估计故事的问题来自对于领域知识的缺乏,这种情况下需要更多的沟通;或者故事太大了,这时需要把故事切分成更小的。


  S:Small小的。一个好的故事在工作量上要尽量短小,最好不要超过10个理想人/天的工作量,至少要确保在一个迭代或Sprint中能够完成。用户故事越大,在安排计划、工作量估算等方面的风险就会越大。


  T:Testable可测试的。一个用户故事是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够被测试,那么就无法知道它什么时候可以完成。


  需求的验收条件在敏捷中被定义为DoD(Defination of Done),即完成的定义。通过事先确定一个对“完成”的共识可以为团队与业务节约大量的时间来处理反差大、模棱两可或隐藏的工作。这个定义也同时被用来指导开发团队了解在Sprint计划时能选择多少产品待办列表项。每个Sprint的目标都是交付符合Scrum团队当前“完成”的定义的潜在可交付功能增量。


  开发团队在每个Sprint都交付产品功能增量。这个增量是可用的,所以产品负责人可以选择立即发布它。如果开发部门制定了“完成”的定义作为规范、标准或者指引,那么所有Scrum团队都必须遵守。如果“完成”的定义还没制定,那么Scrum团队中的开发团队就必须制定符合产品的“完成”的定义。如果系统或者产品由多个团队开发,那么所有Scrum队中的开发团队必须一起参与制定。每个增量都添加到之前的所有增量上,并经过充分测试,以此保证所有的增量都能工作。随着Scrum团队的成熟,“完成”的定义会扩大,包含更严格的标准来保证更高的质量。任何产品和系统都应该对在其上面开发的工作有“完成”的定义。

标签:
版权声明

本网站所有内容版权归项目管理评论杂志社及相关权利人(本网站的资料提供者)所有,未经项目管理评论杂志社明确书面许可,任何组织及个人不得复制、转载、摘编本网站的内容,也不得在本网站所属的服务器上做镜像或以其他任何方式进行使用。凡未经许可擅自转载,均视为侵权行为,本网站将依法追究其责任。

北京世纪东方科技发展有限公司(项目管理评论)

电话:010-58383379/3420(市场部)、58383266(编辑部)

邮箱:pmr@pmreview.com.cn

项目管理评论 版权所有 有意与本刊合作者,请与项目管理评论联系。未经项目管理评论书面授权,请勿转载或建立镜像,否则即为侵权。

京ICP证13028000号-3 京公网安备11010202007990号 技术支持:原创先锋

dddd
关闭
Top