《敏捷开发总结分析解析》由会员分享,可在线阅读,更多相关《敏捷开发总结分析解析(15页珍藏版)》请在金锄头文库上搜索。
1、Intro:简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软 件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的 特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别 完成,在此过程中软件一直处于可使用状态。敏捷开发是由一些业界专家针对一些企业现 状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于 2001 初成立了敏捷联盟。他们 正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非 常支持
2、这一理论,他采取了 敏捷方式组建团队:Capital One的敏捷团队包括3名业务人 员、两名操作人员和57名IT人员,其中包括1个业务信息指导(实际上是业务部门和 IT部门之间的翻译者);另夕卜,还有一个由项目经 理和至少80名开发人员组成的团 队。这些开发人员都曾被Bailar送去参加过敏捷开发的培训,具备相关的技能。每个团队都有自己的敏捷指导(Bailar聘用了 20个敏捷指导),他的工作 是关注流 程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段,团队人员密切合作,开 发有规律地停顿-在9周开发过程中停顿34次,以评估过
3、程及决定需求变更是否必 要。在Capital One大的IT项目会被拆分成多个子项目,安排给各敏捷团队,这种 方式在敏捷开发中叫蜂巢式(swarming),所有 过程由一名项目经理控制。为了检验这个系统的效果,Bailar将项目拆分,从旧的瀑布式开发转变为并列 式开发,形成了敏捷开发所倡导的精干而灵活的开发团队,并将开发阶段分成30天 一个周期,进行冲刺-每个冲刺始于一个启动会议,到下个冲刺前结束。在Bailar将其与传统的开发方式做了对比后,他感到非常兴奋-敏捷开 发使开 发时间减少了30%-40%有时甚至接 近5 0%提高了交付产品的质量不过,有些需求不能 用敏捷开发来处理。Bailar承
4、认,敏捷开发也有局 限性,比如对那些不明确、优先权 不清楚的需求或处于较快、较便宜、较优 的三角架构中却不能排列出三者优先级的需 求。此外,他觉得大型项目或有特 殊规则的需求的项目,更适宜采用传统的开发方式。尽管描述需求一直是件困难的事,但 经过阵痛之后,需求处理流程会让CIO受益匪浅。敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工 作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,他 们认为:个体和交互胜过过程和工具可以工作的软件胜过 面面俱到的文档客户合作胜过 合同谈判响应变化
5、胜过遵循计划并提出了以下遵循的原则:我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞 争优势。经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付 的时间间隔越短越好。在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任 他们能够完成工作。在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交 谈。工作的软件是首要的进度度量标准。 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个 长期的、恒定的
6、开发速度。不断地关注优秀的技能和好的设计会增强敏捷能力。简单是最根本的。最好的构架、需求和设计出于自组织团队。 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地 对自己的行为进行调整。MatainFlow:从无到繁重再到敏捷多数软件开发仍然是一个显得混乱的活动,即典型的“边写边改” (code and fix)。设计过程充斥着短期的,即时的决定,而无完整的规划。这种模式对小系统 开发其实很管用,但是当系统变得越大越复杂时,要想加入新的功能就越来越困难。同 时错误故障越来越多,越来越难于排除。一个典型的标志就是当系统功能完成后有一个很 长的测试阶段,有时甚至有遥遥无期之感,从而
7、对项目的完成产生严重的影响。我们使用这种开发模式已有很长时间了,不过我们实际上也有另外一种选择,那就是“正 规方法” (methodology)。这些方法对开发过程有着严格而详尽的规定,以期使软件开 发更有可预设性并提高效率,这种思路是借鉴了其他工程领域的实践。这些正规方法已存在了很长时间了,但是并没有取得令人瞩目的成功,甚至就没怎么 引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐,要是按照它的要求 来,那有做太多的事情需要做,而延缓整个开发进程。所以它们通常被认为是“繁琐滞重 型”方法,或Jim HighSmith所称的“巨型” (monumental)方法。作为对这些方法的反叛
8、,在过去几年中出现了一类新方法。尽管它们还没有正式的名 称,但是一般被称为“敏捷型”方法。对许多人来说,这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡,使得能以不 多的步骤过程获取较满意的结果。敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏 捷型不是很面向文档,对于一项任务,它们通常只要求尽可能少的文档。从许多方面来 看,它们更象是“面向源码” (code-oriented) 。事实上,它们认为最根本的文档应 该是源码。但是,我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表 象,它其实反映的是更深层的
9、特点:1 敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在 很长的时间跨度内作出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒 绝变化。而敏捷型方法则欢迎变化。其实,它们的目的就是成为适应变化的过程,甚至 能允许改变自身来适应变化。2敏捷型方法是“面向人”的(people-oriented)而非“面向过程”的 (process-oriented) 。它们试图使软件开发工作顺应人的天性而非逆之。它们强调软 件开发应当是一项愉快的活动。我认为以上两个特点很好的概括了敏捷开发方法的核心思想:适应变化和以人为中心AtionAdaptivePlanning PairPr
10、ogrammingAutomatedTestingContinuous IntegrationCustomerEngagementTest DrivenDevelopmentStnd upRefactoringFrequentReleasesCollaboratrveFocusMinimalDocumentation这两个圆圈表示不同的视角上的敏捷实践,包括开发者视角和项目管理的视角。接下来从里向外进行介绍。Tes t-Driven Developmen t,测试驱动开发,它是敏捷开发的最重要的部分。在 ThoughtWorks,我们实现任何一个功能都是从测试开始,首先对业务需求进行分析,分解
11、 为一个一个的Story,记录在Story Card上。然后两个人同时 坐在电脑前面,一个人 依照Story,从业务需求的角度来编写测试代码,另一个人看着他并且进行思考,如果有 不同的意见就会提出来进行讨论,直到达成共识,这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘,编 写该测试代码的实现。如果没有测试代码,就不能编写功能的实现代码。先写测试代码,能够让开发人员明确目标,就是让测试通过。Continuous Integration ,持续集成。在以往的软件开发过程中,集成是一件很痛 苦的事情,通常很长时间才会做一次集成,这样的话,会引发很多问题,比如build未通 过或
12、者单元测试失败。敏捷开发中提倡持续集成,一天之内集成十几次甚至几十次,如此 频繁的集成能尽量减少冲突,由于集成很频繁,每一次集成的改变也很少,即使集成失败 也容易定位错误。一次集成要做哪些事情呢?它至少包括:获得所有源代码;编译源代 码;运行所有测试,包括单元测试、功能测试等;确认编译和测试是否通过,最后发送报 告。当然也会做一些其它的任务,比如说代码分析、测试覆盖率分析等等。 在我们公司 里,开发 人员的桌上有一个火山灯用来标志集成的状态,如果是黄灯,表示正在集成;如果是绿灯,表示上一次集成通过,开发人员在这时候获得的代码是可用而可靠的;如果显示为红灯,就要小心了,上一次集成未通过,需要尽快
13、定位失败原因从而让 灯变绿。在持续集成上,我们公司使用的是自己开发的产品CruiseC on trolRefactoring,重构。相信大家对它都很熟悉了,有很多很多的书用来介绍重 构,最 著名的是Martin的重构,Joshua的从重构到模式等。重构是 在不改变系统外 部行为下,对内部结构进行整理优化,使得代码尽量简单、优美、可扩展。在以往开发 中,通常是在有需求过来,现在的系统架构不容易实现,从而对原有系统进行重构;或者在开发过程中有剩余时间了,对现在代码进行重构整 理。但是在敏捷开发中,重构贯穿于整个开发流程,每一次开发者check in代码之前, 都要对所写代码进行重构,让代码达到cl
14、ean code thatworks。值得注意的是,在重构时,每一次改变要尽可能小,用单元测试来保证 重构是否 引起冲突,并且不只是对实现代码进行重构,如果测试代码中有重复,也要对它进行重 构。Pair-Programming,结对编程。在敏捷开发中,做任何事情都是Pair的,包括分析、写测试、写实现代码或者重构。Pair做事有很多好处,两个人在一起探讨很容 易产生思想的火花,也不容易走上偏路。在我们公司,还有很多事都是Pair来做,比如 Pair学习,Pair翻译,Pair做PPT关于这个话题,钱 钱同学有一篇很有名的文章对它 进行介绍,名为Pair Programming (结对编程)。S
15、t and up,站立会议。每天早上,项目组的所有成员都会站立进行一次会议,由于是站立的,所以时间不会很长,一般来说是 15-20分钟。会议的内容并不是需求分 析、任务分配等,而是每个人都回答三个问题:1你昨天做了什么?2. 你今天要做什么? 3你遇到了哪些困难?站立会议让团队进行交流,彼此相互熟悉工作内容,如果有人曾经遇到过和你类似的问题,那么在站立会议后,他就会和 你进行讨论。Frequent Releases,小版本发布。在敏捷开发中,不会出现这种情况,拿到 需求以 后就闭门造车,直到最后才将产品交付给客户,而是尽量多的产品发布,一般以 周、月 为单位。这样,客户每隔一段时间就会拿到发布的产品进行试用,而我们可以从客户那得 到更多的反馈来改进产品。正因为发布频繁,每一个版本新增的功能简单,不需要复杂 的设计,这样文档和设计就在很大程度上简化了。又因为简单设计,没有复杂的架构,所 以客户有新的需求或者需求进行变动,也能很快的适应。Minimal Documentat ion,较少的文档。其实敏捷开发中并不是没有文档,而是有大量 的文档,即测试。这些测试代码真实的反应了客户的需求以及系统API的用法,如果有新人加入团队,最快的熟悉项目的方法就是给他看测试代码,而比一边看 着文档一边进行debug要高效。如果用书面文档或者注释,某天代码变化