敏捷软件开发方法论_什么是敏捷方法论? 现代软件开发讲解

敏捷软件开发方法论

如今,每个技术组织似乎都在为软件开发或它的一种版本实践敏捷方法。 或者至少他们相信他们这样做。 无论您是敏捷应用程序开发的新手还是几十年前使用瀑布式软件开发方法学过的软件开发,如今,您的工作至少都受到敏捷方法论的影响。

但是什么是敏捷方法论?在软件开发中应如何实践? 实践中,敏捷开发与瀑布有何不同? 什么是敏捷软件开发生命周期或敏捷SDLC? 与看板和其他敏捷模型相比,Scrum敏捷是什么?

[ DevSecOps:如何将安全性引入敏捷开发和CI / CD ]

敏捷于2001年正式启动,当时有17位技术专家起草了敏捷宣言 。 他们编写了敏捷项目管理的四项主要原则,旨在开发更好的软件:

  • 个人与流程和工具之间的互动
  • 通过全面的文档工作软件
  • 客户合作而非合同谈判
  • 响应计划变更

敏捷之前:瀑布方法论的时代

像我这样的老手记得瀑布式方法成为软件开发的金标准的时代。 在开始任何编码之前,软件开发过程需要大量的文档。 通常是业务分析师的人首先编写了业务需求文档,该文档捕获了应用程序中所需的所有业务。 这些业务需求文档很长,详细介绍了所有内容:总体策略,全面的功能规格以及可视用户界面设计。

技术人员获取了业务需求文档并开发了自己的技术需求文档。 本文档定义了应用程序的体系结构,数据结构,面向对象的功能设计,用户界面和其他非功能性要求。

这个瀑布式软件开发过程将最终开始编码,然后进行集成,最后进行测试,然后再将应用程序视为生产就绪。 整个过程可能需要花费几年时间。

我们希望开发人员像完整的文档一样被称为“规范”,就像文档的作者一样。如果我们忘记正确地实施200-200的第77页概述的关键细节,我们常常会受到责备。页面文档。

那时,软件开发本身也不容易。 许多开发工具都需要经过专门的培训,并且当今没有开源或商业软件组件,API和Web服务。 我们必须开发低级的东西,例如打开数据库连接和对数据处理进行多线程处理。

对于基本应用程序来说,团队很大,而通讯工具却很有限。 我们的技术规格是使我们保持一致的要素,我们像圣经一样利用它们。 如果需求发生变化,我们将让业务领导者进行漫长的审查和签字,因为在团队中沟通变更和确定代码非常昂贵。

由于该软件是基于技术架构开发的,因此首先开发了较低级别的工件,然后才开发了相关工件。 任务是由技能分配的,数据库工程师通常首先构造表和其他数据库工件,然后由应用程序开发人员对功能和业务逻辑进行编码,然后再覆盖用户界面。 几个月后,任何人都无法看到该应用程序正常运行,到那时,利益相关者变得烦躁不安,通常对他们真正想要的东西更加精明。 难怪实施更改如此昂贵!

并非您摆在用户面前的所有内容都能按预期工作。 有时,用户根本不会使用任何功能。 有时,一项功能大获成功,但需要重新设计以支持必要的可伸缩性和性能。 在瀑布式世界中,您只有在部署软件之后,经过漫长的开发周期后才了解这些知识。

相关视频:敏捷方法的真正作用

似乎每个人都在谈论敏捷软件开发,但是许多组织对流程的运作方式没有把握。 观看这五分钟的视频,以加快速度。

敏捷软件开发的关键

瀑布式方法于1970年发明,具有革命性,因为它为软件开发带来了规范,以确保遵循明确的规范。 它基于从亨利·福特(Henry Ford)的1913年装配线创新中获得的瀑布式制造方法,该方法为生产过程的每个步骤提供了确定性,以确保最终产品与最初指定的产品相匹配。

[ 同样在InfoWorld上:启动devops程序的3种方法 ]

当瀑布方法论进入软件世界时,计算系统及其应用程序通常是复杂且整体的,需要纪律和明确的结果才能交付。 与今天相比,需求的变化也很缓慢,因此大规模的工作没有那么多问题。 实际上,系统是在假设它们不会改变而是永久的战列舰的前提下建造的。 多年的时间框架不仅在软件开发中很常见,在制造业和其他企业活动中也很常见。 但是,瀑布式的刚性成为互联网时代的致命弱点,因为互联网时代要求速度和灵活性。

