1.2 在程序设计学习中主动实践敏捷康发思想

敏捷软件开发(Agile Development)是一种应对迅速变化的需求实现快速开发软件的思想。为获取程序开发的敏捷性，它提出了一些必须遵守的纪律、使软件保持灵活和可维护的设计原则、设计模式。敏捷的核心是实践，在这些原则下进行实践，可以丰富你的经验、改进你的工作。

1.2.1 敏捷软件开发的四个核心观点

敏捷软件开发宣言中明确提出了其软件开发的四个核心观点：

①个体和交互胜过过程和工具；

②可以工作的软件胜过面面俱到的文档；

③与客户合作胜过合同谈判；

④响应变化胜过遵循计划。

敏捷软件开发需要更新、反馈和共享开发团队和客户之间所产生的知识。敏捷开发者利用顾客、用户、开发者的力量，找到能在质量和敏捷中取得平衡的刚好够用的过程。

1.2.2 敏捷软件开发的原则

以下是敏捷软件开发的原则，也是区别于传统的重型开发过程的特征：

软件开发者最优先要做的是尽早地和持续地交付有价值的软件来使客户满意。

即使到了开发的后期，也欢迎需求发生变化，用拥抱变化为客户创造竞争优势。

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

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

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

在团队内部，面对面交谈是最主要和最有效果和有效率的传递信息方法。

可以工作的软件是首要的进度度量标准。

提倡可持续的开发速度。责任人、开发者和用户应该能保持一个长期的、恒定的开发速度。

不断地关注优秀的技能和好的设计可以增强敏捷能力。

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

每隔一定时间，开发团队应该围绕如何才能更有效地工作这个问题进行反省，然后对自己的行为进行相应地调整。

1.2.3 敏捷软件开发的主要特征

1.以人为本，重视交流和沟通

敏捷软件开发正视软件开发中需求多变的事实，以人为本来响应变化，强调人与人的交流和沟通不完全依赖文档，团队合作和交流程序代码是最有效的传播信息和相互学习的方式，合作、沟通以及交互能力要比单纯的编程能力更重要。在开发过程中为保证质量，提倡结对编程，必要时进行重构来保证软件代码的质量。

以人为本。在软件开发过程中，人是最重要的组成因素，这里的人是指那些与项目存在利害关系的人，包括客户和开发人员。除此之外，工具也是一个很重要的因素，这里所说的工具包括用来沟通的建模语言和其他一些工具。建模语言是形式化的图形语言，UML是当前最流行的一种建模语言。非形式化的沟通在项目中的作用也是举足轻重的。开发人员与客户的各种形式的交互，是项目能够成功的保证，只有通过真诚的沟通，才可能真正按软件开发规律来完成项目。一般情况下，项目的需求处于一个持续变化的状态，只规定需求、进度及成本的合同存在根本上的缺陷，只有能为开发团队和客户协同工作方式提供指导的合同才是最好的合同。开发人员之间的沟通同样很重要，好的沟通能在团队中提高知识传播的速度，增强团队的能力。在敏捷软件开发中，人们之间相互交谈是默认的沟通方式，这种方式不需要规范的书面计划和设计(除非对于文档的需求是迫切并且意义重大的)。强调结对工作，以加快专业知识在团队中的传播，在紧要关头，不会因为个人而影响整个项目。研究表明，结对编程不仅可以提高开发团队的效率，而且能大大减少差错率。

2.积极应对软件开发过程中的可变化性

开发过程自身是不断变化的。一个项目目前用的一个过程和一年后用的过程肯定不同，在开发过程中，根据当前项目的特殊性，对标准过程不断剪辑、创新，在每一次迭代中改进过程，每次迭代时都问几个问题：我们什么地方做得好，我们学到了什么，怎样才能做得更好，还有什么疑问。每个过程在开始时都带着疑问，然后解决疑问，改进过程，以配合整个项目的进行。

