【DevCloud · 敏捷智库】软件项目需求变更频繁,如何做好有效的需求管理和规划?

如果一个项目需求经常变更,如何进行管理? 简单的软件工程文档,如果一个项目需求经常变更,如何进行管理? 立即下载

概述
围绕项目需求变更频繁,如何做好有效的需求管理和规划,本文从背景、问题分析、解决措施、如何进行需求结构化管理?如何进行需求优先级管理?如何避免重要需求遗漏?几个方面进行了细致解答。全文字数:2662 字,预估阅读时间:_7 分钟。全程干货。

背景
不管是项目型软件开发还是产品型软件开发,需求变更频繁都是影响研发效能的第一号因素,在2019年中国DevOps现状调查报告中也可以发现,超半数企业认为需求的频繁变更是阻碍软件按时交付的主要原因。解决或缓解需求变更频繁带来的影响,是势在必行的重要工作。

1.png

联想阅读
2019年中国DevOps行业现状报告:中国信息通信研究院、华为云DevCloud、南京大学联合发布 attachment

问题分析
由于每家企业的情况不同,包括客户合作方式、人员能力水平、研发流程等各方面的差异,同样是需求变更频繁,所体现出来的具体症状却有所不同,导致问题发生的根因也可能不同,所应采取的措施也需要根据实际情况来选择。根据我们的观察以及与企业交流的经验发现,一般都体现为如下几种情况,接下来我们结合这些情况的部分实例来分析:

第一种情况:需求杂乱、经常变更,难以管理;

第二种情况:领导或客户时不时地要把某些需求提前,打乱了开发计划;

第三种情况:做着做着发现有些需求遗漏了;

【第一种情况】软件项目前期结构清楚,开发到后期,需求变化多而细,如何管理,如何规划。困扰我们的是前期需求不明确、不完善,导致后期需改动,需求需要发生变更。而使用DevCloud的项目管理的支持不够。
我们发现出现这种情况,往往跟客户未能正确使用需求规划有一定关系,存在着需求层次划分不清晰、缺少规范机制等问题。例如,某客户规划一个用户登录功能,按照下图所示规划需求。用户会将其中管理员登录的Task放在第一个版本中发布,后期又增加了一个手机号登录的需求,设置成Task放在第二个版本中发布,这样一个Story里面存在多个不同版本(或迭代)发布的Task,不方便管理。由此我们可以将这个问题的根因定性为如何进行需求结构化管理的问题:

没有区分跟随项目进展而持续产生的碎片化需求和系统/产品持续完善的功能特性;

对DevCloud提供的Epic-Feature-Story的需求结构理解有误,未能正确使用;

2.png

【第二种情况】软件项目进行过程中,领导需要提拉需求,在敏捷研发模式中该如何去操作?
提拉需求的意思也就是要将某些需求的优先级提高,要求团队先实现它们,因而我们将此问题定性为需求优先级管理的问题。解决此问题,我们需要了解:

为什么领导会要提拉需求?如果是合理的,那么我们就应该提升响应能力、优化工作安排流程,使得优先级调整对研发进展带来的影响最小化,且我们能够尽快地响应领导需要,先交付被提拉的需求;

这种情况发生频率有多高?如果是经常发生,那就是一种常态,而且是一种不好的常态,那我们需要去思考是什么导致了这种常态发生,并考虑如何从流程、制度、协作模式或人员能力等方面去做调整,减少过程中提拉需求情况的发生;如果是偶尔发生,那就可以特事特办,为例外情况调整流程、制度反而会加重常态工作的负担,没有必要;

需要提拉的需求有无共性特点?比如是否都跟某个客户有关,或者跟某个功能域(如退款)有关?如果能够找到共性,那我们就可以针对这些共性去思考针对性的解决方案。

【第三种情况】由于外界原因经常会临时增加一些紧急需求,并且这是目前常态
临时增加需求,首先是一个如何处理突发需求的问题;紧急需求,也就是说需要马上就做,而且是插队,那就不仅仅是紧急,肯定也是重要的需求,不然不需要插队先做,所以这还涉及到需求优先级管理的问题。但是当两种情况合在一起,我们需要将它定性为是重要需求遗漏的问题,反问一句就是 —— 为什么这些紧急重要的需求无法更早预见?同样的,我们需要了解:

具体是哪些外界原因?这些原因是否有共性,有的话,那就针对性处理;

增加的需求有无共性特点?有的话,可以针对性处理;