当开发人员开始处理Internet应用程序时,软件开发方法就开始发生变化。 许多早期工作是在团队较小,位于同一地点且通常没有传统计算机科学背景的初创公司完成的。 财务和竞争压力迫使网站,应用程序和新功能更快地推向市场。 开发工具和平台响应Swift变化。

这导致我们中的许多人在初创公司中工作,以质疑瀑布式方法论并寻找提高效率的方法。 我们无力承担所有详细的文档,因此我们需要一个更加迭代和协作的过程。 我们仍然在讨论对要求的更改,但是我们更愿意进行试验并适应最终用户的需求。 与企业遗留系统相比,我们的组织结构更少,我们的应用程序也没有那么复杂,因此与购买应用程序相比,我们对构建更加开放。 更重要的是,我们正在尝试发展业务,因此当我们的用户告诉我们某件事不起作用时,我们通常会选择不听他们的话。

我们的技能和创新能力在战略上变得至关重要。 您可以筹集所需的全部资金,但是如果您打算按照“规范”将它们视为从属编码人员,您将无法吸引能够与快速变化的互联网技术合作的软件开发人员。 我们拒绝了提供端到端时间表的项目经理,这些时间表描述了我们应该开发什么,何时发布应用程序,有时甚至是如何构造代码。 我们很难达到瀑布项目经理起草并不断更新的三个月和六个月的时间表。

取而代之的是,我们开始告诉他们如何设计Internet应用程序,并按迭代制定的时间表提供结果。 事实证明,当我们兑现承诺(每隔一周到四周一次)时会做到的话,我们并不差劲。

在2001年,一群经验丰富的软件开发人员聚在一起,意识到他们正在集体实践不同于经典瀑布方法的软件开发。 而且它们并非全部都在初创公司中。 这个包括技术专家Kent Beck,Martin Fowler,Ron Jeffries,Ken Schwaber和Jeff Sutherland的小组提出了“ 敏捷宣言” ,记录了他们对现代软件开发过程应该如何运作的共同信念。 他们强调在文档,自组织而不是严格的管理实践方面的协作,以及在不断变化而不是将自己锁定在严格的瀑布式开发过程中的能力。

从这些原则中诞生了软件开发的敏捷方法论。

敏捷方法中的角色

敏捷软件开发过程始终始于定义用户并记录有关要解决的问题,机会和价值范围的愿景声明。 产品负责人抓住了这一愿景,并与一个或多个多学科团队合作实现了这一愿景。 以下是该过程中的角色。

用户

敏捷过程始终始于用户或客户。 今天,我们经常用用户角色来定义它们,以说明软件所支持的工作流程中的不同角色或不同类型的客户需求和行为。

产品拥有者

敏捷开发过程本身始于要求包括客户内部利益相关者在内的客户的声音。 该人会提炼所有见解,想法和反馈以创建产品愿景。 这些产品愿景通常是简短而直接的,但是它们描绘了客户是谁,正在解决的价值以及如何解决这些问题的策略。 我可以想象Google的原始愿景看起来像是“让具有互联网访问权限的任何人都可以使用简单的关键字驱动界面和一种算法,在搜索结果中将信誉良好的来源排名较高,从而轻松地找到相关的网站和网页。”

我们称此人为产品负责人 。 他或她的责任是定义此愿景,然后与开发团队合作使其实现。

为了与开发团队合作,产品负责人将产品愿景分解为一系列用户故事 ,这些故事更详细地说明了目标用户是谁,正在为他们解决什么问题,解决方案为什么对他们很重要以及什么约束和接受标准定义了解决方案。 这些用户故事由产品所有者确定优先级,并由团队进行审查,以确保他们对所要询问的内容有共同的理解。

软件开发团队

在敏捷中,开发团队及其成员的职责与传统软件开发中的职责不同。

团队是多学科的,由具有完成任务的技能的不同人群组成。 因为重点是交付工作软件,所以团队必须完成端到端的功能应用程序。 因此,开发,然后演示了应用程序一部分的数据库,业务逻辑和用户界面,而不是整个应用程序。 为此,团队成员必须合作。 他们经常会面,以确保每个人都对他们正在构建的内容,谁在做什么以及精确地开发软件保持一致

除开发人员外,软件开发团队还可以包括质量保证(QA)工程师,其他工程师(例如数据库和后端系统),设计师和分析师,具体取决于软件项目的类型。

[ 也在InfoWorld上:如何通过左移测试改善CI / CD ]

Scrum,看板和其他敏捷框架

许多敏捷框架提供了有关软件开发生命周期的开发流程和敏捷开发实践的详细信息。

