最新消息:20190717 VPS服务器:Vultr新加坡,WordPress主题:大前端D8,统一介绍入口:关于

【整理】《用户故事与敏捷方法》读书心得

工作和技术 crifan 2919浏览 0评论

PPT构思:

开发软件

最大一个问题

软件需求 理解错误

-》

之前的办法:

需求用:

大部头的需求文档

IEEE 830 软件需求规格Software Requirements Specifications

-》

看不懂 没人看

开发过程用:

瀑布流程Waterfall Model

从需求文档,概要设计,详细设计,编码,测试,部署,上线

缺点太多,效率太低:

敏捷流程破解瀑布式流程 – ZhuQue – 博客园

  • 版本发布的时间越来越长

  • 无法按时发布

  • 在版本发布的最后阶段让软件稳定的时间越来越长

  • 做计划的时间越来越长,而且不准确

  • 在发布期间很难进行改变

  • 质量持续恶化

  • 拼命竞赛进度使员工士气受挫

所以用 用户故事+敏捷编程

什么是用户故事==用户故事的3C原则

好处

如何写用户故事

典型流程:

  1. 编写故事

  2. 用户角色建模

  3. 搜集故事

  4. 与客户代理合作

  5. 用户故事验收测试

怎么才算好的用户故事:

优秀用户故事准则

然后开始 敏捷开发Scrum:

迭代计划:

讨论故事,分解任务,认领任务

产品Backlog 排好优先级的列表
Sprint Backlog
Daily Scrum 简会
一个Scrum团队通常由4~7个开发人员组成
整个团队,同舟共济,互相帮忙
Scrum团队往往是自组织的
产品负责人:主要负责管理Product Backlog以及排列优先级
Scrum Master:类似于项目经理,但是不是管理者,而像领导者。不是指手画脚,而是为Scrum团队服务,排除障碍。
Sprint计划会议
参加者:产品负责人,ScrumMaster,团队的所有开发人员(其他管理人员,客户代表)
产品负责人:介绍Backlog中的功能
其他人:对功能提出(不懂的需要问的)问题
每日例会:昨天做了啥?今天打算做啥?遇到什么困难?
Sprint结束时:Sprint评审会,团队演示完成的成果
Scrum不要求,甚至也不建议今早维护很大的产品的Backlog
TODO:
1.建议每周五下午留出1~2小时,作为评审会:
主要由测试人员去演示产品的功能进展
以便于项目经理,前端人员,后台人员等清楚最新进展

用户故事和其他对比:

用户故事不是什么

用户故事的优势

【第一章 概览】

给用户故事排优先级-》先做优先级最高的

在敏捷开发之前:

都是写详细的需求规格说明书、概要设计、详细设计

其中:

需求规格说明书-》内容很多,大量的文字描述-》往往写了没人看

现在,变成:

用户故事:从用户的角度,描述功能

按功能特性,而不是架构层次 -》 降低后期开发的整体风险

(极限编程创始人Ron Jeffies提出的)用户故事的3C原则:

  • Card=卡片:用卡片的形式记录功能点,放在白板上,方便移动,隐藏细节,以图形方式,易于理解和记忆

  • Conversation=沟通=交流:鼓励团队和客户之间多讨论和沟通-》促进人际关系,深入理解需求

  • Confirmation=确认:和用户确认使用场景中关键细节

软件需求是个沟通的问题

-》需要一个协同工作的方法

-》

客户或用户 《-》 (产品经理的)用户故事 《-》 技术团队

前期:获取信息,越早越好,越频繁越好

-》用户故事

【什么是用户故事】

用户故事描述了一些对于用户、系统或软件购买者有价值的功能

  • 描述:书面的故事的描述 -》 Card

  • 对话:具体化故事细节 -》Conversation

  • 测试:何时完成,做成什么样 -》 Confirmation

用户故事不能太大(太大的故事=故事史诗=Epic)

-》需要拆分成小的用户故事

-》一般的话:1-2程序员,0.5天~2周 写完+测试完

沟通和讨论是关键

用户故事的卡片背面:可以考虑用来记录描述信息、测试描述信息-》用于细化预期的输入和输出

项目用户故事初稿:故事编写工作坊workshop

迭代长度,velocity速率:1~4周

由客户团队和开发人员一起确定

【规划发布和迭代】

