关于敏捷开发的理解

课堂上老师让我写一下关于敏捷开发的概述。如下是从网上找的资料进行整理的。

敏捷开发的路线：

Test-Driven Development，测试驱动开发。

　　它是敏捷开发的最重要的部分。在ThoughtWorks，咱们实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。而后两我的同时坐在电脑前面，一我的依照Story，从业务需求的角度来编写测试代码，另外一我的看着他而且进行思考，若是有不一样的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另外一我的控制键盘，编写该测试代码的实现。若是没有测试代码，就不能编写功能的实现代码。先写测试代码，可以让开发人员明确目标，就是让测试经过。

　　Continuous Integration，持续集成。

　　在以往的软件开发过程当中，集成是一件很痛苦的事情，一般很长时间才会作一次集成，这样的话，会引起不少问题，好比 build未经过或者单元测试失败。敏捷开发中提倡持续集成，一天以内集成十几回甚至几十次，如此频繁的集成能尽可能减小冲突，因为集成很频繁，每一次集成的改变也不多，即便集成失败也容易定位错误。一次集成要作哪些事情呢？它至少包括：得到全部源代码、编译源代码、运行全部测试，包括单元测试、功能测试等；确认编译和测试是否经过，最后发送报告。固然也会作一些其它的任务，好比说代码分析、测试覆盖率分析等等。在咱们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，若是是黄灯，表示正在集成；若是是绿灯，表示上一次集成经过，开发人员在这时候得到的代码是可用而可靠的；若是显示为红灯，就要当心了，上一次集成未经过，须要尽快定位失败缘由从而让灯变绿。在持续集成上，咱们公司使用的是本身开发的产品CruiseControl。

　　Refactoring，重构。

　　相信你们对它都很熟悉了，有不少不少的书用来介绍重构，最著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽可能简单、优美、可扩展。在以往开发中，一般是在有需求过来，如今的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程当中有剩余时间了，对如今代码进行重构整理。可是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码以前，都要对所写代码进行重构，让代码达到clean code that works。值得注意的是，在重构时，每一次改变要尽量小，用单元测试来保证重构是否引发冲突，而且不仅是对实现代码进行重构，若是测试代码中有重复，也要对它进行重构。

　　Pair-Programming，结对编程。

　　在敏捷开发中，作任何事情都是Pair的，包括分析、写测试、写实现代码或者重构。Pair作事有不少好处，两我的在一块儿探讨很容易产生思想的火花，也不容易走上偏路。在咱们公司，还有不少事都是Pair来作，好比Pair学习，Pair翻译，Pair作PPT，关于这个话题，钱钱同窗有一篇颇有名的文章对它进行介绍，名为Pair Programming (结对编程)。

　　Stand up，站立会议。

　　天天早上，项目组的全部成员都会站立进行一次会议，因为是站立的，因此时间不会很长，通常来讲是15-20分钟。会议的内容并非需求分析、任务分配等，而是每一个人都回答三个问题：1. 你昨天作了什么？2. 你今天要作什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工做内容，若是有人曾经遇到过和你相似的问题，那么在站立会议后，他就会和你进行讨论。

　　Frequent Releases，小版本发布。

　　在敏捷开发中，不会出现这种状况，拿到需求之后就闭门造车，直到最后才将产品交付给客户，而是尽可能多的产品发布，通常以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用，而咱们能够从客户那获得更多的反馈来改进产品。正由于发布频繁，每个版本新增的功能简单，不须要复杂的设计，这样文档和设计就在很大程度上简化了。又由于简单设计，没有复杂的架构，因此客户有新的需求或者需求进行变更，也能很快的适应。

　　Minimal Documentation，较少的文档。

　　其实敏捷开发中并非没有文档，而是有大量的文档，即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法，若是有新人加入团队，最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效。若是用书面文档或者注释，某天代码变化了，须要对这些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的状况，这更加会让人迷惑。而在敏捷中并不会出现，由于只有测试变化了，代码才会变化，测试是真实反应代码的。这时有人会问：代码不写注释行吗？通常来讲好的代码不是须要大量的注释吗？其实简单可读的代码才是好的代码，既然简单可读了，别人一看就可以看懂，这时候根本不须要对代码进行任何注释。若你以为这段代码不加注释的话别人可能看不懂，就表示设计还不够简单，须要对它进行重构。

　　Collaborative Focus，以合做为中心，表现为代码共享。

