敏捷开发方法综述

敏捷开发 是一种以人为核心、迭代、 循序渐进 的开发方法。在敏捷开发中,软件项目 的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小 项目 ,并分别完成,在此过程中软件一直处于可使用状态。

(1)敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。

(2)敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

敏捷方法很多,包括 Scrum、 极限编程 、功能驱动开发以及统一过程( RUP )等多种法,这些方法本质实际上是一样的,敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果; 关注业务优先级; 检查与调整。下图是典型的敏捷过程总图。其实敏捷开发中并不是没有文档,而是有大量的文档,即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法,如果有新人加入团队,最快的熟悉项目的方法就是给他看测试代码,而比一边看着文档一边进行debug要高效。如果用书面文档或者注释,某天代码变化了,需要对这些文档进行更新。一旦忘记更新文档,就会出现代码和文档不匹配的情况,这更加会让人迷惑。而在敏捷中并不会出现,因为只有测试变化了,代码才会变化,测试是真实反应代码的。这时有人会问:代码不写注释行吗?一般来说好的代码不是需要大量的注释吗?其实简单可读的代码才是好的代码,既然简单可读了,别人一看就能够看懂,这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂,就表示设计还不够简单,需要对它进行重构。

时间: 2024-10-27 02:31:00

敏捷开发方法综述的相关文章

敏捷开发 Scrum 综述

敏捷开发 Scrum 综述 这一星期学习了敏捷开发,然后阅读了相关的书籍,从网上查找了很多相关的资料,对敏捷开发scrum有了更加深刻了理解,对敏捷开发做了如下总结: 一.什么是敏捷开发? 敏捷开发提倡的“增量迭代.及时交付”的思想.这种模式能最大程度地不偏离客户需求的本质. 敏捷不是指某一种具体的方法论.过程或框架,而是一组价值观和原则.符合敏捷价值观和原则的开发方法包括:极限编程( XP), Scrum, 精益软件开发( Lean Software Development), 动态系统开发方

敏捷开发方法(一) Scrum

Scrum团队:由产品负责人.开发团队和Scrum Master组成. 是跨职能的自组织团队 自组织团队自己选择如何最好地完成工作,而不是由团队外的人指导 跨职能团队拥有完成工作所需要的全部技能,不需要依赖团队以外的人 这种团队模式的目的是最大限度地优化灵活度.创造力和生产效率 三大角色: Scrum管理-五事件 Scrum 管理: 所有事件是有时间盒限定的 每个事件都有时间限制的 一旦Sprint开始,它的周期也就固定下来了,不能缩短或者延长 Scrum 管理五事件包括: Sprint 计划会

敏捷开发方法论述

首先,是敏捷开发的定义:“敏捷开发以用户的需求进化为核心,采用迭代.循序渐进的方法进行软件开发.在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视.可集成和可运行使用的特征.换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态.” 这在我们目前生活中最多看到的就是手机软件每过一小段时间就会提示更新,开发人员并不是开发完就不管了,而是通过对用户的反馈结果以及实际运行中出现的错误,不断修改,推出更新包,这

敏捷开发方法-Scrum

为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解:所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助.  什么是敏捷开发? 敏捷开发(Agile Development)是一种以人为核心.迭代.循序渐进的开发方法. 怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,

敏捷开发方法

极限编程XP:把整个开发过程分解为比较小而简单的周期,通过大家积极的沟通反馈,开发人员和客户都比较清楚当前的开发进度.需要解决的问题等等,根据这些实际情况去调整开发进程,这是极限编程的思想. 水晶法:相对于其它敏捷方法,水晶系列方法强调软件开发流程的纪律性,所以它比其它敏捷方法易于使用,但它的生产率不如XP等其它敏捷方法.水晶系列与XP一样,都有以人为中心的理念,但在实践上有所不同.人们一般很难严格遵循一个纪律约束很强的过程,因此,与XP的高度纪律性不同,水晶系列方法试图用最少纪律约束而仍能成功

用户故事与敏捷开发方法笔记06

用户故事得到这么多人的肯定,是因为它自身的优势有很多:1.用户故事强调口头沟通,因为传统的通过各种文档进行表达,每个人对于文字的含义的理解都不同,所以在阅读文档的过程中可能会因为理解的不同对项目的完成造成影响:2.人人都可以理解用户故事,并且用户故事可以增强人们对各种事件的记忆:3.用户故事的大小适合做发布规划以及进行编程和测试:4.用户故事适合于迭代开发,项目过程中可以写出一部分故事然后就进行编码和测试5.用户故事鼓励延迟细节:6.用户故事支持随机应变的开发,因为用户故事注重口头交流,而且很容

Scrum/Sprint敏捷开发方法.

从理论上看, 这个方法真是妙得紧: [图片来源: http://en.wikipedia.org/w/index.php?title=File:Scrum_process.svg&page=1] 微软 MSDN 也有类似的流程介绍,看起来真是太容易了:   第一步: 找出完成产品需要做的事情 – Product Backlog, Backlog 翻译成“积压的工作”, “待解决的问题”, “产品订单”都可以. 产品负责人主导大家对于这个Backlog 进行 增/删/改 的工作.每一项的时间估计的

用户故事与敏捷开发方法笔记04

因为需要将每个用户故事按重要性分配到相应的迭代过程,所以每个迭代过程的时间就可以根据用户故事大致估算出来,所以要学会估算用户故事所需的时间.估算用户故事可以采用故事点估算的方法,这种方法的优点就是团队可以定义自己认为合适的故事点,可以根据自己团队的情况具体定义,比较灵活.正因为这个原因,有的团队倾向于用理想时间,有的团队则倾向于使用模糊时间.估算的主要目的之一是知道整个项目的工作量,通常将估算量换算成时间,而模糊时间需要考虑项目过程中可能出现的情况,所以采用理想时间更为简单. 进行估算时尽可能整

用户故事与敏捷开发方法笔记05

每一轮迭代完成之后需要开迭代计划会议为下一轮的迭代计划.迭代计划会议包括:1.讨论故事:2.从故事中分解出任务:3.开发人员承担每个任务的职责:4.以上3项完成之后每个开发人员对其任务量估计,尽量保证自己领取的任务在下轮迭代结束时可以完成. 讨论故事:开发人员充分理解故事,在其中分解出任务:需要理清故事的关键细节. 从故事中分解出任务:因为一个故事有可能由几个程序员一起承担,所以要将故事分级成更小的单位:而且分解任务的过程还可以发现以前被忽视的细节. 开发人员承担每个任务的职责:开发人员自己领取