在敏捷开发之前，我们常用的开发模式是瀑布模式。然而，这种模式有很多问题，包括不能很好的响应变化，容易开发出庞杂而难以理解的系统，导致维护和二次开发变得很困难等。此外，这种模式还会降低团队的开发效率，使得团队经常创建错误的产品。其原因在于这样的过程缺乏实践指导和外部过程管控。即使在现在，国内还有很多公司采取的是瀑布式开发模式。

一、敏捷联盟

01年初，由于看到许多公司的软件团队陷入了不断增长的过程的泥潭，一批业界专家聚集在一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则。他们称自己为敏捷联盟。之后他们创建出了一份价值观声明，也就是敏捷联盟宣言：

敏捷软件开发宣言

我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：

• 个体和交互        胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作            胜过 合同谈判
• 响应变化            胜过 遵循计划

虽然右项也有价值，但是我们认为左项具有更大的价值。

1、个体和交互胜过过程和工具

人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。

一个优秀的团队成员未必就是一个一流的程序员。一个优秀的团队成员可能是一个平均水平的程序员，但是却能够很好地和其他人合作。合作、沟通以及交互能力要比单纯的编程能力更为重要。一个由平均水平程序员组成的团队，如果具有良好的沟通能力，将要比那些虽然拥有一批高水平程序员，但是成员之间却不能进行交流的团队更有可能获得成功。

合适的工具对于成功来说是非常重要的。然而，工具的作用可能会被过分地夸大。食用过多的庞大、笨重的工具就像缺少工具一样，都是不好的。我们的建议是从使用小公举开始，尝试一个工具，直到发现它无法适用时才去更换它。 这也是敏捷编程中所倡导的，直到真正需要时采取实现某种架构或模式。

我们需要记住，团队的构建要比环境的构建重要的多，许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。

2、可以工作的软件胜过面面俱到的文档

没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。

然而，过多的文档比过少的文档更糟。最容易出现的问题就是代码和文档不同步。文档和注释很像，起作用在于补充代码，而非解释代码。如果过度使用，则会消耗很多维护的精力，错误的文档更是会给人带来很大的困扰。这种问题在工作中很容易遇到。

因此，对于团队来说，所需要维护的文档应该是短小的并且主题突出的。短小是指最多有一二十页；主题突出是指应该仅论述系统的高层结构和概括的设计原理。

如果全部拥有的仅仅是一份简短的系统原理和结构方面的文档，那么如何来培训新的团队成员，使他们能够从事与系统相关的工作呢？我们会非常密切地和他们工作。我们紧挨着他们坐下来帮助他们，把我们的只是传授给他们。我们通过近距离的培训和交互使它们成为团队的一部分。

在给新的团队成员传授知识方面，最好的两份文档是代码和团队。代码真实地表示了它所做的事情。有很多时候与其去问一个老员工这个功能应该是怎样的，不如自己搭建环境进行观察。但是，有的时候我们也不得不向其他成员求助。因为他们的头脑中，保存着时长变化的系统的脉络图。这样就能帮助我们更快、更有效地了解整个系统的工作方式。

Martin 文档第一定律：
直到迫切需要并且意义重大时，才来编制文档

3、客户合作胜过合作谈判

告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的管理者来说是极具诱惑力的。然而，这种操作模式将导致低劣的质量和失败。这就像《人月神话》中所提到的，管理者希望通过增加人手来追上已经落后的进度，都是不切实际的空想。这造成的结果就是大家都很累，结果还不好。

成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常地提供反馈。

一个指明了需求、进度以及项目成本的合同存在根本上的缺陷。 在大多数的情况下，合同中指明的条款远在项目完成之前就变得没有意义。那些为开发团队和客户的协同工作方式提供执导的合同才是最好的合同。

4、响应变化胜过遵循计划

相应变化的能力常常决定着一个项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面的变化。

计划不能考虑得过远。首先，上午环境很可能会变化，这会引起需求的变动。其次，一旦客户看到系统开始运作，他们很可能会改变需求。最后，即使我们熟悉需求，并且确信它们不会改变，我们仍然不能很好地估算出开发他们需要的时间。

对于一个缺乏经验的管理者来说，创建一张优美的 PERT 或者 Gantt 图并把它们贴到办公室的墙上是很有诱惑力的。他们也许觉得这张图赋予了他们控制整个项目的权力。他们能够跟踪单个人的任务，并在任务完成时将任务从图中去除。他们可以对实际完成的日期和计划完成的日期进行比较，并对出现的任何偏差做出反应。

实际上发生的是这张图的组织结构不在适用。当团队增加了对于系统的认识，当客户增加了对于需求的认识，图中的某些任务会变得可有可无。另外一些任务会被发现并增加到图中。简而言之，计划将会遭受形态上的改变，而不仅仅是日期上的改变。

较好的做计划的策略是：**为下两周做详细的计划，为下三个月做粗略的计划，在以后就做极为粗糙的计划。**我们应该清楚地知道下两周要完成的任务，粗略地了解一下以后三个月要实现的需求。至于同一年后将要做什么，有一个模糊的想法就行了。