　　在敏捷开发中，代码是归团队全部而不是哪些模块的代码属于哪些人，每一个人都有权利得到系统任何一部分的代码而后修改它，若是有人看到某些代码不爽的话，那他可以对这部分代码重构而不须要征求代码做者的赞成，极可能也不知道是谁写的这部分代码。这样每一个人都能熟悉系统的代码，即便团队的人员变更，也没有风险。

　　Customer Engagement ，现场客户。

　　敏捷开发中，客户是与开发团队一块儿工做的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。若是开发过程当中有什么问题或者产品通过一个迭代后，可以以最快速度获得客户的反馈。

　　Automated Testing ，自动化测试。

　　为了减少人力或者重复劳动，全部的测试包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，可以编写自动化测试脚本或者用工具录制。咱们公司在自动化测试上作了大量的工做，包括Selenium开源项目。

　　Adaptive Planning，可调整计划。

　　敏捷开发中计划是可调整的，并非像以往的开发过程当中，需求分析->概要设计->详细设计->开发 ->测试->交付，每个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时做出相应的调整和变化。

　　敏捷开发过程与传统的开发过程有很大不一样，在这过程当中，团队是有激情有活力的，可以适应更大的变化，作出更高质量的软件。

项目的敏捷开发方法

敏捷方法不少,包括 Scrum、极限编程、功能驱动开发以及统一过程（RUP）等多种法，这些方法本质其实是同样的，敏捷开发小组主要的工做方式能够概括为：做为一个总体工做； 按短迭代周期工做； 每次迭代交付一些成果； 关注业务优先级； 检查与调整。

极限编程XP

 

极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个很是严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目均可以从四个方面入手进行改善：增强交流；从简单作起；寻求反馈；敢于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；经过积极的交流、反馈以及其它一系列的方法，开发人员和客户能够很是清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际状况及时地调整开发过程。

 

Scrum过程

 

Scrum是一个包括了一系列实践和预约义角色的过程骨架。Scrum中的主要角色包括同项目经理相似的 Scrum主管角色负责维护过程和任务， 产品负责人表明利益全部者， 开发团队包括了全部开发人员。

在每一次冲刺（一个15到30 天周期 ，长度由开发团队决定），开发团队建立可用的（能够随时推出）软件的一个增量。每个冲刺所要实现的特性来自产品订单（product backlog）， 产品订单是按照优先级排列的要完成的工做的概要的需求。哪些订单项会被加入一次冲刺由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他须要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们可以承诺完成多少订单项。 在冲刺的过程当中，没有人可以变动冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。

管理Scrum过程有不少实施方法，从白板上的即时贴到软件包。Scrum最大的好处是它很是容易学习，并且应用Scrum不须要太多的投入。

 

精益软件开发

精益开发是从丰田的生产以及开发方式发展出来的一种过程管理方法，从90年代开始被很普遍的研究，其目标是了解客户的价值观，而后充分利用聪明的、具备创造力的员工的时间和精力，以较少的努力提供更多的价值，即尽可能避免复杂的东西。

精益软件开发有七个原则：

• 消灭浪费（Eliminate Waste）：软件开发中最大的浪费就是多余的功能，该原则是Lean最基本的一个原则。
• 品质为先（Build Quality In）：从一开始就注重品质，而不是最后依靠测试。测试驱动开发（TDD）就是一个很好的实践。
• 建立知识（Create Knowledge）：软件开发是个建立知识的过程，应该有一个鼓励你们系统学习的开发流程，并且不断的改进这个流程。
• 推迟决定（Defer Commitment）：软件开发一般具备必定的不肯定性，基于多种选择的方法可以达成更好的结果，尽量的延迟决定，直到可以基于事实而不是不肯定的假定和预测来作出决定。
• 快速交付（Deliver Fast）：尽快的交付软件能使客户满意，还能够削除大量的浪费。
• 尊重员工（Respect People）：软件开发以人为本，人是软件开发团队中最重要的资源。
• 全局优化（Optimize the Whole）：一个Lean的团队应该优化整个价值流（value stream）。

从这些原则看出，精益开发和敏捷开发在不少方面都是相通的，它是软件开发的一种指导思想。咱们不能期待精益开发能够解决全部的问题。“精益软件虽然能够很好地管理复杂性，可是不能彻底消除复杂性。它只是引领开发人员，而咱们也须要证实它是一个可行的办法。”

动态系统开发

