敏捷项目管理-用户故事

在远古时代,文字没有出现之前。知识的传承靠口口相传,不管隔了多少代,其准确性很高。文字出现后,我们大脑中的这种技能反而逐步衰退。于是各种软件、各种方法充斥着我们,左右着我们。各位是否也有相同的想法?试想一下,上节课我们讲了什么?每次应允别人的承诺,我们转过头就忘记?比如忘记约会,忘记洗车、忘记写日报?

“要想知道栗子的味道,你得咬一口”这个真理朴实,正确。当用户提出一款软件时,我们不要只想着从技术的角度,认为用户不专业,他的需求是错误的。如果他专业,就没我们啥事了。用户大脑中的需求是离散的,不可控的,这时,就需要我们放下成见,彼此真诚相对,让用户参与进来,通过各种方法,一条条梳理,直至双方的理解是一直的。

其作用:1.我们弄懂了用户为何会这样想。2.用户通过亲身参与,头脑中的需求逐渐变成技术可理解的。“求同去异”是一个很难的过程,需要双方彼此做出改变,很难.....,往往难得事情才是最重要的,要不怎么会有“战胜困难”的伟大,痛苦成就了欢乐。

软件的最大价值只有在用户认可,使用才算真的有价值。“再牛逼的算法,再严谨的逻辑”不符合用户实际需求,都是白费力气。“当顾客很饥饿时,他只需要的立马填报肚子的食物,而不是需要几天或者几个月才能做好的满汉全席”。

扯远了,回归正题。因用户对软件领域不专业,脑中对需求没有一个正确的定论。就需要我们专业人士,运用特殊的方法,梳理用户真正的意图。“用户故事”无疑是最好的方法之一,其包含三个要素“角色、活动、商业价值”,用户故事的表达方式:”作为一个<角色>,我想要<活动>,以便于<商业价值>。

“例:作为一个很饥饿的顾客,我想要一份食物,来填饱我的肚子“。这就是一份明确的用户故事。

那么要实现这种记录方法,有三个原则:
卡片:故事一般写在小的记事本上。故事尽可能对当前的需求简单的描述,其作用是为了以后的交谈;
交谈:故事背后源于我们和客户/产品负责人的沟通交流;
确认:可以确认验证的正确结果、通过验收测试确认的用户故事被正确完成,才算整的完成。

敏捷开发故事细化为开发提供了可执行标准,其特点是快速迭代,故一个用户故事的大小和复杂度应该在一个迭代周期内完成。如果是史诗那样的故事,可能会导致它需要“几代人”(几波人,即有可能只做了一半,团队砍了,新人接手),其弊端不是本次重点。每个人物最好不要超过8小时,如果超过8小时,说明任务的划分是有问题,如何做到事事清日日清?




用户故事的6个特性:

  1. 独立性
  2. 可协商性
  3. 有价值的
  4. 可以估算的
  5. 短小的
  6. 可测试的

正是每个故事的独立性,才保证其短小,可以估算,也可协商(更改某个故事对系统的影响很小),最终交付给用户才是可以测试的,只有软件通过用户的测试,软件的价值才会被最大化。要避免”孤芳自赏“,做技术的,多少有点读书人的清高,说通俗点就是有”臭老九“的毛病,我的产品是最好的,你客户不认可,是你的问题。要学会转变(不是服软),运用有用的方法,来实现可协商,可以估算、等六个特性,做到刚柔并济....

确定用户故事的优先级,有几种方法:

相对优先级=价值/工作量
莫斯科规则:必须有的、应该有的、可以有的、这次不会有的;按照价值进行分类,优先处理必须要的和应该有的。如果离约定交付的日期还有一定的空余时间,可以考虑可以有的,反之跳过。这次不会有的,不多少,看字面各位应该会理解。
卡诺模型:1.基础型需求;2.期望型需求;兴奋型需求。搞过KPI的都会知道,关于目标会有门槛值、期望值、挑战值,往往我会按挑战值的来做,最终有可能实现期望值,别问我怎么知道的.....
风险--价值指标:确定优先级的同时,要考虑风险和价值,至于是先处理哪一个?灭火时,消防员会优先处理哪一个?娃娃一个不哭、一个哭闹时,我们会优先关注哪一个?
确定好用户故事的优先级后,我们将这些故事组成产品待办列表(product backlog),根据backlog和团队速率(至于如何估算,以后会讲)来估算故事规模,并确定最终的发布计划。



请根据下面的图片,构思一下用户故事

原文地址:https://blog.51cto.com/14082130/2474701

时间: 2024-10-05 03:09:20

敏捷项目管理-用户故事的相关文章

用户故事驱动的敏捷开发 – 2. 创建backlog

本系列的第一篇[用户故事驱动的敏捷开发 – 1. 规划篇]跟大家分享了如何使用用户故事来帮助团队创建需求的过程,在这一篇中,我们来看看如何使用这些用户故事和功能点形成产品backlog.产品backlog是敏捷开发中用来管理需求列表,排定优先级,形成迭代计划,组织开发/测试和交付过程的工具.可以说,产品backlog是一个敏捷团队管理开发过程的核心,所有的活动和交付物都围绕backlog来进行.一旦需求明确,我们就必须在开发过程中持续的跟踪backlog内容的实现和交付过程,确保我们的想法可以按

用户故事驱动的敏捷开发 – 1. 规划篇

