Skip to main content

敏捷软件开发

敏捷软件开发又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方 法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧 密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也 更注重软件开发中人的作用。
软件开发
软件开发步骤
需求分析 | 软件架构 | 软件设计 | 软件编程 | 软件测试 | 软件部署
软件开发模式
敏捷开发 | 无尘室 | 迭代式开发 | RAD | 统一过程 | 螺旋模型 | 瀑布模型 | 极限编程 | Scrum
软件开发辅助领域
配置管理 | 文档编写 | 质量管理 | 项目管理 | 使用者经验设计
软件开发工具
编译器 | 除错器 | 性能分析 | GUI设计 | 集成开发环境

目录

词源

敏捷一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者(他们发起组成了敏捷联盟)的聚会。

价值观

雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述:[1] [2]

借着亲自并协助他人进行软件开发,我们正致力于发掘更优良的软件开发方法。透过这样的努力,我们已建立以下价值观:
  • 人和交互 重于过程和工具。
  • 可以工作的软件 重于求全责备的文档。
  • 客户协作重于合同谈判。
  • 随时应对变化重于循规蹈矩。
其中位于右边的内容虽然也有其价值,但是左边的内容最为重要。

原则

宣言中还包括以下原则:[3] [4]
  • 对我们而言,最重要的是通过尽早和不断交付有价值的软件满足客户需要。
  • 我们欢迎需求的变化,即使在开发后期。敏捷过程能够驾驭变化,保持客户的竞争优势。
  • 经常交付可以工作的软件,从几星期到几个月,时间尺度越短越好。
  • 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
  • 围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务。
  • 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
  • 可以工作的软件是进度的主要度量标准。
  • 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
  • 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
  • 简单——尽可能减少工作量的艺术至关重要。
  • 最好的架构、需求和设计都源自自我组织的团队。
  • 每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为。

对比其他的方法

敏捷方法有时候被误认为是无计划性和纪律性的方法,实际上更确切的说法是敏捷方法强调适应性而非预见性。
适应性的方法集中在快速适应现实的变化。当项目的需求起了变化,团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

对比迭代方法

相比迭代式开发两者都强调在较短的开发周期提交软件,敏捷方法的周期可能更短,并且更加强调队伍中的高度协作。

对比瀑布式开发

两者没有很多的共同点,瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。
瀑布式的主要的问题是它的严格分级导致的自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
相对来讲,敏捷方法则在几周或者几个月的时间内完成相对较小的功能,强调的是能将尽早将尽量小的可用的功能交付使用,并在整个项目周期中持续改善和增强。
有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法,另外的人可能将选择各种工作并行进行,例如极限编程

敏捷方法的适用性

在敏捷方法其独特之处以外,他和其他的方法也有很多共同之处,比如迭代开发,关注互动沟通,减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏 捷方法的适用性:从产品角度看,敏捷方法适用于需求萌动并且快速改变的情况,如系统有比较高的关键性、可靠性、安全性方面的要求,则可能不完全适合;从组 织结构的角度看,组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有:
  • 组织文化必须支持谈判
  • 人员彼此信任
  • 人少但是精干
  • 开发人员所作决定得到认可
  • 环境设施满足成员间快速沟通之需要
最重要的因素恐怕是项目的规模。规模增长,面对面的沟通就愈加困难,因此敏捷方法更适用于较小的队伍,40、30、20、10人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。
另外的问题是项目初期的大量假定或者快速收集需求可能导致项目走入误区,特别是客户对其自身需要毫无概念的情况下。与之类似,人之天性很容易造成某 个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常能把不恰当的方案授予客户,并且直到最后发现问题前都能获得客户认同。虽然理论上快速交互 的过程可以限制这些错误的发生,但前提是有效的负反馈,否则错误会迅速膨胀。

用于敏捷开发团队的项目管理工具

已经有一些项目管理工具用于敏捷开发,可以用它们来帮助规划,跟踪,分析和整合工作。 这些工具在敏捷开发中扮演的重要的角色,也是知识管理的一种方法。
通常包括:版本控制整合,进度跟踪,工作分配,集成发布和迭代规划,论坛和软件缺陷的报告和跟踪。

方法列表

