敏捷软件开发
敏捷软件开发宣言
我们正在通过亲身实践以及帮助他人实践，揭示
更好的软件开发方法。通过这项工作，我们认为：
个体和交互胜过 过程和工具
可以工作的软件胜过 面面俱到的文档
客户合作胜过 合同谈判
响应变化胜过 遵循计划
虽然右项也具有价值，
但我们认为左项具有更大的价值。
C.
Martin
Grenning Robert
James
Beck
Kent
Mellor
Highsmith Steve
Mike
Beedle Jim
Ken
Schwaber
Hunt
Bennekum Andrew
Arie
van
Jeffries Jeff
Sutherland Cockburn Ron
Alistair
Thomas
Kern Dave
Cunningham Jon
Ward
Marick
Martin
Fowler Brian
敏捷宣言遵循的原则
我们遵循以下原则：
z我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
z即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
z经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
z在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
z围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
z在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
z工作的软件是首要的进度度量标准。
z敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
z不断地关注优秀的技能和好的设计会增强敏捷能力。
z简单——使未完成的工作最大化的艺术——是根本的。 z最好的构架、需求和设计出自于自组织的团队。
z每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
面向对象设计的原则
SRP 单一职责原则
就一个类而言，应该仅有一个引起它变化的原因。
OCP 开放－封闭原则
软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。LSP Liskov替换原则
子类型必须能够替换掉它们的基类型。
DIP 依赖倒置原则
抽象不应该依赖于细节。细节应该依赖于抽象。
ISP 接口隔离原则
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它
所在的类层次结构。
REP 重用发布等价原则
重用的粒度就是发布的粒度。
CCP 共同封闭原则
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化
若对一个包产生影响，则将对该包中的所有类产生影响，而对于其
他的包不造成任何影响。
CRP 共同重用原则
一个包中的所有类应该是共同重用的。如果重用了包中的一个类，
那么就要重用包中的所有类。
ADP 无环依赖原则
在包的依赖关系图中不允许存在环。
SDP 稳定依赖原则
朝着稳定的方向进行依赖。
SAP 稳定抽象原则
包的抽象程度应该和其稳定程度一致。
极限编程实践
完整团队
XP项目的所有参与者（开发人员、业务分析师、测试人员等等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
计划游戏
计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。
客户测试
作为选择每个所期望的特性的一部分，客户定义出自动验收测试来表明该特性可以工作。
简单设计
团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
结对编程
所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
测试驱动开发
程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。
改进设计
随时改进糟糕的代码。保持代码尽可能的干净、具有表达力。
持续集成
团队总是使系统完整地被集成。
集体代码所有权
任何结对的程序员都可以在任何时候改进任何代码。
编码标准
系统中所有的代码看起来就好像是被单独一个——非常值得胜任的——人编写的。
隐喻
团队提出一个程序工作原理的公共景像。
可持续的速度
团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作。他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。
前言
敏捷开发（Agile Development）是一种面临迅速变化的需求快速开发软件的能力。为了获取这种敏捷性，我们需要使用一些可以提供必要的纪律和反馈的实践。我们需要使用一些可以保持我们的软件灵活、可维护的设计原则，并且我们需要知道一些已经被证明针对特定的问题可以平衡这些原则的设计模式。本书试图把所有这3个概念编织在一起，使它们成为一个有机的整体。
第Ⅰ部分敏捷开发
原则（principle）、模式（pattern）和实践（practice）都是重要的，但是使它们发挥作用的是人。正如Alistair Cockburm所说的，“过程和方法对于项目的结果只有次要的影响。首要的影响是人。”
如果把程序员团队看做是由过程驱动的组件（component）所组成的系统，那么就无法对它们进行管理。人不是“插入即兼容的编程装置。”如果想要项目取得成功，就必须构建起具有合作精神的、自组织（self-organizing）的团队。
那些鼓励构建这种团队的公司比那些认为软件团队不过是由无关紧要的、雷同的一群人堆砌的公司具有大得多的竞争优势。有凝聚力的团队将具有最强大的软件开发力量。
第1章敏捷实践
1.1 敏捷联盟
2001年初，由于看到许多公司的软件团队陷入了不断增长的过程的泥潭，一批业界专家聚集在一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观（value）和原则。他们称自己为敏捷（Agile）联盟。在随后的几个月中，他们创建出了一份价值观声明。也就是敏捷联盟宣言（The Manifesto of the Agile Alliance）。
敏捷联盟宣言
敏捷软件开发宣言
我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：
z个体和交互 胜过 过程和工具
z可以工作的软件 胜过 面面俱到的文档
z客户合作 胜过 合同谈判
z响应变化 胜过 遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。
Martin Kent
C.
Grenning Robert
Beck
James
Mellor
Steve
Mike
Highsmith
Beedle Jim
Bennekum Andrew
Schwaber
Hunt Ken
van
Arie
Sutherland
Jeffries Jeff
Cockburn Ron
Alistair
Thomas
Dave
Cunningham Jon
Kern
Ward
Marick
Brian
Martin
Fowler
1．个体和交互胜过过程和工具
人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。
一个优秀的团队成员未必就是一个一流的程序员。一个优秀的团队成员可能是一个平均水平的程序员，但是却能够很好地和他人合作。合作、沟通以及交互能力要比单纯的编程能力更为重要。一个由平均水平程序员组成的团队，如果具有良好的沟通能力，将要比那些虽然拥有一批高水平程序员，但是成员之间却不能进行交流的团队更有可能获得成功。
合适的工具对于成功来说是非常重要的。像编译器、IDE、源代码控制系统等，对于团队的开发者正确地完成他们的工作是至关重要的。然而，工具的作用可能会被过分地夸大。使用过多的庞大、笨重的工具就像缺少工具一样，都是不好的。
我们的建议是从使用小工具开始，尝试一个工具，直到发现它无法适用时才去更换它。不是急着去购买那些先进的、价格昂贵的源代码控制系统，相反先使用一个免费的系统直到能够证明该系统已经不再适用。在决定为团队购买最好的CASE工具许可证（license）前，先使用白板和方格纸，直到有足够的理由表明需要更多的功能。在决定使用庞大的、高性能的数据库系统前，先使用平面文件（flat file）。不要认为更大的、更好的工具可以自动地帮你做得更好。通常，它们造成的障碍要大于带来的帮助。
记住，团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。2．可以工作的软件胜过面面俱到的文档
没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。
然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。
对于团队来说，编写并维护一份系统原理和结构方面的文档将总是一个好主意，但是那份文档应该是短小的（short）并且主题突出的（salient）。“短小的”意思是说，最多有一二十页。“主题突出的”意思是说，应该仅论述系统的高层结构和概括的设计原理。
如果全部拥有的仅仅是一份简短的系统原理和结构方面的文档，那么如何来培训新的团队成员，使他们能够从事与系统相关的工作呢？我们会非常密切地和他们在一起工作。我们紧挨着他们坐下
来帮助他们，把我们的知识传授给他们。我们通过近距离的培训和交互使他们成为团队的一部分。
在给新的团队成员传授知识方面，最好的两份文档是代码和团队。代码真实地表达了它所做的事情。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是惟一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。
许多团队因为注重文档而非软件，导致进度拖延。这常常是一个致命的缺陷。有一个叫做“Martin 文档第一定律（Martin’s first law of document）”的简单规则可以预防该缺陷的发生：
直到迫切需要并且意义重大时，才来编制文档。
3．客户合作胜过合同谈判
不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。有时，失败是惨重的。
告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。
成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常地提供反馈。
一个指明了需求、进度以及项目成本的合同存在根本上的缺陷。在大多数的情况下，合同中指明的条款远在项目完成之前就变得没有意义。那些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。
我在1994年为一个大型的、需要多年完成的、有50万行代码的项目达成的合同，可以作为一个成功合同的样例。作为开发团队的我们，每个月的报酬相对是比较低的。大部分的报酬要在我们交付了某些大的功能块后才支付。那些功能块没有在合同中详细地指明。合同中仅仅声称在一个功能块通过了客户的验收测试时才支付该功能块的报酬。那些验收测试的细节也没有在合同中指明。
在这个项目开发期间，我们和客户紧密地在一起工作。几乎每个周五，我们都会把软件提交给客户。到下一周的周一或者周二，客户会给我们一份关于软件的变更列表。我们会把这些变更放在一起排定优先级，然后把它们安排在随后几周的工作中。客户和我们如此紧密地在一起工作，以至于验收测试根本就不是问题。因为他们周复一周地观察着每个功能块的演进，所以他们知道何时这个功能块能够满足他们的需要。
这个项目的需求基本处于一个持续变化的状态。大的变更是很平常的。在这期间，也会出现整个功能块被减掉，而加进来另外一些功能块。然而，合同和项目都经受住了这些变更，并获得成功。成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。
4．响应变化胜过遵循计划
响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面的变化。
计划不能考虑得过远。首先，商务环境很可能会变化，这会引起需求的变动。其次，一旦客户看到系统开始运作，他们很可能会改变需求。最后，即使我们熟悉需求，并且确信它们不会改变，我们仍然不能很好地估算出开发它们需要的时间。
对于一个缺乏经验的管理者来说，创建一张优美的PERT或者Gantt图并把他们贴到墙上是很有诱惑力的。他们也许觉得这张图赋予了他们控制整个项目的权力。他们能够跟踪单个人的任务，并在任务完成时将任务从图上去除。他们可以对实际完成的日期和计划完成的日期进行比较，并对出现的任何偏差做出反应。
实际上发生的是这张图的组织结构不再适用。当团队增加了对于系统的认识，当客户增加了对于需求的认识，图中的某些任务会变得可有可无。另外一些任务会被发现并增加到图中。简而言之，计划将会遭受形态（shape）上的改变，而不仅仅是日期上的改变。
较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。我们应该清楚地知道下两周要完成的任务，粗略地了解一下以后三个月要实现的需求。至于系统一年后将要做什么，有一个模糊的想法就行了。
计划中这种逐渐降低的细致度，意味着我们仅仅对于迫切的任务才花费时间进行详细的计划。一旦制定了这个详细的计划，就很难进行改变，因为团队会根据这个计划启动工作并有了相应的投入。然而，由于计划仅仅支配了几周的时间，计划的其余部分仍然保持着灵活性。
1.2 原则
从上述的价值观中引出了下面的12条原则，它们是敏捷实践区别于重型过程的特征所在。1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
MIT Sloan管理评论杂志刊登过一篇论文，分析了对于公司构建高质量产品方面有帮助的软件开发实践。该论文发现了很多对于最终系统质量有重要影响的实践。其中一个实践表明，尽早地交付具有部分功能的系统和系统质量之间具有很强的相关性。该论文指出，初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。
该论文的另一项发现是，以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的相关性。交付得越频繁，最终产品的质量就越高。
敏捷实践会尽早地、经常地进行交付。我们努力在项目刚开始的几周内就交付一个具有基本功能的系统。然后，我们努力坚持每两周就交付一个功能渐增的系统。
如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入到产品中。
或者，他们可以简单地选择再检查一遍已有的功能，并指出他们想要做的改变。
2．即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
这是一个关于态度的声明。敏捷过程的参与者不惧怕变化。他们认为改变需求是好的事情，因为那些改变意味着团队已经学到了很多如何满足市场需要的知识。
敏捷团队会非常努力地保持软件结构的灵活性，这样当需求变化时，对于系统造成的影响是最小的。在本书的后面部分，我们会学习一些面向对象设计的原则和模式，这些内容会帮助我们维持
这种灵活性。
3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
我们交付可以工作的软件（working software），并且尽早地（项目刚开始很少的几周后）、经常性地（此后每隔很少的几周）交付它。我们不赞成交付大量的文档或者计划。我们认为那些不是真正要交付的东西。我们关注的目标是交付满足客户需要的软件。
4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
为了能够以敏捷的方式进行项目的开发，客户、开发人员以及涉众之间就必须要进行有意义的、频繁的交互。软件项目不像发射出去就能自动导航的武器，必须要对软件项目进行持续不断地引导。
5．围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
在敏捷项目中，人被认为是项目取得成功的最重要的因素。所有其他的因素——过程、环境、管理等等——都被认为是次要的，并且当它们对于人有负面的影响时，就要对它们进行改变。
例如，如果办公环境对团队的工作造成阻碍，就必须对办公环境进行改变。如果某些过程步骤对团队的工作造成阻碍，就必须对那些过程步骤进行改变。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
在敏捷项目中，人们之间相互进行交谈。首要的沟通方式就是交谈。也许会编写文档，但是不会企图在文档中包含所有的项目信息。敏捷团队不需要书面的规范、书面的计划或者书面的设计。团队成员可以去编写文档，如果对于这些文档的需求是迫切并且意义重大的，但是文档不是默认的沟通方式。默认的沟通方式是交谈。
7．工作的软件是首要的进度度量标准。
敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。它们不是根据所处的开发阶段、已经编写的文档的多少或者已经创建的基础结构（infrastructure）代码的数量来度量开发进度的。只有当30%的必须功能可以工作时，才可以确定进度完成了30%。
8．敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
敏捷项目不是50米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。
跑得过快会导致团队精力耗尽、出现短期行为以致于崩溃。敏捷团队会测量他们自己的速度。他们不允许自己过于疲惫。他们不会借用明天的精力来在今天多完成一点工作。他们工作在一个可以使在整个项目开发期间保持最高质量标准的速度上。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
高的产品质量是获取高的开发速度的关键。保持软件尽可能的简洁、健壮是快速开发软件的途径。因而，所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。他们不会制造混乱然后告诉自己等有更多的时间时再来清理它们。如果他们在今天制造了混乱，他们会在今天把混
乱清理干净。
10．简单——使未完成的工作最大化的艺术——是根本的。
敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目标一致的最简单的方法。他们并不看重对于明天会出现的问题的预测，也不会在今天就对那些问题进行防卫。相反，他们在今天以最高的质量完成最简单的工作，深信如果在明天发生了问题，也会很容易进行处理。
11．最好的构架、需求和设计出自于自组织的团队。
敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。
敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目中所有方面的参与权力。不存在单一的团队成员对系统构架、需求或者测试负责的情况。整个团队共同承担那些责任，每一个团队成员都能够影响它们。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏捷团队知道团队所处的环境在不断地变化，并且知道为了保持团队的敏捷性，就必须要随环境一起变化。
第2章极限编程概述
2.1 极限编程实践
极限编程（eXtreme Programming，简称XP）是敏捷方法中最著名的一个。它由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。本章我们将简要地探讨一下这个整体，在后续的章节中，会对一些单独的实践进行研究。
2.1.1 客户作为团队成员
我们希望客户和开发人员在一起紧密地工作，以便于彼此知晓对方所面临的问题，并共同去解决这些问题。
谁是客户？XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。有时，客户是和开发人员同属一家公司的一组业务分析师或者市场专家。有时，客户是用户团体委派的用户代表。有时，客户事实上是支付开发费用的人。但是在XP项目中，无论谁是客户，他们都是能够和团队一起工作的团队成员。
最好的情况是客户和开发人员在同一个房间中工作，次一点的情况是客户和开发人员之间的工作距离在100米以内。距离越大，客户就越难成为真正的团队成员。如果客户工作在另外一幢建筑或另外一个州，那么他将会很难融合到团队中来。
如果确实无法和客户在一起工作，该怎么办呢？我的建议是去寻找能够在一起工作、愿意并能够代替真正客户的人。
2.1.2 用户素材
为了进行项目计划，必须要知道和项目需求有关的内容，但是却无需知道得太多。对于做计划而言，了解需求只需要做到能够估算它的程度就足够了。你可能认为，为了对需求进行估算，就必须要了解该需求的所有细节，其实并非如此。你必须要知道存在很多细节，也必须要知道细节的大致分类，但是你不必知道特定的细节。
需求的特定细节很可能会随时间而改变，一旦客户开始看到集成到一起的系统，就更会如此。看到新系统的问世是关注需求的最好时刻。因此，在离真正实现需求还很早时就去捕获该需求的特定细节，很可能会导致做无用功以及对需求不成熟的关注
在XP中，我们和客户反复讨论，以获取对于需求细节的理解，但是不去捕获那些细节。我们更愿意客户在索引卡片上写下一些我们认可的词语（a few words），这些片言只语可以提醒我们记起这次交谈。基本上在和客户进行书写的同一时刻，开发人员在该卡片上写下对应于卡片上需求的估算。估算是基于和客户进行交谈期间所得到的对于细节的理解进行的。
用户素材（user stories）就是正在进行的关于需求谈话的助记符。它是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。
2.1.3 短交付周期
XP项目每两周交付一次可以工作的软件。每两周的迭代（iteration，也可称为重复周期或循环周期）都实现了涉众的一些需求。在每次迭代结束时，会给涉众演示迭代生成的系统，以得到他们的反馈。
1．迭代计划
每次迭代通常耗时两周。这是一次较小的交付，可能会被加入到产品中，也可能不会。它由客户根据开发人员确定的预算而选择的一些用户素材组成。
开发人员通过度量在以前的迭代中所完成的工作量来为本次迭代设定预算。只要估算成本的总量不超过预算，客户就可以为本次迭代选择任意数量的用户素材。
一旦迭代开始，客户就同意不再修改当次迭代中用户素材的定义和优先级别。迭代期间，开发人员可以自由地将用户素材分解成任务（task），并依据最具技术和商务意义的顺序来开发这些任务。
2．发布计划
XP团队通常会创建一个计划来规划随后大约6次迭代的内容，这就是所谓的发布计划。一次发布通常需要3个月的工作。它表示了一次较大的交付，通常此次交付会被加入到产品中。发布计划是由一组客户根据开发人员给出的预算所选择的、排好优先级别的用户素材组成。
开发人员通过度量在以前的发布中所完成的工作量来为本次发布设定预算。只要估算成本的总
量不超过预算，客户就可以为本次发布选择任意数目的用户素材。客户同样可以决定在本次发布中用户素材的实现顺序。如果开发人员强烈要求的话，客户可以通过指明哪些用户素材应该在哪次迭代中完成的方式，制订出发布中最初几次迭代的内容。
发布计划不是一成不变的，客户可以随时改变计划的内容。他可以取消用户素材，编写新的用户素材，或者改变用户素材的优先级别。
2.1.4 验收测试
可以以客户指定的验收测试（Acceptance Tests）的形式来捕获有关用户素材的细节。用户素材的验收测试是在就要实现该用户素材之前或实现该用户素材的同时进行编写的。
验收测试使用能够让它们自动并且反复运行的某种脚本语言编写，这些测试共同来验证系统按照客户指定的行为运转。
编写验收测试所使用的语言随着系统的增长、演化而增长、演化。客户可以召集开发人员开发一个简单的脚本系统，或者他们拥有一个可以开发脚本系统的独立的质量保证（QA）部门。许多客户借助于QA来开发验收测试工具，并自己编写验收测试。
一旦通过一项验收测试，就将该测试加入到已经通过的验收测试集合中，并决不允许该测试再次失败。这个不断增长的验收测试集合每天会被多次运行，每当系统被创建时，都要运行这个验收测试集。如果一项验收测试失败了，那么系统创建就宣告失败。因而，一项需求一旦被实现，就再不会遭到破坏。系统从一种工作状态变迁到另一种工作状态，期间，系统的不能工作状态时间决不允许超过几个小时。
2.1.5 结对编程
所有的产品（production）代码都是由结对的程序员使用同一台电脑共同完成的。结对人员中的一位控制键盘并输入代码，另一位观察输入的代码并寻找着代码中的错误和可以改进的地方。两个人强烈地（intensely）进行着交互，他们都全身心地投入到软件的编写中。
两人频繁互换角色。控制键盘的可能累了或者遇到了困难，他的同伴会取得键盘的控制权。在一个小时内，键盘可能在他们之间来回传递好几次。最终生成的代码是由他们两人共同设计、共同编写的，两人功劳均等。
结对的关系每天至少要改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。在一次迭代期间，每个团队成员应该和所有其他的团队成员在一起工作过，并且他们应该参与了本次迭代中所涉及的每项工作。
这将极大地促进知识在团队中的传播。仍然会需要一些专业知识，并且那些需要一定专业知识的任务通常需要合适的专家去完成，但是那些专家几乎会和团队中的所有其他人结过对。这将加快专业知识在团队中的传播。这样，在紧要关头，其他团队成员就能够代替所需要的专家。
Laurie Williams和Nosek的研究表明，结对非但不会降低开发团队的效率，而且会大大减少缺陷率。
2.1.6 测试驱动的开发方法
本书第4章是关于测试方面的内容，其中详细地论述了测试驱动的开发方法。在下面的段落中，仅对此进行快速的浏览。
编写所有产品代码的目的都是为了使失败的单元测试能够通过。首先编写一个单元测试，由于它要测试的功能还不存在，所以它会运行失败。然后，编写代码使测试通过。
编写测试用例和代码之间的更迭速度是很快的，基本上几分钟左右。测试用例和代码共同演化，其中测试用例循序渐进地对代码的编写进行指导。（参见第6章的例子。）
作为结果，一个非常完整的测试用例集就和代码一起发展起来。程序员可以使用这些测试来检查程序是否正确工作。如果结对的程序员对代码进行了小的更改，那么他们可以运行测试，以确保更改没有对程序造成任何的破坏。这会非常有利于重构（在后面的章节中进行论述）。
当为了使测试用例通过而编写代码时，这样的代码就被定义为可测试的代码。这样做会强烈地激发你去解除各个模块间的耦合，这样能够独立地对它们进行测试。因而，以这种方式编写的代码的设计往往耦合性较弱。面向对象设计的原则在进行这种解除耦合方面具有巨大的帮助作用。
2.1.7 集体所有权
结对编程中的每一对都具有拆出（check out）任何模块并对它进行改进的权力。没有程序员对任何一个特定的模块或技术单独负责。每个人都参与GUI方面的工作；每个人都参与中间件方面的工作；每个人都参与数据库方面的工作。没有人比其他人在一个模块或者技术上具有更多的权威。
这并不意味着XP不需要专业知识。如果你的专业领域是有关GUI的，那么你最有可能去从事GUI方面的任务，但是你将会被邀请去和别人结对从事有关中间件和数据库方面的任务。如果你决定去学习另一门专业知识，那么你可以承担相关的任务，并和能够传授你这方面知识的专家一起工作。你不会被限制在自己的专业领域。
2.1.8 持续集成
程序员每天会多次拆入（check in）他们的代码并进行集成，规则很简单。第一个拆入的只要完成拆入就可以了，所有其他的人负责代码的合并（merge）工作。
XP团队使用非阻塞的（nonblocking）源代码控制工具。这意味着程序员可以在任何时候拆出任何模块，而不管是否有其他人已经拆出这个模块。当程序员完成对模块的修改并把该模块拆入回去时，他必须要把他所做的改动和在他前面拆入该模块的程序员所做的任何改动进行合并。为了避免合并的时间过长，团队的成员会非常频繁地拆入他们的模块。
结对人员会在一项任务上工作1～2个小时。他们创建测试用例和产品代码。在某个适当的间歇点，也许远远在这项任务完成之前，他们决定把代码拆入回去。最重要的是要确保所有的测试都能够通过。他们把新的代码集成进代码库中。如果需要，他们会对代码进行合并。如果有必要，他们会和先于他们拆入的程序员协商。一旦集成进了他们的更改，他们就构建新的系统。他们运行系统
中的每一个测试，包括当前所有运行着的验收测试。如果他们破坏了原先可以工作的部分，他们会进行修正。一旦所有的测试都通过了，他们就算完成了此次拆入工作。
因而，XP团队每天会进行多次系统构建，他们会重新创建整个系统。如果系统的最终结果是一张CD，他们就录制该CD。如果系统的最终结果是一个可以访问的Web站点，他们就安装该Web 站点，或许会把它安装在一个测试服务器上。
2.1.9 可持续的开发速度
软件项目不是全速的短跑，它是马拉松长跑。那些一跃过起跑线就开始尽力狂奔的团队在远离终点前就会筋疲力尽。为了快速地完成开发，团队必须要以一种可持续的速度前进。团队必须保持旺盛的精力和敏锐的警觉。团队必须要有意识地保持稳定、适中的速度。
XP的规则是不允许团队加班工作。在版本发布前的一个星期是该规则的惟一例外。如果发布目标就在眼前并且能够一蹴而就，则允许加班。
2.1.10 开放的工作空间
团队在一个开放的房间中一起工作，房间中有一些桌子，每张桌子上摆放了两到三台工作站，每台工作站前有给结对编程的人员预备的两把椅子，墙壁上挂满了状态图表、任务明细表、UML 图等等。
房间里充满了交谈的嗡嗡声，结对编程的两人坐在互相能够听得到的距离内，每个人都可以得知另一人何时遇到了麻烦，每个人都了解对方的工作状态，程序员们都处在适合于激烈地进行讨论的位置上。
可能有人认为这种环境会分散人的注意力，很容易会让人担心由于持续的噪音和干扰而一事无成。事实上并非如此。而且，密歇根大学的一项研究表明，在“充满积极讨论的屋子（war room）”里工作，生产率非但不会降低，反而会成倍地提高。
2.1.11 计划游戏
在下一章“计划”中，会详细地介绍XP的计划游戏方面的内容。在这里，先简要描述一下。
计划游戏（planning game）的本质是划分业务人员和开发人员之间的职责。业务人员（也就是客户）决定特性（feature）的重要性，开发人员决定实现一个特性所花费的代价。
在每次发布和每次迭代的开始，开发人员基于在最近一次迭代或者最近一次发布中他们所完成的工作量，为客户提供一个预算。客户选择那些所需的成本合计起来不超过该预算的用户素材。
依据这些简单的规则，采用短周期迭代和频繁的发布，很快客户和开发人员就会适应项目的开发节奏。客户会了解开发人员的开发速度。基于这种了解，客户能够确定项目会持续多长时间，以及会花费多少成本。
2.1.12 简单的设计
XP团队使他们的设计尽可能地简单、具有表现力（expressive）。此外，他们仅仅关注于计划在本次迭代中要完成的用户素材。他们不会考虑那些未来的用户素材。相反，在一次次的迭代中，他们不断变迁系统设计，使之对正在实现的用户素材而言始终保持在最优状态。
这意味着XP团队的工作可能不会从基础结构开始，他们可能并不先去选择使用数据库或者中间件。团队最开始的工作是以尽可能最简单的方式实现第一批用户素材。只有当出现一个用户素材迫切需要基础结构时，他们才会引入该基础结构。
下面三条XP指导原则（mantras）可以对开发人员进行指导。
1．考虑能够工作的最简单的事情
XP团队总是尽可能寻找能实现当前用户素材的最简单的设计。在实现当前的用户素材时，如果能够使用平面文件，就不去使用数据库或者EJB（企业级Java Bean）；如果能够使用简单的socket 连接，就不去使用ORB（对象请求代理）或者RMI（远程方法调用）；如果能够不使用多线程，就别去用它。我们尽量考虑用最简单的方法来实现当前的用户素材。然后，选择一种我们能够实际得到的和该简单方法最接近的解决方案。
2．你将不需要它
是的，但是我们知道总有一天会需要数据库，会需要ORB，也总有一天得去支持多用户。所以，我们现在就需要为那些东西做好准备，不是吗？
如果在确实需要基础结构前拒绝引入它，那么会发生什么呢？XP团队会对此进行认真的考虑。他们开始时假设将不需要那些基础结构。只有在有证据，或者至少有十分明显的迹像表明现在引入这些基础结构比继续等待更加合算时，团队才会引入这些基础结构。
3．一次，并且只有一次
极限编程者不能容忍重复的代码。无论在哪里发现重复的代码，他们都会消除它们。
导致代码重复的因素有许多，最明显的是用鼠标选中一段代码后四处粘贴。当发现那些重复的代码时，我们会通过定义一个函数或基类的方法来消除它们。有时两个或多个算法非常相似，但是它们之间又存在着微妙的差别，我们会把它们变成函数，或者使用TEMPLATE METHOD模式。无论是哪一种代码重复之源，一旦发现，就必须被消除。
消除重复最好的方法就是抽象。毕竟，如果两种事物相似的话，必定存在某种抽象能够统一它们。这样，消除重复的行为会迫使团队提炼出许多的抽象，并进一步减少了代码间的耦合。
2.1.13 重构
第5章会对重构（（refactoring）进行详细的讨论，下面只是做简单的介绍。
代码往往会腐化。随着我们添加一个又一个的特性，处理一个又一个的错误，代码的结构会逐渐退化。如果对此置之不理的话，这种退化最终会导致纠结不清，难于维护的混乱代码。
XP团队通过经常性的代码重构来扭转这种退化。重构就是在不改变代码行为的前提下，对其进行一系列小的改造（transformation），旨在改进系统结构的实践活动。每个改造都是微不足道的，几乎不值得去做。但是所有的这些改造叠加在一起，就形成了对系统设计和构架显著的改进。
在每次细微改造之后，我们运行单元测试以确保改造没有造成任何破坏，然后再去做下一次改造。如此往复，周而复始，每次改造之后都要运行测试。通过这种方式，我们可以在改造系统设计的同时，保持系统可以工作。
重构是持续进行的，而不是在项目结束时、发布版本时、迭代结束时、甚至每天快下班时才进行的。重构是我们每隔一个小时或者半个小时就要去做的事情。通过重构，我们可以持续地保持尽可能干净、简单并且具有表现力的代码。
2.1.14 隐喻
隐喻（metaphore）是所有XP实践中最难理解的一个。极限编程者在本质上都是务实主义者，隐喻这个缺乏具体定义的概念使我们觉得很不舒服。的确，一些XP的支持者经常讨论把隐喻从XP 的实践中去除。然而，在某种意义上，隐喻却是XP所有实践中最重要的实践之一。
想像一下智力拼图玩具。你怎样知道如何把各个小块拼在一起？显然，每一块都与其他块相邻，并且它的形状必须与相邻的块完美地吻合。如果你无法看到但是具有很好的触觉，那么通过锲而不舍地筛选每个小块，不断地尝试它们的位置，也能够拼出整个图形。
但是，相对于各个小块的形状而言，还有一种更为强大的力量把这些复杂的小块拼装在一起。这就是整张拼图的图案。图案是真正的向导。它的力量是如此之大，以致于如果图案中相邻的两块不具有互相吻合的形状，你就能断定拼图玩具的制作者把玩具做错了。
这就是隐喻，它是将整个系统联系在一起的全局视图；它是系统的未来景像，是它使得所有单独模块的位置和外观（shape）变得明显直观。如果模块的外观与整个系统的隐喻不符，那么你就知道该模块是错误的。
隐喻通常可以归结为一个名字系统。这些名字提供了一个系统组成元素的词汇表，并且有助于定义它们之间关系。
例如，我曾经开发过一个以每秒60个字符的速度将文本输出到屏幕的系统。以这样的速度，字符充满整个屏幕需要一段时间。所以我们让产生文本的程序把产生的文本放到一个缓冲区中。当缓冲区满了的时候，我们把该程序交换到磁盘上。当缓冲区快要变空时，我们把该程序交换回来并让它继续运行。
我们用装卸卡车拖运垃圾来比喻整个系统。缓冲区是小卡车，屏幕是垃圾场，程序是垃圾制造者。所有的名字相互吻合，这有助于我们从整体上去考虑系统。
另举一例，我曾经开发过一个分析网络流量的系统。每30分钟，系统会轮询许多的网络适配器，并从中获取监控数据。每个网络适配器为我们提供一小块由几个单独变量组成的数据，我们称这些数据块为“面包切片”。这些面包切片是待分析的原始数据。分析程序“烤制”这些切片，因而被称为“烤面包机”。我们把数据块中的单个变量称为“面包屑”。总之，它是一个有用并且有趣的隐喻。
第3章计划
3.6 结论
通过一次次的迭代和发布，项目进入了一种可以预测的、舒适的开发节奏。每个人都知道将要做什么，以及何时去做。涉众经常地、实实在在地看到项目的进展。他们看到的不是画满了图、写满了计划的记事本，而是可以接触到、感觉到的可以工作的软件，并且他们还可以对这个软件提供自己的反馈。
开发人员看到的是基于他们自己的估算并且由他们自己度量的开发速度控制的合理的计划。他们选择他们感觉舒适的任务，并保持高的工作质量。
管理人员从每次迭代中获取数据，他们使用这些数据来控制和管理项目。他们不必采用强制、威胁或者恳求开发人员忠心的方式去达到一个武断的、不切实际的目标。
这听起来好像是美好轻松的，其实不是这样。涉众对过程产生的数据并不总是满意的，特别是在刚刚开始时。使用敏捷方法并不意味着涉众就可以得到他们想要的。它只不过意味着他们将能够控制着团队以最小的代价获得最大的商业价值。
第4章测试
编写单元测试是一种验证行为，更是一种设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。
4.1 测试驱动的开发方法
第一个也是最明显的一个影响，是程序中的每一项功能都有测试来验证它的操作的正确性。这个测试套件可以给以后的开发提供支援。无论何时我们因疏忽破坏了某些已有的功能，它就会告诉我们。我们可以向程序中增加功能，或者更改程序结构，而不用担心在这个过程中会破坏重要的东西。测试告诉我们程序仍然具有正确的行为。这样，我们就可以更自由地对程序进行改进。
还有一个更重要但是不那么明显的影响，是首先编写测试可以迫使我们使用不同的观察点。我们必须从程序调用者的有利视角去观察我们将要编写的程序。这样，我们就会在关注程序的功能的同时，直接关注它的接口。通过首先编写测试，我们就可以设计出便于调用的软件。
此外，通过首先编写测试，我们就迫使自己把程序设计为可测试的。把程序设计为易于调用和可测试的，是非常重要的。为了成为易于调用和可测试的，程序必须和它的周边环境解耦。这样，首先编写测试迫使我们解除软件中的耦合（forces us to decouple the software）。
首先编写测试的另一个重要效果，是测试可以作为一种无价的文档形式。如果想知道如何调用一个函数或者创建一个对象，会有一个测试展示给你看。测试就像一套范例，它帮助其他程序员了
解如何使用代码。这份文档是可编译、可运行的。它保持最新。它不会撒谎。
4.2 验收测试
作为验证工具来说，单元测试是必要的，但是不够充分。单元测试用来验证系统的小的组成单元应该按照所期望的方式工作，但是它们没有验证系统作为一个整体时工作的正确性。单元测试是用来验证系统中个别机制的白盒测试（white-box tests）。验收测试是用来验证系统满足客户需求的黑盒测试（black-box tests）。
验收测试由不了解系统内部机制的人编写。客户可以直接或者和一些技术人员（可能是QA人员）一起来编写验收测试。验收测试是程序，因此是可以运行的。然而，通常使用专为应用程序的客户创建的脚本语言来编写验收测试。
验收测试是关于一项特性（feature）的最终的文档。一旦客户编写完成了验证一项特性的验收测试，程序员就可以阅读那些验收测试来真正地理解这项特性。所以，正如单元测试作为可编译、运行的有关系统内部结构的文档那样，验收测试是有关系统特性的可编译、执行的文档。
此外，首先编写验收测试的行为对于系统的构架方面具有深远的影响。为了使系统具有可测试性，就必须要在很高的系统构架层面对系统进行解耦合。例如，为了使验收测试无需通过用户界面（UI）就能够获得对于业务规则的访问，就必须要以满足这个目的的方式来解除用户界面和业务规则之间的耦合。
在项目迭代的初期，会受到用手工的方式进行验收测试的诱惑。但是，这样做使得在迭代的初期就丧失了由自动化验收测试的需要带来的对系统进行解耦合的促进力，所以是不明智的。当在最早开始迭代时，如果非常清楚地知道必须要自动化验收测试，就会做出非常不同的系统构架方面的权衡。并且，正如单元测试可以促使你在小的方面做出优良的设计决策一样，验收测试可以促使你在大的方面做出优良的系统构架决策。
创建一个验收测试框架（framework）看起来是件困难的任务。然而，如果仅仅创建框架中对单个迭代包含的特性进行验收测试所需要的那部分，就会发现并不困难。你还会发现所花费的努力是值得的。
第5章重构
在Martin Fowler的名著《重构》一书中，他把重构（Refactoring）定义为：“……在不改变代码外在行为的前提下对代码做出修改，以改进代码的内部结构的过程。”可是我们为什么要改进已经能够工作的代码的结构呢？不是还有句古老的谚语，“如果它没有坏，就不要去修理它！”吗？
每一个软件模块都具有三项职责。第一个职责是它运行起来所完成的功能。这也是该模块得以存在的原因。第二个职责是它要应对变化。几乎所有的模块在它们的生命周期中都要变化，开发者有责任保证这种改变应该尽可能地简单。一个难以改变的模块是拙劣的，即使能够工作，也需要对它进行修正。第三个职责是要和阅读它的人进行沟通。对该模块不熟悉的开发人员应该能够比较容易地阅读并理解它。一个无法进行沟通的模块也是拙劣的，同样需要对它进行修正。
怎样才能让软件模块易于阅读、易于修改呢？本书的主要内容都是关于一些原则和模式的，使
用这些原则和模式可以帮助你创建更加灵活和具有适应性的软件模块。然而，要使软件模块易于阅读和修改，所需要的不仅仅是一些原则和模式。还需要你的注意力，需要纪律约束，需要创造美的激情。
5.2 结论
重构后的程序读起来比一开始要好得多，程序工作得也更好一些。我对这个结果非常满意。程序变得更易理解，因此也更易更改，且程序结构的各部分之间互相隔离，这也使它更容易更改。
你也许担心提取出仅仅调用一次的函数会对性能造成负面的影响。我认为在大多数情况下，提取出函数所增加的可读性是值得花费额外的一些微小开销的。然而，也许那些少许的开销存在于深深的内部循环中，这将会造成较大的性能损失。我的建议是假设这种损失是可以忽略的，等待以后再去证明这种假设是错误的。
这值得我们花费时间吗？毕竟，程序已经可以完成所需的功能。我强烈推荐你应该经常对你所编写和维护的每一个模块进行这种重构实践。投入的时间和随后为自己和他人节省的努力相比起来是非常少的。
重构就好比用餐后对厨房的清理工作。第一次你没有清理它，你用餐是会快一点。但是由于没有对盘碟和用餐环境进行清洁，第二天做准备工作的时间就要更长一点。这会再一次促使你放弃清洁工作。的确，如果跳过清洁工作，你今天总是能够很快用完餐，但是脏乱在一天天的积累。最终，你得花费大量的时间去寻找合适的烹饪器具，凿去盘碟上已经干硬的食物残余，并把它们洗擦干净以使它们适合于烹饪。饭是天天要吃的。忽略掉清洁工作并不能真正加快做饭速度。
重构的目的，正像在本章中描述的，是为了每天清洁你的代码。我们不想让脏乱累积，我们不想“凿去并洗擦掉”随着时间累积的“干硬的”比特，我们想通过最小的努力就能够对我们的系统进行扩展和修改。要想具有这种能力，最重要的就是要保持代码的清洁。
关于这一点，我怎么强调都不过分。本书中所有的原则和模式对于脏乱的代码来说将没有任何价值。在学习原则和模式前，首先学习编写清洁的代码。
第Ⅱ部分敏捷设计
在敏捷团队中，全局视图和软件一起演化。在每次迭代中，团队改进系统设计，使设计尽可能适合于当前系统。团队不会花费许多时间去预测未来的需求和需要，也不会试图在今天就构建一些基础结构去支撑那些他们认为明天才会需要的特性。他们更愿意关注当前的系统结构，并使它尽可能地好。
拙劣设计的症状
我们如何知道软件设计的优劣呢？第7章中列举并描述了拙劣设计的症状，演示了那些症状如何在一个软件项目中累积，并描述了如何去避免它们。
这些症状定义如下：
z僵化性（Rigidity）：设计难以改变。
z脆弱性（Fragility）：设计易于遭到破坏。
z牢固性（Immobility）：设计难以重用。
z粘滞性（Viscosity）：难以做正确的事情。
z不必要的复杂性（Needless Complexity）：过分设计。
z不必要的重复（Needless Repetition）：滥用鼠标。
z晦涩性（Opacity）：混乱的表达。
这些症状在本质上和代码的“臭味”（smell）相似，但是它们所处的层次稍高一些。它们是遍及整个软件结构的臭味，而不仅仅是一小段代码。
原则
在本部分的其余章节中，描述了一些面向对象设计的原则，这些原则有助于开发人员消除设计中的臭味，并为当前的特性集构建出最好的设计。
这些原则如下：
z单一职责原则（The Single Responsibility Principle，简称SRP）
z开放－封闭原则（The Open-Close Principle，简称OCP）
z Liskov替换原则（The Liskov Substitution Principle，简称LSP）
z依赖倒置原则（The Dependency Inversion Principle，简称DIP）
z接口隔离原则（The Interface Segregation Interface，简称ISP）
这些原则是数十年软件工程经验来之不易的成果。它们不是某一个人的成果，而是许许多多软件开发人员和研究人员思想和著作的结晶。虽然在此把它们表述为面向对象设计的原则，但是事实上它们只是软件工程中一直存在的原则的特例而已。
臭味和原则
设计中的臭味是一种症状，是可以主观（如果不能客观的话）进行度量的。这些臭味常常是由于违反了这些原则中的一个或者多个而导致的。例如，僵化性的臭味常常是由于对开放－封闭原则（OCP）不够关注的结果。
敏捷团队应用这些原则来除去臭味。当没有臭味时，他们不会应用这些原则。仅仅因为是一个原则就无条件的去遵循它的做法是错误的。这些原则不是可以随意在系统中到处喷洒的香水。过分遵循这些原则会导致不必要的复杂性（Needless Complexity）的设计臭味。
敏捷开发流程详解
敏捷开发流程详解by yangdl 1敏捷开发流程 ?敏捷软件开发核心是迭代式开发，增量交付。 ?每一次迭代都建立在稳定的质量基础上，并作为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈。 ?迭代型的方法就是将整个软件生命周期分成多个小的迭代，每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。 ?迭代建议采用固定的周期（1-4）周，可以每个迭代周期不一定要相同，但迭代内工作不能完成，应该缩减交付范围而不是延长周期。 1.1敏捷流程详解图-敏捷流程图 1.2敏捷流程三种角色及其职责
1.3敏捷开发流程详解 1.3.1流程图详解步骤 1.制定产品需求列表 ?PO收集来自客户、市场、领导等渠道的信息，从业务角度和市场价值编制一份按优先级排序的、明确的、可度量的、合理的产品需求列表； 2.召开计划会议 ?PO召集TM和SM（也可邀请其他利益相关者参加）召开计划会议（发布计划会议和冲刺会议一块开），发布计划主要是说明产品完整交付给客户的计划时间和交付物， ?冲刺计划就是确定该冲刺阶的长度（建议冲刺长度1-4周）、目标和冲刺任务单及其工作量估算
（以理想人天manday=7.5h估算，单位为小时计算），会议时间建议不要超过6h时间； ?在计划会议上就需要进行确认，是否需要使用持续集成；若使用持续集成，团队需要每天下班前至少提交一次私有构建成功的代码到服务器，并且要求写详细的日志信息；若不使用持续集 成，团队每天有完成任务单的情况，都需要在svn上以增量形式发包并通知到相关人员； ?项目计划会议上可以确定每天站立会时间及其规则要求（建议会议时间在15-20分钟左右），每个人回答3个问题：昨天做了什么，遇到什么问题，今天要做什么。具体问题讨论及其解决， 在私下进行沟通，不要在会议上讨论。站立会上只有TM人员有发言权，其他人员不要干预，SM 主要是维护秩序、规则及其引导作用。 3.需求分析、设计、编码和测试： ?计划会议结束后，TM获取各自的冲刺任务单进行后面的需求分析、设计、编码和测试； ?这里特别要说明的是，开发和测试是并行工作，必要的文档还是需要输出（如：讨论次数较多的功能点、备选方案很多但最后确认一种、重要功能、业务逻辑复杂的等等）。具体情况，需要 项目组根据实际情况决定，但客户要求交付的文档必须要输出； 4.冲刺任务单和燃尽图更新 每天SM需要根据每日站立会上TM反馈的情况，进行更新冲刺任务单和燃尽图或SM和TM之间达成共识，TM各自完成后进行更改状态，这里涉及到的文档都会有相对应的模板供参考使用。 5.迭代周期结束点 ?已到迭代周期结束点，只有哪些经过测试通过的冲刺需求列表才能算是真正的完成，其他未经过测试或测试不通过的不能算是完成。 ?这里要特别注意，所谓的测试通过不是说要把所有的问题都解决才算是通过，这个要根据项目具体的要求和规定来定。还没有达到迭代结束点，该冲刺任务需求列表就完成，可以从产品需 求列表中挑选优先级高的进行开发。 6.冲刺评审会议 ?TM需要召开冲刺评审会议，邀请PO、客户或客户代表来参加，由这些客户或客户代表来表决是否满足需求和期望目标。一般会议时间建议不要超过2个小时，参加人员除PO及其相关利益 人来参加外，TM全体成员，也可以邀请其他相关人员参加。 7.冲刺回顾会议 ?迭代输出的增量交付可能会引起原产品需求列表的改变，可能需要更新原产品需求列表；最后TM需要开展本次迭代的好的实践和不足的改进机会，最终稿由SM整理汇总，作为下一次的迭 代的经验参考。回顾会议建议时间不用太长，一般15-30分钟即可，全体人员都需要参加，包括：
浅谈敏捷项目管理在软件开发中的应用
浅谈敏捷项目管理在软件开发中的应用 摘要：本文先介绍了使用传统项目管理技术管理软件开发项目的方法，然后介绍了使用敏捷项目管理的初步实践，通过两者比较，提出了使用敏捷项目管理进行软件开发的方法。 一、使用传统项目管理技术管理软件开发项目的方法 按照《人月神话》的说法，软件开发是个焦油坑，书店里关于软件开发管理的书籍林良满目，各个软件开发组织也在尝试和应用不同的软件开发管理办法，希望寻找到“软件开发的银弹”。 在软件开发管理中，引入项目管理的办法，已经得到广大软件开发管理人员的一致认同，但对于具体实施何种项目管理办法，各个软件开发组织都有不同的答案，更多的迷茫，因为引入的项目管理办法不能从根本上解决软件开发项目面临的进度拖后、费用超支等问题，软件开发的银弹到底在哪里？ 以下是笔者对国内软件开发组织不同项目管理成熟度的归纳和总结，大概可以分如下几类;1)小作坊、混沌形的，这样的组织还处在接单求生存的阶段，管理者还根本没有项目的意识，以满足客户需求、定制开发和回款为第一要务；2）尝试按照项目管理的思路与方法管理软件开发项目，但发现推
行困难，不得要领，目前很多中小型的软件开发组织都处于这个阶段；3）大型的软件企业，已经通过CMM|ISO认证、有足够的资源做保障，实行规范的项目管理做法，如一些软件外包工厂。 本文主要讲述处于第二个层次的软件开发组织的项目管理问题。软件开发项目管理涉及非常多的内容，从软件开发本身的业务出发，有需求管理、变更控制、配置管理、测试管理、系统分析与设计等；从项目管理的知识领域角度，有范围管理、时间管理、沟通管理、人力资源管理等内容。 按照传统的经典项目管理方法，通过一定的项目管理模板与IT工具，总结多个项目的经验，笔者总结有如下经典步骤来完成项目管理的计划编制与进度控制过程： 计划编制的经典步骤： ①建立企业和项目资源库：这个是进行项目管理的基础工作。 ②设置项目日历、资源日历。 ③设置项目的主要里程碑点。 ④在WBS（工作包）下列出工作清单（Task，Activity）。工作分解结构（WBS）和作业是进行项目范围管理的途径。 ⑤对每个Task估计工期。 ⑥连接每个Task间的逻辑关系（SS，FS，FS，FF，延时）。
Scrum敏捷软件开发过程
Scrum敏捷软件开发过程 目录 ?什么是敏捷软件开发？ ?敏捷方法的项目计划 ?敏捷项目管理和传统项目管理 ?为什么使用敏捷？ ?Scrum概述 ?Scrum的角色 ?Scrum实践和工作产品 ?敏捷开发中的估计方法 ?测试驱动开发 ?Scrum应用 ?支持工具和模版 ?一些常见的误解 敏捷开发方法 什么是敏捷软件开发? ?敏捷软件开发是软件项目的一个概念框架. ?有许多建立在敏捷概念上的方法，如Scrum和Extreme Programming(XP). ?与僵化的、重量级的、官僚式的方法形成对照，比如瀑布模型（指纯粹形式的）?最大限度地降低短期固定时间的迭代式软件的开发风险. 敏捷宣言（2001年） ?人和交互胜过过程和工具. ?Individuals and interactions over processes and tools ?可以工作的软件胜过完备的文档. ?Working software over comprehensive documents ?客户协作胜过合同谈判. ?Customer collaboration over contract negotiation ?随时应对变化胜过遵循计划. ?Responding to change over following a plan 敏捷过程的限制 ?敏捷软件开发过程包含过程、原则、工具，和最重要的-人 ?因此：诚信是基础 ?没有过程能够对诚信进行有效地约束，诚信与否是有效实施敏捷过程的最大限制
Product constantly Scope frozen new PBL items to next Sprint Backlog 使用敏捷方法的项目计划 “Sprintful” of top - priority PBL to the next Sprint Sprint More accurate estimates as man hours 8 Short term planning (commitment by May be 5 2 1 3 8 5 8 ∑32 Long term planning (best guess at the moment): Initial Size Estimates As Story Points Velocity 8 SP/Sprint 4 Sprints T arget Sprint for each PBL item set, feasible implementation Order. 敏捷项目管理和传统项目管理 ? 传统项目管理： ? 事先对整个项目进行估计、计划、分析 ? 反对变更; 变更需要重新估计、重新规划 ? 严密的合同来减少风险, 如果改变需求要走 CR 流程. ? 项目作为一个“黑盒子”，对客户与供应商的可视性差. ? 产品化和测试阶段是分离的. ? 文档和计划驱动的方法. ? 软件交付时间晚, 意识到风险的时间晚. ? 敏捷项目管理: ? 对整个项目做一个粗略的估计,每一次迭代都有详细的计划. ? 鼓励变化, 客户价值驱动开发. ? 信任和赋予权力;合约使变更变得简单，增加价值. ? 客户和开发人员之间是紧密的连续的合作关系 ? 每次迭代都产生可交付的软件 ? 专注于交付软件. ? 第一次迭代就可交付能工作的版本，风险发现的早. 为什么采用敏捷? –预期的收益 ? 采用敏捷方法得当的话，可以： ? 更加透明; 随时跟踪项目的状态和进展情况，及早发现问题和风险 . ? 快速交付, 每次迭代都能交付可运行的软件. ? 最高风险和最高优先级的需求，最优先进行开发. ? 改善应对变更能力, 减少大量的重计划. ? 改善项目沟通. ? 更好的客户参与, 避免错误的假设. ? 总之: ? 提高了生产率; 减少“浪费”（不需要的文档，重复工作等），项目的每次迭代都有明
敏捷开发流程(自己总结)
敏捷开发的相关简介 敏捷定义 Scrum是一个轻量级的软件开发方法 Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的迭代周期，每个小的迭代周期称为一个Sprint，每个Sprint的建议长度2到4周。 在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint 中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。 Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。在每个迭代结束时，Scrum 团队将交付潜在可交付的产品增量。 敏捷的原则 个体与交互胜过过程与工具 可以工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循计划 这四句价值观用语句表达就是： 自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件。 胜过 与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，最后交付需求。 《敏捷宣言》12条原则 1.最优先的目标是通过尽早地、持续地交付有价值的软件来满足客户。 2.欢迎需求变化，甚至在开发后期。敏捷过程控制、利用变化帮助客户取得竞争优势。 3.频繁交付可用的软件，间隔从两周到两个月，偏爱更短的时间尺度。 4.在整个项目中业务人员和开发人员必须每天在一起工作。 5.以积极主动的员工为核心建立项目，给予他们所需的环境和支持，信任他们能够完成工作。 6.在开发团队内外传递信息最有效率和效果的方法是面对面的交流。 7.可用的软件是进展的主要度量指标。 8.敏捷过程提倡可持续发展。发起人、开发者和用户应始终保持稳定的步调。 9.简化——使必要的工作最小化的艺术——是关键。
敏捷软件开发理论与实践
BJUG
敏捷软件开发方法理论与实战
敏捷软件开发方法理论与实战
https://www.sodocs.net/doc/c45185630.html,/ mailto:morningspace@https://www.sodocs.net/doc/c45185630.html,
https://www.sodocs.net/doc/c45185630.html,/
BJUG
敏捷软件开发方法理论与实战
议 题
? ? ? ? 敏捷方法概述 极限编程简介 敏捷实践案例 敏捷游戏
https://www.sodocs.net/doc/c45185630.html,/
BJUG
敏捷软件开发方法理论与实战
敏捷方法概述
https://www.sodocs.net/doc/c45185630.html,/
BJUG
敏捷软件开发方法理论与实战
开场白
军事历史就是一个在装备和灵活性的相对优势之间来回摇摆 的钟摆。
—— 卡尔·冯·克劳塞维茨《战争论》
– – – –
盔甲骑士 vs. 布衣士兵 盔甲骑士 vs. 轻骑兵 坦克 vs. 轻骑兵 坦克 vs. 反坦克导弹
在IT领域，我们正好都在从装备统治一切的时代走出来。现 在我们正进入一个唯有灵活性才是至关重要的时代。
—— Tom DeMarco《规划极限编程》序
– 工程方法 vs. 没有方法 – 工程方法 vs. 敏捷方法
https://www.sodocs.net/doc/c45185630.html,/
BJUG
敏捷软件开发方法理论与实战
工程方法 Engineering Methodology
? 借鉴了工程领域的实践，有着严格而详尽的规定，强调 项目的可控性 ? 官僚繁琐，要做太多的事情从而延缓开发进程 ? 从泰勒主义，到精益制造
https://www.sodocs.net/doc/c45185630.html,/
敏捷软件开发
敏捷软件开发:SRP单一职责原则 (2009-03-24 20:30:24) 转载 标签： it 这条原则实际就是体现内聚性原则的体现，一个模块的组成元素之间的功能相关性。把内聚性概念扩展一下：把内聚性和引起一个模块或者类改变的作用力联系起来。 一个类应该只有一个发生变化的原因。若Game类有2个不同的职责，一个是记录当前轮，另一个式计算分数，最后要把这两个职责分离到两个类中。为何把这两个职责分在单独的类中呢？因为每个职责都是变化的一个轴线，当需求变化会反映为类的职责的变化。如果一个类承担了多于一个职责，那么引起它变化的原因就会有多个。 如果一个类承担的职责太多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或抑制这个类完成其他职责的能力，这种耦合或导致脆弱的设计，当变化发生时，设计会遭受到预想不到的破坏。 定义职责：如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，有时候我们很难注意到这点，我们习惯以组的形式去考虑职责。 public interface Modem{ public void Dial(String pno); public void Handup(); public void Send(char c); public char Recv(); } 接口包括了2个职责，第一个职责是连接管理，第二个职责是数据通信。 如果应用程序的变化方式总是导致这两个职责同时变化，那么就不要分离他们，分开他们就会有不必要的复杂性味道。仅当变化发生时，变化的轴线才有实际意义，如果没有征兆，那么应用SRP或者任何其他原则都是比明智的。 分离耦合的职责：经常会有一些和硬件或者操作系统的细节有关的原因，迫使我们把不愿意耦合在一起的东西欧和在一起了。然而，对于应用的其余部分来说，通过分离他们的接口我们已经解耦概念。 如果ModenImplementation implemet DataChannel,Conection。ModenImplementation看起来是一个混杂物，或者有缺陷的类，所有的依赖关系都是从它发出来的。谁都不需要依赖它，谁都不需要知道它的存在。因此，我们已经把丑陋的部分隐藏起来了。其丑陋性不会泄露出来，污染应用程序的其它部分。 持久化：如Emplyee:CalculatePay,Store,Emplyee类包括了业务规则和对于持久化的控制，这两个职责在大多数情况下绝不应该混合在一起。业务规则往往会频繁地变化，而持久化的方式却不会如此频繁的变化，并且变化的原因也不一样。把持久化系统和业务规则绑定在一起是自讨苦吃的做法。如果发现这种情况存在了，应该使用FACADE、dao或者proxy模式对设计进行重构，分离这两个原则。 SRP是所有原则中最简单的原则之一，也是最难正确运用的原则之一。
敏捷开发与敏捷测试(很详细的说明)
敏捷开发与敏捷测试 来源: cnblogs 敏捷开发：1.敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。2.敏捷型方法是“面向人” 的(people-oriented) 而非“面向过程”的(process-oriented)。它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。 我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心。 敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有多。改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。” 敏捷开发提出了以下遵循的原则： ·我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 ·即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 ·经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 ·在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 ·围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 ·在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。 ·工作的软件是首要的进度度量标准。 ·敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 ·不断地关注优秀的技能和好的设计会增强敏捷能力。 ·简单是最根本的。
敏捷开发过程中如何开发高质量的软件
.、八、- 刖言 什么是软件质量？很多技术同仁都认为软件质量是软件是否存在Bug，是否性 能高，安全性好等等。其实软件质量的含义远多与此。质量就是软件产品对于 某个（或某些）人的价值；价值是指创造利润，又或是降低成本。总的来说， 软件质量是软件的灵魂和存在意义。另外，我们知道现在敏捷开发日趋流行， 其实敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论, 敏捷开发是追求高质量软件的方法论和过程。 本文将和大家一起探讨软件质量的含义，以及敏捷开发中如何进行高质量软件 的开发。 软件质量的理解 首先，我们先来看看什么是软件产品质量？先有了软件质量定性的了解，才能 介绍如何影响、控制和改进质量。 大师温伯格在《质量?软件?管理系统思维》说到：“质量就是软件产品对于 某个（或某些）人的价值”（某个或某些人文章中统称之为用户），这里面包含两个层次的质量含义，即“正确的软件”及“软件运行正确”： 1.“正确的软件”是说，一个软件要能够满足用户的需求，为用户创造价值 此处的价值可以体现在两个方面，即为用户创造利润或者减少成本。如果一个软 件能够满足需求的用户群体越大、创造的利润越大或减少的成本 越大，则该软件产品的质量越高。反之，一个产品尽管运行良好，没有 Bug,扩展性很强，性能很好，但如果没有服务的用户人群，没有为用户 创造价值，则这样的软件尽管运行良好，也无任何质量可言。 2.“软件运行正确”是说软件没有或很少Bug，扩展性很强，性能良好，易 用性高等。这样的软件是一个运行良好的软件，但还不能称之为高质量 的软件。只有在软件符合用户的需求的基础上，运行良好的软件，才是 一个高质量的软件。当然，如果软件完全符合用户需求，但不易使用， 经常出错，性能很差，这样的软件也不是一个高质量的软件。 “正确的软件”及“软件运行正确”二者相辅相成，前者关系到软件的成败， 后者关系到软件的好坏。在现实的很多开发团队中，特别是偏技术的开发团队中，往往过分注重后者（软件的Bug率，性能，可扩展性，架构等），经常陷入在软件开发过程的细节之中，而忽略了前者（软件需要符合用户的需求），开发出的软件经常能用但无用，不是最终用户期望的软件，这样的软件是能用但无用零质量软件。 在产品开发中，能用但无用的现象尤为明显。产品和项目不一样，项目往往是 为某个客户而开展，有特定的需求来源，而产品往往是一个更广泛的概念，是
软件开发方法
敏捷开发 敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。 相关联的关键成功因素有： 组织文化必须支持谈判人员彼此信任，人少但是精干，开发人员所作决定得到认可，环境设施满足成员间快速沟通之需要。最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，20、40人或者更少。大规模的敏捷软件开发尚处于积极研究的阶段。 对比其它方法 敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。 适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化. 对比迭代方法 相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。 对比瀑布式开发 两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。 相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。 极限编程
敏捷软件开发过程中高质量软件的开发
敏捷软件开发过程中高质量软件的开发 姓名：郑哲学号：21120233071 目录 一、敏捷开发的意义 (2) 二、敏捷开发同软件质量并无矛盾 (2) 1、沟通 (3) 2、简单 (3) 3、反馈 (3) 4、勇气 (3) 三、如何在敏捷开发过程中开发出高质量的软件 (3) 1、勇于重构 (4) 2、简单设计 (4) 3、编程规范 (5) 4、平稳的工作效率 (5) 5、每日会议 (5)
一、敏捷开发的意义 敏捷软件开发又称敏捷开发是一种从1990年代开始逐渐引起广泛关注的一 些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。 敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。并不意味着没有文档、没有设计、没有计划随意设计的万能钥匙[1]。 对于从前预见式的软件产品开发，在第一次挖成规格说明以及需求分析后，就进行软件产品的构建，并在开始阶段对所有的安排以及调度等细节活动进行安排，一般情况下不对计划做成没有预定义的变动，造成了项目计划的改动率极低。而相对来讲，敏捷软件开发并不在前期进行详细的规格说明，在开始阶段随着经验数据的出现，计划与估算的可能性才会相应增加，并通过构建反馈周期，推动自适应步骤，因此改动率较高，同时更加注重响应变化而不是一味遵循计划进行软件产品的开发[2]。 针对敏捷软件开发的目标，提出了12条的敏捷宣言： 1、最优先的目标是通过尽早地、持续地交付有价值的软件来满足客户。 2、欢迎需求变化，甚至在开发后期。敏捷过程控制、利用变化帮助客户 取得竞争优势。 3、频繁交付可用的软件，间隔从两周到两个月，偏爱更短的时间尺度。 4、在整个项目中业务人员和开发人员必须每天在一起工作。 5、以积极主动的员工为核心建立项目，给予他们所需的环境和支持，信 任他们能够完成工作。 6、在开发团队内外传递信息最有效率和效果的方法是面对面的交流。 7、可用的软件是进展的首要度量指标。 8、敏捷过程提倡可持续开发。发起人、开发者和用户应始终保持一个长 期的、稳定的开发速度。 9、简化——使必要的工作最小化的艺术——是关键。 10、持续关注技术上的精益求精和良好的设计以增强敏捷性。 11、最好的架构、需求和设计产生于自我组织的团队。 12、团队定期地对运作如何更加有效进行反思，并相应地调整、校正自己 的行为。 二、敏捷开发同软件质量并无矛盾 首先，根据敏捷项目开发的要求以及目标，我们提出四个敏捷开发的价值目标：沟通、简单、反馈以及勇气。同上一节讲到的敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性，同时拥抱市场变化，拥抱客户需求变化，采用迭代反馈的方式管理项目[3]。 我们将从这四个方面一次论证敏捷项目开发同软件质量保证之间并无矛盾。
高级软件开发过程——Rational统一过程、敏捷过程与微软过程-第一章
1946年，世界上第一台电子计算机诞生在美国宾夕法尼亚大学的摩尔学院，由此拉开了计算机软件的发展史。从宏观角度而言，计算机软件的发展主要经历了以下三个阶段[1]。 （1）第一阶段——程序设计阶段 20世纪60年代以前还没有软件开发的说法，那时只有程序设计的概念，最多在写出程序后配有程序结构说明和使用说明。经典的程序设计方法为“程序设计=数据结构+算法”。 （2）第二阶段——软件工程阶段 20世纪70年代以来，人们认识到软件的工作不能仅限于编写程序，软件开发工作在程序编写之前和之后还有很多重要的工作不能忽略，例如需求分析、测试、维护等等。在总结“软件危机”教训后，人们认识到并建立了软件工程的思想。软件工程摒弃了认为只有充满编程技巧的程序才能高水平地发挥个人才能的观念，强调程序的可读性、可理解性、可测试性和易修改性等工程化的原则。 （3）第三阶段——软件过程阶段 从20世纪90年代开始，人们更加强调软件开发的效率、软件的质量以及与软件开发相关的管理工作，建立了“软件过程”的概念。软件过程不仅包括软件开发过程，还包括了支持性、管理性过程。 以上发展历程表明，通过实践、总结、再实践、再总结……人们对软件这门实践学科的理解正朝着更全面、更系统、更深刻的方向发展。 1.1 现代软件产业的困境 1.1.1 困境中的现代软件产业 当今，全球市场变幻莫测，用户需求日趋复杂，IT技术日新月异。软件企业组织在不断变化的市场和技术环境中能否取得成功，关键在于企业组织是否能在市场许可的期
2 限和有限资源条件下不断推出满足用户需求的产品。 然而，现代软件产业的总体情况并不理想。下面先来看一个真实的案例[14]。 Square Cal 3.0版本计划在2.0版本上市后的10个月内发布。项目经理Mickey和上司Kim讨论后决定：他们将为项目组成员提供私人办公室、最新型的计算机以及免费的碳酸饮料，并且要求开发者在前8个月按照预先设计好的接口各自开发，8个月之后进行可视化锁定，在最后2个月内完成系统集成。这是一个完美的计划。于是项目组成员各自做着自己的工作。随着可视化锁定日期的来临，他们开始进行代码集成。他们在可视化锁定最终截止日期前一天的下午两点开始工作，但很快发现程序不能编译通过，更不用说运行了。代码在编译时有数十个错误，而似乎每处理一个错误就会产生十个以上的新错误。他们一直干到午夜也没有结果，只好决定第二天再说。但测试发现问题的速度远比开发人员解决问题的速度快，解决系统某一部分的错误经常会导致其他部分的新问题。项目超期，项目组成员在巨大的压力下工作，士气逐渐低落。最后整个软件开发过程用了15个月时间，即超过了项目计划时间的50%，公司错过了最佳的产品发布日期。产品发布后，用户对Square Cal 3.0版本反映冷淡，在几个月的时间内其市场份额从第二位下降到第四位。 再看一组统计数据。图1-1[12]是根据最近一次项目调查得到的某公司所有软件项目的完成情况。从图中可以看出，出现问题的项目和中途取消的项目所占比例远高于顺利完成的项目。实际上，图1-1代表了整个现代软件产业的现状，很多软件项目最终不能交付，或者最终交付的软件项目进度发生延期、成本超出预算，而且运行经常不可靠。 因此，诸如“软件开发的滑铁卢”（Software Runaways）[2]、“死亡之旅”（Death March） [3]之类关于软件失败项目的报道不时见诸于媒体报端也就不足为奇。 53%16% 31% 中途取消的项目 出现问题的项目 顺利完成的项目 图1-1 项目完成情况图 1.1.2 陷入困境的根源 众所周知，现代计算机和因特网的性能在逐年增强，用户对运行于计算机和因特网
探讨如何进行敏捷软件开发
探讨如何进行敏捷软件开发 软件工程自诞生以来,一直试图通过技术和管理的手段来降低软件项目的不确定性。在这个美好的愿望指导下,专家们发明了结构化、发明了面向对象、发明了CMM,这些新的技术和方法的确有助于“软件危机”的解决,促进了软件业的发展;然而,超支、超时、低质量的老问题并未得到根本解决多数软件开发仍然是一个显得混乱的活动,即典型的“边写边改”(code and fix)。设计过程充斥着短期的、即时的决定,而无完整的规划。这种模式对小系统开发很管用,但是当系统变得越大越复杂时,要想加入新的功能就越来越困难。错误故障也越来越多,越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段,有时甚至有遥遥无期之感,从而对项目的完成产生严重的影响。2001年2月在美国犹他州,敏捷软件开发联盟(Agile Software Development Alliance)成立。在这之前,联盟的成员们在轻型方法的探索与实践方面做了很多有益的工作,知名的XP(Extreme Programming,极端编程)方法就是众多Agile方法论中的一种。敏捷(Agile)方法是对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡,使得能以不多的步骤过程获取较满意的结果。 1敏捷方法将拥有大量artifact(软件开发过程中的中间产物,如需求规约、设计模型等)和复杂控制的软件开发方法称为重型(Heavy Weight)方法,而把artifact较少的方法称为轻型(Light Weight)方法。敏捷方法(Agile Methodologies)汲取了众多轻型方法的“精华”,恰当地表达了这些轻型方法的最根本之处。首先,敏捷方法强调适应,而非预测。重型方法花费大量的人力物力,试图制订详细的计划来指导长期的工作,而一旦情况变化,计划就不再适用。因此重型方法本质上是抵制变化的,而敏捷方法则强调适应变化。其次,敏
大数据时代的敏捷软件开发方法
对象持久与敏捷软件开发 软件设计白皮书 Dirk Bartels 与Robert Greene 编制：Versant中国 2009 年11月 Versant China 上海市昆明路572号B区415-419室 邮箱： info@https://www.sodocs.net/doc/c45185630.html, 电话： (021) 5172 1968 传真： (021) 5172 1967 网址： https://www.sodocs.net/doc/c45185630.html, P 001
概述 效的软件开发方法之一。敏捷软件开发方法的挑战 之一是需要将非面向对象子系统，例如MySQL ， Oralce或者其它关系型数据库管理系统（RDBMS） 与现有的，面向对象的系统集成在一起。关系型数 据库要求将源代码在对象模型和关系模型之间进行 “翻译”，也就是众所周知的“对象关系映射—— ORM”。管理对象到关系的映射不仅仅非常消耗时 间，而且关系型数据库及其Schema经常处于受 限，或者无法“敏捷开发”的状态下。而且，存储 在关系型数据库中的数据经常可能会无法与采用敏 捷开发方法的团队对应用所进行的变更相匹配。 实际上，关系型数据库的数据由于是采用独立管理、独立建模的方式，它的自成体系必然会要求开发团队将有限的开发资源分成两部分。团队的管理者不仅仅需要管理源代码的同步，而且还需要管理实体关系模型的同步，进一步还要保持二者之间映射的同步。在这种情况下，大量的资源就被浪费甚至内耗掉了。尤其是当采用敏捷开发方法，源代码处于经常性的快速变动过程中时，保持对象模型和实体关系模型的一致就是一个费时费力的工作。 这种情况不仅仅会发生在采用敏捷开发方法的团队中，而且也会大量发生系统构建原型期。由于在这个阶段系统需求无法完全明确，可能会根据系统产出有快速迭代的要求，尤其是在中国的特殊国情下更是如此。在一些复杂的、对性能要求很高或者复杂度很高的系统中，这种对象-关系维护成本造成的开发团队的注意力不集中甚至会危及整个原型产品的生命。 本文将通过检讨和比较在采用敏捷开发方法的团队中，采用关系型数据库以及集中常见对象数据库的数据持久方法，对整个开发效果所带来的不同。同时，我们将对不同的持久方法对敏捷应用开发项目的开发速度和开发质量所带来的冲击进行量化的描述。我们相信在 采用敏捷开发方法的项目中，采用真正的对象持久工具，相比较于传统的关系型数据库管 理系统，能够大大改善开发团队的财务状况，以及通过提高开发速度来提高产品抢占市场 P 002
敏捷软件开发
达明咨询精品培训课程 课程名称 RDM065 敏捷软件开发与架构设计（Agile Software Development and Agile Architecture） 参加对象 企业CEO/总经理、研发总经理/副总、公司总工/技术总监、研发项目经理/产品经理、PMO（项目管理办公室）成员、研发骨干、测试、QA等。 客户需求 1、熟悉敏捷开发的流程，掌握敏捷开发关键环节活动和输出物； 2、如何有效的进行需求的管理和分析，形成产品需求； 3、如何做一个卓越的产品经理，要掌握哪些技能和工具； 4、项目经理需要哪些关键的技能，如何处理需求与产品的矛盾，业务需求与产品的矛 盾； 5、如何做到高效的测试，保证软件产品的质量，需要掌握哪些技能和工具； 6、如何构建优秀的敏捷团队，提高交付能力； 7、怎么样有效的提高项目的研发管理以及团队成员的评价和有效绩效管理； 8、如何提高异地办公研发项目管理，增强团队协作，构建统一的产品； 课程背景 21世纪是“快鱼吃慢鱼”的时代！ 现代企业的竞争就是“速度”的竞争！！ 谁能尽快开发出符合客户需求的产品，谁就是大赢家！！ 如何使产品开发周期显著缩短？如何促使企业充分利用外部资源，寻求合作设计、开发和制造的机会，让新产品上市时间更快？ “敏捷化开发”是国外最新提出的着眼于速度竞争的新产品开发管理模式，其基于一系列先进的研发管理方法，采取产品开发与市场投入的速度领先战略，以获得产品开发的时间领先优势，使企业在竞争日趋激烈的环境中获取利益最大化。 软件系统的日益复杂化和用户需求、软件更新的频繁化，加之开发团队分散的工作方式，项目的沟通和平滑管理变得越来越困难。另一方面，如何在多角色分工的情况下，紧扣用户提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，并在产品发
敏捷软件开发
敏捷软件开发宣言 我们正在通过亲身实践以及帮助他人实践，揭示 更好的软件开发方法。通过这项工作，我们认为： 个体和交互胜过 过程和工具 可以工作的软件胜过 面面俱到的文档 客户合作胜过 合同谈判 响应变化胜过 遵循计划 虽然右项也具有价值， 但我们认为左项具有更大的价值。 C. Martin Grenning Robert James Beck Kent Mellor Highsmith Steve Mike Beedle Jim Ken Schwaber Hunt Bennekum Andrew Arie van Jeffries Jeff Sutherland Cockburn Ron Alistair Thomas Kern Dave Cunningham Jon Ward Marick Martin Fowler Brian
敏捷宣言遵循的原则 我们遵循以下原则： z我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 z即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 z经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 z在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 z围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 z在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 z工作的软件是首要的进度度量标准。 z敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 z不断地关注优秀的技能和好的设计会增强敏捷能力。 z简单——使未完成的工作最大化的艺术——是根本的。 z最好的构架、需求和设计出自于自组织的团队。 z每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷开发过程中如何开发高质量的软件
前言 什么是软件质量？很多技术同仁都认为软件质量是软件是否存在 Bug，是否性 能高，安全性好等等。其实软件质量的含义远多与此。质量就是软件产品对于 某个（或某些）人的价值；价值是指创造利润，又或是降低成本。总的来说， 软件质量是软件的灵魂和存在意义。另外，我们知道现在敏捷开发日趋流行， 其实敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论， 敏捷开发是追求高质量软件的方法论和过程。 本文将和大家一起探讨软件质量的含义，以及敏捷开发中如何进行高质量软件 的开发。 软件质量的理解 首先，我们先来看看什么是软件产品质量？先有了软件质量定性的了解，才能 介绍如何影响、控制和改进质量。 大师温伯格在《质量·软件·管理系统思维》说到：“质量就是软件产品对于 某个（或某些）人的价值”（某个或某些人文章中统称之为用户），这里面包 含两个层次的质量含义，即“正确的软件”及“软件运行正确”： 1.“正确的软件”是说，一个软件要能够满足用户的需求，为用户创造价值。 此处的价值可以体现在两个方面，即为用户创造利润或者减少成本。如果 一个软件能够满足需求的用户群体越大、创造的利润越大或减少的成本 越大，则该软件产品的质量越高。反之，一个产品尽管运行良好，没有 Bug，扩展性很强，性能很好，但如果没有服务的用户人群，没有为用户 创造价值，则这样的软件尽管运行良好，也无任何质量可言。 2.“软件运行正确”是说软件没有或很少 Bug，扩展性很强，性能良好，易 用性高等。这样的软件是一个运行良好的软件，但还不能称之为高质量 的软件。只有在软件符合用户的需求的基础上，运行良好的软件，才是 一个高质量的软件。当然，如果软件完全符合用户需求，但不易使用， 经常出错，性能很差，这样的软件也不是一个高质量的软件。 “正确的软件”及“软件运行正确”二者相辅相成，前者关系到软件的成败， 后者关系到软件的好坏。在现实的很多开发团队中，特别是偏技术的开发团队中，往往过分注重后者（软件的Bug率，性能，可扩展性，架构等），经常陷 入在软件开发过程的细节之中，而忽略了前者（软件需要符合用户的需求）， 开发出的软件经常能用但无用，不是最终用户期望的软件，这样的软件是能用 但无用零质量软件。 在产品开发中，能用但无用的现象尤为明显。产品和项目不一样，项目往往是 为某个客户而开展，有特定的需求来源，而产品往往是一个更广泛的概念，是 市场上某一类客户群体的价值代表，没有固定的需求来源，而且良好的产品往
敏捷开发过程中如何开发高质量的软件
前言 1.“正确的软件”是说，一个软件要能够满足用户的需求，为用户创造价值。此处的价值可以体现在两 个方面，即为用户创造利润或者减少成本。如果一个软件能够满足需求的用户群体越大、创造的利润越大或减少的成本越大，则该软件产品的质量越高。反之，一个产品尽管运行良好，没有 Bug，扩展性很强，性能很好，但如果没有服务的用户人群，没有为用户创造价值，则这样的软件尽管运行良好，也无任何质量可言。 2.“软件运行正确”是说软件没有或很少 Bug，扩展性很强，性能良好，易用性高等。这样的软件是一 个运行良好的软件，但还不能称之为高质量的软件。只有在软件符合用户的需求的基础上，运行良好的软件，才是一个高质量的软件。当然，如果软件完全符合用户需求，但不易使用，经常出错，性能很差，这样的软件也不是一个高质量的软件。
敏捷开发对软件过程和质量控制产生了一系列的影响，主要来自两个方面的影响，用下图表示如下： 图 1. 敏捷过程带来的影响 图中的具体含义如下： 1.敏捷开发对“正确的软件”的影响 敏捷开发拥抱市场变化，拥抱客户需求变化，采用迭代反馈的方式管理项目。其背后的一个核心理念是：一个高质量的软件，首先应该是一个“正确的软件”，能够满足客户的需求。 我们知道当今的世界产品极大丰富，不管任何产品都会有的竞争对手和替代产品，大家熟知的有浏览器大战，输入法血拼，视频网站、博客满天飞，国内外 ERP 系统竞争激烈等。所以，软件的质量是要在市场化的竞争激烈的环境中去进行验证，进行优胜劣汰，最终高质量的软件产品被客户接受。所以，一个高质量的软件首先应该是一个“正确的软件”，能在激烈的市场和竞争对手中找到市场定位，有客户需求和市场销量，能提高产品的使用者客户体验的软件。否则，软件做的再好、性能再快、界面再优美好用也不是一个高质量的产品。 敏捷开发正是符合这样市场环境而诞生并流行，其迭代反馈、拥抱变化的理念和方法，能够使得团队更能开发出符合市场和客户的高质量软件。如上图 1 中所示，左图中的大半圆表示传统的开发模式中，产品不能满足客户需求的风险。因为传统的开发模式基于中央控制的计划，没有足够的迭代和反馈理念和方法，犹如一次性的把所有的资金购买了一只股票，导致质量风险大。上图 1 中右边的敏捷开发中，采取迭代反馈的原理，通过一系列的方法（下面会介绍）把市场和客户的需求和期望分散到个整个软件的生命周期中，犹如把所有资金进行资产组合，最后的软件产品质量风险小，能够较大概率的符合市场和客户的需求，并带来价值。 敏捷开发响应市场和客户价值取向，但如果没有完善的方法去收集和分析市场和客户的反馈，也会导致严重的质量问题，如软件随波逐流，随客户朝夕更改；市场定位模糊，没有核心竞争力；和竞争对手没有任何区别，陷入艰难的红海战争中等。所以，敏捷开发方法对高质量软件也提出了挑战，需要相应的方法和流程去执行和控制。 2.敏捷开发对“软件运行正确”的影响