首页 > 代码库 > 敏捷测试和瀑布测试的关联

敏捷测试和瀑布测试的关联

什么是敏捷?

在敏捷开发在软件和互联网产品开发领域日渐普及的情况下,我们从敏捷开发认识敏捷,继而接触到周金根老师的敏捷人生,《managemeng 3.0》又将敏捷的概念带到管理层面,但到目前为止我们谈敏捷都基于一个特定背景,如开发、管理,所以如果脱离背景,敏捷究竟具有哪些特质?和塔勒布先生提出的Anti-fragile有何相同和不同之处?
被浏览
10391

4 个回答

技术分享
Waterwalker
「敏捷销售」教练,公众号ID: agilesales2015
 
 
终于在提出问题一年后可以亲自谈谈对“敏捷”的理解。

一、从“敏捷开发”说起

“敏捷”概念的引入最先是从软件开发领域引入的。传统的软件开发采用的是瀑布式开发的流程,把整个开发过程分成了收集需求、定义、设计、编码、测试、发布等阶段,每个阶段设定明确的目标和标准,达成后再进入下一个阶段,整个过程沿着可预测性逐步增加的方向前进,可以避免资源的无效投入,并有效地保证开发质量。

技术分享

但问题在于瀑布式开发这种预定义过程的方法,每个阶段之间都有强烈的依赖关系,前一个阶段被视为后一个阶段的输入,如果输入质量不高,便会严重影响后续阶段的输出质量。同时,如果前一个阶段未能达到标准,也会造成后续阶段的停滞,导致开发周期拉长。并且,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。


所以敏捷开发就是在提出这样一个问题的背景下所诞生的。有数据显示有70%采用瀑布式开发方法的软件开发项目均已失败告终。原因便在于,市场的需求瞬息万变,很难实现产品需求的明确且完整地收集;同时,技术的发展也日新月异,对于所定义功能的可实现性也面临着多重不确定性的因素。所以当需求收集和产品定义工作无法得到很好地完成,瀑布式开发方法自然无法摆脱高失败率的命运。

技术分享

所以从需求的明确性和工程实现的确定性两个纬度出发,当需求的不明确性和工程实现的不确定性均超出一定范围之后,呈现出复杂系统(Complex System)的特征,瀑布式开发这种结构化的开发方法便不再实用。而敏捷开发方法正是在这样的背景下诞生。

技术分享

敏捷开发的一个核心思维模式的转换便是:从瀑布式开发所代表的“Fix Scope, Flex time”(固定范围,弹性时间)转向“Fix time, Flex Scope”——固定时间,弹性范围。 在市场变化和技术变化的背景之下,既然市场需求和产品定义所代表的“范围”无法实现固化,因而无法确定应该投入多少资源来完成,那不妨固定好已有资源的,以资源为约束,实现“范围”的最大化实现。因此从“计划驱动”转向为“价值驱动”。


而在敏捷开发的思维模式提出后,一方面诞生了“个体与交互胜过过程与工具”、“可以工作的软件胜过面面俱到的文档”、“客户协作胜过合同谈判”、“响应变化胜过遵循计划”这样的代表敏捷价值观的“敏捷宣言”,充分发挥“人”作为代码编写者在软件开发过程中的价值。

技术分享

同时在敏捷宣言的指引之下也产生了多种多样的敏捷开发方法,如冲刺和迭代式的“Scrum”方法,更进一步通过具体的实施手段展现“敏捷宣言”所代表的敏捷价值观。

技术分享对比瀑布式开发所代表的预定义过程的工程方法,敏捷开发方法通过测试驱动/价值驱动的手段,更加贴近最终的应用环境,于是也具备了更好的适应性。同时在敏捷宣言指引下,更强调发挥代码编写者的价值,可以更好地挖掘出代码编写者的潜能。

技术分享二、什么是敏捷


从“敏捷开发”可以看出,敏捷不仅仅简单只是一个形容词,更代表了一种方法,那么究竟什么才是“敏捷”呢?


1. Complex System Context 以“复杂系统”为背景

敏捷并不是一个普世的方法,而是具有一定语境和背景的,如同敏捷开发的诞生,也是在市场瞬息万变和技术日新月异的背景之下而产生的。

“敏捷典型”是以“复杂系统”为背景。作为一种方法,最终都是被“人”所采纳并实施。而人对于世界的认知和理解始终朝着减少未知“Unknown”和不确定性“Uncertainty”两个方向前进,对于未知需要逐步理解(Understandable),而对于不确定性,通常是提前预测,通过反馈,来获得判断(Predictable)。因此可理解和可预测也成了人认知世界的两个纬度。

技术分享

