敏捷软件开发——第1章 敏捷实践

第1章　敏捷实践

敏捷软件开发宣言：
人和交互    重于     过程和工具
能够工做的软件  重于     面面俱到的文档
客户合做   重于     合同谈判
随时应对变化  重于     遵循计划
虽然右项也有其价值，但左项更加剧要。

 

1.人和交互重于过程和工具
　　人是得到成功的最为重要的因素。若是团队中没有优秀的成员，那么就算是使用好的过程也不能从失败中挽救项目，可是，不 好的过程却可使最优秀的团队成员失去效用。若是不能做为一个团队进行工做，那么即便拥有一批优秀的成员也同样会惨败。

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

　　合适的工具 对于成功来讲是很是重要的。像编译器、IDE、源代码控制系统等，对于团队的开发者正确地完成他们的工做是相当重要的。然而，工具的做用可能会被过度地夸 大。使用过多的庞大、笨重的工具就像缺乏工具同样，都是很差的。

　　咱们的建议是从使用小工具开始，尝试一个工具，直到发现它没法适用时才去更换它。不是急着去购买那些先进的、价格昂贵的源代码控制系统，相反先使用一个免费的系统直到可以证实该系统已经再也不适用。在决定为团队购买最好的CASE工具许可证 （license）前，先使用白板和方格纸，直到有足够的理由代表须要更多的功能。在决定使用庞大的、高性能的数据库系统前，先使用平面文件 （flat file）。不要认为更大的、更好的工具能够自动地帮你作得更好。一般，它们形成的障碍要大于带来的帮助。

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

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

　　然而，过多的文档 比过少的文档更糟。编制众多的文档须要花费大量的时间，而且要使这些文档和代码保持同步，就要花费更多的时间。若是文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎话，会形成重大的误导。

　　对于团队来讲，编写并维护一份系统原理和结构方面的文档将老是一个好主意，可是那份文档应该是短小的 （short）而且主题突出的（salient）。“短小的”意思是说，最多有一二十页。“主题突出的”意思是说，应该仅论述系统的高层结构和归纳的设计 原理。

　　若是所有拥有的仅仅是一份简短的系统原理和结构方面的文档，那么如何来培训新的团队成员，使他们可以从事与系统相关的工做呢？咱们会很是密切地和他 们在一块儿工做。咱们紧挨着他们坐下来帮助他们，把咱们的知识传授给他们。咱们经过近距离的培训和交互使他们成为团队的一部分。

　　在给新的团队成员传授知识方面，最好的两份文档是代码和团队。代码真实地表达了它所作的事情。虽然从代码中提取系统的原理和结构信息多是困难的，可是代码是唯一没有二义性的信息 源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。
　　许多团队由于注重文档而非软件，致使进度拖延。这经常是一个致命的缺陷。有一个叫作“Martin文档第必定律（Martin’s first law of documentation）”的简单规则能够预防该缺陷的发生：直到迫切须要而且意义重大时，才来编制文档。

3.客户合做重于合同谈判
　　不能像订购日用品同样来订购软件。你不可以仅仅写下一份关于你想要的软件的描述，而后就让人在固定的时间内以固定的价格去开发它。全部用这种方式来对待软件 项目的尝试都以失败而了结。有时，失败是惨重的。

　　告诉开发团队想要的东西，而后指望开发团队消失一段时间后就可以交付一个知足须要的系统来，这对于公司的 管理者来讲是具备诱惑力的。然而，这种操做模式将致使低劣的质量和失败。

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

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

　　我在1994 年为一个大型的、须要多年完 成的、有50 万行代码的项目达成的合同，能够做为一个成功合同的样例。做为开发团队的咱们，每月的报酬相对是比较低的。大部分的报酬要在咱们交付了某 些大的功能块后才支付。那些功能块没有在合同中详细地指明。合同中仅仅声称在一个功能块经过了客户的验收测试时才支付该功能块的报酬。那些验收测试的细节 也没有在合同中指明。

　　在这个项目开发期间，咱们和客户紧密地在一块儿工做。几乎每一个周五，咱们都会把软件提交给客户。到下一周的周一或者周二，客户会给咱们 一份关于软件的变动列表。咱们会把这些变动放在一块儿排定优先级，而后把它们安排在随后几周的工做中。客户和咱们如此紧密地在一块儿工做，以致于验收测试根本就不是问题。由于他们周复一周地观察着每一个功能块的演进，因此他们知道什么时候这个功能块可以知足他们的须要。