3.是一种方法论而不是具体的过程指导

人们的软件开发活动从最初无规则的“边写边改”(code and fix)，到按工程化方法进行开发是一个巨大的进步。随着软件工程的发展，工程化方法对开发过程给出了严格而详尽的规定。一段时间中，各软件组织纷纷采纳CMM方法，积极对软件过程进行改进，加入到软件组织能力成熟度测评大潮中。究其原因，可能是CMM对软件组织的各种活动都给出了很细的规定，好像谁拿来后都能逐步达到要求，但事实并非如此。而敏捷软件开发作为轻量型的方法，则反其道而行，它并不对具体过程进行什么规定，而是从方法论上进行指导，对过程允许自主调整，以人为中心，调整过程适应组织和需求变化，注重过程的改进而不依赖过程。只要看清软件开发的本质，看清软件工程的特色，就会明白敏捷软件开发方法才是真正指导软件工程的方法论。

4.形式上轻量简洁

敏捷软件开发方法从实用角度出发，它以矫正官僚繁琐过程、许可对过程进行自主调节为特征。传统的重型软件开发方法对文档的要求与作用程度的评估都强调得有点过分。文档的作用是交流和传播，而交流是多层次、多类型的，对文档一律要求标准化，在有些情况下确实不合适，甚至会带来副作用。敏捷软件开发认为，任何比通过文档交流更好的交流形式都值得提倡。通过结对编程就可以不需要文档很好地实现交流和知识传播。敏捷软件开发方法在形式上表现为要求尽可能少用文档，更多地用程序源代码进行体现。

1.2.4 敏捷软件开发的主要过程

敏捷软件开发的主要过程是：计划、简单的设计、测试、重构。

在项目开始时，敏捷软件开发要求开发人员和客户应尽量确定真正重要的用户素材，但不要求确定所有的用户素材。因为随着项目的进展，用户会不断给出新的素材。开发人员要根据素材进行分析，不断地发布计划和迭代计划。

采用敏捷软件开发方法的XP团队使他们的设计尽可能简单和具有表现力。他们仅仅关注计划在本次迭代中要完成的素材，不考虑未来的用户素材，在一次次的迭代中，不断改变系统设计，使之对正在实现的用户素材而言始终保持最优状态。

编制测试程序不仅仅用来对系统进行验证，它本身也是一种设计行为。优先编写测试程序，会迫使开发者把程序设计成可测试和易测试的，在关注程序的同时，也关注它的接口，降低软件中的耦合。测试程序还可以看作一种文档，并且这份文档是一种可编译、可运行的文档，通过具体测试，使文档总是保持最新的版本。

重构是在不改变代码外在行为的前提下对代码进行修改，从而改进代码内部结构的过程。软件需求是不断变化的，几乎所有的模块在它们的生命周期中都会发生变化，这要求模块能修改和易修改。而那些已经发生过变化的地方，以后还可能变化，因此要为以后的修改留出接口。重构的目的是为了每天清理代码，不让脏乱的代码积累，以便能对系统进行修改和扩展。

1.2.5 敏捷软件开发典型方法

1.XP(Extreme Programming—极限编程)方法

在所有的敏捷方法中，XP方法最引人注目，XP方法根源于Smalltalk圈子，特别是Kent Beck和Ward Cunningham在二十世纪八十年代末的密切合作，在九十年初，他们在一系列项目上的实践，深化扩展了他们关于软件开发应是适应性的和以人为中心的思想。XP方法的四条基本价值原则是：交流、反馈、简洁和勇气。在此基础上建立了十多条XP项目应遵循的实践准则。在软件开发中，强调测试优先，在此基础上建立渐进迭代的开发过程，依赖每次迭代时对代码的重构，保证代码质量，所有的设计都围绕当前的迭代进行，而不管将来的需求，这种设计过程的结果是“纪律性”与“适应性”的高度统一，它使得XP在适应性方法中成为发展最好的一种方法。