动态系统开发方法（DSDM）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证实DSDM是成功的敏捷开发 方法之一。在英国，因为其在各类规模的软件组织中的成功，它已成为应用最为普遍的快速应用开发方法。本书主要讲述这样几方面内容：DSDM如何加快产品的 交付，为何像DSDM这样的敏捷开发方法可以快速体现所开发系统给业务带来的好处，如何组织用户参与项目以开发出可用的系统，如何将不一样知识背景的人组 成一个团队，如何应对常规的业务约束以进行项目管理。

　　DSDM的基本原则 DSDM方法创建在9条原则之上，并且在实施过程当中，这9条缺一不可。

　　原则1：用户必须持续参与 

　　DSDM过程当中，用户持续参与的概念是：在整个DSDM生命周期中，有一些专业用户会一直对开发组提供支持和参与。可以随时解决开发组对业务流 程的各类问题，使工做进展顺畅，同时用户也会对原型进行验收，提出各类建议和想法。

　　原则2：必须授予DSDM团队制定决策的权利 

　　DSDM鼓励管理层将权利下放，团队成员都应该获得受权。为了使项目快速进行，团队成员必须可以对他们的工做迅速作出决定，以保证项目可以如期 交付。当出现问题时团队成员应该能作出决定，以下是一些常见的决定：

　　需求的实际含义。

　　从功能、可用性考虑开发中产生的中间产品是否可接受。

　　工做进程中需求的优先级制定。

　　修改技术细节。

　　尽管DSDM不鼓励团队在出现问题时，逐层向上级反馈，可是也提供了这种问题的处理途径。

　　能够看出，同为敏捷方法，DSDM方法与SCRUM方法的项目管理思路，特别是对团队受权和对项目过程问题的处理机制仍是存在很大差异 的，SCRUM方法强调团队成员反馈问题，而且对于开发组不能解决的问题，必须逐层反馈，获取高层的指导，而且支持高层领导参与项目的SCRUM Meeting，强调迅速向上级反馈，上级迅速作出决定。而DSDM方法中，团队成员已经被受权直接作出决定了。

　　原则3：注重产品的常常交付 

　　常常交付产品，可以让外部人员检查团队内部所作出的决定是否能够接受。这样，项目就可以获得控制。这里说的产品是不只仅是软件，还包括数据模 型。产品的常常交付可以反映项目当前的进度，也可以衡量项目是否沿着正确的方向在进行。

　　原则4：知足业务用户用途是接受交付品的主要依据 

　　开发人员没必要沉溺于完美的 解决方案之中，耽误项目时间。在受限的时间内，实现业务利益最大化的交付品才是最重要的。

　　原则5：迭代和增量式开发对获得正确的业务解决方案是必不可少的 

　　采用迭代开发的方法，可以使业务流程逐步进化，使系统不断朝着知足业务需求的方向前进。

　　原则6：开发过程的全部变化可逆 

　　采用迭代和增量式开发过程当中，极可能会碰到走错的状况，此时须要回退到一个已知的可靠的点上。

　　原则7：在高层次上制定需求的基线 

　　在业务研究中所得出的需求必须在高层次上达成一致。接下来在迭代过程当中再获得详细的需求。

　　原则8：测试自始至终贯穿于开发周期之中 

　　开发人员完成一个模块的开发后，本身会进行单元测试。当模块集成到现有系统后，测试人员须要执行集成测试。另外，回归测试在DSDM中占有很重 要的地位。

　　原则9：全部项目涉众间的通力合做是不可获缺的  

　　什么时候使用DSDM？

　　对于具备如下特性的应用，DSDM特别适合：

　　一、交互式、功能经过用户界面体现。

　　二、有清晰的用户群。

　　三、没有复杂计算。

　　四、若是是大型应用，能够分解成小的功能部件。

　　五、有时间限制。

　　六、需求不清楚或不肯定

 

特性驱动开发

FDD是一个模型驱动( model-driven)、短时间遍历(short-iteration)的过程. 注意，FDD是一个开发过程，过程老是有起点和终点，FDD的起点是起源于建立一个全局的模型轮廓（不要求很精确，大概模样就能够），而后大概是两周的一系列的"design by feature, build by feature"的迭代，逐渐丰富模型功能内容，features是指小的、以软件用户的视角看是有用的特征功能，一个FDD开发过程.

1. 开发一个全局的模型