临时增加有多临时?我们是否有提高或改善响应能力的空间,如果我们可以更快调整和响应,使得这些临时需求对我们产生不了什么影响,那么这个问题也就不再是问题了;

既然是常态,为何我们的流程没有做出调整去应对?是调整过流程或工作方式,还是无法解决问题,还是说不知道该怎么调整流程或工作方式去适应?

解决措施
综上,前面几种参考情况经分析后得出了根因,基于这些根因,我们将所要解决的问题重新描述如下:

如何进行需求结构化管理?

如何进行需求优先级管理?

如何避免重要需求遗漏?

如何进行需求结构化管理?
首先,并不是说任何情况下都需要进行需求的结构化管理。只有在需求较多、且需求之间存在关联,而且即便是已经实现的需求也需要进行一定的管理、维护的情况下,我们才需要去思考需求结构化管理的问题,此时,我们需要使用DevCloud提供的Scrum项目模板,因为里面有Epic-Feature-Story的需求结构,以及需求规划功能可以辅助我们进行需求的结构化管理。那么我们应该以什么为脉络来建立这个结构呢?这就意味着,我们的需求结构化管理,需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息,则可以通过需求的不同属性甚至标签等方式来实现。

简单来说,可以通过如下三个步骤来完成:

针对产品或系统建立DevCloud项目

确立Epic-Feature-Story的需求结构

对不同模块以及版本的管理,可以通过工作项的属性来进行管理

联想阅读
【华为云 · 敏捷智库】如何进行需求结构化管理?

如何进行需求优先级管理?
需求优先级的管理,其实是为了帮助我们确定先做哪个需求后做哪个需求,从而可以最大化我们的回报、最小化我们的风险或投入。要做好优先级管理,或者更直接来说是优先级顺序管理,我们需要做到如下几件事情:

确定优先级模型:需要考虑的因素以及因素的综合判断原则,比如Kano模型;

排定需求优先级顺序:因素的具体量化和排序标准,例如成本收益法是按照收入还是按利润的多少来排序;

调整需求优先级顺序;

改进优先级模型:根据反馈调整模型或模型的落地实施细节,以提升效果;

联想阅读
【华为云 · 敏捷智库】如何进行需求优先级管理?

如何避免重要需求遗漏?
根据重要需求遗漏的事前、事中、事后的不同时间点,我们可以采取不同的措施。参照八二原则,我们需要确保常态问题有对应的处理方式,软件项目成员按照既定方案进行处理即可,而特殊情况要有应急机制指导现场处理、事后再复盘总结。

事中的处理:按照常规做法进行处理,或是特殊情况特殊处理,先解决眼下的问题;

事后的处理:基于模型或思路进行复盘,并落实为新的常规做法或特殊情况处理方式;

事前的处理:明确如何区分常规情况或特殊情况,并制定相应的处理方式或应急机制;

参考附录
相关文章
敏捷联盟网站上的Epic术语解释:https://www.agilealliance.org/glossary/epic

维基百科上的Kano模型词条:https://en.wikipedia.org/wiki/Kano_model

相关书籍
Mike Cohn:《用户故事实战》

杰拉尔德·温伯格:《成为技术领导者》

邱昭良:《复盘+:把经验转化为能力》

信号编辑软件ZX/SignalEditing 阅读详情

相关推荐

网安保研避坑指南:中科院信工所各研究室真实体验与导师选择建议

本文为中科院信工所网络安全保研生提供深度指南,详细解析了信工所六个研究室的研究方向、真实氛围与导师选择策略。文章特别强调,选择导师是决定研究生体验的关键,并提供了针对各研究室的避坑建议与实战调研方法,帮助学生做出明智选择。

weixin_29210727的博客 1578

软件项目需求变更频繁,如何做好有效的需求管理和规划

概述 围绕项目需求变更频繁,如何做好有效的需求管理和规划,本文从背景、问题分析、解决措施、如何进行需求结构化管理?如何进行需求优先级管理?如何避免重要需求遗漏?几个方面进行了细致解答。全程干货。背景 不管是项目型软件开发还是产品型软件开发,需求变更频繁都是影响研发效能的第一号因素,在2019年中国DevOps现状调查报告中也可以发现,超半数企业认为需求的频繁变更是阻碍软件按时交付的主要原因。解...

devopscsdn的博客 2468

Origin2018(汉化版)在使用科学计数法的时候如何将坐标刻度的0.0改成0

