[开发测试]《敏捷软件开发》— 敏捷开发 — 敏捷实践

一、敏捷联盟

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

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