　　在一个有经验的组件/对象建模专家（首席架构师）指导下，业务领域需求人员与开发人员一块儿协调工做，业务领域人员提供一个初始的、具备必定高度的、能够覆盖整个系统和业务场景的介绍，领域人员和开发人员会依此产生初始的模型，而后再结成单独小组，进入详细继续讨论阶段，将模型轮廓描绘出来，而后丰富以前产生的初始模型。

2. 创建特征列表（Feature List）

　　当初始模型产生之后，有一个单独小组成员将开始构建复杂的特征(feature)功能列表.

3. 依据特征规划(Plan By Feature)

　　下一步工做就是将主要的特征功能集合进行排序和计划，而后分配给主要程序员组长，这时，程序员也会跟着他们在全局对象模型中所负责的类进入相应的程序员小组。例如张三开始是参与Message这个Model构建和规划，那么与Message这个对象模型相关的特征功能列表被分类出来并分配到特定程序员小组时，张三也就是跟着进入这个程序员小组。

4.依据特征设计/依据特征构建(Design By Feature / Build By Feature)

　　当每一个程序员小组领到本身的特征功能集合后，召集4-5个程序员开会，组长挑选一小组适合2周内完成的特征功能集合，而后执行 'Design By Feature (DBF)' 和 'Build By Feature (BBF)'. 组长将相应的一些类和特征功能分配给小组Team，特征Team进行详细的顺序图设计， 而后写出类和方法逻辑。

　　下面是进入依据特征构建阶段，也就是代码的编译调试测试阶段，在进入BBF阶段以前，Team小组要进行设计代码复核，在进入后，类的做者进行类的整合、测试和复核，一旦程序员组长满意，完整的特征功能实现将被提交到主要的Build过程，也就是进入集成测试阶段。

　　每一个程序员组长能够并行负责带领2-3特征小组Team运转，特征小组中任何人任什么时候候均可以成为类的做者（编写类的具体实现代码）。

 

 

宣言原则

最重要的是经过尽早和不断交付有价值的软件知足客户须要。

咱们欢迎需求的变化，即便在开发后期。敏捷过程可以驾驭变化，保持客户的竞争优点。

常常交付能够工做的软件，从几星期到几个月，时间尺度越短越好。

业务人员和开发者应该在整个项目过程当中始终朝夕在一块儿工做。

围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，知足他们的须要，并相信他们可以完成任务。

在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

能够工做的软件是进度的主要度量标准。

敏捷过程提倡可持续开发。出资人、开发人员和用户应该老是维持不变的节奏。

对卓越技术与良好设计的不断追求将有助于提升敏捷性。

简单——尽量减小工做量的艺术相当重要。

最好的架构、需求和设计都源自自我组织的团队。

每隔必定时间，团队都要总结如何更有效率，而后相应地调整本身的行为。

开发宣言

个体和交互赛过过程和工具

能够工做的软件赛过面面俱到的文档

客户合做赛过合同谈判

响应变化赛过遵循计划

虽然右项也有价值，可是咱们认为左项具备更大的价值。

 

 

水晶开发

水晶方法，Crystal ，是由 Alistair Cockburn 和 Jim Highsmith 创建的敏捷方法系列，其目的是发展一种提倡“机动性的”[1]方法，包含具备共性的核心元素，每一个都含有独特的角色、过程模式、工做产品和实践。Crystal 家族其实是一组通过证实、对不一样类型项目很是有效的敏捷过程，它的发明使得敏捷团队能够根据其项目和环境选择最合适的 Crystal 家族成员。

透明水晶方法的七大致系特征：

体系特征一：常常交付

体系特征二：反思改进

体系特征三：渗透式交流

体系特征四：我的安全

体系特征五：焦点

体系特征六：与专家用户创建方便的联系

体系特征七：配有自动测试、配置管理和常常集成功能的技术环境

 

一、敏捷小组做为一个总体工做

　　项目取得成功的关键在于，全部项目参与者都把本身当作朝向一个共同目标前进的团队的一员。“扔过去无论”的心理不是属于敏捷开发。设计师和架构师不会把程序设计“扔”给编码人员；编码人员也不会把只通过部分测试的代码“扔”给测试人员，一个成功的敏捷开发小组应该具备“咱们一块儿参与其中的思想”， “帮助他人完成目标”这个理念是敏捷开发的根本管理文化。固然，尽管强调一个总体，小组中应该有必定的角色分配，各类敏捷开发方法角色的起名方案可能不一样，希望则基本上是同样的。第一个角色是产品全部者，他的主要职责包括：确认小组成员都在追求一个共同的目标前景；肯定功能的优先等级，以便老是处理最有价值的功能；做出可使项目的投入产生良好回报的决定。产品全部者一般是公司的市场部门或者产品管理部门的人员，在开发内部使用的软件的时候，产品全部者多是用户、用户的上级、分析师，也多是为项目提供资金的人。