　　这个项目的需求基本处于一个持续变化的 状态。大的变动是很日常的。在这期间，也会出现整个功能块被减掉，而加进来另一些功能块。然而，合同和项目都经受住了这些变动，并得到成功。成功的关键 在于和客户之间真诚的协做，而且合同指导了这种协做，而不是试图去规定项目范围的细节和固定成本下的进度。

4.随时应对变化重于遵循计划
　　随时应对变化的能力经常决定着一个软件项目的成败。当咱们构建计划时，应该确保计划是灵活的而且易于适应商务和技术方面的变化。

　　计划不能考虑得过远。首先，商务环境极可能会变化，这会引发需求的变更。其次，一旦客户看到系统开始运做，他们极可能会改变需求。最后，即便咱们知道需求是什么，而且确信它们不会改变，咱们仍然不能很好地估算出开发它们须要的时间。

　　对于一个缺少经验的管理者来讲，建立一张优美的PERT 或者Gantt 图并把他们贴到墙上是颇有诱惑力的。他们也许以为这张图赋予了他们对项目的控制权。他们可以跟踪单我的的任务，并在任务完成时将任务从图上去除。他们能够对实际完成的日期和计划完成的日期 进行比较，并对出现的任何误差作出反应。

　　实际上发生的是这张图的组织结构再也不适用。当团队增长了对于系统的认识，当客户增长了对于需求的认识，图中的某些任务会变得没有必要。另一些任务会被发现并增长到图中。简而言之，计划图的形态（shape）将会改变，而不只仅是日期上的改变。

　　较好的作计划的策略是：为下一周作详细的计划，为下3个月作粗略的计划，再之后就作极为粗糙的计划。咱们应该清楚地知道下周要完成的任务，粗略地了解一下之后3个月要实现的需求。至于系统一年后将要作什么，有一个模糊的想法就好了。

　　计划中这种逐渐下降的细致度，意味着咱们仅仅对于迫切的任务才花费时间进行详细的计划。一 旦制定了这个详细的计划，就很难进行改变，由于团队会根据这个计划启动工做并有了相应的投入。然而，因为计划仅仅支配了几周的时间，计划的其他部分仍然保 持着灵活性。

 

敏捷开发遵循的原则
　　从上述的价值观中引出了下面的12 条原则，它们是敏捷实践区别于重型过程的特征所在。

　　（1）咱们最优先要作的是经过尽早的、持续的交付有价值的软件来使客户满意。《MIT Sloan管理评论杂志》刊登过一篇论文，分析了对于公司构建高质量产品方面有帮助的软件开发实践。该论文发现了不少对于最终系统质量有重要影响的实践。其中一个实践 代表，尽早地交付具备部分功能的系统和系统质量之间具备很强的相关性。该论文指出，初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。该论 文的另外一项发现是，以逐渐增长功能的方式常常性地交付系统和最终质量之间有很是强的相关性。交付得越频繁，最终产品的质量就越高。
　　敏捷实践会尽早地、常常地进行交付。咱们努力在项目刚开始的几周内就交付一个具备基本功能的系统。而后，咱们努力坚持每两周就交付一个功能渐增的系统。若是客户认为目前的功能已经足够了，客户能够选择把这些系统加入到产品中。或者，他们能够简单地选择再检查一遍已有的功能，并指出他们想要作的改变。

　　（2）咱们欢迎需求的变化，即便到了开发的后期。敏捷过程可以驾驭变化 ，为客户创造竞争优点。这是一个关于态度的声明。敏捷过程的参与者不害怕变化。他们认为改变需求是好的事情，由于那些改变意味着团队已经学 到了不少如何知足市场须要的知识。
　　敏捷团队会很是努力地保持软件结构的灵活性，这样当需求变化时，对于系统形成的影响是最小的。 在本书的后面部分，咱们 会学习一些面向对象设计的原则和模式，这些内容会帮助咱们维持这种灵活性。

　　（3）常常性地交付能够工做的软件，交付的间隔能够从几周到几个月，交付的时间间隔越短越好。咱们交付能够工做的软件，而且尽早地（项目刚开始不多的几周后）、常常性地（此后每隔不多的几周）交付它。咱们不同意交付大量的文档或者计划。咱们认为那些不是真正要交付的东西。咱们关注的目标是交付知足客户须要的软件。
　　