XP方法提倡结对编程，它开创了一种团队合作的良好模式。乍一听，结对编程好像缺乏效率，事实上，结对编程在经济和其他方面提供了以下优越性：所有设计决策都至少涉及两个人，代码至少总能被一个人审查，而实践中几乎不可能出现两个人同时疏忽的测试或其他错误；改变结对的组合可以在团队范围内传播知识。这些特点都有利于交流、沟通，不会把错误留到最后，事实表明，结对编程比单独编程效率更高。

极限编程是一组简单、具体的实践，这些实践结合在一起形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法。其他项目团队可以直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。

2.Cockburn的水晶系列方法

水晶系列方法与XP方法一样，都树立以人为中心的理念，但实践上有所不同。Alistair Cockburn从人们一般很难严格遵循一个纪律约束很强的过程的观点出发，探索用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。水晶系列强调每次迭代后的回顾，鼓励过程本身的自我完善。它还强调开发人员要随时观察他们所用的过程，并随着项目的发展而进行调整。之所以称之为一个系列，是因为它相信不同类型的项目需要不同的方法。

3.Highsmith的适应性软件开发方法(ASD—Adaptive Software Development)

ASD的核心是猜测、合作与学习这三个非线性的、重叠的开发阶段。在一个适应性环境中，因为结果是不可预见的，Highsmith把计划看成一个“反论”(paradox)。在传统习惯中，偏离计划是错误，应予以纠正；在ASD中，则认为偏离计划是引导开发者向正确目标迈进。ASD强调学习是连续不断的，它特别强调如何在一个项目中增强合作和学习。

1.2.6 两种方法学的比较

1.两种方法学

“软件=程序＋文档”一直是公认的关于软件的定义，其中，程序是计算机工作的基本依据，而文档则是为了方便人之间的交流。根据对文档态度的不同形成了两种方法学，即传统的重型方法和现代的敏捷开发方法。

在传统工程方法中，文档是完成每个阶段的里程碑，需求分析阶段必须形成软件需求规格说明，设计阶段以此为依据进行设计，每个阶段都有相应的文档。这些文档是软件开发人员交流、沟通的重要媒介，也是软件组织过程能力改进的重要载体。但实际上软件需求是不断变化的，在相应的软件变更后，各类文档都要变化以实现同步。这是软件开发人员最头痛的事情。软件开发人员用在文档维护上的时间大大超过用来编制程序的时间，这种做法极大地影响了开发人员的士气，进而影响软件质量和开发进度。

敏捷软件开发改变了对文档的重视程度，它更加提倡“代码主义”：可以工作的软件胜过面面俱到的文档。团队更需要编制易于阅读的文档，来对系统及设计决策的依据进行描述。在交流方面，敏捷软件开发强调代码和团队。代码真实地、无二义地表达了所做的事情，在团队成员的头脑中，保存着时常变化的脉络图(road map)。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。团队对文档应持的态度是：直到迫切需要并且意义重大时，才来编制文档。

2.应对变化与拥抱变化

传统工程方法认为需求发生变化是需求分析不彻底的结果，强调在需求分析阶段深入进行需求开发，对问题加深认识，从抽象上下功夫。这种做法存在的问题是分析的程度难以把握。对此有两种做法：一是要求在开发软件之前对整个系统的需求有完整准确的了解，让客户确认需求，严格按照需求设计程序，并签订合同，不允许变更需求。这种情况适用于需求稳定的小项目。对于大多数项目，应该允许变更需求，这就是第二种作法，在需求变更控制下变更需求。

敏捷软件开发正视软件开发过程中需求会不断发生变化的事实，以人为本来响应变化，强调人与人的交流和沟通不完全依赖文档，团队合作和代码是最有效的传播信息和学习的方式，合作、沟涌以及交互能力要比单纯的编程能力更重要。在开发过程中保证质量，提倡结对编程，必要时通过重构来保证软件代码的质量。

