【软件工程】敏捷宣言

【转载】：

敏捷宣言以及敏捷开发的特点 - 鸿鹄当高远 - 博客园

敏捷宣言的简单介绍 - SuperZhang828 - 博客园

http://agilemanifesto.org/iso/zhchs/manifesto.html

http://agilemanifesto.org/iso/zhchs/principles.html

最近在复习软件工程，对敏捷宣言并不是很理解，因此搜集并整理了一些资料，方便自己复习。

敏捷宣言

敏捷宣言，也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。

 

敏捷宣言强调的敏捷软件开发的四个核心价值是：

• 个体和互动高于流程和工具
• 工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划

1、个体与互动高于流程和工具 

       敏捷开发的第一条价值观就是“ 以人为本”，强调“ 个体（人）” 及“ 个体” 间的沟通与协作在软件开发过程中的重要性。这个顺序不是偶然而为之的，敏捷开发将重视个体潜能的激发和团队的高效协作作为其所推崇的第一价值观。这意味着虽然流程和工具重要（尤其是大型组织），但是它们无法替换有能力的个体和高效的互动。个体的技能和他们之间的互动才是最关键的。

• 当我们开发产品、解决问题或改进工作方式时，我们要寻找改进互动和提高能力的方法
• 在项目期间，产品管理和开发团队必须在一起工作
• 在项目期间，架构师、设计师和测试人员必须每天在一起工作
• 面对面沟通是极其重要的，它不能被其它形式完全替换

2、工作的软件高于详尽的文档 

　   敏捷开发的第二条价值观就是“ 目标导向”。同其他众多管理理论和模型一样，敏捷开发认同目标导向是成功的关键，因为没有目标也就无所谓成功。敏捷开发的价值观中清楚地阐明，软件开发的目标是“ 可工作的软件”，而不是面面俱到的文档。而遗憾的是，很多软件项目已经在纷繁的文档之中迷失了自己的目标。这意味着已集成、已测试、潜在准备发布的产品才是关键度量，它能够有效地跟踪项目进度和对发布做出决策。

• 要以小步增量的方式构建产品：做一些分析、设计，然后开始编码和测试以验证设计
• 设计需要做，比如敏捷建模工作坊(设计与文档不一样)。如果需要传递信息给客户、维护工作的人员，简易文档还是必要的
• 好架构是持续开发产品的关键，架构是设计出来的，建立一个可实现的简单架构是持续化开发的第一步。随着时间的推移，架构会演进，所以持续追求卓越技术和好设计能够增强产品敏捷性。

3、客户合作高于合同谈判 

        敏捷开发的第三条价值观就是“ 客户为先”。虽然敏捷开发强调的第一价值观是“ 以人为本”，但敏捷宣言的缔造者们并没有忘记客户，相反他们真正的理解客户的需求、懂得如何与客户合作。敏捷价值观里强调的“ 客户为先”即不是简单地把客户当作“ 上帝”、刻板的推崇“ 客户至上”，客户要求什么、我们就做什么；也不是把客户当作“ 谈判桌上的对手” 甚至“ 敌人”，去斗智斗勇。敏捷价值观把客户当成了合作者和伙伴，把自己的使命定位为“ “ 帮助客户取得竞争优势”。这意味着我们应该超越谈判并尝试提升与客户的合作。我们还应该建立以合作为基础的关系，而不是靠公司内的正式接口。

• 在实践中，意味着产品经理、市场或销售人员在产品开发期间要经常从客户那里请求反馈并排列优先级。
• 在与我们自己的业务方合作中，我们应该寻找开发期间增进和改善合作的方法。
• 产品管理和开发应该密切合作，而不是通过契约或手续。

4、响应变化高于遵循计划 

　　敏捷开发的第四条价值观就是“ 拥抱变化”。人们常说“ 世界上唯一不变的就是变化”，大多数人也相信事实确实如此。而以往很多的软件项目却忽视了这一点，或者更准确地说是他们不愿意“ 正视”。他们总是试图用详尽的计划去预先穷举这些变化，然后又试图通过严格遵循计划来控制变化的发生，而结果往往是被不断涌现的变化击垮。敏捷开发价值观中承认变化是软件开发的一部分、并相信正是客户在不断变化其需求的过程中明晰了其真正的需要。因而敏捷开发欢迎变化、拥抱变化，并可坦然应对变化，正是这些变化为客户和项目带来了价值。这意味着欢迎需求变化，哪怕是开发后期。

• 首先，预先知道所有需求是不可能的。每个项目都会有浮现和继承的需求。
• 如果我们对客户需求变更做的好，我们就会增强客户的竞争优势还有我们自己。
• 为了鼓励响应变化并使其更容易操作，需要建立流程和工作方式。承认计划的不确定性
• 计划是必要的，但计划必须适应变化：我们需要持续调整计划。前期花很长时间制定详尽的计划的结果会导致大量的返工。同时，我们需要有足够的计划水平来评估业务需求和对其长期影响的判断。这是一种平衡的艺术。

最后，还应记住敏捷宣言中的最后一句话：“ 尽管右项有其价值，我们更重视左项的价值”—敏捷宣言并未否定或贬损“ 右项” 的价值，在敏捷开发的价值观中承认“ 流程和工具”、“ 详尽的文档”、“ 合同谈判” 以及“ 遵循计划” 的重要性，只是两相比较，“ 更重视左项的价值”。