一个发布由一个或多个迭代组成

故事点 Story Point:相对于其他故事的大小和复杂度

根据团队的速率和故事点去分配每个迭代的故事点

【什么是验收测试】

验证实现了的用户故事是否符合预期

客户团队,最好有专业的测试人员

尽早的写测试用例,更早的让开发人员知道你的预期和需求的细节

【为什么要变】

用户故事:

  • 强调对话交流而不是书面沟通

  • 同时被开发人员和用户理解

  • 大小适合做计划

  • 适用于迭代开发

  • 鼓励推迟考虑细节,直到你非常清楚地了解自己的真正需求

【总结】

故事卡:包含了用户或客户有价值的功能的简短描述

故事卡是故事的可见部分,但是沟通对话更重要-》了解细节

客户团队包含了:确保软件符合潜在用户需求的人员:测试人员、产品经理、实际用户、交互设计师

故事卡由客户团队编写:他们了解需求和优先级顺序

按照价值去安排故事的优先级

速率是开发人员在一轮迭代中完成的工作量

可以把太大的故事拆分成更小的多个小故事

鼓励推迟细节:真正需要去确定要做了,再去了解细节

【第二章 编写故事】

【故事的特点】

INVEST

  • 独立的 Independent

  • 可讨论的 Negotiable

  • (对用户或客户)有价值的 Valuable(to Purchasers or Users)

    • 故事卡只是提醒之后需要讨论,不是一个正式的承诺或者某个功能的具体描述

  • 可估计的 Estimatable

  • 小的 Small

  • 可测试的 Testable

【小的】

  • 分割故事

    • 史诗故事包含两种

      • 复合故事Compound story

      • 复杂故事Complex story

分解故事的一种方法:

创建,修改,删除

对于不熟悉的领域=缺乏领域知识,可以用:

  • 探针实验:调研熟悉某个xxx领域的相关技术

  • 真正的某个用户故事

【可测试的】

尽量把那些不可测试的,非功能性的需求,去用自动化测试去帮忙发现是否有问题

【总结】

  • 故事尽量独立

  • 故事细节是由用户和开发人员讨论得出

  • 最好的话,让用户去编写用户故事

  • 可以加一些必要的注释去说明细节,但不能太多

  • 最好的故事的注释是,编写测试用例

  • 如果太大,就拆分为多个小故事

  • 如果太小就合并为一个较大的故事

  • 应该是可以测试的

【第三章 用户角色建模】

为何要建模?

以便于更好的编写更好的故事

有些故事并不是针对于系统的一般用户

【用户角色】

建模步骤:

  • 头脑风暴列出初始的用户角色集合

    • 尽量列出更多

  • 整理最初的角色集合

    • 角色重叠的,重叠的放在一起

  • 整合角色

  • 提炼角色

-》为了更加便于讨论需求,可以考虑引入一个 虚拟人物

极端人物

-》可能会带来额外灵感和考虑到之前漏掉的需求

【总结】

  • 大部分项目小组只考虑单一的用户类型-》导致忽略掉原本需要的一些用户类型

  • 给每种用户定义相关的特征,可以清楚地看到不同角色间的不同点

  • 对于有些用户角色,考虑用代表人物去描述,容易理解和记住。

  • 有些情况下,用极端人物,可能会帮助搜集原本被遗忘的故事

【第四章 搜集故事】

trawling 拖网 描述收集需求的过程

  1. 不同大小的网用来捕获不同大小的需求

  2. 拖网表达的另一个含义:需求会像鱼一样,会成长,可能也会死亡

  3. 不可能捕获到所有的需求

  4. 技能也是发现需求的一个重要因素

创建用户故事的方法:

  • 用户访谈

  • 问卷调查

  • 观察

  • 故事编写工作坊

    • 开发人员,用户,产品客户,共同参与,写出尽量多的故事

业务分析师

大部分用户不太善于理解,更难于表达他们的真实需求

在了解用户的需求的基础上,要善于引导用户,找到更有效的问题的解决办法。

【总结】

  • 用拖网捕鱼去比喻捕捉需求是很有用的:它说明了需要去有大小的不同,会随着时间变化,需要一些技巧来发现需求

尽量用开放式和背景无关的提问去了解客户的真实需求。

【第五章 与客户代理合作】

