敏捷方法软件开发生命周期: 优点和缺点

Scrum 同时被 2 个专栏收录
135 篇文章 1 订阅
154 篇文章 5 订阅

敏捷SDLC模型是迭代和增量流程模型的组合,通过快速交付工作软件产品,专注于流程适应性和客户满意度。敏捷方法将产品分解为小型增量构建。这些构建在迭代中提供。每次迭代通常持续大约一到三周。每次迭代都涉及跨职能团队同时在各个领域工作,如 -

  • 规划 (Planning)
  • 需求分析 (Requirement Analysis)
  • 设计 (Design)
  • 编码 (Building)
  • 单元测试和 (Testing)
  • 验收测试。(Acceptance)

iterative agileçåçæå°çµæ

在迭代结束时,向客户和重要的利益相关者显示工作产品。

什么是敏捷?

敏捷模型认为每个项目都需要以不同方式处理,现有方法需要根据项目要求进行定制。在Agile中,任务分为时间框(小时间框架),以便为发布提供特定功能。

采用迭代方法,并在每次迭代后提供工作软件构建。每个构建在功能方面都是增量的; 最终版本包含客户所需的所有功能。

以下是敏捷模型的图解说明 -

 

敏捷思维过程在软件开发的早期就开始了,并且由于其灵活性和适应性而开始变得流行。

最流行的敏捷方法包括Rational Unified Process(1994),Scrum(1995),Crystal Clear,Extreme Programming(1996),Adaptive Software Development,Feature Driven Development和Dynamic Systems Development Method(DSDM)(1995)。在敏捷宣言于2001年出版后,这些现在统称为敏捷方法论

以下是敏捷宣言原则 -

agile manifestoçåçæå°çµæ

  • 个人和互动 - 在敏捷开发中,自组织和动机很重要,共同定位和结对编程等互动也很重要。

  • 工作软件 - 演示工作软件被认为是与客户沟通以了解其要求的最佳方式,而不仅仅是依赖于文档。

  • 客户协作 - 由于各种因素无法在项目开始时完全收集需求,因此持续的客户交互对于获得适当的产品要求非常重要。

  • 应对变化 - 敏捷开发的重点是快速响应变化和持续发展。

敏捷与传统SDLC模型

Agile基于自适应软件开发方法,而传统的SDLC模型(如瀑布模型)基于预测方法。传统SDLC模型中的预测团队通常使用详细的计划,并完整预测未来几个月或产品生命周期中要交付的确切任务和功能。

预测方法完全取决于在周期开始时进行的需求分析和计划。要纳入的任何变更都要经过严格的变更控制管理和优先排序。

敏捷使用自适应方法,没有详细的规划,只有在需要开发哪些功能时才能明确未来的任务。有功能驱动的开发,团队动态地适应不断变化的产品需求。通过发布迭代,该产品经常进行测试,从而最大限度地降低未来发生重大故障的风险。

客户交互是这种敏捷方法的支柱,而使用最少文档的开放式通信是敏捷开发环境的典型特征。敏捷团队彼此密切合作,通常位于同一地理位置。

敏捷模型 - 优点和缺点

敏捷方法最近在软件世界中被广泛接受。但是,这种方法可能并不总是适用于所有产品。以下是敏捷模型的一些优缺点。

敏捷模型的优点如下 -

  • 是一种非常现实的软件开发方法。

  • 促进团队合作和交叉培训。

  • 功能可以迅速发展并得到证明。

  • 资源要求最低。

  • 适合固定或变化的要求

  • 提供早期部分工作解决方案。

  • 适用于稳定变化的环境的良好模型。

  • 最小的规则,易于使用的文档。

  • 在整体计划环境中实现并发开发和交付。

  • 很少或根本不需要计划。

  • 易于管理。

  • 为开发人员提供灵活性。

敏捷模型的缺点如下 -

  • 不适合处理复杂的依赖项。

  • 可持续性,可维护性和可扩展性的风险更大。

  • 总体规划,敏捷领导者和敏捷的PM实践是必须的,如果没有它,它将无法工作。

  • 严格的交付管理决定了范围,要交付的功能以及满足截止日期的调整。

  • 在很大程度上取决于客户互动,因此如果客户不清楚,团队可能会被推向错误的方向。

  • 由于生成的文档最少,因此存在非常高的个人依赖性。

  • 由于缺乏文档,技术转让给新的团队成员可能非常具有挑战性。

敏捷的商业利益


敏捷管理可降低与项目交付,范围和预算相关的常见风险。

它鼓励客户和团队之间的协作 ; 在缓解软件开发过程中的高风险方面提供互惠互利。
什么是æ•æ·ï¼Œæ•æ·ï¼Œä»€ä¹ˆæ˜¯æ•æ·æ–¹æ³•è®ºï¼Œæ•æ·æ–¹æ³•è®º

2009年,David F Rico博士将Agile与传统的软件项目管理方法进行了比较。在他的研究和综合过程中,他分析了23个敏捷过程,并将它们与7,500个传统项目进行了比较。