但无论科学技术如何进步,对世界的很多事物已经达到可理解、可预测的地步,但依然还存在非常多的不可理解或不可预测的事物。特别是每个人的认知能力也存在差异,相同的事物对某些具有足够认知能力的人来说是可理解、可预测的,但如果认知能力不足,便会出现既无法理解、也无法预测这样的“混乱系统”(Chaotic)。


而复杂系统(Complex)也是同样,当相对于人的认知而言,对可理解性和可预测性均提出一定高度的要求,便呈现出复杂系统的特征。如同敏捷开发所产生时的背景,市场瞬息万变,需求变得不可预测;技术日新月异,对某些需求的技术可实现性也变得越来越难以理解。但这种不可理解性和不可预测性并没有远远超出人的认知潜能的范围,没有到达彻底混乱的地步;同时,通过过程中不断地反馈和学习,也可以逐渐消除未知和不确定。因此,对于这样的复杂系统,运用敏捷方法,将可以更好地获得对系统的理解和预测。


2. Human-Driven 以人为核心驱动


敏捷的另一个特征是“以人为核心驱动”——Human Driven。


对于适用敏捷方法而言,其最终的目的是为了理解所处的复杂系统,激发复杂系统所具有的能量。更强调“系统”对于“人”的价值,而非单纯地承认其“复杂”的特征。


同时复杂系统又是一个相对的概念,是相对于人的认知能力而言。而对于复杂系统,其认知的过程依然会沿着“可理解”“可预测”两个方向发展,这其中“人”将扮演主要的角色,需要充分挖掘“人”的潜能。


无论对“目的”而言,还是“过程”而言,在运用“敏捷”方法时,“人”都是认知和运转“复杂系统”过程中的核心驱动力。

技术分享

所以这也对运用“敏捷”方法的“人”提出要求,需要思维模式和价值观的支撑,才能真正理解并运用“敏捷”方法。在《管理3.0》一书中,作者Jurgen Appelo给出了一个具有六只眼睛的异形生物,并取名为“Martie”,代表了运用“敏捷”方法的人应该所具备的六种思维模式:

  • Energize People 有效激励
  • Empower Teams 赋能团队
  • Align Constraints 调和约束
  • Develop Competence 发展能力
  • Grow Structure 结构成长
  • Improve Everything 全面改善

技术分享

3. Adaptive Empirical Process Control 具有适应能力的经验性过程控制


“敏捷”的第三个特征便是:“敏捷”实际上是一种经验性的过程控制方法。作为一种方法,通常都具有一定的目的性,而为了达成目的,势必要实施一定的过程控制,才能提升达成目标的几率。而在“复杂系统”的背景之下,“瀑布式开发”所代表的预定义过程控制(Predefined Process Control)已不再适合,而以人为核心驱动的经验性过程控制(Empirical Process Control)将具有更高的适应性和灵活性,同时也能充分发挥“人”的潜能和价值。

人类在进化过程以及认知、改造世界的过程中始终都面临着各种“未知”(Unknown)和“不确定”(Uncertainty),所以人类的历史天然就是一个“敏捷”的过程。

让我们借助一部经典动画片《疯狂原始人》中的人物和场景,来更好地表达“敏捷”这样一个经验性过程控制方法需要遵循哪些原则。

Rule1:适应性原则。Keep Relevant-时刻保持与背景“复杂系统”的关联,适应“复杂系统”的变化。

技术分享

Rule2: 灵活性原则。Always be optional-拥有多重选项,根据环境的变化进行灵活选择。

技术分享

Rule3: 利用系统的“原力”——Leverage the Gravity。人的力量毕竟微弱,需要充分挖掘“复杂系统”自有的力量并加以利用。

技术分享

Rule4: 模式识别——Patterns Recognition。识别“复杂系统”中所呈现出的“模式”,基于“模式”,逐步理解“复杂系统”。

技术分享

Rule5: “自下而上”原则(Bottom-up)。由于“复杂系统”的未知性和不确定性,在缺乏必要信息的情况下,无法通过“自上而下”(Top-down)的方式来理解系统。因此,从基本的“模式”出发,并在过程中学习和认知,不断地向上发展更高层的“模式”,才能最终实现对“复杂系统”的全面认知。

技术分享

三、总结


所以,“敏捷”(Agile)代表的是一种方法,是在“以人为核心驱动”(Human-Driven)的“复杂系统”(Complex System)背景下,一个具有适应性的“经验性过程控制方法” (Adaptive Empirical Process Control)。

技术分享持续运用“敏捷”的方法,即使有眼前的“未知”和“不确定”所困扰,但逐渐拨开云层,便是灿烂的曙光。

技术分享
了解了什么是“敏捷”之后,你对具体什么是“敏捷销售”是否更加期待?
 
转自:知乎:https://www.zhihu.com/question/30945320?sort=created

敏捷测试和瀑布测试的关联