最流行的敏捷框架称为scrum 。 它关注于称为sprint和会议结构的交付节奏,包括以下内容:

  • 规划-确定冲刺优先级
  • 承诺-团队审查用户故事的列表或待办事项,并确定在sprint持续时间内可以完成多少工作
  • 每日站立会议-团队可以交流其发展状况和策略的最新信息)

Sprint会在演示会上结束,在演示会上向产品所有者展示该功能,然后在回顾会议上,团队讨论进展顺利的过程以及需要改进的过程。

许多组织雇用Scrum管理员或教练来帮助团队管理Scrum流程。

尽管Scrum占主导地位,但还有其他敏捷框架:

  • 看板是一个扇入和扇出的过程,在该过程中,团队从入口板上提取用户故事,并通过分阶段的开发过程将其归纳,直到完成。
  • 一些组织采用混合敏捷和瀑布方法,将敏捷过程用于新应用程序,将瀑布用于旧应用程序。
  • 还有一些框架可以使组织将实践扩展到多个团队

尽管敏捷框架定义了流程和协作,但是敏捷开发实践特定于解决与敏捷框架保持一致的软件开发任务。

因此,例如:

  • 一些团队采用结对编程,其中两个开发人员一起编码以驱动更高质量的代码,并使更多的高级开发人员可以指导初级开发人员。
  • 更高级的团队采用测试驱动的开发和自动化来确保基础功能能够提供预期的结果。
  • 许多团队还采用技术标准,以便开发人员对用户故事的解释不仅能带来所需的功能,而且还满足安全性,代码质量,命名约定和其他技术标准。

为什么敏捷方法更好

翻译自: https://www.infoworld.com/article/3237508/what-is-agile-methodology-modern-software-development-explained.html

