在远古时代,文字没有出现之前。知识的传承靠口口相传,不管隔了多少代,其准确性很高。文字出现后,我们大脑中的这种技能反而逐步衰退。于是各种软件、各种方法充斥着我们,左右着我们。各位是否也有相同的想法?试想一下,上节课我们讲了什么?每次应允别人的承诺,我们转过头就忘记?比如忘记约会,忘记洗车、忘记写日报?
“要想知道栗子的味道,你得咬一口”这个真理朴实,正确。当用户提出一款软件时,我们不要只想着从技术的角度,认为用户不专业,他的需求是错误的。如果他专业,就没我们啥事了。用户大脑中的需求是离散的,不可控的,这时,就需要我们放下成见,彼此真诚相对,让用户参与进来,通过各种方法,一条条梳理,直至双方的理解是一直的。其作用:1.我们弄懂了用户为何会这样想。2.用户通过亲身参与,头脑中的需求逐渐变成技术可理解的。“求同去异”是一个很难的过程,需要双方彼此做出改变,很难.....,往往难得事情才是最重要的,要不怎么会有“战胜困难”的伟大,痛苦成就了欢乐。
软件的最大价值只有在用户认可,使用才算真的有价值。“再牛逼的算法,再严谨的逻辑”不符合用户实际需求,都是白费力气。“当顾客很饥饿时,他只需要的立马填报肚子的食物,而不是需要几天或者几个月才能做好的满汉全席”。
扯远了,回归正题。因用户对软件领域不专业,脑中对需求没有一个正确的定论。就需要我们专业人士,运用特殊的方法,梳理用户真正的意图。“用户故事”无疑是最好的方法之一,其包含三个要素“角色、活动、商业价值”,用户故事的表达方式:”作为一个<角色>,我想要<活动>,以便于<商业价值>,“例:作为一个很饥饿的顾客,我想要一份食物,来填饱我的肚子。这就是一份明确的用户故事。
那么要实现这种记录方法,有三个原则:卡片:故事一般写在小的记事本上。故事尽可能对当前的需求简单的描述,其作用是为了以后的交谈;交谈:故事背后源于我们和客户/产品负责人的沟通交流;确认:可以确认验证的正确结果、通过验收测试确认的用户故事被正确完成,才算整的完成。
敏捷开发故事细化为开发提供了可执行标准,其特点是快速迭代,故一个用户故事的大小和复杂度应该在一个迭代周期内完成。如果是史诗那样的故事,可能会导致它需要“几代人”(几波人,即有可能只做了一半,团队砍了,新人接手),其弊端不是本次重点。每个人物最好不要超过8小时,如果超过8小时,说明任务的划分是有问题,如何做到时时清日日清?
用户故事的6个特性:
- 独立性
- 可协商性
- 有价值的
- 可以估算的
- 短小的
- 可测试的
正是每个故事的独立性,才保证其短小,可以估算,也可协商(更改某个故事对系统的影响很小),最终交付给用户才是可以测试的,只有软件通过用户的测试,软件的价值才会被最大化。要避免”孤芳自赏“,做技术的,多少有点读书人的清高,说通俗点就是有”臭老九“的毛病,我的产品是最好的,你客户不认可,是你的问题。要学会转变(不是服软),运用有用的方法,来实现可协商,可以估算、等六个特性,做到刚柔并济....
确定用户故事的优先级,有几种方法:
- 相对优先级=价值/工作量
- 莫斯科规则:必须有的、应该有的、可以有的、这次不会有的;按照价值进行分类,优先处理必须要的和应该有的。如果离约定交付的日期还有一定的空余时间,可以考虑可以有的,反之跳过。这次不会有的,不多少,看字面各位应该会理解。
- 卡诺模型:1.基础型需求;2.期望型需求;兴奋型需求。搞过KPI的都会知道,关于目标会有门槛值、期望值、挑战值,往往我会按挑战值的来做,最终有可能实现期望值,别问我怎么知道的.....
- 风险--价值指标:确定优先级的同时,要考虑风险和价值,至于是先处理哪一个?灭火时,消防员会优先处理哪一个?娃娃一个不哭、一个哭闹时,我们会优先关注哪一个?
确定好用户故事的优先级后,我们将这些故事组成产品待办列表(product backlog),根据backlog和团队速率(至于如何估算,以后会讲)来估算故事规模,并确定最终的发布计划。
原文地址:https://www.cnblogs.com/atun/p/12081655.html