建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

kaverjody

发帖: 12粉丝: 10

级别 : 版主

发消息 + 关注

发表于2019年09月10日 11:25:34 3357 20
直达本楼层的链接
楼主
显示全部楼层
【DevCloud · 敏捷智库】如何避免重要需求遗漏?

封面.png


避免重要需求遗漏的思路

避免重要需求遗漏,首先我们需要反问一句 —— 为什么这些紧急重要的需求无法更早预见?同样的,我们需要了解:

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

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

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

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

具体操作方法

具体操作,可以按照事前、事中、事后各个阶段来采取不同的措施处理。

一、事中的处理

根据具体情况不同,在发现需求遗漏的当时,可以采取如下一些做法:

  • 重要需求遗漏,不紧急:既然不紧急,按照常规做法增加进去即可,但如果经常出现遗漏,就要考虑是否是需求分析和规划的实践做法有问题,才会导致问题持续出现,这种情况,应强化需求结构化管理,从全局出发进行思考和规划,避免因为思考的片面化和局部性导致的遗漏;

  • 重要需求遗漏,紧急:既然是又重要又紧急的需求,那么必然就得调整当前开发工作的顺序,把这个遗漏的重要紧急需求排进去,把工作安排下去;然后就要考虑从需求的优先级和需求的结构化管理两个方面入手复盘,并切实改进,避免类似情况再次发生;

  • 需求遗漏:如果是不太重要的需求遗漏,按照常规做法处理即可;可以根据其紧急程度和影响,决定是否调整工作顺序让这个需求插队;如果这种情况反复出现,那建议可以考虑进行复盘,从需求结构化管理的角度进行分析,并商讨改进措施;

     

二、事后的处理

事后其实就是复盘,复盘的关键是要基于盘来推演和分析,这个盘就是事前制定的模型和规范。是我们有模型有规范,但执行出了问题?还是说这几个需求情况特殊,模型比较简单没有覆盖到这些特殊情况?还是说模型和规范都没问题,就是人员能力不足,导致判断偏差大?只有找到正确的根因,才能够真正有效的解决问题,所以我们不复盘则已,要复盘就务必要认真严格地进行复盘。

怎么复盘?复盘也是有方法有套路的,业界也有相关书籍可供我们参考借鉴。例如温伯格在《成为技术领导者》中提出的MOI模型就可以用作复盘的一种思路。

  • M:激励(Motivation),是不是人们没有动力去做这件事情?

  • O:组织(Organization),是不是无组织无纪律、一片混乱,人们不知道自己或别人该做什么?

  • I:想法或创意(Idea/Innovation),是不是缺少如何解决这些问题的点子或创意,不知道有什么办法解决这个问题?

    复盘时要注意,受限于能力或经验以及出问题次数多少的影响,我们可能无法得出一个准确的结论和必然有效的解决方案。此时一方面需要秉持持续改进的心态,我们可以先落实当前已经比较明确的改进措施,后续再观察效果,持续复盘、持续改进即可。另一方面我们也可以先采取一些临时措施。

  1. 预留时间:比如,如果确实很难分析清楚为什么总是会遗漏需求,无法进行非常有针对性的处理时,也可以采取较为模糊应对的方式。可以拉取过去一段时间的工作记录,评估这段时间每个迭代的突发需求所消耗的工作量投入,可以取个平均值,然后在后续进行迭代工作安排的时候,固定的预留出一定量的时间,用于应对极有可能会出现的突发需求。

  2. 需求拆细:当出现突发需求,导致我们需要调整工作顺序时,很有可能会因为需求颗粒度大以至于腾挪余地有限,而难以避免突发需求带来的影响,因而还应该尽可能地采取拆细需求的方式,将颗粒度比较大的需求拆分为较小颗粒度的需求,可以增加调整需求工作顺序时的灵活性;

    要确定到底要预留多少时间,可以利用DevCloudEpic-Feature-Story结构,把突发需求汇集在一起,便于统计。例如创建一个特殊的Epic“突发需求,下一级是为每个迭代创建的Feature,用来承载各个迭代里面具体的那些突发需求(体现为Story),并做好工时的记录,迭代结束后,就可以来计算出现了多少个突发需求、投入了多少工作量了。

    1.png

    也可以采用模块字段来辅助记录和统计突发需求的数据。例如,新建一个模块,取名突发需求,所有突发需求都标注为这个模块,那么后续就可以基于模块进行筛选或查看报表等方式来统计突发需求所消耗的工作量了。

2.png

三、事前的处理

事前的处理放到最后来介绍,是因为之所以会出现问题一般都是因为事前没有做好,但已经出现了问题就需要在当时尽快处理,所以先介绍了事中的处理。但当我们处理完问题也完成了事后复盘,就需要考虑未来的事前,尽可能的避免问题发生。
简单来讲,事前的话,就是要做好需求的结构化管理和需求的优先级管理,以及做好相关规范的宣导、人员的动员和能力的培养,这样就能够有效的避免或减小突发需求带来的影响了。

参考附录

相关书籍

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

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

敏捷

举报
分享

分享文章到朋友圈

分享文章到微博

hw84820715

发帖: 5粉丝: 2

级别 : 中级会员

发消息 + 关注

发表于2020年06月09日 15:20:23
直达本楼层的链接
沙发
显示全部楼层

【DevCloud · 敏捷智库】如何避免重要需求遗漏‘

不断学习,不断进步,最短时间内有效处理

点赞 评论 引用 举报

yblyh673

