前言
前些日子，和一位朋友交流敏捷方面的话题，他所在团队实施敏捷开发流程，由于竞争的压力，产品需要尽快上市抢占市场，产品在匆忙开发、测试之后投入运营，上线后出现了一系列的问题，迫切需要快速的改进并投入运营；2008年是经济困难的一年，物价飞涨，与之合作的外包公司人员大面积的流失，问题也随之暴露出来：由于人员的快速更迭，产品知识的传递与衔接成为产品持续改进的重大障碍。于是他开始怀疑敏捷开发方法，困惑于敏捷开发方法该如何运作；
之前也和朋友断断续续的讨论过实施敏捷的话题，发现大家对敏捷缺乏一个全面、深入的认识，于是想做一个全面、彻底的梳理，以便于进一步深入的交流、探讨敏捷开发这个软件工程方法；
敏捷开发是近几年出现的新事物，其发展背景是互联网的快速发展和开源运动的蓬勃兴起；借助互联网的快速发展，互联网成为所有公司的无国界的巨大市场，所有公司从诞生的第一天就面临全球市场竞争；巨大的市场规模、多样化的用户需求、突发性的访问流量、海量计算基础设施、市场能量的快速辐射等都是互联网行业的典型特点；
我们也注意到，越来越多的公司为了实现更快的交付产品，实施全球研发部署，或外包或自建研发实验室，实现东西半球24小时滚动研发；如火如荼的开源运动动员了几乎全球的闲散力量，以一种更加松散的方式全球协作：开发人员开发程序，用户参与测试并反馈Bug和修改意见，创造出巨大的生产力，已经成为影响全球软件业市场格局的一支重要力量；
在这样的快节奏下，传统的软件工程方法无法有效的整合各种研发因素：快速演进变革的社会体系、不断变化的多样化的用户需求、需要更快的响应速度（针对用户）、活跃的用户社区、激烈的竞争要求更快的交付、研发成本的快速提高等；
怎么办？敏捷开发就在这样的需求驱动下破土而出，被业界广发关注和讨论，并在实践中不断完善；
因为敏捷开发没有一个系统全面的定义和解释，故无法以大篇幅的方式介绍，就以我们遇到的问题开始，逐个深入探讨探讨；
敏捷开发是不是一个全新的软件工程开发方法？
不是！
敏捷开发只是一系列实践原则，但由于它是构建在已有的软件开发模型基础上，虽然没有整理出属于它的完整的实践体系，但是它所总结提炼出的一系列的工程实践原则仍然能有效的指导软件开发过程，遵循之能取得显著的效果，故我们可以称之为敏捷开发模型；
敏捷联盟晒出了一系列的精炼的原则，但他们太过于抽象，缺乏可操作性，各人的理解、掌握各不相同，得到的结果也不尽相同，进而对敏捷的效用评价也不相同，有人说敏捷开发好，有人说敏捷开发不好，各执一词，只因道不同结果亦不同；为了改善这种状况，我们把对实践中的敏捷开发过程进行总结和归纳，我们提出了六个更具可操作性的原则：
1、以小周期代替大周期：瀑布模型、螺旋模型、快速原型等方法都有比较长的工程周期，常常要经历立项、需求、架构设计、详细设计、开发、测试等大的工程周期，耗时很长，很难看到完成的日子，更别说开什么庆功会了；敏捷开发强调使用小周期：需求、设计、开发、测试、发布，快速实现、快速验证、快速应用；
2、以小版本代替大版本：过去我们一般是在规划阶段规划为若干个大版本，一次性整体实现，大版本实现周期长、工程复杂，由于工程整体实现技术复杂、工程周期长，风险很大，常常出现延时和夭折；敏捷开发提倡在规划阶段就根据关键成功因数和团队工程能力规划为多个小版本，团队通常情况下只需要稍加努力就能够完成，大部分情况下版本如期发布，这样更有利于激励团队，使团队保持良好的战斗力；
3、以重构为基础，系统高度组件化、接口化、可扩展，强调契约设计；敏捷欢迎变化，甚至有可能推倒重来，而能实现这一特征的唯一法门就是不断重构，在重构中融入变化甚至是结构性的变化，重构是敏捷开发的常态行为；
敏捷开发实现的系统是低耦合、可扩展的，系统被打散为多个不同职责的组件，协作完成整个功能；组件是责任的实体，组件之间通过公开的接口交互，契约是组件间交互行为的语义表达；
4、以变化适应变化：敏捷强调小周期、小版本、快速重构，所以新需求总能很快找到并入系统的时机，新需求一旦提出即可进入开发视野，根据重要性排除优先级，即刻设计实现并测试发布；敏捷也重视团队中人的变化，团队犹如一个变化的泡泡，不同阶段具有不同的形态，由于周期短，人员得到快速调整的时机和机会；
5、重构重视人的能动性，强调用户参与；小版本规划的功能少，容易实现，容易发布，使团队很快就能尝到成功的喜悦，团队在成功的激励下走向下一个成功，这个行为具有很强的社会心理学基础：成功激励成功；
心理学实验表明：一个人面临的挑战强度太低或者强度太大，都会士气底下，进而不重视；挑战强度太低，轻而易举的取得成功，两三次之后就会提不起兴趣了；挑战强度太大则很难看到成功的希望，容易自暴自弃，也会造成士气低；根据团队的能力制定适度的版本规划是很重要的，它能保持团队良好的士气，使成功的喜悦迷漫在成员的心头；
用户在表达其构想时常常无法完整的表达出来，唯有我们做出来演示给其看时，他才会说：“哦，就是这样子；这里还需要改一下！我想法是这样的。。。“，用户参与能清晰、有效的获取其真实意图，通过不断的确认、修改而实现用户满意的交付件；
6、发布是一件轻松愉快的过程；敏捷开发提倡尽早交付，也由于采用了小周期、小版本，开发过程中不断的有版本构建出来用于测试、验证、评价、归档，因为发布的过程仅仅只是从众多的版本中挑选一个合适的版本交付给最终用户使用；这样的状态下，发布过程是非常轻松愉快的；
敏捷开发最少需要开发和维护哪些文档？
软件终归是人来维护，业务知识和技能的传递就成为产品可持续发展的一个重要因素；但现实中的情况是大多数人不喜欢编写文档、也不太喜欢研读文档，因此太多的文档只会消耗团队有限的时间，并不能带来多大的好处；
敏捷开发重视文档的作用，也重视文档的维护；它认为文档宜少且精炼，一般情况下建议开发并维护三份文档：
《软件需求规格说明书》或者《产品规格说明书》：定义软件应该具有的功能、边界等，使软件相关的涉众对软件有一致的理解，它作为用户同开发团队之间共同的讨论基础，并在开发过程中不断的更新维护；
《架构设计文档》：软件如何实现，内部之间是什么关系？
《项目管理计划》：计划如何分期实现、测试、发布等；
敏捷开发是否需要系统设计？
敏捷开发是以小周期代替大周期，小周期包括：需求、设计、开发、测试、发布，这个过程中是包括设计环节的，也就是说需要做系统设计；
由于做完整的设计需要有相对完整的资料和比较长的时间，与小周期是相对立的，因此敏捷开发不主张高度细化和完整的设计，提倡做出一个大粒度的框架性设计，一般指架构设计或者系统设计，避免在以后的重构中发生架构级别的变化，然后在逐步实现的过程中逐渐深入展开、细化；
传统的一些设计方法比如结构化设计、面向对象分析(OOA)、面向对象设计(OOD)、自顶向下、快速原型法都是可以融入敏捷开发过程中加以使用的；
敏捷开发是否需要编写文档？
一份概要性的高阶的文档是用户和开发团队之间的契约，双方的一致理解有助于沟通和互动；用户只关心他要什么，不关心如何实现，更不关心实现有多难，所以我们不能奢求用户理解我们遇到的技术问题，甚至读懂我们的代码或者注释；
敏捷开发主张最起码需要一份文档《需求规格说明书》或者《产品规格说明书》，并不断更新和完善之；这份文档用于界定产品的边界，便于和用户沟通；
百家之言：
Jack Reeves,
敏捷开发是否需要项目计划？
商业软件开发需要承担获取利润的责任，因此对产品的功能完整性、稳定性、即时性等都有较高的要求， 它是一种有组织有目标的行为，因此它需要项目计划，但这个计划是一个短程计划，根据未实现的功能情况、前一个版本的反馈和组织目标制定开发计划；唯有这样才能不断的融入新的变更；
敏捷开发的迭代周期大概多长？
敏捷开发的迭代周期没有硬性的规定，结合组织目标、功能实现情况、产品稳定性综合决定，如果产品用户活跃、功能实现难度小、维护复杂度低，建议以月为周期；对于规模比较大、维护复杂度高的产品，考虑以季度、半年为周期发布较为合适；
频繁的发布会降低用户的期望并提高用户成本，给用户心理上带来额外的负担：他会认为产品质量低，质量控制不严谨等；
敏捷开发为何提倡小版本？小版本有哪些优势？
小版本的目的就是分解复杂度、降低风险，改善团队士气等；小版本有众多优势，我们一一道来：
Ⅰ、总体风险比较少：小版本变化小，总是在上一个版本基础上局部调整和增加，技术复杂度低；由于规划的功能较少，工作量也易于估算，所以其总体风险比较少，常常能如期发布；
Ⅱ、需求的接纳能力强：由于小版本快速实现并发布测试，然后就进入下一个版本的规划实现周期，这样新需求一旦提出就能快速进入开发视野，就能尽快实现；
Ⅲ、测试和开发高效协作：开发和测试可以并行工作，当开发实现第一个版本时，测试设计测试方案和用例；发布第一个版本后，开发就进入下一个版本轮次，测试就应用测试方案测试刚才发布的版本，提交Bug；开发在下一个版本结束时修正所有上一轮发现的Bug，然后发布新版本，如此循环往复，开发和测试实现高效协作；
敏捷开发与重构的关系如何？
敏捷开发以重构为基础，时时刻刻处于重构过程中；
敏捷开发为何强调团队人员的参与、用户的参与？
人是一切关系的主体，是生产力提升的主体；敏捷强调团队成员的高度参与就是要统一认识，把团队的目标变成每个人的工作目标，使之为每个团队成员的认同，形成高度的凝聚力，以达到群策群力、高效协作的效果；
由于没有高度细化的文档，成员之间交换信息的唯一渠道就是面对面沟通，良好的团队氛围和协作关系促进这种沟通，并使消息准确有效传达；
用户由于缺乏专业训练，无法清晰、准确的表达其意图，导致需求的歧义和模糊；用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善；在用户参与过程中，我们常常可以听到这样的话：
“是的，就是这样的”
“这正是我想要的。。。”
“这里需要修改一下。。。”
“我的想法是这样的。。。”
在这个过程中，用户承担了一部分测试人员的角色，而开源软件开发过程中，用户承担很大一部分测试工作，用户已经成为研发团队一员；
我们努力做的事情就是实现用户需要的东西，并最终让用户喜欢它，唯有用户喜欢它才能用好它，那么我们怎能不认真听取用户的意见呢？
一句话总结就是：用户参与帮助我们做正确的事情！
怎么才能评估我们团队和开发过程已经敏捷了？
由于敏捷开发没有标准的可供参考的实践过程，所以很难通过某个过程而断定其开发过程敏捷了，那么我们如何来评估我们的团队和开发过程是敏捷的呢？这里采用办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷，我们认为评估项目团队和开发过程是否已经敏捷的方法如下：
1、 团队有共同的愿景，并且对这个愿景充满信心
2、 团队有明确的阶段目标并且为每个成员所知晓；
3、 团队知晓当前计划：做什么、何时完成、预期效果等
4、 团队任务是低耦合的，并且紧密协作；
5、 发布过程是轻松愉快的，构建版本并不断测试是常态行为之一；
敏捷开发能缩短项目时间并提高质量吗？
敏捷开发能缩短项目周期并提高整体质量吗？能，但我目前无法提供量化的数据做参考，只能从几个方面评估和推断：敏捷开发是能缩短项目时间并提高质量的；
1、 用户的参与帮助团队把功能一次性完成并做正确，缩减了返工的时间；
2、 不断的重构和测试发布能把问题发现在早期，整体质量显著提高；
3、 过程目标导向，使团队高度集中于项目目标，提高了生产力；
4、不断的发布对团队是种正向激励，荣誉感和成功欲使团队保持持续的激情；
附录：敏捷联盟发布的敏捷宣言和敏捷12原则
敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷价值观，遵循敏捷的原则。
敏捷的价值观如下：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
由价值观引出的12条敏捷原则：
1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3、经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5、围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7、工作的软件是首要的进度度量标准。
8、敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9、不断地关注优秀的技能和好的设计会增强敏捷能力。
10、简单——使未完成的工作最大化的艺术——是根本的。
11、最好的构架、需求和设计出自于自组织的团队。
12、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