二、敏捷小组按短迭代周期工做

    在敏捷项目中，整体上并无什么上游阶段、下游阶段，你能够根据须要定义开发过程在初始阶段能够有一个简短的分析、建模、设计，但只要项目真正开始，每次迭代都会作一样的工做（分析、设计、编码、测试。等等）。迭代是受时间框限制的，也就是说即便放弃一些功能，也必须结束迭代。时间框通常很短，大部分是 2～4周，在 Scrum中采用的是 30个日历天，也就是 4 周。迭代的时间长度通常是固定的，但也有报告说，有的小组在迭代开始的时候选择合适的时间长度。

三、敏捷小组每次迭代交付一些成果

　　比选择特定迭代长度更重要的，是开发小组在一次迭代中要把一个以上的不太精确的需求声明，通过分析、设计、编码、测试，变成可交付的软件（称之为功能增量）。固然并不须要把每次迭代的结果交付给用户，但目标是能够交付，这就意味着每次迭代都会增长一些小功能，但增长的每一个功能都要达到发布质量。每次迭代结束的时候让产品达到可交付状态十分重要，但这并不意味着要完成发布的所有工做，由于迭代的结果并非真正发布产品。假定一个小组须要在发布产品以前对软硬件进行为期两个月的“平均无端障时间”（MTBF）测试，他们不可能缩短这两个月的时间，但这个小组仍然是按照 4 周迭代，除了MTBF测试，其它都达到了发布状态。

四、敏捷小组关注业务优先级

　　敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先，他们按照产品全部者制定的顺序交付功能，而产品全部者通常会按照组织在项目上的投资回报最大化的方式来肯定优先级，而且把它组织到产品发布中去。要达到这个目的，须要综合考虑开发小组的能力，以及所需功能的优先级来创建发布计划。在编写功能的时候，须要使工能的依赖性最小化。若是开发一个功能必须依赖其它 3 个功能，那产品全部者这就很难肯定功能优先级。功能彻底没有依赖是不太可能的，但把功能依赖性控制在最低程度仍是至关可行的。

五、敏捷小组检查与调整

　　任何项目开始的时候所创建的计划，仅仅是一个当前的猜想。有不少事情可让这样的计划失效：项目成员的增减，某种技术比预期的更好或更差，用户改变了想法，竞争者迫使咱们作出不一样的反应，等等。对此，敏捷小组不是惧怕这种变化，而是把这种变化当作使最终软件更好地反映实际须要的一个机会。每次新迭代开始，敏捷小组都会结合上一次迭代中得到新知识作出相应调整。若是认为一些因素可能会影响计划的准确性，也可能更改计划。好比发现某项工做比预计的更耗费时间，可能就会调整进展速度。也许，用户看到交付的产品后改变了想法，这就产生反馈，好比他发现他更但愿有另外一项功能，或者某个功能并不像先前看得那么重。经过先期发布增长更多的用户但愿的功能，或者减小某些低价值功能，就能够增长产品的价值。迭代开发是在变与不变中寻求平衡，在迭代开始的时候寻求变，而在迭代开发期间不能改变，以期集中精力完成已经肯定的工做。因为一次迭代的时间并不长，因此就使稳定性和易变性获得很好的平衡。在两次迭代期间改变优先级甚至功能自己，对于项目投资最大化是有益处的。从这个观点来看，迭代周期的长度选择就比较重要了，由于两次迭代之间是提供变动的机会，周期太长，变动机会就可能失去；周期过短，会发生频繁变动，并且分析、设计、编码、测试这些工做都不容易作到位。综合考虑，对于一个复杂项目，迭代周期选择4周仍是有道理的。

　　MIT Sloan Management Review（麻省理工学院项目管理评论）所刊载的一篇为时两年对成功软件项目的研究报告，报告指出了软件项目得到成功的共同因素，排在首位的是迭代开发，而不是瀑布过程。其它的因素是：

　　一、至少天天把新代码合并到整个系统，而且经过测试，对设计变动作出快速反应。

　　二、开发团队具有运做多个产品的工做经验。

　　三、很早就致力于构建和提供内聚的架构。