发帖: 0粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年06月11日 15:47:17
直达本楼层的链接
板凳
显示全部楼层

M:激励(Motivation

O:组织(Organization

I:想法或创意(Idea/Innovation


点赞 评论 引用 举报

张辉

发帖: 78粉丝: 29

级别 : 金牌会员

发消息 + 关注

发表于2020年06月12日 09:11:42
直达本楼层的链接
地板
显示全部楼层

需求遗漏不清楚,但是就个人开发的经验,需求不明确大概有几个原因:

  1. 需求沟通时找错了干系人。比如原以为接口人是负责需求的人,结果这个人谈完之后,并不能做需求确认。等真正的业务部门的人员来沟通时,发现需要的并不是这个东西,或者又在上面提出了新的需求。所以首先应理清干系人。找错对象是无法有好结果的。

  2. 需求分析时建模没有做好,没有划分好需求的边界。导致本应是系统内部要求的内容忘记放入系统中,或者本不该是系统需要实现的功能要求系统去实现。

  3. 用户故事(业务用例或者用户用例)编制不清晰。无论是用户故事的价值,还是业务流程,如果划分不明确,编制不清晰,就容易导致需求的不明确或者遗漏的情况。

点赞1 评论 引用 举报

中华之为

发帖: 0粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年06月12日 11:47:08
直达本楼层的链接
5#
显示全部楼层

挺好的  值得学习


点赞 评论 引用 举报

吉杰

发帖: 0粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年06月13日 23:39:08
直达本楼层的链接
6#
显示全部楼层

避免重要需求遗漏的思路:

    1.外界原因:是否有共性

    2.无共性特点

    3.临时性:提高或改善响应能力

    4.调整与应对

操作方法分三个阶段:

事前:做好需求的结构化和需求的优先级管理、相关规范的宣传、人员的动员以及能力的培养

事中:可以根据遗漏的需求重不重要、紧不紧急进行分类,逐个解决

    1.重要,不紧急:按照常规做法增加进去,经常出现遗漏,针对需求分析和规划,强化需求结构化管理,避免思考的片面化和局部性导致的遗漏

    2.重要,紧急:调整当前工作的顺序,安排此需求的增加工作,考虑复盘时,可从需求的优先级和结构化管理两个方面入手,改进

    3.不重要,不紧急:按照常规做法处理,必要时可以让这个需求插队;考虑复盘时,分析需求的结构化管理,改进

事后:可以参考MOI模型:

    M:激励(Motivation),动力,实践

    O:组织(Organization),纪律,目标

    I:想法或创意(Idea/Innovation),点子,创意

    复盘时无法得出一个准确的结论和必然有效的解决方案时,可以先落实已经比较明确的改进措施,再观察效果,持续复盘、持续改进。此外,可以采取预留时间和需求拆细的措施:

    预留时间:采取较为模糊应对方式,固定预留出一定的时间,应对极有可能会出现的突发需求

    需求拆细:将颗粒度比较大的需求拆分为较小颗粒度的需求,增加调整需求工作顺序时的灵活性



点赞 评论 引用 举报

Hello Digger

发帖: 9粉丝: 0

级别 : 高级会员

发消息 + 关注

发表于2020年06月14日 00:38:47
直达本楼层的链接
7#
显示全部楼层

预防和复盘结合,按紧急优先级处理

点赞 评论 引用 举报

春风吹又生

发帖: 0粉丝: 1

级别 : 注册会员

发消息 + 关注

发表于2020年06月14日 17:46:51
直达本楼层的链接
8#
显示全部楼层

不错的学习地方。

点赞 评论 引用 举报

山地车

发帖: 0粉丝: 0

级别 : 新手上路

发消息 + 关注

发表于2020年06月17日 11:16:17
直达本楼层的链接
9#
显示全部楼层

大神就是大神,收获很多

点赞 评论 引用 举报

lte网络工程师

发帖: 154粉丝: 8

级别 : 外部版主

发消息 + 关注

发表于2020年06月17日 16:46:25
直达本楼层的链接
10#
显示全部楼层

需求拆细:当出现突发需求,导致我们需要调整工作顺序时,很有可能会因为需求颗粒度大以至于腾挪余地有限,而难以避免突发需求带来的影响,因而还应该尽可能地采取拆细需求的方式,将颗粒度比较大的需求拆分为较小颗粒度的需求,可以增加调整需求工作顺序时的灵活性;

数据分析有种类似的说法,钻取数据。

点赞 评论 引用 举报

speeds

发帖: 6粉丝: 4

级别 : 高级会员

发消息 + 关注

发表于2020年06月19日 14:13:43
直达本楼层的链接
11#
显示全部楼层

如果确实很难分析清楚为什么总是会遗漏需求,无法进行非常有针对性的处理时,也可以采取较为模糊应对的方式。可以拉取过去一段时间的工作记录,评估这段时间每个迭代的突发需求所消耗的工作量投入,可以取个平均值,然后在后续进行迭代工作安排的时候,固定的预留出一定量的时间,用于应对极有可能会出现的突发需求。事后其实就是复盘,复盘的关键是要基于盘来推演和分析,这个盘就是事前制定的模型和规范。是我们有模型有规范,但执行出了问题?还是说这几个需求情况特殊,模型比较简单没有覆盖到这些特殊情况?还是说模型和规范都没问题,就是人员能力不足,导致判断偏差大?只有找到正确的根因,才能够真正有效的解决问题,所以我们不复盘则已,要复盘就务必要认真严格地进行复盘.


点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册