需求管理和版本规划基础

简介: 需求管理和版本规划基础

开发者学习笔记【阿里云DevOps助理工程师认证(ACA)课程需求管理和版本规划基础

课程地址:https://edu.aliyun.com/course/3112069/lesson/18993

需求管理和版本规划基础

 

内容介绍:

一、需求收集与分析

二、基于用户故事的需求拆分与澄清

三、需求优先级与排期

 

一、需求收收集与分析

需求的定义:

IEEE 软件工程标准词汇表 97 年中定义需求为用户解决问题或达到目标所需的条件或全能。

系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或全能。

一种反应上面1或 2 所描述的条件或全能的文档说明。

软件需求包括以下几个层次:

第一,业务需求。

第二,用户需求。

第三,功能需求。第四,非功能需求软件需求规格说明等。

需求的管理流程包括这么几个方面,首先是需求收集,之后要做需求分析,再者要进行需求分解与澄清,最后我们要对需求进行优先级排序和排期。

图片151.png

首先我们来学习需求收集,在最初我们获得的是原始的用户需求,我们还需要进行进一步的需求收集来获得真正的用户需求。

一般来说,需求获取方法包括:

第一是访谈,

第二调查问卷,

第三需求讨论会,

第四竞品分析,

第五文档与数据

有时我们需要进行大数据的挖掘,最后是原型。

 图片152.png

当我们获得真正的用户需求后,还要再进一步的进行需求的分析,需求分析究竟是做什么呢?也就是把用户需求转化成我们可以实施的产品需求,针对待开发软件提供完整、清晰、具体的要求,确定软件必须实现哪些任务。我们现在比较常用的一个需求分析的工具是影响地图,它从 3 W 1H 的几个方面来对需求进行分析。首先就是确定目标我为什么要做这个需求,其次就是我们要看它影响到了谁,以及谁会对这个需求有影响。how就是我们是如何影响的,或者是怎么样反过来影响。最后我们基于这个影响的分析决定我们要做什么样的产品需求。

 图片153.png

 

二、基于用户故事的需求拆分与澄清

第二部分我们来学习基于用户故事的需求拆分与澄清。在这之前我们先要学习需求的层级,用户需求转化成产品需求之后,一般是比较大的需求,也就是 Epic story。史诗故事,简称我们称它为史诗,一般被定义为一个非常大的用户故事,是产品中的主干任务。史诗级用户故事还可以拆分成特性,也就是 feature 特性,是能对用户提供价值的完整功能,描述了产品具有的一个完整功能特性,一般也比较大,可能持续数周,横跨几个迭代,特性再进一步分解。 拆分成用户故事,也就是 use a story。每个用户故事都对用户有价值,但是单个用户故事却有可能不能被用户正常使用,或者是整个功能的细分场景。当我们具体要实施产品时,我们还会把用户故事再拆分成工作任务。

图片154.png

什么是用户故事?

用户故事就是描述需求的一种表达方式,从用户的角度来描述用户渴望得到的功能。用户故事一般有三个要素,角色、活动、价值。角色,也就是谁要使用这个功能。活动就是需要完成什么样的功能?商业价值,为什么需要,这个功能带来什么样的价值?用户故事的书写要遵从一定的格式,英文的格式是, as a role, i want to do some activity do that have business value。中文翻译过来就是,作为一个角色,我想要做什么样的活动,以便于实现什么样的商业价值。举例,作为一个网站管理员,我想要统计每天有多少人访问了我的网站,以便于我的赞助商了解我的网站会给他们带来什么收益。

图片155.png

 

用户故事要遵从 3C 原则。什么是 3C 原则?

是 Art conversation, confirmation.,card 也就是卡片,用户故事一般写在小的纪实卡片上,可能会写上故事的简短描述工作量估算等。 conversation 就是交谈用户故事背后的细节,来源于和客户或者产品负责人的交流沟通。 confirmation 确认用户故事要通过验收测试确认才能被正确完成。一般用来写用户故事的卡片,正面会写上用户故事,比如作为什么用户角色,我想要完成什么样的活动,以便实现什么样的商业价值,而背面就会写上我们的验收标准。