其实进度的变化大多来源于需求的变动。如果一开始的需求就是明确而细致的，那么瀑布式开发当然没有问题。但就像人一样，你很难从一开始就知道自己想要什么。在这种情况下，我们就需要通过反馈和重构来实现系统的稳定性，就像生态系统一样。

二、原则

1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意

MIT Sloan 管理评论杂志刊登过一篇论文，分析了对于公司构建高质量产品方面有帮助的软件开发实践。该论文发现了很多对于最终系统质量有重要影响的实践。其中一个实践表明，尽早地交付具有部分功能的系统和系统质量之间具有很强的相关性。该论文指出，初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。

该论文的另一项发现是，以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的相关性。交付得越频繁，最终产品的质量就越高。

敏捷实践会尽早地、经常地进行交付。我们努力在项目刚开始的几周内就交付一个具有基本功能的系统。然后，我们努力坚持每两周就交付一个功能渐增的系统。

2、即使到了开发的后期，也欢迎改变需求。敏捷过程里用变化来为客户创造竞争优势

这是一个关于态度的声明。敏捷过程的参与者不惧怕变化。他们认为改变需求是好的事情，因为那些改变意味着团队已经学到了很多如何满足市场需要的知识。这种拥抱变化的态度和信心是基于软件结构的灵活性。这样当需求变化时，对于系统造成的影响是最小的。

3、经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好

我们交付可以工作的软件，并且尽早地（项目刚开始很少的几周后）、经常性地（伺候每隔很少的几周）交付它。我们不赞成交付大量的文档或者计划。我们认为那些不是真正要交付的东西。我们关注的目标是交付满足客户需要的软件。

4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作

为了能够以敏捷的方式进行项目的开发，客户、开发人员以及涉众之间就必须要进行有意义的、频繁的交互。相对来说，这个原则更难实现一些。

5、围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作

在敏捷项目中，人被认为是项目取得成功的最重要的因素（书中多次提到这句话）。所有其他的因素 —— 过程、环境、管理等等 —— 都被认为是次要的，并且当它们对人有负面的影响时，就要对它们进行改变。

6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈

在敏捷项目中，人们之间相互进行交谈。首要的沟通方式就是交谈。也许会编写文档，但是不会企图在文档中包含所有的项目信息。敏捷团队不需要书面的规范、书面的计划或者书面的设计。团队成员可以去编写文档，如果对于这些文档的需求是迫切并且意义重大的，但是文档不是默认的沟通方式。

7、工作的软件是首要的进度度量标准

敏捷项目不是根据所处的开发阶段、已经编写的文档的多少或者已经创建的基础结构代码的数量来度量开发进度的。只有当30%的必须功能可以工作时，才可以确定进度完成了30%。这是由于敏捷开发细致的功能拆分和频繁的交付周期，使得根据可以工作的模块多少来确定进度成为了可能。

8、敏捷过程提倡可持续的开发速度。责任人、开发者和用户能够保持一个长期的、恒定的开发速度。

敏捷项目不是50米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。

敏捷团队会测量自己的速度。他们不允许自己过于疲惫。他们不会借用明天的精力来在今天多完成一点工作。他们工作在一个可以使在整个项目开发期间保持最高质量标准的速度上。

但是现在996的工作模式完全违背了这种可持续的开发理念。和可持续发展的观念类似，在我们薄弱的时候只能采取先污染再治理的办法，先把整体国力提升上去再解决环境问题；很多公司在起步阶段也需要先把产品做出来再说质量的问题。遗憾的是，有些公司的管理团队并不会给你回顾和改善代码质量的机会。

9、不断地关注游戏的技能和好的设计会增强敏捷能力

高的产品质量是获取高的开发素的的关键。保持软件尽可能的简洁、健壮是快速开发软件的途径。因此，所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。就像童子军军规所指，离开时要比发现时更更整洁。

10、简单 — 是未完成的工作最大化的艺术 — 是根本的

敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目标一致的最简单的方法。不要看中明天会出现的问题。相反，他们在今天以最高的质量完成最简单的工作，深信如果明天发生了问题，也会很容易进行处理。

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

敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。

这样每个成员都具有项目中所有方面的参与权力。不存在单一的成员对系统构架、需求或测试负责的情况。此外，成员不仅可以负责自己擅长的领域，也可以选择自己感兴趣的领域。这会大大发挥程序员的主观能动性。

12、每隔一定时间，团队会在如何才能够更有效地工作方面进行反省，然后相应地对自己的行为进行调整

敏捷团队知道团队的环境在不断地变化，并且知道为了保持团队的敏捷性，就必须要随环境一起变化。

《敏捷软件开发》— 敏捷开发 — 敏捷实践相关推荐