1.2.7 敏捷软件开发思想的实践

方法、过程和工具是软件工程的三要素。敏捷软件开发方法是软件工程发展的新方向，我们应该吸取这种开发方法的精髓，在人才培养中也要以人为本拥抱变化。

学生动手能力差是我国高校毕业生普遍存在的问题，这主要因为学生的实践环节没有抓到实处，出了问题，因此实践环节从内容和形式上都有待改进和加强。当前计算机专业学生的实践环节(即上机环节)中的内容一般都是重复性地验证例题，遇不到真正的困难。对上机课认识不到位，认为上机课是主课程的辅助，是导致学生动手能力差的重要原因，这当然与课程的体系设置有关系。从形式上讲，当前的上机方式也不利于学生的动手能力的提高。单人单机虽然改善了学生的上机条件，但不利于学生之间进行交流和沟通。我们把结对编程(也叫做结对上机)引入学生上机课，也就是让两个学生共用一台计算机，共同编码、调试。俗话说当局迷，旁观者清，调试过程序的人对此都会有切身体会。两个人共用一台计算机编码，一般不会发生相同的错误，容易及时发现对方的错误，对问题的理解又会各有所长，更利于问题的解决，同步的交流沟通不会出现理解的偏差，共同调试更容易发现错误，使一个人的经历变成两个人的财富，实现知识的共享和传播。实际上，在上机过程中，同学们经常会三三两两地聚在一起调试程序，这就是一种结对方式，我们应因势利导，鼓励学生们相互合作，相互借鉴，取长补短，由自发的互助到有组织的团队合作，是我们培养学生团队合作的最好方式。

课程设计与毕业设计是教学的重要环节，我们利用课程设计与毕业设计，有目的地加强学生综合素质的培养。对给定的课题，按照软件工程思想，从分析到设计始终强调交流与沟通的重要作用。从获取需求开始，学习用专业语言和伙伴进行交流与沟通，用领域语言和用户进行交流与沟通，在分析与设计的迭代过程中理解沟通的重要作用，掌握交流的方法与技巧。针对实际需求的不断变化，沟通在整个团队中能起到控制步调一致的作用。而当前教学中的常用模式却是单打独斗，缺少交流，这样不利于合作，更不利于竞争和创新。在一些关键的技术问题上，单人钻研不但费时费力，而且很容易导致士气低落。结伴而行，不仅会累加力量，更可以通过相互启发促进智慧的交汇和迸发！

大学生的课余时间比较充足，利用这一点，我们通过组织兴趣小组、计算机爱好者协会等多种形式，培养学生的团队合作精神。兴趣相同、共同探讨、共同开发、共同进步，这是发展自己特长的最好方式。另外，从学校到社会也应向学生提供更好的发展环境。当前，由于学生的就业压力大，许多学生只能循规蹈矩地进行学习，走考研、考博之路，这种情况下，只考虑升学之间有竞争，哪里还能想到合作，更不用说团队。前几年还时常有学生办公司，现在已经很少，当然办公司未必是行之有效的锻炼合作创新能力的方法，我们需要考虑处一些好的方法、形式去培养学生的创新能力，培养学生的团队合作能力，比如校企联合，让兴趣小组与公司结合。一种好的创新模式可以更好地培养学生的创新能力，要让学生走向社会，真正在社会中学会交流、沟通，养成与人合作的团队精神，从多角度、多方位提高学生的综合素质。

“程序=数据结构+算法”，数据结构的学习和实践在程序设计中的地位非常重要，本书从敏捷软件开发思想的角度出发，对数据结构进行研究，在讨论综合案例的过程中体现敏捷软件开发思想，从设计到实现，强调响应变化，通过代码传播思想。

只有亲身实践才能体会方法论的作用，只有遵循实践的规律才能丰富敏捷软件开发方法论。