（计算机软件与理论专业论文）敏捷软件开发、极限编程的研究.pdf

摘要 软件开发是一种艺术、工艺、科学和工程。人们在设想、确定以及创建软件 时，身边的环境不断在变更。敏捷是为了在动荡的业务环境中获益而创造变革和 响应变革的能力。本论文主要分析了敏捷软件开发观点，敏捷宣言的基本内容， 及其中包含的十二个原则。 极限编程是最著名的敏捷软件开发方法。随着通信技术的不断进步，新的信 息可以随时随地进行传递，很多商业项目在进行期间，需求仍在不断变化，极限 编程便是针对快速改变的软件需求而产生的。文中分析了极限编程的观点；其中 的变量，准则，原则，基本工作和十二个实践。 。传统方法强调的是严密的计划和文档驱动的瀑布式周期，他们侧重于计划和 架构，计划驱动开发关注的是软件的质量和过程的可预见性，计划驱动开发最佳 范例是能力成熟度模型。两种表面上有不同观点的方法在争夺着软件开发的主导 权。文中对敏捷软件开发与计划驱动开发就特征、擅长领域和关键要素等进行了 ， 比较。 作为极限编程的重点，单元测试已经成为整个开发过程中很重要的一部分。 本文对极限编程中的测试驱动开发进行了分析，描述了测试驱动开发的执行步 骤，测试驱动开发是一个迭代过程，所有新的代码都要先有其单元测试，在相对 稳定中增加功能，保证软件的开发在控制之下。文中最后给出了测试驱动开发的 形式化描述，并例举了测试驱动开发的应用实例。 关键词： 敏捷软件开发极限编程计划驱动方法测试驱动开发 a b s t r a c t s o f t w a r ed e v e l o p i n gw a sa na r t ，t e c h n o l o g y ，s c i e n c ea n de n g i n e e r i n g e n v i r o n m e n tw a sc h a n g i n gc o n s t a n t l y , w h e np e o p l ei m a g i n e d ，d e t e r m i n e da n d c r e a t e d s o f t w a r e a g i l ew a sa b i l i t yo fc r e a t i n gc h a n g e sa n dr e s p o n d i n gt oc h a n g e s ，i tp r o f i t e d i 1 1t h ev o l a t i l eb u s i n e s se n v i r o n m e n t a n a l y z i n gt h em a j o rp e r s p e c t i v eo fa g i l e s o f t w a r ed e v e l o p m e n t t h eb a s i cc o n t e n to ft h ea g i l ed e c l a r a t i o n ，a n dt h e 12 p r i n c i p l e sc o n t a i n e di nt h ea g i l ed e c l a r a t i o nw e r et h em a i nd i s c u s s i o ni nt h i sp a p e r e x t r e m ep r o g r a m m i n gw a st h em o s tf a m o u si na g i l es o f t w a r ed e v e l o p m e n t w i t hc o n t i n u i n ga d v a n c e si nc o m m u n i c a t i o nt e c h n o l o g y , t h en e wi n f o r m a t i o nc o u l d b et r a n s m i t t e da ta n ym o m e n ta n de v e r y w h e r e d u r i n gt h ec o u r s e o fm a n y c o m m e r c i a lp r o j e c t s ，d e m a n dw a sc o n s t a n t l yc h a n g i n g ，a n de x t r e m ep r o g r a m m i n g w a st a r g e t e da tt h en e e d so fr a p i d l yc h a n g i n gs o f t w a r e t h ep e r s p e c t i v e ，t h ev a r i a b l e s ， t h er u l e s ，t h ep r i n c i p l e s ，t h eb a s i c t a s k sa n d1 2p r a c t i c e si ne x t r e m ep r o g r a m m i n g w e r ei nt h i sp a p e ra n a l y z e d t h et r a d i t i o n a lm e t h o ds t r e s s e dt h er i g o r o u sp l a na n dt h ed o c u m e n t d r i v e n w a t e r f a l lc y c l e t h e ye m p h a s i z e dp a r t i c u l a r l yo nt h ep l a na n ds t r u c t u r e p l a n 。d r i v e n d e v e l o p m e n tc o n c e r n e dt h ep r e d i c t a b i l i t yo f t h ep r o c e s sa n dt h eq u a l i t yo fs o f t w a r e c a p a b i l i t ym a t u r i t ym o d e li st h eb e s te x a m p l e o fp l a n - d r i v e nd e v e l o p m e n t t h et w o d i f f e r e n tv i e w sc o n t e s tf o r t h ed o m i n a t i o no ft h es o f t w a r ed e v e l o p m e n t a g i l e s o f t w a r ed e v e l o p m e n tt ot h ep l a n d r i v e nd e v e l o p m e n ti nf e a t u r e s ，a d e p tf i e l d sa n d k e ye l e m e n t sw a sh e r ec o m p a r e d a st h ee m p h a s i so fe x t r e m ep r o g r a m m i n g ，u n i tt e s th a s b e c o m eav e r yi m p o r t a n t p a r to ft h ee n t i r ed e v e l o p m e n tp r o c e s s t e s t - d r i v e nd e v e l o p m e n ti n e x t r e m e p r o g r a m m i n gw a sa n a l y z e d t e s t d r i v e nd e v e l o p m e n ti m p l e m e n t a t i o ns t e p s w e r e d e s c r i b e d t e s t d r i v e nd e v e l o p m e n tw a sa ni t e r a t i v ep r o c e s s n e wc o d e sm u s tb e t e s t e df i r s t l y , a d d e df u n c t i o ni nr e l a t i v e l ys t a b i l i z a t i o n ，e n s u r e ds o f t w a r ed e v e l o p m e n t i nc o n t r 0 1 f i n a l l y , f o r m a ld e s c r i p t i o no ft e s t d r i v e nd e v e l o p m e n t ，a n dt h ee x a m p l e s w e r eg i v e n k e yw o r d s ：a g i l es o f t w a r ed e v e l o p m e n t ，e x t r e m ep r o g r a m m i n g ， p l a n - d r i v e nd e v e l o p m e n t ，t e s t - d r i v e nd e v e l o p m e n t 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取得的 研究成果，除了文中特别加以标注和致谢之处外，论文中不包含其他人已经发表 或撰写过的研究成果，也不包含为获得鑫叠盘堂或其他教育机构的学位或证 书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均己在论文中 作了明确的说明并表示了谢意。 学位敝储虢凌聊签字吼砷年月7 日 学位论文版权使用授权书 本学位论文作者完全了解盘鲞盘堂有关保留、使用学位论文的规定。 特授权苤鲞盘堂可以将学位论文的全部或部分内容编入有关数据库进行检 索，并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校 向国家有关部门或机构送交论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 学位论文作者签名： 签字同期：年月h 导师签名- 瓣选当： 弹h 肌卅年f r 月7 同 第一章绪论 第一章绪论 随着科学技术的高速发展和因特网的普及应用，人们生活和工作的方式发生 了很大变化，而随着我国加入w t o ，竞争环境则越来越严酷，尤其是在i t 行业。 一个i t 企业要想在这种环境下生存并发展，就必须采用新的管理方法和工作模 式。 1 1 敏捷软件开发的背景和意义 许多人都经历过没有实践的指导而导致的噩梦，缺乏有效的实践会导致不可 预测性，重复的错误以及努力的白白浪费，很多系统最终不能交付，或者最终交 付的系统发生延期或超出预算，或者没能满足用户的需要，结果是不得不一遍又 一遍地开发，使客户对开发人员丧失信心，也使得开发人员感到沮丧。 由于看到许多公司的软件团体陷入了不断增长的过程的泥潭，为了应对软件 开发人员所面临的挑战，2 0 0 1 年2 月，在美国犹他州的雪鸟城，1 7 位业界专家 聚在一起，共享和宣传他们对软件开发的共识，概括出了一些可以让软件开发团 队具有快速工作、响应变化能力的价值观和原则，使用“敏捷”来描述他们共同 的想法。这次会议形成了敏捷软件开发运动，创建了敏捷联盟。会议的结果是 1 7 名与会者签署了“敏捷软件开发宣言”。( 敏捷联盟诞生于2 0 0 1 年，但其各种 方法和研究这些方法的人的历史可追溯到1 0 1 5 年前) 敏捷软件开发方法以人为本，以满足用户需求为目标，其特征是：具有随时 响应外界变化的能力。这种变化体现在许多方面：如经济全球化导致的业务和经 济环境更难确定，竞争对手的策略和用户需求的不断变化，技术的高速发展，员 工薪酬的不断提高，等等。采用敏捷方法的公司具有驾驭这种不确定性的能力， 从而立于不败之地，蓬勃发展。 敏捷软件开发是一组相关的方法的统称，其中包括：s e r u m ，水晶方法 ( c r y s t a l ) ，特征驱动软件开发( f e a t u r ed r i v e nd e v e l o p m e n t ，简称f d d ) ，自适 应软件开发( a d a p t i v es o f t w a r ed e v e l o p m e n t ，简称a d p ) ，以及最重要的极限编 程( e x t r e m ep r o g r a m m i n g ，简称x p ) 。 第一章绪论 1 2 极限编程的背景和意义 随着通信技术的不断进步，新的信息可以随时随地进行传递，很多商业项日 在进行期间，需求仍在不断变化，因此必须做出相应改变。变化当然会引起成本 上涨，而在传统软件开发环境里，改变所需的成本往往很高，人们因此而抗拒改 变，最终导致了项目失败。极限编程便是针对快速改变的软件需求而产生的。 2 0 世纪9 0 年代初，克莱斯勒公司的薪资服务部门和信息服务部门决定采用 新的统一系统来取代老系统。1 9 9 6 年，克莱斯勒邀请k e n tb e c k 作为顾问，指导 这个已陷于困境的c 3 项目。为了解决这个问题，在1 9 9 6 年到1 9 9 9 年间，b e c k , c u n n i n g h a m j e f f r i e s 等人构建了现在被称为极限编程的基本元素。 极限编程是敏捷软件开发中最著名的一个，是一种针对业务和软件开发，将 两者力量集中在共同的、可以达到的目标上。它是一种轻量、高效、低风险、柔 性的软件开发方式，由一系列简单却相互依赖的实践组成。它把注意力放在了提 供价值的工作上面：对系统的需求以及实现系统的代码。 极限编程是一个高度迭代的过程，有较多的反馈对环境和需求变化做出调 整，同时极限编程强调以小版本形式来开发系统，由此使用户可以很快使用一个 较小的系统，然后不断增加此系统的功能。它的优点是程序员可以从客户实际的 使用情况里得到反馈。 在进行极限编程的过程中，一切都是以需求开始的，而且采用了用户素材 ( 1 1 8 e rs t o r y ) 的形式。客户提供用户素材并确定用户素材的优先级。开发人员分 析这样的素材并为它们编写测试一切都归结到了代码上。代码由结对的人员 进行开发以提高质量，对代码进行重构以使其更加简单，参照需求对代码不断进 行测试，以代码为中心的活动存在于软件开发生命周期的每个阶段中。 极限编程是一种极为严格的开发方法，其重点在于代码评审，频繁测试，客 户参与，快速反馈，持续重构，精炼框架，持续性整合，以及在开发过程的早期 发现问题，时刻进行设计和再设计，此外还有持续计划。 测试驱动开发是极限编程中必不可少的一部分。测试驱动开发的前提是高质 量的软件通过下面这个迭代的过程来进行设计和实现。首先，对软件期望能够达 到的功能进行测试。开始，这个测试可能不会被通过，接下来，编写使软件能通 过测试的必要的代码，最后，周期性地对代码进行重构。单元测试保证了当代码 出现问题时可以及时发现，从而实现高效的设计。同时，这样做也使得开发人员 能够始终专注于开发真正需要的代码。 2 第一章绪论 1 3 本文的研究工作 本文研究了敏捷软件开发的宣言以及包含的十二项准则。 极限编程是敏捷软件开发中具有代表性的一种，研究了极限编程的四个变 量，四个准则，五个基本原则，四项基本工作，十二个实践。 有基于一些来自传统工程领域的概念，是计划驱动的方法，它们使用一些标 准的、定义良好的、组织持续改进的过程，以一种需求设计构建的模式来进行 开发。比较了敏捷软件开发与计划驱动方法的特征、擅长领域和关键要素等，并 得出结论。 t 町，b 7j 胛口口 x e ：i 厶泪i 、n 订旰- 上t r i l 土j 士 八7 h m i 一n 订矗 丌牡_ - 扎，匕j t 二可取占，l 1 l i 第二章敏捷软件开发 第二章敏捷软件开发 2 1 敏捷软件开发观点 敏捷软件开发宣掣u “我们通过亲身实践和帮助他人实践，找到了更好的软件开发方法。在工作 中我们得出以下观点： 较之于过程和工具，应更注重人及其交互的价值。 较之于面面俱到的各类文挡，应更注重可运行的软件的价值。 较之于合同谈判，应更注重与客户合作的价值。 较之于遵循计划，应更注重响应需求变化的价值。 虽然左侧的观点是有价值的，但我们认为右侧的观点更有价值。” 敏捷软件开发原则【l 】 1 最高优先级是通过尽早和经常交付有价值的软件来令客户满意。 2 不断地交付软件，以每两周或每两个月为周期，推荐使用较短的周期。 3 可运行的软件是工作进展的主要度量标准。 4 以积极的态度对待需求的变化，即使在开发阶段末期也不例外。敏捷过 程利用变化来为客户创造竞争优势。 5 在整个开发过程中，业务人员和开发人员最好能每天一起工作。 6 项目由积极主动的人员来完成，给他们提供所需的环境和支持，信任他 们能把工作做好。 7 在开发团队中，最具有效果和最有效率的信息交流手段是面对面的交谈。 8 最好的系统构架、需求和设计产生于自组织的团队。 9 应时刻关注技术上的精益求精和合理的设计，这样可以提高应变能力。 1 0 敏捷过程提倡可持续开发思想。出资人、开发者、用户应该保持长期、 恒定的开发速度。 1 1 简单化最佳化未完成的工作的艺术是至关重要的。 1 2 团队应该定期对其运作方法进行反思，考虑如何能变得更有效，提出改 进意见，并据此进行相应的调整。 4 第二章敏捷软件开发 2 2 敏捷软件开发观点分析 2 2 1 敏捷软件开发宣言分析 在敏捷宣言的价值陈述中，人及其交互、可运行的软件、与客户合作、响应 需求变化比过程和工具、面面俱到的各类文挡、合同谈判、遵循计划更重要，但 并不是说工具、过程、文档或合同等不重要。 1 较之于过程和工具，应更注重人及其交互的价值【1 】【3 】。 第一个观点：与其使用有文档但交互中充满敌意的过程，还不如使用没有文 档，而有良好交互的过程。 人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使 用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队 成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员 也一样会惨败。 一个优秀的团队成员未必就是一个一流的程序员。一个优秀的团队成员可能 是一个平均水平的程序员，但是却能够很好地和他人合作。合作、沟通以及交互 能力要比单纯的编程能力更为重要。一个由平均水平程序员组成的团队，如果具 有良好的沟通能力，将要比那些虽然拥有一批高水平程序员，但是成员之问却不 能进行交流的团队更有可能获得成功。 合适的工具对于成功来说是非常重要的。像编译器、i d e 、源代码控制系统 等，对于团队的开发者正确地完成他们的工作是至关重要的。然而，工具的作用 可能会被过分地夸大。使用过多的庞大、笨重的工具就像缺少工具一样，都是不 好的。 从使用小工具开始，尝试一个工具，直到发现它无法适用时才去更换它。不 是急着去购买那些先进的、价格昂贵的源代码控制系统，相反先使用一个免费的 系统直到能够证明该系统已经不再适用。在决定为团队购买最好的c a s e 工具许 可证前，先使用白板和方格纸，直到有足够的理由表明需要更多的功能。在决定 使用庞大的、高性能的数据库系统前，先使用档案记录，不要认为更大的、更好 的工具可以自动地帮你做得更好。通常，它们造成的障碍要大于带来的帮助。 团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环 境，然后期望团队自动凝聚在一起的错误。相反，首先致力于构建团队，然后再 让团队基于需要来配置环境。 2 较之于面面俱到的各类文挡，应更注重可运行的软件的价值 1 】 3 1 。 第二个观点：文档非常有用，但对它们采用“刚好足够”、虮恰好充分”的原 第二章敏捷软件丌发 则。 没有文档的软件是一种灾难，代码不是传达系统原理和结构的理想媒介，团 队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。 然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时问， 并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间 失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。 对于团队来说，编写并维护一份系统原理和结构方面的文档将总是一个好主 意，但是那份文档应是短小的并且主题突出的。“短小的”意思是说，最多有一 二十页。“主题突出的”意思是说，应该仅论述系统的高层结构和概括的设计原 理。 如果全部拥有的仅仅是份短的系统原理和结构方面的文档，这样来培训新 的团队成员，使他们能够从事与系统相关的工作：非常密切地和他们在一起工作。 紧挨着他们坐下来帮助他们，传授知识给他们，近距离的培训和交互使他们成为 团队的一部分。 在给新的团队成员传授知识方面，最后的两份文档是代码和团队成员。代码 真实地表达了它所作的事情。虽然从代码中提取系统的原理和结构信息可能是困 难的，但是代码是唯一没有二义性的信息源。在团队成员的头脑中，保存着时常 变化的系统的脉络图。人和人之间的交互是把这份脉络图传授给他人的最快、最 有效的方式。 许多团队因为注重文档而非软件，导致进度拖延。这常常是一个致命的缺陷。 有一个的简单规则可以预防该缺陷的发生，直到迫切需要并且意义重大时，才来 编制文档。 3 较之于合同谈判，应更注重与客户合作的价值【l 】【引。 第三个观点描述了希望软件被构建的人和构建软件的人之间的关系。尽管合 同有时会有用，但无论有没有合同，协作都会巩固开发。 不能像订购日用品一样来订购软件。不能够仅仅写下一份关于想要的软件的 描述，然后就让人们在固定的时问内以固定的价格去开发它。所有用这种方式来 对待软件项目的尝试都将以失败而告终。有时，失败是惨重的。 告诉开发团队想要的东西，然后期望开发团队消失一段时间就能够交付一个 满足需要的系统，对于公司的管理者来说是具有诱惑力的，但是，这种操作模式 将导致低劣的质量和失败。 成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的陈 述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常地提供反馈。 一个指明了需求，进度以及项目成本的合同存在根本上的缺陷。在大多数的 6 第= 章敏捷软件开发 情况下，合同中致命的条款远在项目完成之前就变得没有意义。那些为开发团队 和客户的协同工作方式提供指导的合同才是最好的合同。 在项目开发期间，和客户紧密地在一起工作。每个周末，把软件提交给客户。 到下一周的周一或者周二，客户给一份关于软件的变更列表。把这些变更放在一 起排定优先级，然后把它们安排在随后几周的工作中。客户和开发人员如此紧密 地在一起工作，以至于验收测试根本就不是问题。因为客户周复一周地观察着每 个功能块的演进，所以客户知道何时这个功能块能够满足他们的需要。 这样，项目的需求基本处于个持续变化的状态。大的变更是很平常的。在 这期间，也会出现整个功能块的变更。然而，合同和项目都能经受住这些变更， 并获得成功。成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作， 而不是试图去规定项目范围的细节和固定成本下的进度。 4 较之于遵循计划，应更注重响应需求变化的价值【1 】【3 1 。 最后一个观点是为了应付大量产生的项目变化。制定计划是有用的，每种敏 捷软件开发方法论都包含明确的制定计划活动，也包含处理优先级变化的机制。 响应变化的能力常常决定着个软件项目的成败。当构建计划时，应该确保 计划是灵活的并且易于适应商务和技术方面的变化。 计划不能考虑得过远。首先，商务环境很可能会变化，这会引起需求的变动。 其次，一旦客户看到系统开始运作，很可能会改变需求。最后，即使开发人员熟 悉需求，并且确信他们不会改变，仍然不能很好地估算出开发它们需要的时间。 对于一个缺乏经验的管理者来说，创建一张优美的p e r t 图或者g a n t 图并 把它们贴到墙上是很有诱惑力的。他们也许觉得这张图赋予了他们控制整个项目 的权力，能够跟踪单个人的任务，并在任务完成时将任务从图上去除，可以对实 际完成的日期和计划完成的日期进行比较，并对出现的任何偏差做出反应。 实际上发生的是，这张图的组织结构不再适用，当团队增加了对于系统的认 识，当客户增加了对于需求的认识，图中的某些任务会变得可有可无，另外一些 任务会被发现并增加到图中。简而言之，计划将会改变，而不仅仅是日期上的改 变。 较好的作计划策略是：为下两周作详细的计划，为下三个月作粗略的计划， 再以后就作极为粗糙的计划。应该清楚地知道下两周要完成的任务，粗略地了解 一下以后三个月要实现的需求。基于系统一年后将要做什么，有一个模糊的想法 就行了。 计划中这种逐渐减低的细致度，意味着仅仅对于迫切的任务才花费时间进行 详细的计划。一旦制定了详细的计划，就很难进行改变，因为团队会根据这个计 划启动工作并进行了相应的投入。然而，由于计划仅仅支配了几周的时间，计划 7 第二章敏捷软件开发 的其余部分仍然保持着灵活性。 2 2 2 敏捷软件开发的原则分析 十二个详细原则组成了上述四个观点，是区别于重型过程的特征所在： 1 最高优先级是通过尽早和经常交付有价值的软件来令客户满剖l 】【3 】。 尽早地交付具有部分功能的系统，和系统质量之间具有很强的相关性。初期 交付的系统中所包含的功能越少，最终交付的系统的质量就越高。以逐渐增加功 能的方式经常性地交付系统，和最终质量之问有非常强的相关性。交付得越频繁， 最终产品的质量就越高。 尽早交付可以快速取胜，并能及早获取对需求、团队、过程的反馈；经常交 付可以让团队保持胜利感，快速获得反馈，在项目中期调整方向和优先级。 尽早地、经常地进行交付，在项目刚开始的几周内就交付一个具有基本功能 的系统。然后，坚持每两周就交付一个功能渐增的系统。如果客户认为目前的功 能已经足够了，客户可以选择把这些系统加入到产品中。或者，他们可以简单地 选择再检查一遍已有的功能，并指出他们想要作的改变。 强调交付那些对客户有最大价值的部分。随着客户心情的变化、市场的竞争 的计划、股票市场的摆动，对一年或更长的交付周期的项目保证其收益不变几乎 是不可能的。这个原则指出及早交付是有价值的，因为万一出资人收回资金，他 们将不会仅留下一堆承诺便笺，而是对购买者而言有价值的能工作的软件。 2 不断地交付软件，以每两周或每两个月为周期，推荐使用较短的周期儿引。 如果用户能够接受每个月的变化，开发团队也能完成变化带来的新需求，那 么短一点的反馈周期会更好。 交付可以工作的软件，并且尽早地( 项目刚开始时很少的几周后) 、经常性 地( 1 i t 后每隔很少的几周) 交付它。不赞成交付大量的文档或者计划，那些不是 真正要交付的东西，目标是交付满足客户需要的软件。 3 可运行的软件是工作进展的主要度量标准儿引。 敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。不是根据 所处的开发阶段、已经编写的文档的多少或者已经创建的基础结构代码的数量来 度量开发进度。也就是说，只有当3 0 的必须功能可以工作时，才可以确定进度 完成了3 0 。 可运行的代码比任何允诺型便笺，如计划和文档都更真实可靠。敏捷方法论 鼓励尽早交付可运行的代码，并随时间不断改进它。将大项目的巨大构架拆分为 一个个能够用增量方式构建和测试的小项目，确实需要不少时间，不过可以实现， 并值得去做。 第二章敏捷软件开发 s t e p h e nm e l l o r 曾详细指出在模型驱动开发中，有两部分工作代码必须被论 证。个是可执行模型，应评价它是否符合客户的需要；另一个是生成最终代码 的映射算法，这一点更容易被忽视，许多项目创建了一个很华丽的可执行模型， 但不能及时完成可用的代码生成算法。 4 以积极的态度对待需求的变化，即使在开发阶段末期也不例外。敏捷过程利 用变化来为客户创造竞争优势 1 】【3 1 。 这是一个关于态度的声明，参与者不惧怕变化，改变需求是好的事情，因为 那些改变意味着团队已经学到了很多满足市场需要的知识。 通过及早和经常交付可运行的软件，使用迭代和时间框技术，始终注重框架， 愿意更新设计，敏捷过程能够应付在开发阶段末期改变需求的要求，把末期变化 合并到需求中。 开发人员努力地保持软件结构的灵活性，这样当需求变化时，对于系统造成 的影响是最小的j 5 在整个开发过程中，业务人员和开发人员最好能每天一起工作【1 1 【3 1 。 行业中充斥着这种项目，出资人不花时间去确定自己到底需要什么。 用户和项目的成败有很强的关系，为了能够以敏捷的方式进行项目的开发， 客户、开发人员以及相关人员之问就必须要进行有意义的、频繁的交互。软件项 目不像发射出去就能自动导航的武器，必须要对软件项目进行持续不断地引导。 最好的联系方式是通过专家在场和日常讨论。“日常”是指一种最佳条件， 讨论能够在需要时进行，一经请求就能获得。 6 项目由积极主动的人员来完成，给他们提供所需的环境和支持，信任他们能 把工作做好 1 】f 3 1 。 在敏捷项目中，人被认为是项目取得成功的最重要的因素。所有其他的因素： 过程、环境、管理等等，都被认为是次要的，当它们对于人有负面的影响时，就 要对它们进行改变，如果办公环境对团队的工作造成障碍，就必须对办公环境进 行改变，如果某些过程步骤对团队的工作造成阻碍，就必须对那些过程步骤进行 改变。 积极的、熟练的人们通过良好的交流来工作，他们为工作而自豪，为项目中 的友善和集体氛围所激励。 7 在开发团队中，最具有效果和最有效率的信息交流手段是面对面的交谈【l 】【3 1 。 在敏捷项目中，首要的沟通方式就是交谈，也许会编写文档，但是不会企图 在文档中包含所有的项目信息。 如果文档的需求是迫切并且意义重大的，团队成员可以去编写文档，但是文 档不是默认的沟通方式。默认的沟通方式是交谈。 9 第二章敏捷软件开发 8 最好的系统构架、需求和设计产生于自组织的团酣1 】【3 】。 敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员，而是分配 给整个团队，然后再由团队来确定完成的任务的最好方法。 敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目 中所有方面的参与权利。不存在单一的团队成员对系统构架、需求或者测试负责 的情况。整个团队共同承担那些责任，每一个团队成员都能够影响它们。 坚持随着时间不断调整构架，就像对需求和过程所作的。锁定一个构架太难。 太早锁定，将不能调整它以应付不可避免的意外情况，尤其是在实现过程中和需 求变化时。步步发展的构架能够随着团队知识的变化而改变，并满足用户群体 的变更需要。 9 应时刻关注技术上的精益求精和合理的设计，这样可以提高应变能力【l 】【3 】。 一个简洁、适当精简的设计更容易改变，这意味着项目有更快的应变力。要 保持敏捷，设计者从一开始就要完成好的设计，并需要定期审查和改进设计。随 着时间当有了更深入的理解后应修改设计，去除那些为了实现短期目标进行过度 的设计。 高的产品质量是获取高的开发速度的关键。保持软件尽可能的简洁、健壮是 快速开发软件的途径。 。 开发团队成员致力于只编写他们能够编写的最高质量的代码，不会制造混乱 然后告诉自己等有更多的时间再来清理它们，如果在今天制造了混乱，他们会在 今天把混乱清理干净。 1 0 敏捷过程提倡可持续开发思想。出资人、开发者、用户应该保持长期、恒定 的开发速度 j 1 1 3 。 敏捷项目不是5 0 米短跑，而是马拉松长跑。团队不是以全速启动并试图在 项目开发期间维持那个速度，相反，他们以快速但是可持续的速度进行。 跑得过快会导致团队筋疲力尽、出现短期行为以至于崩溃。开发团队会测量 自己的速度。不允许自己过于疲惫，不会借用明天的精力在今天多完成一点工作， 他们工作在一个可以使整个项目在开发期间保持最高质量功能标准的速度上。 这个原则有两个方面。一方面是社会责任，另一方面是项目效率。不是每个 人都同意社会责任问题，但都同意效率问题。 当长时间工作时人们会疲倦，进度会减慢，不仅在加班的那段时问里，而且 在正常工作时间里的效率也会下降，工作中会出现更多错误，降低了加班所带来 的效益，这是人这一组件的非线性特征。 一个警惕、投入的团队比一个疲倦、辛劳的团队更敏捷，即使抛开所有的社 会责任问题，结论也是如此。长时间工作是一个征兆，说明项目出现了问题。 l o 第二章敏捷软件开发 1 1 简单化最佳化未完成的工作的艺术是至关重要的【1 l 【3 1 。 简单化至关重要。这一点大家很快就达成共识。 开发人员不会去试图构建那些华而不实的系统，更愿意采用和目标一致的最 简单的方法，在今天以最高的质量完成最简单的工作，深信如果在明天发生了问 题，也会很容易进行处理。 在开发过程的设计中，实现简单化必须在工作未完成时进行，生产好的软件 时，应最佳化未完成的工作，把事情变得简单是不容易的，一个笨重的模型很容 易被完成，而生产一个能有效处理变化的简单设计则困难得多。 1 2 团队应该定期对其运作方法进行反思，考虑如何能变得更有效，提出改进意 见，并据此进行相应的调整【1j 【3 】。 开发人员会不断地对团队的组织方式、规则、规范、关系等进行调整，团队 所处的环境在不断地变化，并且为了保持团队的敏捷性，就必须要随环境一起变 化。 不断调整，最终会适合，对任何一个项目来说多轻是正确的? 刚好够用，或 比期望的稍轻一些。 在自己的项目中应如何去做? 花时问去反思所做的事。如果团队每两周抽一 个小时的时间来反思工作习惯，就能够演进方法论。使它更敏捷、有效和适用。 第三章极限编程 3 1 极限编程的观点 第三章极限编程 极限编程的四个变量2 1 1 成本 2 时间 3 ，质量 4 范围 极限编程的四个准则【2 】 ，1 沟通 2 。简单 3 反馈 4 勇气 极限编程的五个基本原n t 2 】 1 快速反馈 2 假设简单性 3 递增更改 4 提倡更改 5 优质工作。 极限编程的四项基本工作【2 】 1 编码 2 测试 3 倾听 4 设计 极限限编程的十二个实践【2 】 1 计划游戏通过结合使用业务优先级和技术评估来快速确定下一个版本 的范围。当计划赶不上实际变化时，就应更新计划。 2 小版本将一个简单系统迅速投产，然后以很短的周期发布新版本。 3 隐喻用有关整个系统如何运行的简单、众所周知的故事来指导所有开 发。 4 简单设计任何时候都应当将系统设计得尽可能简单，不必要的复杂性 1 2 第三章极限编程 一旦被发现就马上去掉。 5 测试程序员不断地编写单元测试，在这些测试能够无误地运行的情况 下，开发才可以继续。客户编写功能测试证明各功能已经完成。 6 重构程序员重新构造系统( 而不更改其行为) 以去除重复、改善沟通、 简化或提高柔性。 7 结对编程所有的生产代码都是由两个程序员在同一台计算机上编写 的。 8 集体所有权任何人在任何时候都可以在系统中的任何位置更改任何代 码。 9 持续集成每天多次集成和生成系统，每次都完成一项任务。 1 0 每周工作4 0 小时一般情况下，一周工作不超过4 0 小时，不要连续两 个星期都加班。 1 1 现场客户在团队中加入一位真正的、起作用的客户，他将全职负责回 答问题。 1 2 编码标准程序员依照强调通过代码沟通的规则来编写所有代码。 3 2 极限编程的观点分析 3 2 1 极限编程的四个变量分析 极限编程的四个变量：成本，时间，质量，范围( 这个从控制变量系统的角 度建立的软件开发模型中，客户、管理人员确定任意三个变量的值，开发团队确 定第四个变量的值) 。其中范围的控制最有价值。 成本钱多一点可以促进工作顺利进行，但是太短时间内投入太多的钱则 会产生更多的无法解决的问题。另一方面，拨给项目的钱太少，将不能解决客户 的业务问题。 在许多方面，成本是受约束最多的变量。不能只靠花钱就得到质量、范围或 者短的发行周期。另外，成本同其他变量密切相关。在有意义的投资范围之内， 可以花更多的钱扩大范围，可以更加周密地行动以提高质量，可以( 在一定程度 上) 缩减投入市场的时间。花钱也可以减少资源冲突更快的计算机、更多的 技术专家和更好的办公室。 时间更长的交付时问能够帮助提高质量和扩大范围。由于来自生产系统 的反馈的质量要比任何其他种类的反馈高得多，因此，给一个项目太多时间有损 第三章极限编程 质量。划给项目的时问太少也会使质量受损，而且会有类似程度的对范围和成本 的损害。 通过控制时间来控制项目所受的约束通常来自外部。年末、季度开始前、旧 系统预定关闭的时间、一场商业展览这些都是外部时间约束的例子，因此， 时间变量经常是在项目管理人员的控制之外，而掌握在客户手中。 质量作为一个控制变量，质量极其重要。如果有意识地牺牲质量，可能 在短期( 几天或几周) 内获利，但是耗费的成本人力、商务和技术是巨大的。 质量是一个奇特的变量，经常出现这样的情况，坚持更好的质量能够更快地 完成项目，或者在给定的时间内完成更多的工作。 在内部和外部质量之间存在一种奇特的关系。外部质量是由客户衡量的质 量，而内部质量是由程序员衡量。暂时牺牲内部质量以缩减投入市场的时间，然 后还希望外部质量不会损害太多，在几周或几个月里，可能不会把事情搞得一团 糟，然而，最终内部质量会受惩罚，使软件维护费用昂贵或者外部质量达不到有 竞争力的水平。 存在一个由质量而来的人为影响。每个人想干好工作，而且，如果感觉自己 做得不错，就会干得更好。如果有意识地降低质量，团队开始时或许进行得更快， 但是很快由制造废品而产生的消沉情绪将压倒性地抵消不测试、不评审或者不坚 持标准而获得的暂时收益。 范围更小的范围可能会有助于提高质量( 只要能够解决客户的业务问 题) 。它也能够更快或更经济地交付产品。 对于软件开发来说，范围是应该注意的最重要的变量。无论是开发人员还是 业务人员，都仅对开发中的软件的价值有一个模糊概念。在项目管理中，最有力 的决定之一是消除范围。如果积极主动地管理范围，就可以向管理人员和客户提 供成本、质量和时间的控制。 范围的一个重要特点就是它是一个变化很大的变量。几十年来，开发人员不 断在抱怨：“客户不能告诉我们他们想要什么。而当我们给出他们所说的需要的 东西时，他们又不喜欢它。”这在软件开发中是一个不争的事实。在开始的时候， 需求从来都是不清楚的。客户从来不能确切地说出需要什么。 软件的开发会改变软件本身的需求。一旦客户见到第一个版本，他们就明白 了在第二个版本中他们需要的东西，或者他们在第一个版本中实际上想要什 么。这是宝贵的知识，因为它不可能根据猜想而得到，它只能从经验中获得，但 是客户无法独自做到这一点，他们需要会编程的人来共事。 范围是四个变量中最容易控制的，由于它具有柔性，可以对它进行塑造，如 果到发行日期的时间变得紧张时，那么总会有一些东西可以延期到下一个版本。 1 4 第三章极限编程 通过不去试图完成太多的功能，可以保持能力，按时实现满足所需质量的产品。 如果在每个发行周期结束时，都丢弃了重要的功能，那么客户很快会变得烦 躁。为了避免这种情况，x p 使用了两个策略： 1 进行大量估算和反馈实际结果的工作，更好的估算能减少不得不放弃功能 的几率。 2 首先实现客户最重要的需求，这样如果不得不放弃别的功能，那么这个功 能也不会比已经在系统中运行的功能更重要。 3 2 2 极限编程的四个准则分析 沟通：x p 的第一个准则是沟通。x p 旨在采用许多只能通过沟通完成的实 践来保持良好的沟通。这是一些在短期内有意义的实践，如单元测试、结对编程 及任务估算。测试、配对及估算的作用就是让程序员、客户和管理人员必须进行 沟通。 沟通对于) 【p 项目能否成功至关重要。沟通是指开发人员之间以及开发团队 和客户之间进行的高效的交流。极限编程要求客户或者客户代表能够和开发团队 一起工作，这样可以鼓励和增进交流，也符合极限编程及时的特性。客户和开发 人员要在发布计划会和迭代计划会上进行正式的交流。 在结对编程( p a i r - p r o g r a m m i n g ) 期问开发人员之问需要沟通。开发人员和 客户之间也需要沟通。当开发人员遇到问题时，应该和客户进行面对面的交流， 从而得到及时的回答。这样能够提高项目的质量和成功率。如果开发人员必须等 待一份文档或者一个回复，他们通常会猜测结果，或者去做其他一些并不重要的 工作。这显然都不是所期望的。尽管可以通过e - m a i l 进行交流，但是面对面交 流的效果要好得多，因为这样可以更容易地传递信息，并且更容易确认对方是否 真正理解了自己表达的意思。 简单：x p 的第二个准则是简单。简单和沟通之间有一种奇妙的互相支持的 关系。沟通得越多，就越清楚哪些工作需要做，并能更加确信哪些工作不需要做。 系统越简单，需要的沟通就越少，这将使沟通更加全面，尤其是在能够将系统简 化到需要更少程序员的时候。 简单通常比复杂更难实现，它需要精益求精的精神。开发团队应该尽量使设 计保持简单。这意味着必须要重视可重用代码以减少冗余的代码。如果在完成了 一段代码后发现了更简单的实现方法，那么就应该重写这段代码。因为软件的大 部分费用花在维护上，所以从长远的眼光来看，这种做法是省时省钱的。同时， 因为极限编程强调持续测试，所以不用担心改变系统的某个部分或某些类会产生 负面影响。 第三章极限编程 实现简单性的另一方面就是保证代码的标准化。如果代码是用通用的格式编 写的，那么任何人都可以轻易地读出一段代码，并理解代码的意义。还要保证变 量名、方法和类的标准化，大小写、括号和缩进格式的使用也要保持一致。这样 有助于降低复杂程度，减少建立与维护软件的相关成本。 反馈：x p 的第三个原则是反馈。对系统当前状态的具体反馈是极为宝贵的。 乐观是编程这一行业的大忌，而反馈则是良药。反馈可以以不同的时问规模来进 行。 首先，在分钟和天的级别里进行反馈。开发人员为系统中所有可能出错的逻 辑编写单元测试。他们每分钟都得到有关系统状态的具体反馈。当客户编写新的 “故事”( 功能说明) 时，开发人员马上对它们进行估算，这样客户就会得到关 于他们的故事质量的具体反馈。负责跟踪进度的人观察任务的完成情况，向整个 团队发出有关他们能否在一段时间内完成已经开始的所有任务的反馈。 进行测试还有另外一个原因。开发人员在编写一段代码时，这段代码的印象 最深。所以测试代码的最佳时机是在代码刚刚编写的时候，因为这个时候开发人 员还能清晰地记得所作的一切。如果测试安排在开发完成后一两个星