图片156.png

下面我们来学习用户故事的验收标准。 acceptance Criteria,简称 AC。验收标准代表了用户故事 3C 中的 confirmation 准则,同时也是我们一会要讲 invest 属性中的 testable 的具体体现。 在用户故事 card 中, AC 一般用 given when then公式来书写。 given 就是指用户触发操作之前处于的系统状态, when 触发系统结果的操作, then 系统预期返回的结果。比如我们的用户故事是,作为一个网站管理员,我想要统计每天有多少人访问我的网站,以便于我的赞助商了解我的网站会给他们带来什么收益。我们的验收标准就可以这样写, given 网站运行一天后,when,当我点击首页访问人数按钮时, then 我可以看到这一天一共有多少人访问了网站。


当我们拿到产品需求的时候,一般是比较大的 epic 或者特性,我们还要遵从 invest 原则,进一步地对产品需求进行拆分成可以实施的用户故事。


什么是 invest 原则?

independent 独立性,要尽可能的让一个用户故事独立于其他的用户故事。

negotiable 可协商性,一个用户故事的内容要是可以协商的,用户故事不是合同。

valuable 有价值,每个故事必须对客户具有价值,无论是用户还是购买方。

estimable 可以估算的开发团队需要去估计一个用户故事,以便确定优先级工作量安排迭代。  

small 短小,一个好的用户故事在工作量上要短小,要确保是在一个迭代中能够完成。

testable 可测的,用户故事必须是可测试的,只有成功通过测试,才能说明该用户故事已经被完成开发。

图片157.png图片158.png

最后我们还要进行需求澄清与评审。需求澄清包括两个阶段,第一个阶段是产品负责人,也就是我们的产品经理最初和用户来澄清用户的需求,当产品经理通过需求分析把用户需求转化成产品需求后,还要和我们的开发团队,即我们的 Scrum 团队进行进一步的澄清。我们可以开几个需求讨论会来进行需求澄清。 最后我们的需求评审要有一个产品定稿会,这是一种仪式或承诺,向各团体要确认这个需求。产品负责人,他的责任是做产品设计初稿,召集评审产品定稿规。而技术负责人也就是我们的开发测试,他们的责任是要参加review,参加评审,提出意见,确保逻辑完备性。

 

三、需求优先级与排期

需求定稿后,我们就可以进行需求优先级与排期。优先级一般是在我们做了需求分析,需求分解之后,对它进行优先级的排序。排优先级的方法有很多,我们主要介绍有四种。第一种是莫斯科法则,它包括 must /should /could/ would not, must 就是指必须做的要求或特性,是系统的基础,没有他们系统就不工作或没有价值。 should 是应该做的,应该有的价值或者功能,这样系统才能工作。 could 可以做的,提供了产品的附加价值,可以让这个产品更具有亮点。 would not 暂时不考虑做的,在产品中没有的功能。 我们也可以通过常用的矩阵分析法,比如把重要且紧急的排在第一位,其次是重要不紧急,紧接是紧急不重要,最后才做不重要也不紧急的。还可以从满足核心用户优先的二八原则来进行排序,或者满足核心业务的投入产出比最大的需求优先这个角度来进行需求排序。具体使用哪一种方法,还需要根据产品经理在当时的情况下来做出决定。

图片159.png

 

我们对需求进行优先级后,可以用户故事地图对需求进行进一步的梳理,最后能够对需求进行排期,规划我们的发布和迭代。 这个用户故事包括横轴是它的业务流程,比如我们购买,包括我们的管理账户浏览、购买、支付、配送、退货这样一个业务流程,而纵轴是我们根据商业价值来定的优先级,从高到低,比如管理账户最开始的时候我们肯定要进行注册和登录的功能,其次我们才进一步的提供其他的功能,比如修改密码,手机验证等。 通过这样的梳理,我们就可以对需求进行发布规划和迭代规划。

图片160.png 