文章目录1 问题2 解决方法 1 问题 先看下面这张图,当我使用科学计数法时,纵坐标出现了0.0的字样,这样看起来很不美观。有些期刊还会有要求,不能出现0.0的格式。 图1 那么该怎么将它改成0呢?首先让我们尝试着用Origin自带的属性,看看能不能设置。 2 解决方法 解决方法一: step1: 双击坐标轴,打开坐标轴属性设置。 step2: 在刻度线标签选项中设置左轴的显示 图2 会发现,按照图2的方式改好之后,其它的小数位也全没了,如果但是有些数字就被覆盖了,这显然不是我

qq_40077565的博客 2万+

开发人员如何应对频繁更改的需求

做为一个开发人员除了Bug让人头疼外,而一个不靠谱的策划更让人头大。为什么?因为他写的需求文档变来变去,将朝令夕更发挥到了极至。 那么做为开发人员要如何应对这种局面呢?甩袖子不干?这当然可以。但只要你继续做开发就无法保证下 一个需求文档是一层不变的。而要碰到一个不改需求的策划是很难很难的。因为策划面对的是一个个不停变化需求的客户。 那么碰到总是变化的需求要怎么办呢? 首先要仔细的阅读需求文档。真正的了解接下来要实现的具体功能。有不清楚之处一定要向策划人员了解清楚。接下来就着手开发吗? 不!接下来你要好

hdn5855的博客 1640

GEE土地分类:一文读懂精度评定—混淆矩阵confusion matrix、整体精度OA、用户者精度、生产者精度、kappa系数和F1score系数含案例

本文介绍了如何在 Google Earth Engine (GEE) 中构建和分析混淆矩阵,以评估分类模型的性能。首先,通过 ee.Array 构建混淆矩阵,并展示了如何指定自定义类标签。接着,计算了多种性能指标,包括准确率、Kappa 值、F1-score、消费者准确率和生产者准确率。此外,还演示了如何计算不同类别的 F1-score。最后,通过一个实际案例,展示了如何利用 GEE 进行土地分类,并评估分类器的性能,包括训练和验证样本的准确率、Kappa 值等指标。这些步骤帮助用户理解模型的优缺点,并进行

此星光明博客 442

Dify 第 7 篇 Dify 应用介绍 + 聊天助手&Agent 应用关键点说明

本文介绍了Dify应用的核心概念与使用方法。Dify是基于大模型构建的实际场景应用,提供API、WebApp和易用界面。包含5种应用类型:聊天助手、文本生成、Agent、对话流和工作流。创建方式有模板创建、空白应用和DSL文件三种。重点讲解了聊天助手和Agent应用的关键功能:聊天助手支持提示词优化、知识库引用、文件处理等;Agent应用则强调推理能力、工具调用和任务自动化。文章还详细介绍了应用的调试、发布和管理工具,为开发者提供了全面的应用构建指南。

甘蓝的专栏 1882

如何应对频繁的需求变更?

需求变更带来危机和机遇 需求的变更发生在任意的一个项目过程,它针对的是一个过程的影响,进而给整个项目带来重大甚至致命性的影响,轻则延期发布,重则分崩离析。 作为项目经理,要理解一个概念:项目的铁三角(范围S、进度T、成本C),当然也可以说是项目的四要素:范围、进度、成本和质量。 S、T、C三者之间存在强烈的制衡关系,当你需要扩大/变更范围(也就是需求边界)的时候,一定会给进度和资源的投入带来影响,变更的范围越大变更的频率越高,则对进度和资源的影响越大,也就是你不要奢望“又想马儿跑,又不给马儿吃草”。由

cherry的专栏 1689

PX4从放弃到精通(十九):串口驱动

文章目录前言一、创建进程二、编写驱动 前言 硬件: PIXHAWK4 USB转串口模块 软件: Ubuntu18.04 PX4 1.11.3固件 QGC地面站 串口助手 一、创建进程 参考:https://mbot1.blog.youkuaiyun.com/article/details/122587617 二、编写驱动 .........

超维空间科技的博客 4597

需求频繁变更,测试怎么办?

参考极客时间董建琴老师讲解的《怎么有效解决3个测试痛点》 文章目录前言一、需求变更后的测试痛点1. 不能精准确认开发改动的影响面2. 需求变更影响测试环节3.确定测试优先级二、如何解决?1.如何精准确认开发改动的影响面?2.如何降低需求变更对测试环节的影响?3.如何确定测试优先级?总结 前言 现在的公司,需求是由各个业务部门提出的,需求常常有一些或大或小的改动,而改动后的产品就意味着要进行回归测试,回归测试的测试范围大家都知道:①修改的功能②修改的功能影响的其他范围。 因此,在这种情况下,怎么精确的把.