用户代理User proxy:

  • 用户的经理

  • 开发经理

  • 销售人员

  • 领域专家

  • 市场营销团队

  • 以前的用户

  • 客户

  • 培训师和技术支持

  • 业务分析师或系统分析师

可能的话,尽量和实际客户接触,而非用户代理

【第六章 用户故事验收测试】

在写代码之前写测试

测试是开发过程中的一部分,而不是在编码完成后要做的事情。

在迭代开始时,项目经理和测试人员共同列出详细的测试。

一个优秀的开发团队会为很多详细的用例写单元测试。

在每轮迭代结束时都应该执行验收测试。

尽量用自动化测试。

测试类型:

  • 功能性测试

  • 用户交互测试

  • 可用性测试

  • 性能测试

  • 压力测试

【总结】

  • 验收测试应在程序员写代码之前就写好

  • 如果新的测试对阐明故事的细节或意图没有任何帮助,就不用再写

【第七章 优秀用户故事准则】

从目标故事开始

从每个角色开始

编写故事的一种方式:每个故事都提供某种程度的完整(end-to-end)

就像 切蛋糕 一样

编写封闭故事:随着一个有意义的目标的实现而结束的故事,能让用户使用后就觉得完成了某个任务

卡片约束

根据实现规模来确定故事规模

不要过早涉及用户界面:

常见问题之一:把需求和解决方案混在一起,即在陈述需求时,也显式说明或暗示了解决方案。

有些需求并不是故事:放心的用其他合适的方式

在故事里包含用户角色

只为一个用户编写

以主动语态编写

由客户编写

尽量不要给卡片编号

不要忘记意图:故事卡片的目的是,用来提醒开发人员和客户团队对功能进行讨论的。

【第八章 估算用户故事】

故事点story point:可能是一个工作日,可能是一周

时间的模糊单位

客户+开发人员 故事卡 额外的空的笔记卡

估算应该包括:开发的时间+测试代码+和客户讨论+帮助客户计划或自动化验收测试+。。。

估算

三角测量:对比评估和确认 故事点不同的工作的工作量的确是和数字总体上是一致的

【第九章 发布计划】

DSDM,另外一种敏捷过程,包括一个排列优先级的方法莫斯科MoSCoW方法:

  • Must have 必须有

  • Should have 应该有

  • Could have 可以有

  • Won’t have this time 这次不会有

重要性加上:

  • 预估的时间

  • 风险

  • 架构需要

大小后,才能判断出优先级

迭代长度:尽量一致,特殊情况下,可以有个别时候不长度有变

假如 去除了各种干扰后的 一个理想工作日=理想日

实际上的日历上的工作日=日历日 往往只有1/3或1/2的理想工作日

【第十章 迭代计划】

讨论故事,分解任务,认领任务

【第十一章 测量并监控速率】

计算速率,在迭代结束时计算,不把未完成的故事的故事点计算在内

计划速率和实际速率

累计故事点

Burndown Chart迭代燃尽图

敏捷团队都承认客户不可能预先知道所有事情。

【总结】

不要在一两轮迭代后就忙着预测速率趋势

【第十二章 故事不是什么】

其他需求方法:

  • 用例user case

  • IEEE 830软件需求规格 software requirements specifications

    • 侧重于关注需求列表而非用户的目标

  • 交互设计场景interaction design scenario

【用例】

用例是对系统之间以及一个或多个用户之间交互的一般性描述,使用者是用户或其他系统。

用例 vs 故事:

  • 用例的范围一般都比故事大

    • 故事对应于用例的主要成功场景

    • 故事测试对应于用例扩展

  • 用例在产品开发或维护期间,常常作为永久性的工件持续存在

    • 故事不会超过包含他们的迭代

  • 用例比故事更容易包含用户界面的细节

  • 用例编写者更早的关注软件的实现的细节,而不是去关注商业目标

基本用例:剥离了技术和实现细节的隐藏假设

用户意图=用户故事

目的:

用例:记录客户和开发团队之间的协议

用户故事:更方便的发布计划和迭代计划

结果:

用例一般写成分析活动的结果

用户故事则写成注释,用于启动分析谈话。

【场景】

scenario:用户与计算机交互的详细描述

场景包含的特征性元素:

  • 应用环境

  • 使用者

  • 目标或目的

  • 行动和事件

where

who

what

how

场景中比用户故事包含更多的细节

场景常包含多个故事