发布和迭代之间的关系是什么呢?一个项目我们可以有多个发布,而一个发布我们可以有多个迭代去实现。一般发布规划应该是 3- 9 个月一个发布或者更长,而迭代一般是 1- 4 个周。在发布规划里我们规划的是用户故事,而在迭代规划里,我们需要把用户故事再进一步的拆分成任务进行实施,但是现在在很多互联网的企业里,他们也是一个迭代,就是一个发布。

我们主要讲解的内容,需求的收集与分析,基于用户故事的需求拆分与澄清,以及需求优先级与排期。

图片161.png

发布规划

迭代规划

时间的区间

3~9个月(或者更长)

1~4个周

计划中的项目

用户故事

任务

相关实践学习
基于函数计算一键部署掌上游戏机
本场景介绍如何使用阿里云计算服务命令快速搭建一个掌上游戏机。
相关文章
|
10天前
|
监控 数据挖掘 BI
探索项目管理系统:解析五大功能,洞悉项目成功的关键
项目新手常忽视管理系统的价值,而高手已借助系统实现规划清晰。优秀的项目管理系统必备五大功能:项目WBS分解、图表报表、工时管理、团队协作和任务自动化。WBS能将复杂项目拆分成可管理任务,明确责任,评估时间和资源需求,便于跟踪进度。Zoho Projects作为示例,支持创建任务层级,利用甘特图和资源利用图监控进度和资源分配,工时管理则帮助控制项目时间和成本。同时,系统促进团队协作,如通过即时通讯和知识库增强团队凝聚力,而任务自动化则减少错误,提升效率。
24 1
|
10天前
|
运维 监控 Cloud Native
如何设计与构建 FinOps 流程、团队、体系与目标
企业 FinOps 实施不是一蹴而就的项目,如果您正在推进企业云原生 FinOps 落地,除了选择合适的技术手段,企业内部的流程和体系建设也尤为重要。
162861 12
|
10天前
|
敏捷开发 测试技术 项目管理
【高项】项目的概念,项目管理基础与立项管理
项目是临时性、独特性、逐步完善、资源约束和目的性的任务,尤其在企业战略中扮演关键角色。项目管理是系统化的过程,涉及沟通、领导、激励等软技能,常用方法有PRINCE2。项目生命周期包括启动、准备、执行和结束,不同阶段相互重叠,影响因素包括组织结构、生命周期模型(如瀑布、螺旋、V模型等)。立项管理涉及申请书、可行性研究、评估和招标,可行性研究评估技术、经济、社会和法律可行性。项目论证和评估是决策基础,包括机会研究、初步和详细可行性研究。
12 2
|
10天前
|
数据采集 存储 运维
提升团队工程交付能力,从“看见”工程活动和研发模式开始
本文从统一工程交付的概念模型开始,介绍了如何将应用交付的模式显式地定义出来,并通过工具平台落地。
121801 414
|
6月前
|
监控 供应链 测试技术
什么是 2B 软件的实施和上线概念
什么是 2B 软件的实施和上线概念
64 0
|
11月前
|
程序员 开发者
CMMI-技术评审管理方案
CMMI-技术评审管理方案
159 0
|
消息中间件 负载均衡 测试技术
测试环境建设原则和管理实践
测试环境是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据等的总称,即够支持完成测试工作所需要的软件和硬件。测试环境是测试活动的基础,正确模拟生产环境,稳定支持测试活动是测试环境的基本要求。稳定可控的测试环境能够提升测试工程师的测试工作效率,测试工程师无需花费过多的时间维护测试环境的稳定、测试数据的合理等工作上。测试工程师只需正确执行测试用例(这里既包含了自动化测试用例也包含手工测试用例)就可以稳定复现测试过程。
485 0
测试环境建设原则和管理实践
技术三板斧:关于技术规划、管理、架构的思考
实践需要理论的指导,理论从实践中来。作为技术工程师,要不断地从事件中反思经验、总结规律,才能避免踏入同一个坑,才能更高效地完成 KPI ,甚至是晋升。今天的文章来自阿里巴巴高级技术专家毕啸,从五个方面总结工程技术的核心要点,相信对你能有所启发。
19302 0