敏捷软件开发方法论

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目录   译者序   第2版前言   第1版前言   第0章不可知和不可说   0.1和解析体验相关的问题   0.1.1解析模式的冲突   0.1.2检测解析模式   0.1.3思考不准确的思想   0.2沟通的不可能性   0.2.1内部重新组织   0.2.2触及共享体验   0.2.3管理不完美的沟通   0.3聆听的三个层次   0.3.1三个层次和方法集   0.3.2三个层次与本书   0.3.3守-破-离   0.4那么,明天我做什么   第0A章不可知和不可说:演进   0A.1沟通和共享的体验   0A.2守-破-离   第1章创造和沟通的合作博弈   1.1软件和诗歌   1.2软件与博弈   1.2.1博弈的类型   1.2.2软件与攀岩   1.2.3创造和沟通的博弈   1.2.4软件与工程化   1.2.5软件与模型构建   1.3再论合作博弈   1.3.1程序员成为沟通专家   1.3.2更快地博弈   1.3.3标识物和道具   1.3.4减少回报   1.3.5对于首要目标的充分度   1.3.6对于积淀的充分度   1.3.7博弈中的博弈   1.3.8开放源码开发   1.4这对我意味着什么   第1A章创造和沟通的合作博弈:演进   1A.1沼泽游戏   1A.2合作中的竞争   1A.3其他领域的合作博弈   1A.4软件工程的重建   1A.4.1这一词汇从哪里来   1A.4.2我们从哪里走错了   1A.4.3重建软件工程   1A.4.4技艺   1A.4.5合作博弈   1A.4.6精益制造   1A.4.7重建后的软件工程   1A.4.8其他工程化中的协作   第2章个人   2.1人是古怪的   2.1.1寻找特征函数   2.1.2古怪性格的元素   2.1.3不可避免的多样性   2.1.4技术的作用   2.1.5相互冲突的共同点   2.2克服失败模式   2.2.1犯错误   2.2.2宁可失败也要选择保守   2.2.3创新而不研究   2.2.4不能始终如一的习惯动物   2.2.5使用纪律和容忍来应对   2.3以一些更好的方式工作   2.3.1具体化   2.3.2实物   2.3.3在某些东西的基础上进行修改   2.3.4观察和聆听   2.3.5支持专注和沟通   2.3.6工作分配要与个性相匹配   2.3.7天赋   2.3.8奖励要能保留乐趣   2.3.9组合奖励   2.3.10反馈   2.4利用成功模式   2.4.1善于四处寻找   2.4.2人们学习   2.4.3可塑性   2.4.4贡献和采取主动   2.4.5组合成功模式   2.4.6英雄也是普通人   2.5明天我该做什么   第2A章个人:演进   2A.1策略平衡   第3章团队的沟通与合作   3.1信息的对流   3.1.1延迟和机会损失成本   3.1.2尔格-秒   3.1.3渗透式沟通   3.1.4穿堂风   3.1.5信息辐射源   3.1.6热空气理论的应用   3.2跨越沟通的鸿沟   3.2.1沟通的形态   3.2.2去掉某些形态所产生的影响   3.2.3利用各种形态   3.2.4黏度与跨越空间的鸿沟   3.3团队就是集体   3.3.1友善和冲突   3.3.2工作时间的公民意识   3.3.3敌意的XP与友善的XP   3.3.4使用胜利来建立“团队”   3.3.5团队文化与亚文化   3.4团队就是生态系统   3.5我明天该做什么   第3A章团队:演进   3A.1一个修订后的办公室布局样本   第4章方法集   4.1一个交付软件的生态系统   4.2方法集中的概念   4.2.1结构术语   4.2.2范围   4.2.3概念术语   4.2.4发布一个方法集   4.3方法集的设计原则   4.3.1常见设计错误   4.3.2在方法集上成功的项目   4.3.3与作者的相关性   4.3.4七条原则   4.4细看XP   4.4.1XP简介   4.4.2剖析XP   4.4.3调整XP   4.5到底为什么使用方法集   4.5.1方法集解决什么问题   4.5.2如何评估一个方法集   4.6明天我应该做什么   第4A章方法集:演进   4A.1方法集与策略   4A.2组织级的方法集   4A.3过程就是循环   4A.4更简单地描述方法集   第5章敏捷与自适应   5.1轻但足够   5.1.1刚好足够   5.1.2对于编制文档的建议   5.2敏捷   5.2.1最佳击球点   5.2.2虚拟团队的麻烦   5.3变得自适应   5.3.1不厌其烦地进行反思   5.3.2方法集成长技术   5.3.3反思研讨会技术   5.4明天我该做什么   第5A章敏捷与自适应:演进   5A.1对于寓意的误解   5A.1.1迭代必须简短   5A.1.2敏捷团队必须驻扎在一起   5A.1.3敏捷团队不需要计划   5A.1.4架构已死;重构是你全部所需要的   5A.1.5我们不需要什么经理   5A.1.6敏捷开发在纪律上要求很低   5A.1.7敏捷只适合最优秀的开发人员   5A.1.8敏捷是既老又新的、失败的、没有尝试过的   5A.2敏捷方法集的演进   5A.2.1XP第2版   5A.2.2Scrum   5A.2.3实用主义和无名的   5A.2.4可预测、计划驱动和其他中心调整   5A.2.5约束理论   5A.2.6精益开发   5A.3新的方法集话题   5A.3.1敏捷项目管理   5A.3.2测试   5A.3.3用户体验设计   5A.3.4规划管控、Burn图和系统工程   5A.3.5用例和用户故事   5A.4经久不绝的问题   5A.4.1最佳击球点和下降   5A.4.2固定价格、固定范围的合同   5A.4.3敏捷、CMMI和ISO9001   5A.4.4何时停止建模   5A.4.5高科技/高接触的工具箱   5A.4.6敏捷的中心   5A.4.7你有多敏捷   5A.4.8引入敏捷   5A.5软件开发之外的敏捷   5A.5.1项目组合管理   5A.5.2客户关系   5A.5.3合同   5A.5.4将变更引入组织   5A.5.5程序员读哈佛商业周刊   5A.5.6建造房屋   5A.5.7机场建设   5A.5.8图书出版   5A.5.9会议组织和敏捷模型的限制   第6章Crystal方法集   6.1对Crystal家族塑形   6.1.1核心Crystal元素   6.2CrystalClear   6.2.1CrystalClear的简要描述   6.2.2CrystalClear的反思   6.3CrystalOrange   6.3.1CrystalOrange的简要描述   6.3.2CrystalOrange的反思   6.4CrystalOrangeWeb   6.4.1CrystalOrangeWeb的简要描述   6.4.2CrystalOrangeWeb的反思   6.5明天我该做什么   第6A章Crystal方法集:演进   6A.1Crystal基因代码   6A.1.1合作博弈的理念   6A.1.2方法集的重点   6A.1.3方法集设计原则   6A.1.4高度成功的项目的7个特性   6A.1.5技术与选择   6A.1.6样本方法集设计   6A.2CrystalClear   6A.3把CrystalClear扩展到Yellow   附录A敏捷软件开发宣言   附录Aa敏捷软件开发宣言和相互依赖声明   附录BNaur、Ehn、宫本武藏   附录BaNaur、Ehn、宫本武藏:演进   附录C后记   参考文献

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值