　　（4）在整个项目开发期间，业务人员和开发人员必须朝夕工做在一块儿。为了可以以敏捷的方式进行项目的开发，客户、开发人员以及利益相关者之间就必需要进行有意义的、频繁的交互。软件项目不像发射出去就能自动导航的武器，必需要对软件项目进行持续不断地引导。

　　（5）围绕斗志高昂的人构建项目。给 他们提供所须要的环境和支持，而且信任他们可以完成工做。人是项目取得成功的最重要的因素。全部其余的因素（过程、环境、管理等）都被认为是次要的，而且当它们对于人有负面的影响时，就要对它们进行改变。例如，若是办公环境对团队的工做形成阻碍，就必须对办公环境进行改变。若是某些过程步骤对团队的工做形成阻碍，就必须对那些过程步骤进行改变。

　　（6）在团队内部，最具备效率也最有效果的信息传达方式，就是面对面的交谈。在敏捷项目中，人们之间相互进行交谈。首要的沟通方式就是交谈。也许会编写文档，可是不会企图在文档中包含全部的项目信息。敏捷团队不须要书面的规范、书面的计划或者书面的设计。团队成员能够去编写文档，若是对于这些文档的需求是迫切而且意义重大的，可是文档不是默认的沟通方式。默认的沟通方式是交谈。

　　（7）能够工做的软件是首要的进度度量标准。敏捷项目经过度量当前软件知足客户需求的数量来度量开发进度。它们不是根据所处的开发阶段、已经编写的文档的多少或者已经建立的基础结构（infrastructure）代码的数量来度量开发进度的。只有当30%的必须功能能够工做时，才能够肯定进度完成了30%。

　　（8）敏捷过程提倡可持续开发。出资人、开发者和用户应该老是保持稳定的开发速度。敏捷项目不是50 米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速可是可持续的速度行进。
　　跑得过快会致使团队精力耗尽、出现短时间行为以至于崩溃。敏捷团队会测量他们本身的速度。他们不容许本身过于疲惫。他们不会借用明天的精力来在今天多完成一点工做。他们工做在一个可使在整个项目开发期间保持最高质量标准的速度上。

　　（9）对卓越技术和良好设计的为断追求有助于提升敏捷性。高的产品质量是获取高的开发速度的关键。保持软件尽量的简洁、健壮是快速开发软件的途径。于是，全部的敏捷团队成员都致力于只编写他们可以编写的最高质量的代码。他们不会制造混乱而后告诉本身等有更多的时间时再来清理它们。若是他们在今天制造了混乱，他们会在今天把混乱清理干净。

　　（10）简单--尽可能减小工做的的艺术是相当重要的。敏捷团队不会试图去构建那些华而不实的系统，他们老是更愿意采用和目标一致的最简单的方法。他们并不看重对于明天会出现的问题的预测，也不会在今天就对那些问题进行防卫。相反，他们在今天以最高的质量完成最简单的工做，深信若是在明天发生了问题，也会很容易进行处理。

　　（11）最好的构架、需求和设计都源自自我组织的团队。敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员，而是分配给整个团队，而后再由团队来肯定完成任务的最好方法。
　　敏捷团队的成员共同来解决项目中全部方面的问题。每个成员都具备项目中全部方面的参与权力。不存在单一的团队成员对系统构架、需求或者测试负责的状况。整个团队共同承担那些责任，每一 个团队成员都可以影响它们。

　　（12）每隔必定时间，团队都要总结如何更有效率，而后相应地调整本身的行为。敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏捷团队知道团队所处的环境在不断地变化，而且知道为了保持团队的敏捷性，就必需要随环境一块儿变化。

 

结论
　　每 一位软件开发人员、每个开发团队的职业目标，都是给他们的雇主和客户交付最大可能的价值。但是，咱们的项目以使人沮丧的速度失败，或者未能交付任何价值。虽然在项目中采用过程方法是出于好意的，可是膨胀的过程方法对于咱们的失败至少是应该负一些责任的。敏捷软件开发的原则和价值观构成了一个能够帮助团 队打破过程膨胀循环的方法，这个方法关注的是能够达到团队目标的一些简单的技术。

 http://www.cnblogs.com/jesselzj/p/4757209.html

 

摘自：《敏捷软件开发：原则、模式与实践(C#版)》Robert C.Martin　Micah Martin 著