敏捷软件的十二条原则

1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

      客户满意和有价值的软件是关键词。要确保我们开发的软件产品能够给客户带来真正的价值，这完全取决于在开发期间与客户的密切合作。产品管理是确保客户需求在开发期间被正确理解的关键。我们应该集中精力在对客户最有价值的工作上。

       尽早并持续交付的能力是满足客户的关键。及时交付部分功能比最后交付全量功能更好，至少我们应该给我们客户一个选择。

2.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

  我们的目标是为了开发能够帮助客户提升价值的产品，要支持任何变化。变化不是一种否定，它体现了团队和产品负责人在敏捷开发过程中的一种工作方式。

3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

     开发周期和发布周期完全不同。尽管有发布周期，但我们的目标是短开发周期。发布周期的长度依赖业务决策，并且和客户的期望紧密关联。短开发周期的频繁交付缩短了反馈周期并增强了学习。频繁交付还能让团队及早暴露弱点并及时移除障碍，增加了敏捷性和灵活性。   

4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。

     只要在业务和研发之间建立起桥梁，我们就能从中受益。业务人员和产品管理知道市场状况、客户需求和客户的价值。开发团队知道产品和技术可行性。如何将这两方面结合？我们需要作出睿智的决策。

5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

     知识类工作(比如软件开发)是由具有技能和激情的人来做的。为了激发个体的斗志和创造力，自由是最重要因素。要让角色去适应人而不是让人去适应角色。   

6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

      面对面交谈在分布式开发中尤为重要。当我们看到人们彼此交谈时，信息更多以听说的形式被传递。文档(虽然它很重要)不能代替交谈，将每件事都写下来简直是不可能的。我们不应该只依靠写文档来传递重要信息。

7.可工作的软件是进度的首要度量标准。

     跟踪有多少功能已经实现，集成，测试是一种更可靠的进度度量。    

8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

10.以简洁为本，它是极力减少不必要工作量的艺术。

11.最好的架构、需求和设计出自自组织团队。

12.团队定期地反思如何能提高成效，并依此调整自身的举止表现。

 

敏捷开发的主要特点

与传统开发方法相比，在敏捷开发的整个过程中，有以下几个主要的特点：

（1）敏捷开发的过程有着更强的适应性而不是预设性，从敏捷宣言的第四条响应变化高于预设计划便可以看出来。因为软件开发过程的本身的不可预见性，很多用户在项目开始时不可能对于这个项目有着一个完整而明确的预期。很多对软件的预期都在后期的修改和完善过程中产生。因此高适应性显然更加符合软件工程开发的实际。而敏捷开发实现其适应性的方式主要在于，第一，缩短把项目提交给用户的周期；第二，增加用户，业务人员，开发人员这三者之间的交流；第三，通过减少重构的成本以增加软件的适应性。

（2）敏捷开发的过程中，更加的注重人的因素。在传统软件工程中，个人的因素很少的被考虑到分工中，每个个体都是只是整个代码开发机器的一个小小的螺丝钉，个人的意志和创造力很大程度上的被抹去为了更好的为集体服务。而在敏捷开发过程中，每个个人的潜力被充分的考虑，应用什么技术很大程度上直接由在第一线开发的技术人员决定；每个人的特点和创造力都可以充分地发挥，这样开发出来的软件更加的具有生命力，因为他融入了开发者的心血和创意，开发者不再是进行机械的乏味的堆砌，而是创造属于自己的艺术品，这样的条件下产生的代码必然在质量上更占优势。

（3）在敏捷开发的过程中，整个项目是测试驱动的而不是文档驱动的。不仅每个模块有着自己的相应的测试单元，开发人员在开发自己的模块的过程中必须保证自己所开发的模块可以通过这一单元的测试，并且集成测试贯穿了整个开发过程的始终。集成测试每天会进行十几次甚至几十次，而不是像传统方法一样只有当各个模块的编码都结束了之后再进行联合调试。这样，在软件开发的进程中每一点改动所引起的问题都容嘉容易暴露出来，使得更加容易在错误刚刚产生的时候发现问题从而解决问题。这样就避免了在最后整个系统完成时错误隐藏的太深给调试造成极大的困难。

 

敏捷开发与传统开发方法的比较

优势

敏捷开发的高适应性，以人为本的特性，和轻量型的开发方法即以测试为驱动取代了以文档为驱动，这三个主要的特点，也就是敏捷开发相对与传统开发方式的主要有点。因为它更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。

 

敏捷确实是项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品。敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。

劣势

与传统开发方式相比，敏捷开发的最主要的劣势在于敏捷开发欢迎新的需求，而在每次新的需求产生时都可能引起整个系统的大幅度的修改。因为开发者在开发上一个版本的时候，完全没有考虑以后的优化将要如何进行。这样的开发方式实际的软件开发过程中，并不一定总是有效的。

而另一个方面，敏捷开发因为缺乏很多在敏捷开发中被认为“不重要”的文档，这样在一个大型项目比如一个操作系统开发的时候，由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。

 

敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。

需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题。