敏捷开发心得体会（精选13篇）
敏捷开发，曾经对它的理解就是没有文档的快速开发，先做原型，针对原型面对面交流，按照大家认可的原型再做快速开发，多次的面对面讨论原型，不断迭代原型，针对每次迭代的原型进行快速开发。众所周知，写软件开发文档是每一个程序员都懒于做的事情，认为比较痛苦的事情，所以越来越多的人因为这点去使用敏捷开发。但是经过培训学习之后，我对敏捷开发有了一些新的理解。
首先，对敏捷开发下个定义，借用百度百科的定义。简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
这个定义只从表面上解释了一下敏捷开发，没有具体说明怎样使用敏捷开发。下面讲一下我对敏捷开发的具体心得。
1、架构师的重要性
首先，敏捷开发对于个人能力的要求是十分高的，尤其是领导人的能力。领导者及架构师是个举足轻重的角色，需要眼观大图，并关注最终成果，这就要求领导者及架构师有深厚的行业背景、创新能力、以及架构能力。一个好的架构师，必须能考虑到产品当前使用模块、产品可以继续发展的模块以及下一代产品的方向。只有考虑到这三种模块和特性，这样的产品才能保持长期的生命力。敏捷开发也强调拥抱市场变化，这对产品架构师提出了更高的要求——深厚的业务背景、创新能力、技术洞察力和架构思想。
2、能够随时应对变化的结构，适应需求变化，并能驾驭需求变化 能够随时应对变化的结构，比遵循计划更重要。计划不要考虑太远，因为各种环境都在发生变化，随着软件的提交，需求也许会发生变化。完美的甘特图能够体现对项目的整体控制力，但是详细的甘特图也是不切合实际的。感觉一般做一周的计划，是最切合实际的。
3、尽早地、持续地交付有价值的软件来满足客户需求
经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。只要我们可以保证交付的软件可以很好的工作，那么交付时间越短，我们和客户协作就越紧密，对产品成果就更有益。虽然我们多次迭代，但并不是每次迭代的结果都需要交付给用户，敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能，增加的每个功能都是经过编码、测试，达到可以交付的标准。
4、严格执行单元测试
所有编程人员都知道需要做单元测试，但是有多少人可以认真对待。很少人是真的想尽办法构建测试案例，大多数人都是应付了事。所以要认真对待单元测试，无单元测试的代码严禁提交。“Y23理论”教导我们不要忽视细小的错误，如果不把细小的错误消灭掉，它会给你带来毁灭性的重创。
5、每日站立会议，面对面交流
各团队成员的工作相对比较独立，对其它成员的工作了解不多，不利于整个项目的发展，每个成员容易歇入研究的死胡同。所以在团队内部，每日站立会议、面对面交流是最具有效果并且富有效率的传递信息的方法。每日站立会议要求每个人必须定点进入会议状态。每日会议前每个人要更新自己的任务面板。每日会议中决定要签出的任务，并在会议后更新任务面板，并在任务便签上注明任务的签出人。
6、关注成果，把工作按照重要性和紧急性进行分类，权衡工作重点 团队成员围绕“眼观大图，关注成果”这一导向，把自己的近期工作按照重要性和紧急性进行分类，分为四类：
1、重要、紧急
2、重要、不紧急
3、不重要、紧急
4、不重要、不紧急。根据四类情况对自己的近期工作进行权衡，把握工作重点，紧扣要事，使近期工作得以顺利开展，使远期工作也得以顺利进行。
敏捷开发, 它是一种软件开发方法学, 可以应对客户快速变更的需求, 用来替代以文件驱动开发的瀑布模型。敏捷开发与传统开发过程的最大的不同之处在于它强调以人为核心, 团队有激情、有活力能够适应需求的不断变化。随着敏捷开发的流行, 越来越多的公司开始采用敏捷开发技术。Scrum模型是敏捷开发的一种, 它是一种迭代的增量化过程, 用于产品开发或工作管理, Scrum中发布产品的重要性高于一切。开发软件就像开发新产品, 无法一开始就能定义软件产品最终的规程, 过程中需要研发、创意、尝试错误, 所以没有一种固定的流程可以保证方案成功。
它的框架如下图所示:主要包括三种角色和四个会议。三种角色指图中的Product Owner、Scrum Master、Team Member;四个会议包括周期计划会、每天例会、周期展示会、周期回顾会。Backlog:可以预知的所有任务, 包括功能性的和非功能性的所有任务。
Sprint:一次迭代开发的时间周期, 一般以2-4周为一个周期, 在这段时间内, 开发团队需要完成一个制定的backlog, 并且最终成果是一个增量的, 可以交付的产品。每个Sprint周期可能包含全部的开发阶段, 如需求分析、设计、编写代码、测试、整合以及产品部署。
Sprint Backlog:一个sprint周期内所需要完成的任务。
Product Owner:该角色负责产品的远景规划, 平衡各方面的利益, 确定不同的产品需求积压的优先级等。它是开发团队和客户或最终用户之间的联络点。
Scrum Master:负责监督整个Scrum进程, 修订计划的一个团队成员。负责指导开发团队进行Scrum开发与实践。它也是开发团队与产品拥有者之间交流的联络点。
Team Member:即项目成员, 包括业务员, 开发员, 测试员, 一般5-8个人为1个Team.
Sprint Planning Meeting:在启动每个sprint前召开。一般为一天时间 (8小时) 。该会议需要制定的任务是产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint里需要完成多少小功能模块, 确定好这个Product Backlog的任务优先级。另外, 该会议还需详细地讨论如何能够按照需求完成这些小功能模块, 制定的这些模块的工作量以小时计算。
Daily Scrum Meeting:开发团队成员召开, 一般为15分钟。每个开发成员需要向Scrum Master汇报三个项目:昨天完成了什么?是否遇到了障碍?今天要做什么?通过该会议, 团队成员可以相互了解项目进度。
Sprint Review Meeting:在每个Sprint结束后, 这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。
Sprint Retrospective Meeting:对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。
Scrum的开发过程包括以下几个点:1.将整个产品的backlog分解成Sprint Backlog, 这个Sprint Backlog是按目前的人力物力可以完成的。2.召开sprint planning meeting, 划分确定这个Sprint内需要完成的任务, 标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的, 并不是按人天计算。3.进入sprint开发周期, 在这个周期内, 每天需要召开Daily Scrum meeting。4.整个sprint周期结束, 召开Sprint review meeting, 将成果演示给Product Owner。5.团队成员最后召开Sprint retrospective meeting, 总结问题和经验。6.这样周而复始, 按照同样的步骤进行下一次Sprint。
对敏捷开发的思考:作为一种开发模式敏捷开发同样需要面对众多挑战。大项目的拆分意味着更多子项目的出现, 如何协调这些同步或异步推进的子项目, 合理的资源调配将变得更加复杂。人的重要性尤其重要。减少人员流动和项目变更对整个项目影响成为一大挑战。
敏捷开发之所以广受认可，是因为强调持续集成、快速迭代、重构、测试驱动的敏捷开发与传统开发方法相比，能更快速、更有效地交付给客户可用的软件，在市场竞争日益激烈、强调新产品快速交付的今天，能更好地支持企业创新。
然而，敏捷开发并不是一剂万能药，不能解决软件开发团队的所有问题，甚至也不能用以完全取代传统开发方法（比如瀑布流开发）。曾有研究机构进行过调查，走向敏捷开发的公司中有73%并不完全是敏捷开发，而是敏捷开发与传统开发同时采用。
“敏捷开发最初是作为传统开发方法的颠覆者出现的，它摒弃了传统开发方法在工作流程上的严格限制，能更好地彰显软件开发者个人的创造力。然而，在管理方面天生不足，比如规划管理、需求管理、资源管理等方面。”TechExcel公司创始人兼CEO周铁人博士告诉记者。
TechExcel是周铁人博士于1995年在美国加州创建的一家以软件开发为主要业务领域的公司。最初的10多年来公司一直专注于提供软件开发工具，近5年来逐步将业务重点转到软件项目管理。作为公司创立者的周铁人对包括敏捷开发在内的软件开发过程管理和项目管理也有着更为深入和全面的认识。基于多年的软件开发经验的积累，周铁人总结出了一套软件开发的方法论——SpecDD （需求驱动开发），并基于它推出了一套软件开发及项目管理的工具。
“让敏捷开发的团队有一个好的工具，更好地走上敏捷之路。这是我们推出SpecDD方法论及其相关解决方案的初衷。”周铁人说。
SpecDD是一个开发框架，旨在促进敏捷开发过程中的两个交付件：可执行的软件和量化的产品设计。周博士说，SpecDD的本质是一种混合开发模式，既兼容敏捷开发的快速、灵活的优点，同时又融入了传统软件开发方法在开发过程管理方面的优势。
因为敏捷开发否定了文档、流程，也几乎没有需求管理，而这些对于大型软件项目的管理非常必要。以需求管理为例，敏捷开发的入口只有一个简单的功能列表，而大型软件项目的需求涉及很多人，制订功能列表是一个比较复杂的过程，对工作量也需要进行预估。另外，由于敏捷开发没有需求管理，也就没有了需求用例管理，而这些用例对将来的测试是非常重要。
SpecDD要求软件的开发过程由一组连续的迭代组成，每次迭代都含有两个交付件：改进后的可执行软件，可以发布给内部团队和客户验证;改进后的“概念产品”，对原始需求更好的理解，包括需求、设计和质量标准的改进。可执行的软件可以用于市场的商业发布，并为企业带来成功。“概念产品”则在内部团队进行沉淀，并让团队在将来持续获得成功。
敏捷软件开发项目环节多，项目运行复杂，因此要改变旧式的分散管理模式，将成本管理、资源管理、风险管理及进度管理进行集中控制，做到管理统一。这样有利于项目成本的节约，项目资源的合理调配，项目风险的有效控制，保证项目的正常运行并顺利完成。[3]在做到集中管理的同时要侧重项目进度管理，对项目进度管理保持高度的重视。因为项目进度管理是整个敏捷软件开发项目的重点工作，各种因素都会对项目进度产生严重甚至决定性的影响，只有侧重项目进度管理工作，保持高度重视才能保证项目进度的顺利完成，避免项目延期甚至项目失败的情况。
2.2合理调配项目资源
敏捷软件开发项目进度的管理离不开项目资源的支持，其中最重要的就是资金、技术及人员的支持。资金支持不及时会导致项目进度的拖延;技术更新支持不及时会拖慢甚至暂停项目进度;管理人员及技术人员落实不到位会严重影响项目的整体进度，给敏捷软件开发项目的进度管理造成极大困难。所以，要合理调配项目资源，将整体项目的资金、技术、人员更多的投入到项目进度管理环节，保证项目进度的良好进行进而保障敏捷软件开发项目的顺利完成。
2.3及时处理约束因素
在敏捷软件开发项目的进度管理中要及时解决制约进度的各种因素问题，避免因项目资金、技术、人员、管理等项目资源的匮乏问题产生的进度滞后现象。出现影响项目进度的因素必须加大各种资源的投入，及时解决，保证项目进度。同时，问题的解决方式要在尽量满足项目进度的前提下寻找针对性的或者可替代性的解决方法，杜绝因困难问题难以解决而进行进度计划修改，保证项目进度，更好的做好项目进度管理工作。
2.4发挥人员主观能动性
在敏捷软件开发项目进度管理工作中要重视人的作用，激发其工作积极性与创造性，解决敏捷软件开发项目进程中的技术难题及工作适应性问题，丰富项目的人员、技术资源，保障项目进度的按期进行甚至因技术创新、管理有序而提前完成项目工期任务。
3结束语
关键链项目管理是一种先进的项目管理模式，能够为项目的正常运行直至顺利完成提供管理保障。基于关键链的敏捷软件开发项目进度管理，要做到侧重进度管理，及时解决阻碍进度管理工作的资源问题，合理调配项目资源，保证项目进度管理工作的顺利进行，进而保障项目的顺利完成。同时要结合实际情况，对敏捷软件开发项目进度管理进行科学合理的调整，保证项目完成的高质、高效。
参考文献:
[1]胡丹.基于关键链的敏捷软件开发项目进度管理研究[D].浙江工业大学，.
[2]张雪娇.基于关键链技术的敏捷软件开发项目管理研究[D].华中科技大学，.
说起敏捷开发，很多人第一反应这是一种开发技术，立马想到OOP设计原则、TDD、MDD、XP等等，
我理解的敏捷：
敏捷是一个过程，而不是技术。一个过程让团队成员爽、轻松、高效、产品质量过关，这就是敏捷的过程。TDD、MDD、oop等是实施过程中的一些方法，这些方法可能某些的团队实施起来让过程很敏捷，但是某些团队实施起来就不一定敏捷了，就像女人适合练 、男人适合练九阳神功，因为每个团队所处的环境、团队的水平都不一样，有很多的客观和主观的原因。
敏捷的基础：信任——你做事、我放心。
没有信任，就不可能有敏捷。想想老板、同事告诉你“你做事，我放心”，你是什么反映。
信任，意味着你有更大的权利决策更多的事情，同时也意味着你需要承担更多的责任，俗话说“这件事交给你了，你当家做主了”。
对于我们，我们应该怎么做：
1、 流程是否可以减少：
产品会议->需求评审->Kick Off ->设计评审->项目周会（晨会）->TC评审->发布评审 等等，我们是否每个项目都要按照一定模板，一个阶段一个阶段的实施。如果大家互相非常信任，是否还需要这么多的流程。我的理解，该省则省，视项目而定。有些小项目，UC可以简单点，设计可以不做，有些复杂点的项目，一步一步走，不要越级。就像如果拿着一个小东西，你跑没关系，跳着前进也没关系，但是背着一个很大很重的包，这时就跑步动了，那就一步一步稳稳当当的走吧（东北话，有点墨迹）。
2、 开会是否真的需要邀请那么多人：
我们发会议邀请，邮件列表里往往几十个人，运营、运营老大、pd、pd老大、开发及其老大等等，想想这么多人都是真的需要关注这件事情么，
3、 开会是否必须要到会议室
现在我们每次开会都要预定会议室，每次都很难订到，那么想想我们是否真的需要到会议室才能开会。开会，是找几个相关的人到一个不受影响（也不要影响别人）的地方，
一起讨论碰到的问题，或者宣布一些什么事情、汇报情况等。那么座位上，或者休闲吧、或者楼梯口、旺旺群邮件等是否也具有相应的功能。
4、 设计：过度设计。
我们在做设计的时候（需求设计、系统设计），经常听到这样的话“将来什么什么情况时，你怎么办”。想想，如果将来的情况你都能考虑到话，现在为什么不把做掉，
还要等到将来，或者说将来的多种情况你都考虑到，那将来还需要我们干什么，直接从你这几种方案里选一个就好了。现实当中，我们为将来做的设计，将来真的用上的，大家可以
举几个实际例子来看看，很少。当然，适当考虑一些是没错的，但是不要过多的考虑，否则就是过度设计，我们不需要为将来背太多的书，还是多花点精力盯紧当前的需求。
做一天和尚撞一天钟，你看和尚活得多爽。
5、 重构：随时重构、包括流程。
需求每天都在变，环境每天都在变，所以两年前很好的流程，很好的技术架构现在已经很不爽了，所以需要随时把不爽的，过时的流程、架构、代码
砍掉，换上与时俱进的流程、架构、代码。
6、保持学习：
社会在发展、环境每天都在变，我们不学习，会落伍的。
7、最后一点，敏捷不是一个人、一个部门的事情，是需要整个公司一起来做才能做好的事情，现在我们没做一个项目，都会涉及多人、多部门、甚至多个公司，需要大家互相理解互相信任。单纯一个人或者一个部门敏捷的过程是无法实施的。
Alistair Cockburn说这种说法完全不对：
谁提出观点并不重要，重要的是观点是否够好。
这引起社区中“我们对他们”的分裂，而不是“我们加他们”的合作。
与Nielsen提到的其他威胁不同，他并没有提出解决方案，所以把“我们对他们”这个悬而未决的问题留给我们，这是不能接受的。
建议方案:好的观点拿来用就行了——不要担心它们的出处。像Kurt Morris在敏捷可用性发贴中说的：“一旦消除了“我们对他们”的敌对心态，你就会见到令人惊羡的成果。”
Nielsen 继续提出这样的问题，敏捷习惯把故事分成更小的任务，这允许以不一致的方式开发功能，有可能掩盖了总的用户体验。他说，最糟糕的是“用户界面最终会看起来像缝缝补补”。Nielsen“s的解决方案是：
快速重复地执行可用性测试。他说“每周测试完全可行，即使在最短的sprint开发周期，也肯定能让你整合用户的多轮反馈。”
采取并行轨道，让可用性工作比开发工作更早一步完成。
采用不需编码的低仿真原型(比如纸)，把前面花费的时间减少到最小。
Jeff Patton 提炼了12个可用性的最佳实践(与Nielsen的相呼应)：
驱动：用户体验从业者是客户或者产品所有者团队的一部分
前期研究，建模，设计——但是只需要够用就行了
分解大块设计工作
采用并行轨道开发，提前工作，后期跟踪
从复杂故事中争取设计时间
培养用户验证小组，以方便持续用户验证使用
在单独轨道中进行用户持续研究，与开发分离
平衡用户多个活动的时间
开发前采用RITE方法对用户界面进行迭代
低真原型
把原型当作详细说明
成为设计的协调者
Jeff描述的RITE (pdf) 方法来自于微软的游戏工作室：“RITE与传统的可用性测试不同，它强调极快的变化，并验证这些变化的有效性”，
管理资料
具体来说，一旦发现问题，方案受到影响， 从业者就修改用户界面(原型或者应用程序)。在另一个参与者到来之前，诸如重命名按钮、修改菜单条目文字这样的变化经常发生。更复杂、但是很明显的变化是 越快越好，这样变化就能被尽快地测到。
除此之外，Jeff发现他的角色发生了变化：“由于我开始在敏捷团队内工作，我变得喜欢协同设计。我发现自己越来越多地扮演着协调者的角色：从大规模人群中收获信息并对信息建模。我发现自己同一群群的用户和开发者一起工作，撰写用户场景，起草用户接口设计。”
最后，Alistair 说道(在提到开发者/可用性分歧时)：“谨记住，”只有我们“。”
查看英文原文：Agile Usability
计算机游戏可以说是与计算机同步发展的最流行的软件。谈到游戏软件，大多数人都认为其神妙莫测，高不可及。而一般游戏软件也确实具有很高的技术难度，随着开发工具及软件开发方法学的不断发展，动手开发游戏也不是十分困难的。五子棋是一种古老而又有趣的游戏，五子棋游戏软件不计其数，并且不断推陈出新。网上就有好多关于实现的复杂算法和设计，其难度让一般初学者望而却步，本文旨在提出一种简单而不愚蠢的敏捷软件开发方法。
敏捷软件开发是一种相对传统软件开发方法而言的轻型方法。认为只要能适应软件需求变化的开发方法都是敏捷的。解决需求变化之路强调以人为本，强调个人能力及素质重于过程，强调能够工作的代码胜过面面俱到的文档。以下是以Delphi为开发工具的一个开发过程。
2 需求获取及系统设计
敏捷开发不再像传统过程把开发过程分成明显的阶段，在开始时，进行简单设计。在需求获取上，不是从细节上过分细致地讨论，而是稍微粒度大些，抽象出关键的、主要的类，简单设计的意思是不做过分设计复杂的算法，尽快做出能工作的软件或原型，在后面需求变化中不断调整目标。根据软件开发的一般步骤，进行需求分析，开始时不可能一步得到最终详尽的软件需求规格说明，只能对需求进行粗略描述：给出五子棋盘，供两个玩家对弈，可以人人对弈，也可人机对弈。从此可以看出，应设置两个类：棋类和玩家类。棋类提供棋盘，接受棋子，供玩家读棋盘状态。考虑到棋手只是一个参与者，只要会给出位置就以了，不必设置类只需增设一全局变量player表示当前棋手是黑或白即可。因此可写出棋类说明如下：
通过编写测试用例容易验证其正确性。
3 界面设计
界面设计与实现相分离，都以接口为中心，面向接口设计。具体的实现依赖抽象的接口，在开发的过程中，算法可能不断改进，可以在基类的基础上进行派生，利于实现封闭-开放性原则。根据类设计的相关原则，下棋、棋盘显示等都不应由棋类负责，其它的功能先由表单实现。根据单一职责原则适当的时刻分离出新的类来。新建表单form1,在其内添加一image对象，设置其picture属性为一棋盘BMP文件。当鼠标按下时，通过对位置的转换向棋类发出行列信息，即可实现下棋。
以上代码已能实现两人在计算机前下棋，但需要人工判赢。
4 不断响应需求变化进行增量迭代
如果要让计算机自动判赢，根据单一职责原则，增设一计算机类，让其判断在一条线上的某类棋子的数目，在棋盘中，有四个方向，在一条直线可能是由一点向两个相反方向的射线组成，根据抽象原则，应设置从某点向八个方向中的某个方向试探的方法。
在判赢时只要函数four(player,x,y)为真即为赢。到此想到，让计算机下棋就是让计算机找合适的、有利的位置，首先能守。当对手的棋子四个一线时，上述函数可以完成此功能。同样，对手的三个棋子相连也是需要防守的，以及两线交叉的致胜点等，因此计算机类增加以下方法：
在procedure TForm1.Image1MouseDown中的form1.drawxy(y DIV 35+1,x DIV 35+1);之后加上computer.select(player)就可实现人机对弈了。此时计算机具有一定的防守和攻击能力。
5 重构让代码清洁，以利于响应变化
代码是最重要文档，为了让代码利于交流、传播，必须不断对代码重构。根据重构的原则，在代码重复时，就要考虑重构，在一个方法中，如果语句行数起过30行，就要考虑重构，来保障代码的清晰易读。发现在computer类中有许多重复的语句，分别对它们进行重构。特别是对select重构时，发现一缺陷，只凭优先级找到的点，太简单，不能实现既对自己有利又堵了对方，另外，每一方法都是进行一遍扫描，即多次双重循环，就考虑用一个双重循环，经过分析设计得出按优先级加权求和的方法，并修改four等返回类型为整数类型。通过重构，代码更简洁清晰，并且以后很容易响应规则的变化，以利于软件的深度开发。以下是计算机类的一部分代码：
通过重构，此程序具有了较高的攻守能力，能达到中级棋手水平。容易增加模块实现网上两个选手的对弈，以及丰富其他功能。
6 总结
敏捷软件开发强调简单设计，不是设计复杂的扩展接口，而是重视代码的质量，及时重构，利于增加功能。代码即为设计，实行结对编程，利于交流和知识的传播。进行敏捷开发不仅是开发的性走之路，也是个人技术、素质提高的最好方式。
摘要：敏捷软件开发是一种相对传统软件开发方法而言的轻型方法,强调以人为本,尽可能少的约束开人员,利于发挥开发人员的的创造性,也是提高软件质量的根本。开发人员必须遵循敏捷开发实践,提高自身水平,游戏软件的开发是进行实践的好方式,本文以五子棋游戏开发为例,给出敏捷开发的一些关键实践,需求的敏捷获取、代码的重构及测试驱动等响应需求变化的敏捷开发方法。
关键词：游戏,敏捷开发,增量迭代,重构
参考文献
[1]Martin R C.敏捷软件开发[M].邓辉,译.北京:清华大学出版社,2003.
[2]Ken Auer Roy Miller.应用极限编程[M].唐东铭,译.北京:人民邮电出版社,2003.
摘 要：通过对CMMI尤其是CMMI-4体系及敏捷开发模式各自特点的分析，给出符合CMMI-4体系规范的项目敏捷开发模式，使之能在保证项目整体可控情况下，更快地响应用户的需求变化，从而提升用户满意度。
关键词：软件产品；质量保证；CMMI认证；敏捷开发
本文中涉及的项目类型为可视化实施类项目，此类项目的内容为根据用户的需求，进行展示场景的设计，并使用公司自主开发的可视化平台进行配置实施，其特点为用户的需求不定且变化非常频繁，配置实施的成本/效能为线性关系，因此本质上项目组欢迎变化并有能力进行快速响应，因为这并不会带来额外的成本投入，并可显著提升用户满意度。
敏捷软件开发又称敏捷开发，是从 1990 年开始逐渐引起广泛关注的一种新型软件开发方法， 是一种应对快速变化的需求的一种软件开发能力。敏捷开发的核心思想是：以人为本，适应变化。
敏捷软件开发突出如下四点： ①个体和交互胜过过程与工具；②可以工作的软件胜过面面俱到的文档；③客户合作胜过合同谈判；④响应变化胜过遵循计划。
敏捷过程具有下列五项共通的特性： ①客户与项目组人员形成密切合作的团队，共同努力达成项目目标；②项目最终的目标是提交给客户需要的工作产品， 因此所有的中间产品必须经过审慎评估；③采用增量、迭代方式分阶段进行；④过程可以简单，但规划与执行必须严谨；⑤强调团队合作，赋予高度的责任，团队有自主权得以因应变化做调整。
敏捷开发的适用项目的选择条件： ①相对比较成熟的产品团队；②开发技术架构稳定；③项目人员能力较强；④具备较强的自我学习和较高的管理能力；⑤当前进度要求不紧迫。
1 敏捷模式的建立
可视化实施类项目的敏捷研发模式是参考业界各种敏捷开发流程，经过团队实践总结出的项目开发流程及实施模型。该模式通过产品Backlog整理产品需求，并通过迭代Backlog将需求按照迭代次数分解，每个迭代推荐以2周时间为一个Scrum周期，在迭代过程中团队通过每日站立会议沟通项目进展以及问题，在每个迭代结束时，交付可用的增量产品。该模型引导团队敏捷迭代、小步快跑，持续交付有价值的产品。以反馈→需求→迭代→发布为主线，贯穿整个敏捷开发生命周期。（表1）
1.1 需求阶段
在项目启动之初，应确定项目的愿景目标，并与用户达成一致。通过关键目标分解和用户反馈，收集所有需求归总需求池；PDM从需求池中整理出一份按重要性排序的需求列表。需求列表至少包括场景编号、描述、目标、重要性等。PDM定期维护需求列表（注：“重要性”是对目标、对用户而言的重要性，不等同于“优先级”）。根据项目的实施计划，由PDM和SM在需求列表的基础上，分解细化扩充关键字段， 把原始需求拆分成最小颗粒度的用户故事，以方便团队拆分任务（Task）、估算开发时间、领取开发任务，从而规划出一份Product Backlog，如：规模、场景内容、优先级等。
1.2 计划阶段
项目在启动阶段与其他项目类似，需要制定整个项目的总体计划以及其他附属计划，包括：配置管理计划、测量与分析计划、质量保证计划等。需求负责人、项目经理以及项目团队应该对项目的风险进行管理，并在每次迭代中持续进行风险管理。同时，项目经理需要明确各阶段目标，并确定大概的时间范围。
在每次迭代规划会议中，项目经理和团队成员根据各阶段目标，对Product Backlog中的用户故事进行排序，选取合适的用户故事进行本轮迭代，并为每一任务分派合适的人员。
1.3 配置实施
在配置实施阶段，项目组需要每日对配置成果进行检查，它体现的思想是每天都可以交付新功能，每天都可以展示产品现状，交付产品价值，及时获取反馈。鼓励团队提交工作成果，帮助团队及时收到反馈并修正错误，持续、频繁的集成将集成化风险降到最低点。可视化实施类项目直接在用户环境中进行配置，用户会持续对配置的阶段成果进行验证及确认。
1.4 测试阶段及用户反馈
在项目进行过程中，时刻保持用户的积极参与，能有效地降低项目的风险，避免不必要的理解偏差与变更。因此，项目组在配置实施阶段，定期召集用户方相关人员进行阶段成果评审，并持续跟踪用户反馈，由需求负责人整理后，以邮件、Excel等方式转给项目团队跟进处理，并把反馈转为Bug或需求。
1.5 过程跟进与总结阶段
因为敏捷模式下每个迭代周期都非常短，因此及时的沟通显得尤为重要。除项目组集中办公外，项目组必须进行每日站立会议，在会议上每个项目组成员都要发言，以Sprint Backlog为核心，每个人说三句话，昨天做了什么，今天准备做什么，有没有需要协调的问题。会议必须在15分钟内结束，因此在会议过程中只记录问题，不解决问题。会议不需要有详细的会议记录，但是必须有会议问题的列表及跟踪情况。
在每个Scrum周期结束后，需要有正式的迭代回顾会议，在会议上对本次迭代的数据进行分析，Review本次迭代过程中的所有障碍和问题及上个迭代针对过程改进措施的改进效果，对下个迭代中重点改进的问题及解决方案进行讨论。
2 敏捷模式与CMMI-4活动的对照
如表2所示，分析了一个迭代周期内主要项目活动与CMMI过程域的对照关系，可以看出，敏捷开发模式与传统的软件开发模型并无本质区别，也同样经历有需求设计实现测试的环节；而CMMI-4着重于对项目进行量化管理，而因为敏捷开发在工作量评估上采用故事点估算，且在迭代过程中使用燃尽图进行进度控制，因此敏捷模式与CMMI-4具有天然的亲和性。
3 具体实践及成果
在刚开始对可视化实施类项目进行规范管理时，因为使用的是适用于软件开发的瀑布模型，因此对项目进行中发生的变更应对不及时，项目过程中或多或少地存在着实际项目工作与流程不符的情况，有效的项目管控工作很难开展；尤其是在公司推行CMMI-4体系管理后，因为各项目执行阶段的无序性，导致很难收集到准确的度量数据，对建立准确的量化模型及实施量化管理带来了很大的难度。在尝试建立敏捷开发模式并采用其进行项目实施后，因强调“持续构建，阶段交付”，用户可以随时看到最新的工作成果。
参考文献：
[1]徐俊，彭章纲.敏捷开发过程与CMMI实施融合研究[J].现代计算
机，2011.12.
[2]James Shore， Shane Warden.敏捷开发的艺术[M].机械工业出版社，2009.
“赶紧来睡吧。”妈妈在被窝里大声喊道。“等一下，让我准备好明天的`衣服。”我一边走一边慢吞吞地回答。这是发生在我上一年级时候的事情。
“啊!老鼠，妈，快来呀!”还未走到卧室我就大声喊了起来。爷爷听到了我的叫声，连忙跑来问道：“怎么了，怎么了，有老鼠吗?在哪里?”“对……对，有……老鼠，就在我放衣服的那个屋。”我被吓得说话都结巴了。爷爷听了，就快速跑去捕捉老鼠了。
我赶紧站起来，跟在爷爷的身后，想看看爷爷究竟是怎么捕老鼠的。只听见爷爷压低声音急促地对我说：“把灯、手套、扫把都拿过来。”我不敢马虎，按照他的要求把一切都准备好，就开始捕鼠了。“爷爷，老鼠在柜跟前。”我激动地报告，“在缝纫机下面。”爷爷弯下腰观察了一番，便开始用扫把使劲儿一通打，不一会儿竟然发现，真的有一只老鼠躺在了地上。
有了这次经历，我发现爷爷虽然有点胖，但却像一只敏捷的“猫”。虽然十二生肖里面没有猫，可是我还是认为爷爷就是属“猫”的吧!哈哈……
也就是说，虚拟公司就像专门完成特定计划的`一家公司一样，只要市场机会存在，虚拟公司就存在；该计划完成了，市场机会消失了，虚拟公司就解体。能够经常形成虚拟公司的能力将成为企业一种强有力的竞争武器。
只要能把分布在不同地方的企业资源集中起来，敏捷制造企业就能随时构成虚拟公司。在美国，虚拟公司将运用国家工业网络――全美工厂网络，把综合性工业数据与服务结合起来。
以便能够使公司集团创建并运作虚拟公司，排除多企业合作和建立标准合法模型的法律障碍。这样，组建虚拟公司就像成立一个公司那样简单。
1.1 核心思想及模型框架
RUP可以适应小型软件项目开发的需要,但在小型项目中成功应用RUP的关键是剔除不需要的工件,选择合适的工件子集并保持这些工件非常简明。开发小型项目的时候,可以从RUP出发,并结合敏捷软ARUP结合了RUP严谨周密的过程框架和灵活多样的敏捷过程的思想,在整体框架上遵循了RUP的分阶段逐步演进的主导思想,在成本控制与核心实践上继承了敏捷方法的思想精髓。ARUP既是利用敏捷思想对RUP过程的适当剪裁,也是利用RUP思想对敏捷过程的合理扩充。ARUP是以用户为中心,需求驱动,小增量迭代,快速满足变更的有序的开发过程。
1.2 角色设计
ARUP软件开发过程的角色设置如下:①项目负责人;②客户代表;③系统分析师;④系统设计师;⑤系统开发人员;⑥系统测试人员。
ARUP最突出的特点是把客户纳入到软件项目的主要人员里面来,专人专职。项目开发中各种活动的执行需要担任不同角色的人员进行分工合作,一个角色可以包括许多人员,一个人也可以承担不同的角色。在ARUP中定义的角色,在实际开发中可根据需要在其中进行选择。
1.3 里程碑与过程阶段设计
根据RUP的软件过程框架并结合敏捷方法的特点,将ARUP的软件生命周期分为4个阶段:系统规划阶段、详细设计阶段、迭代开发阶段、产品交付阶段,分别对应4个里程碑:规划里程碑、详细设计里程碑、初步可使用里程碑、产品支付里程碑。生命周期模型如图1所示。
(1)规划阶段。是ARUP生命周期4个阶段中的第一个阶段,主要目标是确定项目的可行性,确定项目成功的核心与关键点并确定项目的范围,这一阶段主要沿用RUP的初始阶段的主要活动,并且要求在规划阶段不求面面俱到,抓住重点,抓住主要矛盾,对项目范围以及项目整体形成清晰的认识。规划阶段有4个主要任务:①确定系统的概貌及主要参与者;②确定系统的主要功能点;③模拟实现一个最为可行的体系结构解决方案(原型);④对系统的成本、进度等作出评估。
(2)详细设计阶段。详细设计阶段是ARUP生命周期的第二个阶段。详细设计阶段的目标是确定并创建系统体系结构的基准线,为系统生命周期的后两个阶段建立稳定的基础。在详细设计阶段要完成下面3个主要的任务:①更加深入细致的描述系统用例;②确定系统体系结构并建立体系结构的基线;③进一步精确费用预算和项目进度。
(3)迭代开发阶段。迭代开发阶段是ARUP生命周期的第三个阶段,迭代开发阶段的主要任务是通过详细设计、实现以及测试来充实一个完整的系统。要达到此目标,我们为ARUP过程设计了如下重要的实践环节:①根据系统的架构基线设计安排项目组人员;②建立完善的配置管理体系;③保持系统体系结构的稳定性;④按照需求的优先级制定迭代计划;⑤描述剩余的用例以及其他用户需求;⑥采用重构策略完善设计;⑦加强单元测试和集成测试;⑧频繁交付并不断反馈。
(4)产品交付阶段。产品交付阶段的主要目标是确保软件基本上满足用户的需求,圆满完成用户制定的系统功能。具体要完成的任务如下:①系统测试;②培训用户和维护人员;③完成产品验收测试,向用户交付产品;④通过得到的经验改进未来的项目。
2 ARUP的实例研究
2.1 项目背景
长沙邦创公司自动化办公系统是一个基于该公司内部网络环境的办公系统,提供了公司内部所有办公人员利用该系统进行文件发布、信息共享与传递、信息管理。项目开发时间3个月,属于典型的小型项目。
2.2 第一次迭代
规划阶段,拥有的主要工件有:一个经批准的业务案例、风险清单、初步项目计划、项目验收计划(其接受的标准是直接由客户做出的)、精化阶段迭代计划、初始用例模型。系统设计师在精化阶段,根据.net开发的特点决定采用多层软件架构。
根据系统软件架构的复杂程度选择构建阶段用到的开发工具.在精化阶段建立了测试环境并且开发测试,系统开发过程中使用的自动化测试工具为N Unit。在这个阶段中经过客户调研,确定了粗粒度的业务模型并通过了复审。
实际开发过程中,精化阶段只用了一周时间。最终,精化阶段产生的主要工件包括:粗粒度业务模型、软件构架文档、构建过程迭代计划;构建阶段,项目经理根据精化阶段的用例模型,确定第一次迭代要完成的功能。然后建模员建立系统模型,将各个要实现的构件组织成包。各个包中是详细的构件设计,每个构件由1个或多个类构成,整个系统模型是以“类—构件—包”的形式设计组装的。实施员根据系统模型进行代码编写和测试,构建阶段在第一次迭代过程中用了4周的时间,经过2次小的迭代。在构建阶段的迭代过程中产生的主要工件为业务模型和系统模型、构件、部署计划、产品化阶段迭代计划。
产品化阶段的重点是部署,部署最终在客户方完成。软件开发过程必须集中处理向用户发布高质量软件的所有必需活动,这个阶段中,构建软件的工作远远多于编写代码的工作。
2.3 第二次迭代
在经过了第一次迭代后,下一个迭代即第二次迭代过程中可以采取同样的步骤。经过使用第一次迭代的系统后,发现存在以下问题:①界面操作不方便;②应提供安全的网上数据传输;③对于输入数据的一些格式需要加入一些提示,减少用户输入的出错几率。
把这些作为第二次迭代的目标,进行第二次迭代。界面的改变由客户、开发人员、设计人员共同来完成,直至达到客户的要求为止。增加的新功能按照第一次迭代中的过程,重新进行开发。
2.4 实例开发总结
本系统开发过程以ARUP为指导,采用了两次迭代完成了项目。在项目成功交付后,做了一些统计及总结工作,并与另外一个2005年初采用结构化生命周期法开发的项目相比较。其中,有4个人同时在这两个项目中进行开发。如表1所示。项目于2008年8月4日启动,在2008年11月7日交付第一个版的可用系统。与其它阶段相比,构建阶段花费了更多的时间。这种情况通常发生在一开始并不清晰需求,需要在项目期间不断澄清的项目中。经比较可以看出,采用ARUP开发项目可以缩短开发周期并减少开发人员工作量。
3 结束语
RUP和敏捷软件开发方法的目标对象和适用环境各不相同,在理解其精神实质和基本原理的基础上灵活运用,根据项目和团队的实际情况剪裁出适合的过程体系,对团队生产率和产品质量有显著的影响。ARUP是RUP和敏捷软件的适当结合,它采用迭代式开发,吸收了RUP过程中设计与文档的特点,又遵守了敏捷软件开发中的快速开发、重构、测试驱动开发等原则。一方面适合了小型软件项目开发的实际情况,不必使开发者陷入过分设计而导致开发进度缓慢的困境,最终达到进行快速、和谐开发系统的目的。
参考文献
[1]Rational软件公司.Rational Unified Process[EB/OL].[2000-02- 20].Http://www.rational.com.
[2]Abrahamsson P,Salo O,Ronkainen J,et al.Agile softwaredevelopment: review and analysis[EB/OL].http://www.inf.vtt.fi/pdf/publications /2002/P478.pdf,2006-03-18.
[3]孙晓阳.RUP在中小型软件项目开发上的应用[D].长春:吉林大学学位论文,2004.
一月份，《纽约客》发表了一篇关于关于头脑风暴的文章“团队思考(Groupthink)”。
头脑风暴看上去是一项完美的技巧，是一项感觉很好的、能够提高生产率的方式，但是头脑风暴也有问题：它并不工作。
在引用众多的案例之后，文章在最后的结尾处写道：
头脑风暴并没有释放团队的潜力，反而恰恰降低了每个人的创造性。虽然初始的发现并没有影响头脑风暴的流行，但大量的后续研究都得 出了相同的结论。华盛顿大学的哲学家Keith Sawyer这样总结道：“数十年的研究一直表明进行头脑风暴的团队思考出的想法远远少于那些独自工作、之后再汇集想法的人们。”
的确，头脑风暴并非一项必要的敏捷技巧，而且或许在很多敏捷团队里面根本不会被应用，但是团队办公室、团队工作以及结对编程又如何呢?
Susan Cain最近做了一个非常受欢迎的TED演讲“内向的力量”。她的演讲以及随后的博客文章把目标对准了我们针对外向与团队工作的偏见：
正如Cain所言，独处是创造性的关键。达尔文在树林中漫步，拒绝晚宴的邀请;Seuss博士独自写作，并且担心遇见阅读自己书籍的小朋友，因为害怕他们在看到自己是如何安静时会失望。史蒂夫·沃兹尼亚克声称如果离开房子，他就从来也不会成为专家。当然，合作也是好的(睿智的沃兹与史蒂夫·乔布斯)。
我们从哲学中的所学也证明了这一点。我们不可能处于人群之中，却不去本能地模仿其他人，而且团队会追随最有个人魅力的人，即使好的演讲者并不一定拥有好的想法。(TED听众迟疑了一会，然后全场哄然大笑。)
作为演讲的结束，她最后号召行动起来：
“结束无时无刻不团队的疯狂吧。”(听众鼓掌。)办公室需要交谈讨论，需要宽敞的空间促成偶尔为之的交互。但是我们需要更多的私密性、更多的自治。对于学校，这也是正确的——极为正确的。没错，要教育孩子合作，也要教育孩子如何独自工作。
她关于“变化正在来到”的说法是对的，整个礼堂的所有听众，无论外向内向，都起立报以长时间的热烈鼓掌。
最近，Jon Evans在Tech Crunch上撰写了一篇关于办公室空间以及结对编程的文章“结对编程是有害的吗?”
像旧金山的Pivotal实验室以及多伦多的Xtreme实验室这类传奇性的开发公司已经100%地采用了结对编程，取得了非常显著的成功，
管理资料
好极了!问题解决了，对吧?
⋯⋯并非如此。
《纽约时报》上，一篇谴责“新团队思考”的文章里面指出“研究表明人们在享有个人空间以及不被打扰的自由时创造力更优⋯⋯让顶尖公司程序员脱颖而出的因素不在于更好的经历或者更高的薪酬，而在于他们能享有多少个人空间、个人工作区以及不受打扰的自由。”文章还引用了史蒂夫·沃兹尼亚克的观点：
“独自工作⋯⋯不是在委员会里面，也不是在团队里面。”
尤其是开敞式办公室，看 上去是一个非常糟糕的想法。英国的第四频道(Channel 4)在最近的一次分析中指出“开敞式布局创造了大量的分神之物，破坏了生产率。” 新闻(Hacker News)也有相关的评论，其中不乏珠玑之语，比如“大多数现代办公室布局都似乎是为了整天激发人们争执或者争执本性”以及“我个人是安静型，我经常需要 时间独处以思考和编写代码与文档。“叽里呱啦”的社交型迫使我们匆促行事⋯⋯我日益痛苦和怨恨。”
Jon也总结了一些结对有利于创造性的证据：
独自工作利于创造性——但是与其他思维方式不同的人一起结对可以导致更有创造性的结果。
并总结道：
最合适的答案是这里不存在唯一的答案;要想效果最好，就要根据具体场景，通过你的判断，将独处、结对以及团队工作动态地结合。结对编程并非一无是 处。(Betteridge定律又一次大获全胜!)在有些情况下，“大部分时间”里面都可能要结对。但执着于100%的结对只是欠思考的教条主义，而且正 如所有的欠缺思考的教条主义，最终反而适得其反。
另一篇主题为“社交媒体如何投合外向性格人士”的文章指责了社交媒体背后的技术公司：
我要指责马克·扎克伯格(Facebook创始人)。当Facebook在二月初推向公众时，那位眨着天真眼神的CEO给投资者发了一封邮件，将Facebook描述成不是一家公司，而是某种宗教意义的宗派——这使作为Facebook领袖的扎克伯格成为某类社交的传教士。扎克伯格将Facebook形容为“为了完成社交的使命——让世界变得更为开放与互连——而创建。”
为众人熟知地是，扎克伯格支持拥有开敞式布局以及玻璃墙的办公场所——正如属于他的梦想世界的隐喻。这是一个例子，社交媒体“一切免费(free-for-all)”的本性正渗入真实的世界，这对于像我们这样喜欢原来的墙的人是一个问题。
我猜想Facebook里面不会有太多内向性格的人。
敏捷是否应该为倡导这些理念而受到指责?这些年中，敏捷是否让内向性格的人和创造力走开?果若其然，又该如何?现在应该回归格子间吗?
【敏捷的反义词】(以下词语任选其一)
痴钝；缓慢；迂缓；笨拙；迟缓；迟钝；好听的字
附录词语（敏捷）的相关知识：
【敏捷的.意思】好听的军团名字
（形容词）(动作)迅速而灵敏。多用于书面语。
【敏捷的例句】
他身手敏捷。（作谓语）；他身手敏捷。（作谓语）
【敏捷的近义词】(以下词语任选其一)
麻利；赶快；飞快；机敏；敏锐；急迅；圆活；灵活；精巧；伶俐；矫捷；快捷；火速；灵巧；乖巧；灵动；灵便；迅速；生动；迅捷；聪明；灵敏；快速；活络；明锐；讯速；
扩展：
才思敏捷造句
1、他是个才思敏捷的人，而且他做什么事都能胸有成竹。
2、我们班上的张兰是一个才思敏捷的学生。
3、他的学养深厚，兼以才思敏捷，自然出口成章。
4、苏轼苏辙兄弟的才思敏捷无疑也有其祖其父的文学遗传因素在其中。
5、他才思敏捷，什么难题都难不到他。
6、他才思敏捷，勤奋刻苦，每次考试都胸有成竹。
7、学生的知识经验增多了，人文素质提稿了，就会才思敏捷，写出既具一定的思想见解，又具有较丰富的文化内涵的好文章。
8、这位同学参加面试，答题的时候才思敏捷，应对自如。
9、要取得这次比赛的胜利，不仅要知识基础牢靠，还要才思敏捷才可以。
10、大学生对新事物接受能力强，才思敏捷，感情丰富。
11、一个功底扎实，广泛涉猎的学生才会才思敏捷，能说会写，才能较好地掌握学法，运用知识，形成较强的迁移能力。
12、1000字的作文，才思敏捷的他，半个小时就搞定了。
形容敏捷的成语：
1、巧能成事：巧：灵巧、机敏。灵巧机敏能成就事业。
2、随机而变：随着时机或情况而变化。形容灵活机敏。
3、眼疾手快：形容做事机警敏捷。
4、身手敏捷：身手行动灵敏迅速。
5、眼明手快：看得准，动作敏捷。
6、拿手好戏：原指演员擅长的剧目。泛指最擅长的本领。
7、手急眼快：急：迅速。动作迅速，眼光敏捷。形容机灵敏捷。
8、心闲手敏：闲：熟悉；敏：灵敏。形容技艺熟练了，心里闲静，手法灵敏。
9、眼尖手快：眼力好，动作快。
10、心手相忘：极言得心应手。比喻技艺纯熟或做事情非常顺利。
11、右手画圆，左手画方：比喻用心不专，什么事也办不成。也形容心思聪明，动作敏捷。
12、遂心应手：犹得心应手。形容运用自如。
