有时候我觉得我们的门徒在圈子里工作,’我的意思是经过数年的发展后,讨论突然转向质疑是否需要BA,甚至是否应该记录需求。我们是否有可能退回到几年前的软件开发过程中?

我们这是在哪

几年前,当我为一家中型公司管理软件开发时,软件开发包括让开发人员与用户坐下来,然后在楼上奔跑并开始编码,没有软件需求,规范(或任何文档)测试用例的概念在软件开发过程中,需要开发人员专注于特定领域,因此,只要我们在该领域有新开发,我们就会派遣该人。当然,这也意味着对应用程序的任何维护几乎总是由同一位开发人员完成的。当时,分析还没有被视为单独的责任或学科。我当然不会说这是在各处进行开发的方式,但这是我们与之建立联系的公司的典型做法。多年以来,术语“业务分析师”是被创造出来的,在大型开发项目中,分析师的角色被明确地理解为必不可少的过程知识,过程管理者,负责人的责任,负责人负责了解所需信息,问题,文档,最后与开发人员沟通最终结果。我们业务,系统等的复杂性使广管局以及业务架构师成为过去或不再需要的必需品。从另一个角度看,我最近参加了SDN网络上的一次对话(树液网络博客– Just a developer?!)关于开发人员和分析师之间的职责划分,这是一个棘手的问题,尤其是对于内部开发人员而言,因为他们通常对业务非常了解,有时还质疑是否需要业务分析师或应该让他们与用户。随着业务分析状态的改善,从长远来看,由于业务分析师的角色将变得更加清晰,并且利用此职位的公司将处于优势地位,因此讨论将变得毫无意义。在这方面,中小型公司可能会落后于大型公司,但这仅是因为雇员担任许多职务是很典型的。

我们在哪里

 

在过去的十年中,软件开发过程一直在变化,软件需求规格说明(SAP称之为蓝图)的概念已得到相当理解,尽管我认为我们还没有达到成熟的水平(我对此发表了评论。以前的帖子 What is a 树液Blueprint? 所以我赢了’请在这里告诉您细节)。我要说的是,随着我们开始在分析方面取得进展,突然之间有一种讨论(我称之为混乱),即新方法论意味着不再需要软件需求规范,即使业务分析师需要。看到 行业观察:不断变化的需求,不断变化的技能,以获取一些讨论的更多详细信息。我不确定新方法是否特别提倡该文档,分析师也不再重要,但我认为它是通过这种方式解释的。如果您从敏捷的角度看待需求,则与标准瀑布式开发的唯一区别在于,与其在开发开始之前就先让需求预先签署并签字,不然它会分散在整个开发过程的整个生命周期中。无论使用哪种开发过程,都存在相同的问题,仍然需要知识转移,可追溯性,变更影响分析,风险评估,并且所有这些都需要纳入开发过程中。

 

我们要回到过去吗?

 

为了推动发展中的最先进技术,我们当然需要重新考虑这一过程,但是让’不要忘记过去和以前的所有错误,我们没有’称其为敏捷时,我们将其称为开发是因为总体上软件开发还处于起步阶段,但是我当然不希望回到那个时代,尽管我拥护使用敏捷开发方法,但我并不认同。

固定在Pinterest上

分享
分享这个