什么是敏捷

什么是敏捷?

1 年前


一、从“敏捷开发”说起

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

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

所以敏捷开发就是在提出这样一个问题的背景下所诞生的。有数据显示有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)。

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

时间: 2024-08-03 12:00:31

什么是敏捷的相关文章

敏捷流程

流程简介 第一步:找出完成产品需要做的事情--Product Backlog 第二步:决定当前的冲刺需要解决的事情--Sprint Backlog 第三步:冲刺 第四步:得到软件的一个增量版本,发布给用户 敏捷流程的问题和解法 第一步:在计划中体现依赖关系 第二步:技术能力和交流能力 第三步:定义好任务 第四步:得到一个增量的软件发布 敏捷的团队: 自主管理 自我组织 多功能型 敏捷流程的经验教训: 敏捷宣言表明的是一些优先级 Scrum Master不是一个官,而是一个没有执行权力的沟通者 一

一站式大数据敏捷分析平台

OpenFEA是一站式大数据敏捷分析系统,融合了内存计算.集群运算.机器学习.交互分析.可视化分析等技术,涵盖数据收集.数据探索.构建模型.模型发布等功能,分析性能卓越,使用简便,无需复杂编程即可快速实现大数据分析,助力数据分析师激扬数据,塑造业务标杆.          数据收集         OpenFEA能够融合更多类型的数据来进行运算,支持关系型数据源. Hadoop数据源.数据文件.第三方数据源. 支持数据源与接口/格式的双向自定义机制.表示各种复杂结构或LOAD和STORE各类数据

《敏捷开发的45个习惯》

开篇第一句:continuous development,not episodic. 1以迭代的方式工作: 缺定一小块时间的计划,按时完成他们. 2态度决定一切 a指责不能解决bug b欲速不达:普通的码农不理解那块代码,只要能够工作就好,要么直接复制,要么直接调用.优秀的程序员会深挖一层,想明白会产生什么影响. (防微杜渐,别想着快速修补) (不要孤立编代码,实行代码复审) (使用单元测试,每一快都能测试) c对事不对人 (消极扼杀创新  团队仲裁机制) d排除万难(如何维护别人的代码.还是自

敏捷软件开发简述

前言:由于我读了邹欣老师的<构建之法:现代软件工程(第二版)>,因此对敏捷软件开发有了比较大的兴趣.于是我在网上找了一些论文,比如Requirements Engineering and Agile Software Development.A decade of agile methodologies: Towards explaining agile software development.在读了这些论文之后,对敏捷软件开发有了大致的了解.这篇博文主要是简单介绍敏捷软件开发,重点集中在主

敏捷软件开发VS传统软件工程

敏捷软件开发:又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新兴软件开发方法,是一种应对快速变化的需求的一种软件开发能力. 与传统软件工程相比,它们的具体名称.理念.过程.术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作.面对面的沟通(认为比书面的文档更有效).频繁交付新的软件版本.紧凑而自我组织型的团队.能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中"人"的作用. 本文将介绍敏捷软件开发的历史背景与发展,

用户故事与敏捷方法①

在读这本书之前,自己觉得有点好奇,用户故事指的是什么呢,读完之后,有了体会:用户故事描述了对用户.系统或者软件购买者有价值的功能.它由3方面组成:1>一份书面的故事描述,用来做计划和作为提示:2>有关故事的对话,用于具体化故事细节:3>测试,用于表达和编档故事细节且可用于确定故事何时完整. 它总共分为了五大部分来介绍: 第一部分是一些简单的概念或者使用故事的细节方面,比如如何编制用户故事,有哪些细节要求:在故事中找出用户角色模拟使用情节:怎样搜集到用户故事,通过各种途径:如何找到用户代理

敏捷开发

学习内容: 敏捷开发 Agile Development 是一种软件开发流程,开发方法,能够知道我们按照规定的环节一步步的去完成项目的开发任务,主要驱动核心是人,采用的是迭代式的开发. 是相对于瀑布开发模式的缺点改进的一种开发模式,就是把一个大项目切分成多个子项目,然后分别开发.测试. 是以用户的需求变化为核心,采用迭代和循序渐进的方式进行软件开发. 四句开发宣言: 个体和互动  胜过     流程和工具 可用的软件    胜过     详尽的文档 客户合作 胜过     合同谈判 响应变化  

利用敏捷开发的原则开发自己的大学生校园博客系统

  敏捷开发原则 我们的做法 1 尽早并持续交付有价值的软件以满足顾客需求 软件暂时未完成,但目前已经交付某些文档,可以通过文档与用户进行交互. 2 欢迎需求的变化,并利用这种变化来提高用户的竞争优势 不时向同学询问或自我思考看自己所要做的能否使大学生满意. 3 经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 由于我们的项目是要求在一个月内进行交付,所以我们并没有进行软件的交付,但是我们每周都会交一些设计文档,对项目及完成进度进行说明. 4 业务人员和开发人员在项目开发过程中应该每天共

&quot;产品测试管理&amp;敏捷项目管理&quot;研讨会在深圳成功举办!

2015年1月9日,由深圳市共创力企业管理咨询发起的"产品测试管理&敏捷项目管理"研讨会在深圳南山科技园创新谷咖啡成功举办!参加此次研讨会的企业有华为.中兴.烽火.腾讯.康佳.OPPO.元征.神视检测等高新企业管理人员,研讨会由研发资深顾问杨学明先生主持.此次会议的议程如下: 2016.1.9 10:10~11:00 由华为员工分享敏捷项目管理实践  2016.1.9 11:00~12:00 由元征科技分享IPD模式下的测试管理  2016.1.9 12:00~13:00 午餐

2016年开篇 - 敏捷与成果经济

Manifesto for Agile Software Development 敏捷软件开发宣言 Individuals and interactions over processes and tools 个体和互动 高于 流程和工具 Working software over comprehensive documentation 工作的软件 高于 详尽的文档 Customer collaboration over contract negotiation 客户合作 高于 合同谈判 Resp