其他分享
首页 > 其他分享> > 一篇短文再谈“敏捷”

一篇短文再谈“敏捷”

作者:互联网

仅以此文用来抒发一些对于行业现象的批判。

 

敏捷是现在十分流行的软件研发模式,并且正在成为业界主流。下图来自于2018年软件测试行业报告,可以看到在受访测试人员中,工作于敏捷或类敏捷项目中的比例已经高达89%。

将测试融入敏捷模式中,根据敏捷项目的模式进行调整,实现“敏捷测试”,是成熟的测试团队必须具备的能力。

 

在谈论敏捷测试之前,首先要搞清究竟什么是敏捷。

敏捷,汉语名词解释指反应(多指动作或言行)迅速快捷,关键在于快字。也正是由于这一特点,非常适用于小步快跑的现今项目节奏,也使得敏捷得以大行其道。做项目,必谈敏捷,不敏捷项目经理出门都不好意思跟人打招呼。

然而,许多(危言耸听的说,甚至是大多数)项目对于敏捷的理解和应用都是产生了偏差的。对于某些项目组织者而言,敏捷就像是一棵救命稻草,使得他们可以名正言顺的抛弃掉他们认为的那些繁文缛节,自以为是的将团队力量投入到他们认为最有价值的领域中去。这样的敏捷,蔑视流程,蔑视管理,蔑视所有的准备和规划,到头来项目只能是乱成一团

敏捷是行之有效的理念和模式,但必须被正确的看待和使用。

 

当我们谈论敏捷,我们到底在谈论什么

有一些理论体系中,会将敏捷和一些常见的软件生命模型并列而谈,认为敏捷与瀑布模型、迭代模型一样是一种“模型”。但笔者认为,与其认为敏捷是一种模型,不如说是一种颠覆性理念。敏捷这一概念所对比的,并不是软件生命模型,而是更基础的,软件研发的组织办法:“软件工程”。

软件产业的发展,经历许多个阶段,从早期的软件开发=编程,到上世纪70年代,逐渐诞生了工程体系。到现在,软件工程已经是行业的一种标准理念了。

我们不妨回过头来问一句,为什么软件的研发要采用“工程”式的组织?

我们不去纠结其名词解释,工程这个词通常的用法在什么场景下面呢?他被用的最多的一个领域可能就是:基础建设“工程”,比如盖房子,装修--典型的工程式管理。

我们可以对比一下软件研发和基建项目的类同性:通过一行一行代码的积累,与一砖一瓦的将一栋建筑搭建起来,是不是非常近似呢?!

于是就如下图所示,我们将软件研发过程与基建工程做了一个类比:

这种类比是非常ok的,确实我们可以按照基建工程的组织形式,将软件研发同样进行工程式管理。到现在为止,“软件工程”已经是我们行业内的标准定义和模式了。

在工程思维导向下,许多“精益生产”领域的理论体系也在被不断的融入软件研发行业内,比如PMP项目管理,比如CMMi成熟度模型,等等。

 

——————————————————————————分割一下——————————————————————————————————————————

 

但是,随着社会节奏的加快,业内的人士逐渐发现了工程式管理的弊端。比如,繁文缛节的项目组织、计划、设计阶段所花费的投入,甚至远高于实际的产品生产。

这个时候我们再回过头去审视我们关于软件工程和基建工程的对比,他们真的是一毛一样的吗?

盖一栋房子,我们需要严密的工程规划,设计,需要严格按照计划进行建筑材料的采购,需要严格按照结构设计的要求进行施工。规划和设计中出现的一点不合理,都可能会动摇后续的工作的根基;施工过程中的一点点不严谨,都可能造就成一项豆腐渣工程。

那么软件研发是不是也同样如此?是不是一个产品功能特性,采用A方法完成和B方法完成会产生根本性问题?是不是少写几行代码,就一定会导致产品的崩溃?是不是没有设计图纸,工程师就完全无法开展施工(编码)工作?

你会发现这些问题的答案全部都是否定的,软件研发与基础建设工程绝非完全类同,衡量软件研发的成功与否,甚至只有一条标准:用户的满意

换一个角度来说,传统工程意义上的软件研发,将软件视作一种待售产品,他与其他的商品生产过程并无二样。那么精益生产的理念,流水线式的生产车间管理也被引入软件研发过程。软件真的与工厂里流水线上生产的产品一样吗?绝对不一样,软件的需求具有高度定制的特性,不同的企业不同的人不同的群体,需要不同的软件,绝非日用产品那般千篇一律。随着理念的更新和升级,现在的业界更多认为,与其说软件是一种产品,软件更是一种服务。用做服务的思想去做软件研发,也是敏捷的出发点之一。

所以从这个角度而言,软件究竟通过怎么样的过程被研发出来,并不重要,重要的是研发出来的软件要符合用户需求。闭门造车,循规蹈矩,工厂车间式的软件研发,已经不能适应当今的许多项目需求。

 

我们可以看看,敏捷四宣言都在谈论什么:

  1. 人员交流重于过程与工具(Individuals and interactions over processes and tools)
  2. 软件产品重于长篇大论(Working software over comprehensive documentation)
  3. 客户协作重于合同谈判(Customer collaboration over contract negotiation)
  4. 随机应变重于循规蹈矩(Responding to change over following a plan)

对于这些敏捷宣扬的理念,如果不理解敏捷的上述背景,就会产生应用的偏差。

比如说第二点:软件产品重于长篇大论,强调说复杂的文档不是软件研发的核心,产品本身才是我们的最终目标。指的其实是我们不应该过分追求复杂的文档,指的是文档形式的转变,而不是不要文档!敏捷项目有着自己适用的文档组织形式,比如敏捷需求更倾向于使用用户故事形式,而非传统意义上的PRD。

再比如说第四点:随机应变重于循规蹈矩,强调说不应该死板的遵循计划,而是应该拥抱变化。他谈论的问题核心在于变化的处理和应对,而不是毫无计划,杂乱无章

比如传统意义上的软件研发,可能耗费一两年一个软件才最终问世,而在这一两年的时间内,这个软件到底是否符合市场定位和用户需求,这一判断是含糊的,因为这个过程中最终用户始终也没有看到软件的成品。而敏捷则强调对于用户需求的强响应,通过引入冲刺周期的形式,将庞大的软件开发过程拆分成为期2-4周的阶段,快速的产出基础产品。快速的将基础产品推向市场和用户,让用户来评判产品的适用度,如果市场满意度低,一个字:改。

拥抱变化,这才是敏捷。

 

最后总结一下:

敏捷的核心在于灵敏迅捷,在于快速。快速的终极目标不是为了快速而快速,不是为了偷工减料而快速,不是因为你管理能力低下,很多事情你组织不好,所以干脆抛弃这些你没能力做好的事情来达到快速目的。不是因为敏捷所以可以不要需求,因为敏捷所以该做的事情不做,不要以敏捷为借口来达到偷懒的目的,这是无知和无耻的表现!

标签:短文,工程,项目,重于,再谈,研发,敏捷,软件
来源: https://www.cnblogs.com/ht22ht22/p/11655829.html