扫码阅读
手机扫码阅读

在敏捷环境中该如何进行需求分析(一)

326 2023-09-02

感谢阅读,本文共2220字,预计阅读时间大约需要5分钟。

为了方便您的阅读提前列出本文的章节:

1.瀑布开发VS敏捷开发

2.敏捷环境中的需求

3.如何面对需求



一、瀑布开发VS敏捷开发
    不管是作为项目经理、产品经理还是架构师的角度来考虑,进行需求优先级分析是一个项目或者产品成功的第一步。
    传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体,也是一份契约。
    然而详细的需求说明书有以下4大弊端:
  • 单向的信息传递,容易出现理解偏差。
  • 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断。
  • 有了详细的文档,我们不会反复讨论它,相互确认。
  • 书面文档不利于团队共享责任,它扮演了证据的角色。

    而当我们使用敏捷开发时,Scrum强调团队共享责任,不论是需求人员、开发人员和还是测试员,大家的共同目标是通过讨论、协作,正确理解需求之后把这些需求变成客户真正需要的功能,而不是单向的任务传递。
    编制详细的、表达准确需求文档需要花费大量的时间,如果需求变化频繁,维护成本更高。

    在瀑布的软件开发模式里面不可变的是范围!
    因为在瀑布的软件开发里面先有功能需求说明书,这已经规定好了交付的范围,那么能够变的就只有资源和时间了。
    这也是我们会看到瀑布的团队里面经常会加人,会增加时间。
    再看敏捷的软件开发模式,不变的是什么?是资源和时间。
    因为敏捷团队成员和迭代都是固定的,所以可变的只有范围了。
    那么范围是什么,就是我们所说的需求!

二、敏捷环境中的需求
1.不要想着一开始就能做好全部需

首先,不同于瀑布一开始就通过功能需求说明书把需求定好了,假设这个项目可能需要一年的时间,按照瀑布的做法,我们在项目开始前的一个月内可能就要确定所有的需求,等同于说在一个月内就要预测到一年以后的事情,这个是很难的,一年会发生什么技术变化,或者市场变化,我们都无法准确得预测到。

所以,在敏捷管理中,我们认为需求是变化的,不会也无法在一开始就做好项目所有的需求规划和细节,因为我们知道后面还会有各种我们无法预测到的情况发生。

2.需求将以涌现的方式出现

在刚开始一个新的项目时,我们通常会考虑组织知识库当中找到经验教训,不能在新的项目中继续踩坑。这也是一个正常技术型公司惯常的做法。我们就会下一些结论说:我们只要在某方面做得更努力或者更多,结果就会更好。在很多时候,可能真的如我们预料的一样,但这个用在需求的收集上是行不通的。

    不管我们在项目的开始阶段工作多长时间或多么努力来确认所有需要的功能,我们总是不能成功,因为总有很多需求只有在产品开发启动以后,才会以用户主动变更、反馈、开发人员发现的新问题等等形式出现。
    这些是无法预知的,在软件开发的过程中或是开发结束时才会被发现,所以,我们认为需求就是以这种涌现的方式出现的。

很多重要的项目都会有涌现的需求,而且这些需求涌现出来会引起其他问题,比如,突然涌现的需求让我们很难准确地预测进度。

3.需求的涌现是持续性的过程
    需求的涌现,并非一次性的事情,软件开发过程中变数很大,所以需求的涌现也是个持续性的过程。
    为什么这样说呢,我们从三个维度考虑:
  • 事情会发生变化
    在项目的过程中,优先级会发生变化,刚开始我们认为重要的功能可能随着系统向潜在的用户或客户演示,就变得不那么重要了,新的需求会被发现出来,这时候就需要我们重新排列优先级。
  • 不需要

所以并不需要全部预测,而是让需求就以这样涌现的方式在项目的进程中出现。

  • 时间有限
    所有的项目都会设有时间限制,往往我们需要的时间比实际更多,所以在一开始就花费同样的精力对待所有的需求是一种浪费。
    站在敏捷的角度,从目前的情况来看假设某个功能还不需要马上就去做,可能会放在一个月后,那我们只要简要地描述一下这个功能就够了。
    等到后面按照优先级排序终于开始做这个功能时,我们再将这个需求去细化,细化成一个个根据当下的情况而产生的小需求,就是涌现的需求。

二、如何面对需求
    需求既然无法一开始就做好全部规划,在项目的进行中,还会一直以涌现的方式呈现出来,那么问题来了,面对这样的需求,我们应该做好什么样的准备呢?
1.从文档到沟通的转

需求在变化,我们应对需求的方式也可以发生变化,传统的需求功能说明书已然不适合当下,传闻中有个神乎其神的神话:如果你把需求写下来,用户就能得到他们想要的东西。

    很明显,在这里不成立,敏捷宣言强调“可工作的软件胜过全面的文档”,敏捷宣言还说“个体和互动高于流程和工具”。
    综合这两条,我们看到敏捷宣言强调了个体和互动的价值,也提醒了全面文档的价值是不及可工作的软件的。
    敏捷认为个体互动价值更高,所以在以产品待办列表这样的书面文档形式呈现出需求时,更重要的是增加了PM和团队一起针对产品待办列表的讨论,
    大家对于事项的安排有什么意见,产品做成什么样有什么想法,围绕着这张产品待办事项列表,坐在一起讨论。

所以:少量的/简化的书面文档+沟通>全面的书面文档。

2.持续提炼需求的转变

处理涌现需求的第一步就是认识到我们不可能想到每一件事情。

    如果能够认识到某些需求只会在我们开发系统的过程中才会涌现,就比较容易接受这样的观点:我们不需要,也不可能,提前就拥有一份已规定好待开发系统的所有细节的完美文档。
    事实上,我们最好根据功能要被实现的时间,采用不同精确程度的方式来规定功能需求,而不是从一开始就为了它的完整性苦苦挣扎。

当需求出现时,持续地去提炼它。

原文链接: https://mp.weixin.qq.com/s?__biz=Mzg3NDc0MDc4Mg==&mid=2247483995&idx=1&sn=b0eb8865d517a5455ddff1d233c399b8

对待离自身尚远的事物时,人们可以把它分析得淋漓尽致;但到了自己身上,就往往成了当局者迷,旁观者清。譬如软件开发,譬如项目,譬如产品,譬如敏捷,譬如精益,譬如管理,譬如思辨,譬如哲科思维,譬如哲学。来到圆桌派,让我们一起旁观者清!

35 篇文章
浏览 9823
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线