【第十三章 用户故事的优势】

  • 用户故事强调口头沟通

  • 人人都可以理解用户故事

  • 用户故事的大小适合做计划

  • 用户故事适合迭代开发

  • 用户故事鼓励延迟细节

  • 用户故事支持随机应变的开发

  • 用户故事鼓励参与性设计

  • 用户故事传播隐性知识

【口头沟通】

要更关注共有的认识,而非一份共享的文档

-》

开发人员知道如何开发

测试人员知道如何测试

客户得到想要的系统

用户故事鼓励延迟细节-》用户故事是个占位符-》在需要开发时再去讨论细节

以为:

写下一个系统的所有的需求,从上到下想出对应的解决方案

-》是不可能的

因为:

  • 用户及客户都不会准确知道自己的实际需求

  • 即便软件开发者知道需求的细节,也只能随着开发进展而变得清楚

  • 即便假设所有细节可以在前面弄清楚,人们也没能力理解这么多的细节

  • 就算我们能理解所有细节,产品和项目也经常会变更

  • -》人非圣贤,孰能无过

【用户故事的不足】

大项目的用户故事太多,关系太复杂,不太好把握

可追溯:

需要额外写一些必要的文档

不足:

  • 大型项目中难以组织好成千上万的故事

  • 有时候需要额外的文档以实现可追溯性

  • 尽管面对面的沟通大大促进隐性知识的共享,但是大型项目中,单单依赖这种交谈难于实现有效的扩展来完全替代书面文档

【第十四章 用户故事不良征兆一览】

  • 故事太小

    • 经常需要调整估算

  • 故事互相依赖

  • 镀金

  • 细节太多

  • 过早考虑用户界面细节

  • 想的太远

  • 故事划分太过频繁

  • 客户很难为故事安排优先级

  • 客户不愿意写用户故事,也不愿意为故事安排优先级

【第十五章 Scrum与用户故事】

用户故事,一种管理需求的方法

Scrum敏捷过程

类似于 极限编程

迭代递增的软件过程

迭代:一种持续改进的过程

     类比:雕刻。选择合适的石头,雕刻出大体轮廓,再区分出头和躯干,在雕刻细节,直至完美作品。

递增:一个递增的软件过程,指团队按照功能点开发和发布软件。

Scrum中,一个迭代Sprint,往往是30天,一个月

产品Backlog 排好优先级的列表

Sprint Backlog

Daily Scrum 简会

一个Scrum团队通常由4~7个开发人员组成

整个团队,同舟共济,互相帮忙

Scrum团队往往是自组织的

产品负责人:主要负责管理Product Backlog以及排列优先级

Scrum Master:类似于项目经理,但是不是管理者,而像领导者。不是指手画脚,而是为Scrum团队服务,排除障碍。

Sprint计划会议

参加者:产品负责人,ScrumMaster,团队的所有开发人员(其他管理人员,客户代表)

产品负责人:介绍Backlog中的功能

其他人:对功能提出(不懂的需要问的)问题

每日例会:昨天做了啥?今天打算做啥?遇到什么困难?

Sprint结束时:Sprint评审会,团队演示完成的成果

Scrum不要求,甚至也不建议今早维护很大的产品的Backlog

TODO:

1.建议每周五下午留出1~2小时,作为评审会:

主要由测试人员去演示产品的功能进展

以便于项目经理,前端人员,后台人员等清楚最新进展

【第十六章 其他话题】

处理非功能性需求:

很多非功能性需求可以视为系统行为的约束;

纸质卡片还是软件村故事卡片?

建议:纸质卡片

优点:

  • 技术含量低,提醒人们故事就是不准确的。

    • 放到软件中的话:容易增加额外的复杂的不必要的细节

  • 有限的大小,给了故事描述很自然的字数的上限

  • 常见做法,可以在卡片背面写部分验收测试的样例

注:

远程工作人员,不太可能用纸质卡片,所以会使用软件去管理用户故事

软件开发完后是否保留用户故事:

建议保留

  • 软件:自然可以归档存储

  • 纸质卡片:用橡皮筋绑在一起

缺陷:

如果所花时间类似于故事,可以考虑当作一个故事去对待

转载请注明:在路上 » 【整理】《用户故事与敏捷方法》读书心得

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
46 queries in 0.181 seconds, using 18.75MB memory