敏捷软件开发之开篇

在软件项目管理中,软件开发实践一直在追求一种在业务需求,当前技术能力与能最大程度提高开发人员效率的方法之间的一种平衡,敏捷软件开发方法也不例外。在了解敏捷开发方法之前需要清楚敏捷宣言。

敏捷宣言

它描述了一组软件开发方法的关键价值,也是敏捷软件开发方法所遵守的原则。其具体内容如下:

个人与互动 大于 流程与工具
可用的软件 大于 文档
与客户的合作 大于 合约和商定
响应变化 大于 遵循计划

敏捷宣言所描述的软件开发方法具有更快速,更轻型的特点;它解决了传统瀑布软件开发方法和迭代,递增方法的一些缺陷。

目前常用的敏捷软件开发方法如下:

  • scrum
  • XP(极限编程)
  • 功能驱动开发
  • Clear case
  • 自适应软件开发

虽然这些软件开发方法的实现方式完全不同,但是他们具有如下的共同特征:

  • 都将团队内部的交流放在优先地位,即鼓励开发人员,业务用户和测试人员经常交流。
  • 注重项目的透明性;开发团队不是生存在一个黑盒中,不能向团队的其他成员隐藏自己的行为,都是用非常公开的工具来保证团队成员能够获得足够的信息
  • 团队成员都是相互负责的;团队不会因为某一个人而成功或失败;他们的成功与失败是按整个团队来衡量的
  • 开发人员没有自己的codebase,整个团队拥有完整的codebase,每个人都对其质量负责
  • 工作是在短暂的开发周期中完成的,理想情况下,每个周期结束时会发布。
  • 应对变化的能力是这种方法的基础
  • 一个系统的大致框架是提前定义的,但详细设计要等到实际安排功能开发计划时才会进行

敏捷软件开发之开篇

时间: 2024-10-08 20:59:23

敏捷软件开发之开篇的相关文章

敏捷软件开发简述

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

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

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

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

一.   传统软件工程 从上个世纪60年代开始,人们开始逐渐认识到了确实存在着"软件危机" 这样一个事实,软件开发人员被诸如下列问题困扰: 软件生产不能满足日益增长的需要 软件开发成本和开发进度估计往往不准确 软件开发人员和用户之间信息交流不充分,用户对完成的软件满意度很低 软件价格昂贵,软件成本在整个计算机系统中所占的比例急剧上升,软件已成为许多计算机系统中花钱最多的项目 软件质量难以保证 软件可维护性差,程序中的错误很难改正,适应性或完善性维护都极其困难 导致危机问题的一个重要原因

敏捷软件开发?什么是敏捷?

敏捷软件开发?什么是敏捷? 敏捷开发(Agile development)是如今软件工程项目中一个大热的词汇,很多大大小小的开发团队都喜欢高举敏捷开发的旗号,搞出一套显得大大不同于传统的运行模式来区分自己的团队博取眼球,他们手头所做的事情,只是套用一套流行的敏捷开发模板,如Scrum,Crystal,XP到自己的开发流程中,就认为自己的整个开发体系会有一个质的飞越.然而他们是否能真正驾驭所谓的敏捷开发?他们是否理解了敏捷开发的核心理念?这都是要划一个大大的问号. 笔者我在刚刚接触这个词的时候,下

软件工程:传统软件工程 vs 敏捷软件开发

前言 软件工程(Software Engineering): 是一种层次化技术. 将系统化的.规范的.可量化的方法应用于软件的开发.运行和维护,即将工程化的方法应用于软件. 研究"建立和使用一套合理的工作原则,以便经济地获得可靠的.可以在实际机器上高效运行的软件"的方法. 敏捷软件开发(Agile software development): 一种应对快速变化的需求的一种软件开发方法.基于迭代和增量开发,通过自组织,跨团队,沟通协作完成开发工作. 一.传统软件工程 (一)产生背景 随着

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

敏捷软件开发与传统软件工程 北航计算机学院 14061157 李奕成 引言 软件开发过程是软件工程中相当重要的一环.一个正确.高效的软件过程能够提高软件工程活动的稳定性.可控性和有组织性.但是,并不存在一种软件过程能够完美的适应所有的软件工程情况.因此,在不同情况下选择合适的软件开发过程显得尤为重要.现代软件工程方法必须是"灵活"的,也就是要求软件工程活动.控制以及工作方法适合于项目团队和要开发的产品. 说到软件工程.敏捷开发,就要提到软件过程的发展历史.20世纪60年代,不存在现代意

敏捷软件开发 – OCP 开放-封闭原则

软件实体(类.模块.函数等)应该是可以扩展的,但是不可修改的. 如果程序中的一处改动就会产生连锁反应,导致一系列相关模块的改动,那么设计就具有僵化性的臭味.OCP建议我们应该对系统进行重构,这样以后对系统再进行这样那样的改动时,就不会导致更多的修改.如果正确地应用OCP,那么以后再进行同样的改动时,就只需要添加新的代码,而不必改动已经正常运行的代码. OCP概述 遵循开放-封闭原则设计出的模块具有两个主要的特征.它们是: 对于扩展是开放的(open for extension).这意味着模块的行

敏捷软件开发 – SRP 单一职责原则

SRP:单一职责原则  一个类应该只有一个发生变化的原因. 为何把两个职责分离到单独的类中很重要呢?因为每一个职责都有变化的一个轴线.当需求变化时,该变化会反映为类的职责的变化.如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个. 如果一个类承担的职责过多,就等于把这些职责耦合在了一起.一个职责发生变化可能会削弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 有两个不同的应用程序使用Rectangle类.一个应用程序是有关计算几何

敏捷软件开发:原则、模式与实践——第10章 LSP:Liskov替换原则

第10章 LSP:Liskov替换原则    Liskov替换原则:子类型(subtype)必须能够替换掉它们的基类型(base type). 10.1 违反LSP的情形 10.1.1 简单例子 对LSP的违反导致了OCP的违反: struct Point { double x, y;} public enum ShapeType { square, circle }; public class Shape { private ShapeType type; public Shape(Shape