敏捷21天打卡--用户故事

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

“要想知道栗子的味道,你得咬一口”这个真理朴实,正确。当用户提出一款软件时,我们不要只想着从技术的角度,认为用户不专业,他的需求是错误的。如果他专业,就没我们啥事了。用户大脑中的需求是离散的,不可控的,这时,就需要我们放下成见,彼此真诚相对,让用户参与进来,通过各种方法,一条条梳理,直至双方的理解是一直的。其作用:1.我们弄懂了用户为何会这样想。2.用户通过亲身参与,头脑中的需求逐渐变成技术可理解的。“求同去异”是一个很难的过程,需要双方彼此做出改变,很难.....,往往难得事情才是最重要的,要不怎么会有“战胜困难”的伟大,痛苦成就了欢乐。

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

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

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

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

用户故事的6个特性:

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

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

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

  1. 相对优先级=价值/工作量
  2. 莫斯科规则:必须有的、应该有的、可以有的、这次不会有的;按照价值进行分类,优先处理必须要的和应该有的。如果离约定交付的日期还有一定的空余时间,可以考虑可以有的,反之跳过。这次不会有的,不多少,看字面各位应该会理解。
  3. 卡诺模型:1.基础型需求;2.期望型需求;兴奋型需求。搞过KPI的都会知道,关于目标会有门槛值、期望值、挑战值,往往我会按挑战值的来做,最终有可能实现期望值,别问我怎么知道的.....
  4. 风险--价值指标:确定优先级的同时,要考虑风险和价值,至于是先处理哪一个?灭火时,消防员会优先处理哪一个?娃娃一个不哭、一个哭闹时,我们会优先关注哪一个?

确定好用户故事的优先级后,我们将这些故事组成产品待办列表(product backlog),根据backlog和团队速率(至于如何估算,以后会讲)来估算故事规模,并确定最终的发布计划。

原文地址:https://www.cnblogs.com/atun/p/12081655.html

时间: 2024-09-30 00:25:05

敏捷21天打卡--用户故事的相关文章

21天敏捷打卡-用户故事地图

上图是基于敏捷故事的一个看板或者说敏捷流程中的一种,没有什么比亲身投入的效果更好.用户.组员需求方通过自身的投入.表达以便于让团队成员更加了解其想法和统一组员的想法.用户故事是一种思维,通即故事思维,运用故事的元素进行思考和设计,解决问题.达到某种效果.用户故事设计中核心是通过故事传递信息,引起共鸣,决绝问题. 讲故事不是一个简单工作,需要优秀的组织能力,清晰的表达方式,达到听众清晰明了我们想表达的.这里笔者建议,如果平时和人交流的时间太少,可以通过书写博客等方式,组织自己的中心思想,让听众知道

敏捷实践(3)-用户故事

用户故事如何划分?如何落实到工作中? 用户故事的INVEST原则我是非常赞成的.(搜索了一个相关的说明,http://duweizhong.blogbus.com/logs/112151436.html) 但是要做到INVEST,实际上还是很不容易的.我接触到的常见问题是 1.不知道如何划分,无从下手 2.不知道划分的是否合适,是否满足INVEST原则 3.划分好后,如何跟踪story的进度 实际上这也是我刚接触敏捷时遇到的问题,这些问题,我个人的体会是"按照一些优秀实践的分享,自己亲自参与并实

敏捷21天打卡-敏捷项目管理(终章)

软件项目管理的两大主流管理模式:传统项目管理(预测型项目管理).敏捷项目管理: 传统项目管理(预测型项目管理):瀑布式.部分迭代开发模式,要求在项目一开始,需求足够明确.文档足够规范.迭代过程需求变更越频繁,其对项目造成的遭难往往越大.相信很多IT团队都尝试过,这里不赘述. 敏捷项目管理作为新兴的项目管理模式,简化了传统项目的流程,从繁琐的流程和详尽的文档中解脱出来.但并不代表敏捷不做计划,有很多人的观念“敏捷不做计划”这是错误,否“probacklog.scrum.看板.燃起图.燃尽图.用户故

敏捷21天打卡--Scrum活动

Sprint(冲刺)是Scrum的核心,持续时间为一个月或更短的时间,在这个时间内构建一个完成.可用的和潜在可发布的产品增量.在整个开发过程期间,其长度应保持一致,前一个Sprint完成后,新的下一个Sprint紧接着就开始,有点像接力棒的游戏. Sprint计划会议:会议时间不要过长,不要为了会议而会议.通常一个月内的,上线为8小时或更短:依次类推.其主要目的是确定每个参会者都理解会议的目的.敏捷教练要确保会议梳理举行并教导敏捷团队遵守时间盒规则.包含几点:这次做什么?如何完成所选的工作?期间

敏捷21天打卡-精益产品开发最佳实践 之 “AB测试&quot;

”一个错误的背后往往存在一个正确的假设,对假设的肯定程度越高引发的错误越严重!“ 从上章节中“MVP”中一文中我们了解到,最低限度的可用的产品是MVP的精髓,其目的在于迅速验证产品的可用性及市场用户的反馈:不能市场用户需要一辆汽车,我们给对方一辆自行车,典型的违背市场的原则. 伟人曾说过“实践出真知”,对于软件行业亦是如此,有了最低限度的可用产品,这是就需要收集市场的反馈,根据反馈调整产品策略,A/B测试是众多工具/方法中的一种. “推出一个代步工具.节约用户上下班时间,从而让用户有更多的时间来

敏捷21天打卡-AARRR模型

介绍下AARRR模型,AARRR模型是Acquisition(获取).Activation(活跃).Retention(留存).Revenue(收入).Refer(传播)的缩写,对应了产品生命周期的每个阶段.而无论是那个阶段,都是围绕着中间的用户展开,为用户提供有价值的产品和服务. 获取:对于一款产品,首先要获取用户,即拉新.如果没有新用户,产品就如一潭死水,即为死水,何来繁荣之说. 活跃:产品有了用户之后,就要考虑如何让用户活跃起来.”久别重逢的老友聚会,缅怀过去光辉岁月之时,有人提议创建个群

敏捷21天打卡--Scrum角色

Scrum团队由一名产品负责人.开发团队.Scrum Master组成.Scrum团队是跨职能的自组织团队,团队成员自己选择如何以最好的方式完成工作,而不是由团队之外的人来指导.理论上来讲,团队拥有完成工作所需的全部技能,不需要依赖团队之外的人. Scrum团队迭代增量式交付产品,通过这种方式最大的获得反馈的机会,增量式交付”完成“产品保证一个可以工作产品的. 产品负责人PO:Product Owner角色定义,产品负责人的职责是将开发团队研发的产品价值最大化,为产品回报率负责,负责维护Prpd

划分用户故事(user-story)的原则

在敏捷开发过程中是通过用户故事来将需求具体化成可以进行迭代开发的一个个现实的可见的开发任务.因此在敏捷软件的开发过程中,用户故事的划分对于迭代和开发起着举足轻重的作用. 用户故事从其名字来看是站在用户的角度所描述的故事,同时也是用户所能看懂的故事,开发人员最容易犯下的一个错误就是站在自己的角度去思考和划分故事,这样就背离了用户故事的初衷. 那什么是用户故事?首先来说用户故事是对需求的细化和切分,既然是细化,就得有一个度,需求的颗粒度需要多少才能称之为用户故事?这就牵扯出和用户故事一起出现的另外一

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

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