敏捷开发现在已经不是新鲜事物了,我们都从各种渠道听到过不同的团队实施敏捷的胜果,听的时候觉得很美,回到家就发现那都是别人家的团队,结合自己的情况一看就发现问题一大堆.就算是最终打算一试,也经常会不知如何开始.这就是我希望编写这份文档的原因,能够找到一个遵循的敏捷项目管理模型,虽然我们都知道没有一个放之四海而皆准的方法,但在更高的层面上我觉得这仍然是可行的.也就是说,管理模型是一致的,但是其中采用的方法可能各有不同,最终目标是唯一的:打造一支可以快速适应变化的高质量团队,并输出高质量的产品! 今天

菜鸟Scrum敏捷实践系列(三)用户故事的组织---功能架构的规划

采用Scrum敏捷项目管理方法进行产品开发,当碰到较大规模的产品开发,用户故事较多时,就必须采取一定的方法来组织.管理用户故事,使其分门别类的管理,条理才清楚.通常我们采用“功能架构”来分层分类别来管理用户故事. 一.规划层次 遵循Scrum敏捷项目管理理论,可把项目划分为三个大的层次,分别是顶层的产品层,支持多个产品同时开工:第二层是功能架构(Features)层,能够规划软件产品的整个骨架(功能蓝图):第三层是用户故事层,把用户故事分门别类的放在功能架构之下.项目管理者和开发者能够一目了然的

用户故事与敏捷方法①

在读这本书之前,自己觉得有点好奇,用户故事指的是什么呢,读完之后,有了体会:用户故事描述了对用户.系统或者软件购买者有价值的功能.它由3方面组成:1>一份书面的故事描述,用来做计划和作为提示:2>有关故事的对话,用于具体化故事细节:3>测试,用于表达和编档故事细节且可用于确定故事何时完整. 它总共分为了五大部分来介绍: 第一部分是一些简单的概念或者使用故事的细节方面,比如如何编制用户故事,有哪些细节要求:在故事中找出用户角色模拟使用情节:怎样搜集到用户故事,通过各种途径:如何找到用户代理

菜鸟Scrum敏捷实践系列(一)用户故事概念

敏捷开发对需求规划的要求是很高的,首先需求是打散的,一个大的项目需求会拆分成很多小的功能完整的需求,以便排定优先级去逐个实现,敏捷开发提升了开发效率,但是对需求规划的要求更高了,就是对产品的需求规划能力提出了更高的要求,必须有清晰的思路,很强的需求规划能力才行,这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计. 敏捷开发是通过“用户故事”这个东东来实现传统软件开发所说的需求的. 一.什么是用户故事? 用户故事就是定义用户所需功能的文字描述,简单说就是用户的需求.一个好的用户故事包括

《用户故事与敏捷方法》阅读笔记06

第八章 估算用户故事 故事点有一个很好的特性是团队可以定义自己认为合适的故事点,一个团队可能定义一个故事点为一个理想日的工作,也可能定义为一个理想周的工作.故事点有很多意义,所以故事点代表时间的模糊单位. 故事估算应该由整个团队集体来完成.故事估算属于团队集体有两个原因,第一个,还不确定团队中谁负责完成这个故事,第二个,团队决定的估算可能比个人估算更有用.在估算时,作者介绍了他所用的方法迭代的方式进行估算.在初步估算好后,成员进行讨论,然后进行下一轮的讨论,最终达成一致. 三角测量.估算一个故事

用户故事与敏捷开发方法笔记06

用户故事得到这么多人的肯定,是因为它自身的优势有很多:1.用户故事强调口头沟通,因为传统的通过各种文档进行表达,每个人对于文字的含义的理解都不同,所以在阅读文档的过程中可能会因为理解的不同对项目的完成造成影响:2.人人都可以理解用户故事,并且用户故事可以增强人们对各种事件的记忆:3.用户故事的大小适合做发布规划以及进行编程和测试:4.用户故事适合于迭代开发,项目过程中可以写出一部分故事然后就进行编码和测试5.用户故事鼓励延迟细节:6.用户故事支持随机应变的开发,因为用户故事注重口头交流,而且很容

用户故事与敏捷方法读书笔记02

开发软件可以通过编写用户故事来确立开发的目标和方向.而在编写故事前首先要对所有用户进行分类,根据角色的不同属性进行分类.步骤为:1.通过头脑风暴,列出初始的用户角色集合:(要坚持‘已确认的角色代表的是单一用户’的原则)2.整理最初的角色集合:(确认角色之间的关系:用户角色定义的是人而不是外部系统)3.整合角色:(对于完全重叠的用户进行重新定义,舍弃对系统成功作用不大的角色)4.提炼角色(根据角色特征来建立角色的模型). 编写故事之前需要搜集故事,通过与用户沟通来发现故事.可以像用渔网捕鱼一样获取

《用户故事与敏捷方法》阅读笔记01

用户故事与敏捷方法第一章是对用户故事的概览.      首先第一个问题用户故事是什么?用户故事描述了对用户.系统或软件购买者有价值的功能.用户故事由三个方面组成,包括1 .一份书面的故事描述,用来做计划和作为提示.2.有关故事的对话,用于具体化故事细节.3.测试,用于表达和编档故事细节且可用于确定故事何时完成.      然后第二个问题细节,故事的细节可以用另外的用户故事来描述,多个小故事远远胜于一个庞大的故事.书上将大的故事成为史诗故事,那些史诗故事可以分为多个小故事.例如将"用户可以搜索工作