qq_43844012的博客 3401

FAST-LIVO2 源码精读(十六):接入自定义传感器——多雷达适配与内外参标定

本文是「FAST-LIVO2 激光-惯性-视觉里程计源码精读」专栏第十六篇。上一篇拆解了中每个关键参数的物理含义与调参路径,并反复强调外参RclPcl与时间偏移配错即全局失效;本篇承接这一悬念,回答更前置的工程问题——如何把 FAST-LIVO2 接到一套全新硬件上:新雷达如何通过的类型分支适配、相机内参与畸变模型如何配置、两组外参与时间偏移如何标定出来并填入 YAML,最后给出一份落地检查清单。

PX4-SLAM-PNC 199

Video Diffusion Models:基于扩散模型的视频生成

Diffusion Models专栏文章汇总:入门与实战 前言:扩散模型已经被广泛运用到图像生成、image-to-image转换、时间序列生成、3D点云生成、文本生成、音频生成等领域,谷歌研究院最新的研究成果成功将diffusion models运用到视频生成领域。 目录 模型结构 分解时空体系联合训练 梯度条件法 恐怖的实验结果 论文和代码 个人启发 个人疑问? 模型结构 在前面的博文中,我详细介绍了为什么绝大部分的diffusion models都使用Unet结构.

沉迷单车的追风少年 6670

敏捷转型的12大难题及解决方法

如今,在敏捷的大潮下,不少企业的开发部门都已经跃跃欲试,或已经身在其中。其实,当企业做出类似敏捷转型一样,涉及方方面面的较为重大的决策时,无非是希望在产出速度、效率、质量三个方面有所提升,进而实现ROI的最大化。即老话说的“多快好省”。但是,敏捷转型之路大家都走得一帆风顺么?今天我们一起看看敏捷开发转型有哪些避之不及的“陷阱”和解决方式。 1、谁适合当Scrum Master Scrum ...

逸尘谈PM 1330

数学建模模型总结

这是本人在两年内准备参加数学建模竞赛搜集到的模型资料,已经经过了本人的筛选和整理,希望能够对准备参加数学建模竞赛的学弟学妹们提供一些帮助!

为什么软件需求会频繁变动

在我看来软件需求变更范围更为宽泛,贯穿开发周期,直到后期维护,就是因为有需求存在,导致我们的开发规模越来越大,软件更难维护,如果只是一锤子买卖,就不会衍生出软件危机;市场:主要来自于为了商机或者业务规模调整等,比如原来是线下转为线上,或者为了促销采取各种促销活动,比如秒杀,会员日、新注册用户福利等一系列活动,这时候我们的软件开发人员就叫苦不迭了,原来设计的用户账号模型被打破了,要支持第三方账号,微信,QQ,支付宝等社交账号接入,这时候用户体系得做一番调整,存在多个用户账号等;

u011360045的博客 1228

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

WINCC7.3破解文件

WINCC7.3硬件够破解文件,有需要的下载!WINCC7.3硬件够破解文件,有需要的下载!

为什么项目越来越难以维护

为什么项目越来越难以维护软件生命周期 软件生命周期 软件生命的周期包括: 问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级、废弃。 在上述阶段中: 维护升级是时间最长的阶段,正确的维护项目可以极大的延长软件的生命周期。 以上是百度百科对软件生命周期的定义。 维护升级时间占比最长,我们在这里讨论一下怎样为什么项目维护起来越来越难。 我现在在做的是一个很老的项目,有多老...

qq_39100644的博客 1111

精雕软件(JDpaint) 5.5 绿色版

精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版

你的代码为何难以维护?

本文仅仅是从笔者的旧项目延展,并未升华到哲学高度。但已表达清楚,应该如何思考才能让代码更加易读易维护。建议各位有时间也翻翻自己的旧代码,你会发现总有改进的空间。

Maisucsdn的博客 329

开发和测试在同一个环境下怎么测试的,怎么控制的

因为如果开发和测试在同一环境时候会存在这样一种情况,我在测试的时候,开发也在修改代码,这样我不知道我测试的功能,会不会因为开发修改代码之后受到影响。如果真的是只能在同一个环境下,我是这样去处理的,但是这也是我的想法,就是我们每次测试的时候,尽量跟开发沟通。毕竟一边在开发,一边在测试,相互影响的程度还是很大的。并且现在服务器普遍都是云服务器,服务器的成本大大降低,多购置一台服务器也不会造成太大的浪费。开发和测试在一个环境下本身就不合理,我们公司开发有开发环境,测试有测试环境。