他发现敏捷项目有20项好处:

41%的整体业务价值更好
83%的人表现出更快的上市时间
50%的质量更高
50%的成本更低
83%的人更有效率


其他 scrum 文章

敏捷宣言和十二項原則

All Agile Software Development Methodologies (SCRUM, Kanban, XP) contain the Agile Manifesto (Core Values) and 12 Agile Principles, which represent a set of values to guide people in an organization how to behave with each other. ( 所有敏捷軟件開發方法(SCRUM,看板,XP)都包含敏捷宣言(核心價值觀)和12個敏捷原則,它們代表了一系列價值觀,用於指導組織中的人們如何相互行事。)

Timeboxing 在 Scrum中是什么含义?

The goal of timeboxing is to define and limit the amount of time dedicated to an activity. Scrum uses timeboxing for all of the Scrum events and as a tool for concretely defining open-ended or ambiguous tasks. (时间装箱的目标是定义和限制专用于活动的时间量。scrum 将时间装箱用于所有 scrum 事件, 并用作具体定义无期限或不明确任务的工具。)

极限编程(XP)vs Scrum

Scrum is a framework for product development, which is a container where you can add other practices. XP is one of those practices that you can do within Scrum framework. This article shows you the similarities and differences between them and there are no reasons why a team need choose between Scrum and XP exclusively. (Scrum是一个产品开发框架,它是一个容器,您可以在其中添加其他实践。XP是可以在Scrum框架内完成的实践之一。本文向您展示了它们之间的相似性和差异,并且没有任何理由说明团队需在Scrum和XP之间进行选择。)

精益生产中的8种浪费 – 如何定义?

A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste. This article shows you how to identify those wastes (精益组织了解客户价值, 并专注于其关键流程以不断提高客户价值。最终目标是通过一个零浪费的完美价值创造过程, 为客户提供完美的价值。本文向您展示了如何识别这些浪费)

最好的免费和商业敏捷工具 – 每个Scrum团队都需要

In this article you will get a list of 10 latest and efficient Agile Project Management tools that would help your team in the entire scrum development process. You need some agile toolset for enhancing the productivity of your team and help ease the pain points even if you have remote employees. (在本文中,您将获得10个最新,最有效的敏捷项目管理工具列表,这些工具可以帮助您的团队完成整个Scrum开发过程。您需要一些敏捷的工具集来提高团队的工作效率, 并帮助缓解难题, 即使您有远程员工也没关系。)

为什么选择Scrum?Scrum如何克服我们总是面临的8个痛点?

What you need to know in a nutshell — the 8 pain points we most often see in Scrum project planning and analysis. This article shows you how to using Scrum and Agile to overcome them. (你需要知道的是–scrum 项目规划和分析中我们最常看到的8个痛点。本文向您展示了如何使用 scrum 和敏捷来克服它们。)

什么是Scrum框架中的3355?

using four simple facts (3355) to help us to understand and recap the key concepts of scrum (使用四个简单的事实(3355)来帮助我们理解和概括Scrum的关键概念)

Scrum vs 瀑布 vs 敏捷 vs 精益 vs 看板

There are a number of different approaches in the software development industry – some are new takes on old methods and others have adapted a relatively new approach. The two most commonly used methods in this field are the Agile such as, Scrum, Kanban and Lean and etc., and traditional Waterfall models such as structured methods or newer RUP. ( 软件开发行业有许多不同的方法 - 一些是旧方法的新方法,另一些方法采用了相对较新的方法。该领域中最常用的两种方法是敏捷,如Scrum,Kanban和Lean等,以及传统的瀑布模型,如结构化方法或更新的RUP。大多数遵循这两种模式的软件公司都认为他们选择的方法在方面是优越的,所以在我们回答这个问题之前,“哪一个更成功?我们应该看看它们的主要区别。)

如何保持Scrum的透明度?

Transparency is vital to the Scrum process, as it allows everyone to see and understand what is really happening in each sprint, achieving a bigger and better communication and trust on the team and in this methodology. This Article shows you how to do it. ( 透明性对于Scrum过程至关重要,因为它允许每个人看到和理解每个Sprint中实际发生的事情,从而在团队和这种方法中实现更大、更好的沟通和信任。这篇文章向您展示了如何做到这一点。)

Scrum: 经验过程控制vs定义过程控制

In empirical process control, you expect the unexpected. With defined process control, every piece of work is understood. In Scrum, an empirical process is implemented where progress is based on observation and experimentation instead of detailed, upfront planning and defined processes. (在经验过程控制中,你期待着意想不到的结果。通过定义的过程控制,可以理解每一件工作。在Scrum中,实现了一个经验过程,其中进度是基于观察和实验,而不是详细的预先规划和定义的过程。)

  • 2
    点赞
  • 0
    评论
  • 8
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

目录   译者序   第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方法集成长技术  
©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值