1. 项目管理电子书_Scrum实战：敏捷软件项目管理与开发【电子书】 附下载地址

   关注公众号[互联互通社区],回复[敏捷软件项目管理与开发]获取全部内容 内容介绍 <Scrum实战--敏捷软件项目管理与开发>为软件项目团队提供了如何成功实施敏捷软件框架Scrum的实用指 ...

2. 《规范敏捷交付：企业级敏捷软件交付的方法与实践》——3.11　观点总结

   3.11 观点总结 本章描述了规范敏捷交付过程框架所基于的核心敏捷方法的根基.它们之间有很多相似之处,但每个方法又都有一些不同.肯·施瓦伯,Scrum的创始人之一,曾经将敏捷方法比作象棋比赛.这里面只 ...

3. 敏捷软件开发实践——估算与计划02

   目录 一.使用故事点估算大小 1.故事点是相对的 2.速度 3.小结 二.使用理想人天进行估算 1.理想时间和软件开发 2.以理想人天作为对大小的度量 3.给出一个而不是多个估算值 4.小结 三.估算 ...

4. 敏捷软件开发实践——估算与计划（01）

   目录 一.计划的目的 1.为什么要进行估算和计划 2.优秀的计划是什么 3.敏捷计划是什么 4.小结 二.计划失败的原因 1.基于活动而不是基于特性进行计划 1.1.活动不会提前完成 1.2.延误沿着 ...

5. 《敏捷软件开发：原则、模式与实践（C#版.修订版）》—第1章1.4节参考文献

   本节书摘来自异步社区<敏捷软件开发:原则.模式与实践(C#版.修订版)>一书中的第1章1.4节参考文献,作者[美]Robert C. Martin , Micah Martin,更多章节内 ...

6. 软件开发计划_敏捷软件开发实践：估算与计划读书笔记113第11章 确定渴望度优先级...

   <敏捷软件开发实践:估算与计划>第11章 确定渴望度优先级,重点和要点的思维导图及文字内容. 第11章 确定渴望度优先级 If you have a choice of two thing ...

7. 敏捷软件开发:原则、模式与实践(C#版)

   刚才在china-pub看到<敏捷软件开发:原则.模式与实践(C#版)>已经出版了.这本书是以前那本<敏捷软件开发:原则.模式与实践>的C#版,这是不是说明C#程序员的数量已经 ...

8. 敏捷软件开发实践-Sprint Status Track

   介绍: 对于敏捷软件开发来说,能时刻保持跟进项目的进度是非常重要的,因为你可以随时了解团队的健康状况,并且对各种突发情况进行突发的处理,从而保证每个迭代结束后我们的项目可以按时的交付. 实现方式: 看 ...

9. 软件开发计划_敏捷软件开发实践：估算与计划读书笔记123第21章 关于计划的沟通...

   <敏捷软件开发实践:估算与计划>第21章 关于计划的沟通,重点和要点的思维导图及文字内容. 第21章 关于计划的沟通 The more elaborate our means of com ...

10. 敏捷软件开发：原则、模式与实践——第12章　ISP：接口隔离原则

    第12章 ISP:接口隔离原则 不应该强迫客户程序依赖并未使用的方法. 这个原则用来处理"胖"接口所存在的缺点.如果类的接口不是内敛的,就表示该类具有"胖"接口 ...

最新文章

1. linux文件查找命令find、which、locate、whereis 和type
2. win7没有个性化如何把计算机放到桌面,win7系统家庭版右键没有个性化设置桌面壁纸...
3. phantomjs使用说明
4. keepalived+httpd 做web服务的高可用
5. mysql表的类型_浅谈MySQL表类型
6. VI编辑器的基本使用
7. C++ 解析Json
8. 第二百七十九节，MySQL数据库-pymysql模块操作数据库
9. python 判断数字连续_关于python：检测列表中的连续整数
10. 聊聊spring的ioc
11. VB打开资源管理器并指定文件
12. zabbix 接触这段时间的感悟
13. 2021年塔式起重机司机考试题库及塔式起重机司机模拟考试
14. MySQL 分页查询
15. 2019上半年教资综合素质——主观题
16. 计算机相关的外国文献,计算机发参考文献外国 计算机发参考文献有哪些
17. web端前端自定义提示语信息
18. 在Word中方括号中打勾
19. webServer_国内手机号码归属地查询
20. Peekaboo——项目系统设计与数据库设计

热门文章

1. JAVA实现对PDF文件加密、解密、暴力破解密码功能
2. LeetCode每日一题（20200820）
3. 重庆江北鲁能旁边孩子学计算机,家长们注意！重庆多个区县中小学划片公布！这些学校民转公...
4. Python实现图像的全景拼接
5. PSV破解流程+软件游戏安装（最简单/最快的方法整理，已测支持3.65~3.68，理论上支持全系列版本）
6. php+ioncube',windows下php安装ionCube
7. Linux的基础操作
8. Python3.4中文手册chm，3.7中文手册HTML
9. 2.Smali的基础语法
10. c语言房屋中介系统,ZX房屋中介管理系统(毕设)源码