m0_58079308的博客 763

数据库设计经验谈

一个成功的管理系统,是由:[50% 的业务 + 50% 的软件] 所组成,而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序] 所组成,数据库设计的好坏是一个关键。如果把企业的数据比做生命所必需的血液,那么数据库的设计就是应用中最重要的一部分。有关数据库设计的材料汗牛充栋,大学学位课程里也有专门的讲述。不过,就如我们反复强调的那样,再好的老师也比不过经验的教诲。所以我归纳历年来所走

小小猪的小开发 923

复杂的业务变更,前端如何维护代码

在业务需求变化比较大的项目中,我们必须考虑代码版本的问题,甚至是不能只听产品或者后端的一些片面之语。没有一成不变的需求。 刚接手项目的时候,开发的是关于金额计算和展示以及优惠券使用的项目,开始的需求甚至包含一些金额随意调大小的功能,在项目经过几个人轮番接手之后,到我手里已经积累了很多不可控因素,很多话暂时放进肚子里,开始谈代码的套路。 很多时候大家都一个感觉就是修改别人的代码不如重构!!!就是这个...

curry_zhao的博客 923

测试环境使用问题及其优化对策实践

方法等价类划分法边界值分析法核心“分类”及代表值边界值和边界两边的邻值优点通过把输入数据和输出数据进行分类,选用分类中的代表值,在保证了测试覆盖的情况下大大减少了测试用例的数量,使测试工作变得简单高效大量的程序错误发生在输入的边界上,考虑了边界值的测试用例能更高效发现程序中的错误和缺陷缺点输入与输入之间的关系考虑少,可能产生一些逻辑错误。还需要其他用例设计方法来补充测试只能作为一个对其他设计方法的补充;这种方法表面上听起来简单,但有的边界值非常微妙,不容易确定下来;

wqda125的博客 241

【面试】场景处理:某开发bug很多,作为测试应该如何处理

某开发bug很多,作为测试要保证软件质量,但是也要顾及与开发的关系,这种情况下,应该怎么处理

孤之鹜的博客 754

【DevOps研发管理方案】二:需求管理

需求收集环节是需求提出方和产品经理之间明确产品需求的阶段,是产品研发运营一体化最初始阶段,把产品的需求具体化,形成待办事项列表的过程。

夢的点滴的博客 1951

软件需求变更,测试人员应如何应对?

需求频繁变更的原因 前期需求调研工作没有做到位,在需求调研时没有真正深入了解用户的需求?用户需要这款产品的目的?为什么要这么做? 项目经理对项目掌控力度不够,如果一个项目的需求一定情况下,尽可能避免在短时间里频繁变更,可以采用集中变更或者分阶段变更 客户在最开始时自己也没搞清楚要做出什么样子?随着系统的成型上线,提出一些新想法等导致需求变更。 客户就是上帝,所以有些变更时必须的 测试人员如何面对变更 协调制定变更规范,比如说每次需求人员都会发出变更申请书,这样可以作为开发人员和测试人员工作的依据。如果

weixin_53489607的博客 1621

如何应对软件需求不明确、需求频繁更改和需求的无底洞

入职以来一直会遇到这种问题,也许是软件行业的死穴,任何项目如果处理不好解决不了这些问题,就相当于得了慢性绝症,不但项目的结局是死路,经手项目的每 个开发人员到管理者都在经受挑战人体极限的折磨。开发人员就像交通工具,上级传达指令,他就会最高效的将之送到目的地,如果老板自己都不知道想去哪里或者 不会开或者GPRS导航都不会用,就算给他一辆保时捷或者飞机都是白搭,说到这就知道为什么软件行业跳槽之频繁了。...

明亮的技术博客 2万+

【DEVOPS】需求跟踪管理全面落地

如何在有成功先例的前提下,将标准化的项目管理流程全满铺开

夫礼者的专栏 1073

测试人员遇到需求变更 4大处理技巧

测试人员遇到需求变更 4大处理技巧,CoCode自动生成测试用例助力软件测试人员效率提高。

CoCode888的博客 1656
上一篇: 肖风在第五届区块链全球峰会的闭幕演讲全文:由 Libra 引起的思考
下一篇: QT两个独立窗口,子对象如何传信号到父对象
99学商
博客等级 码龄7年 21粉丝 40原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值