目前列入敏捷方法的有:
  • 软件开发之韵,Software Development Rhythms
  • 敏捷数据库技术,AD/Agile Database Techniques
  • 敏捷建模,AM/Agile Modeling
  • 自适应软件开发,ASD/Adaptive Software Development
  • 水晶方法,Crystal
  • 特性驱动开发,FDD/Feature Driven Development
  • 动态系统开发方法,DSDM/Dynamic Systems Development Method
  • 精益软件开发,Lean Software Development
  • AUP(Agile Unified Process)
  • Scrum
  • XBreed
  • 极限编程XP Extreme Programming
  • 探索性测试

敏捷技术

Comments

Popular posts from this blog

OWASP Top 10 Threats and Mitigations Exam - Single Select

Last updated 4 Aug 11 Course Title: OWASP Top 10 Threats and Mitigation Exam Questions - Single Select 1) Which of the following consequences is most likely to occur due to an injection attack? Spoofing Cross-site request forgery Denial of service   Correct Insecure direct object references 2) Your application is created using a language that does not support a clear distinction between code and data. Which vulnerability is most likely to occur in your application? Injection   Correct Insecure direct object references Failure to restrict URL access Insufficient transport layer protection 3) Which of the following scenarios is most likely to cause an injection attack? Unvalidated input is embedded in an instruction stream.   Correct Unvalidated input can be distinguished from valid instructions. A Web application does not validate a client’s access to a resource. A Web action performs an operation on behalf of the user without checking a shared sec

CKA Simulator Kubernetes 1.22

  https://killer.sh Pre Setup Once you've gained access to your terminal it might be wise to spend ~1 minute to setup your environment. You could set these: alias k = kubectl                         # will already be pre-configured export do = "--dry-run=client -o yaml"     # k get pod x $do export now = "--force --grace-period 0"   # k delete pod x $now Vim To make vim use 2 spaces for a tab edit ~/.vimrc to contain: set tabstop=2 set expandtab set shiftwidth=2 More setup suggestions are in the tips section .     Question 1 | Contexts Task weight: 1%   You have access to multiple clusters from your main terminal through kubectl contexts. Write all those context names into /opt/course/1/contexts . Next write a command to display the current context into /opt/course/1/context_default_kubectl.sh , the command should use kubectl . Finally write a second command doing the same thing into /opt/course/1/context_default_no_kubectl.sh , but without the use of k

标 题: 关于Daniel Guo 律师

发信人: q123452017 (水天一色), 信区: I140 标  题: 关于Daniel Guo 律师 关键字: Daniel Guo 发信站: BBS 未名空间站 (Thu Apr 26 02:11:35 2018, 美东) 这些是lz根据亲身经历在 Immigration版上发的帖以及一些关于Daniel Guo 律师的回 帖,希望大家不要被一些马甲帖广告帖所骗,慎重考虑选择律师。 WG 和Guo两家律师对比 1. fully refund的合约上的区别 wegreened家是case不过只要第二次没有file就可以fully refund。郭家是要两次case 没过才给refund,而且只要第二次pl draft好律师就可以不退任何律师费。 2. 回信速度 wegreened家一般24小时内回信。郭律师是在可以快速回复的时候才回复很快,对于需 要时间回复或者是不愿意给出确切答复的时候就回复的比较慢。 比如:lz问过郭律师他们律所在nsc区域最近eb1a的通过率,大家也知道nsc现在杀手如 云,但是郭律师过了两天只回复说让秘书update最近的case然后去网页上查,但是上面 并没有写明tsc还是nsc。 lz还问过郭律师关于准备ps (他要求的文件)的一些问题,模版上有的东西不是很清 楚,但是他一般就是把模版上的东西再copy一遍发过来。 3. 材料区别 (推荐信) 因为我只收到郭律师写的推荐信,所以可以比下两家推荐信 wegreened家推荐信写的比较长,而且每封推荐信会用不同的语气和风格,会包含lz写 的research summary里面的某个方面 郭家四封推荐信都是一个格式,一种语气,连地址,信的称呼都是一样的,怎么看四封 推荐信都是同一个人写出来的。套路基本都是第一段目的,第二段介绍推荐人,第三段 某篇或几篇文章的abstract,最后结论 4. 前期材料准备 wegreened家要按照他们的模版准备一个十几页的research summary。 郭律师在签约之前说的是只需要准备五页左右的summary,但是在lz签完约收到推荐信 ,郭律师又发来一个很长的ps要lz自己填,而且和pl的格式基本差不多。 总结下来,申请自己上心最重要。但是如果选律师,lz更倾向于wegreened,