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 敏捷軟件開發思想的實踐

方法、過程和工具是軟件工程的三要素。敏捷軟件開發方法是軟件工程發展的新方向，我們應該吸取這種開發方法的精髓，在人才培養中也要以人為本擁抱變化。

學生動手能力差是我國高校畢業生普遍存在的問題，這主要因為學生的實踐環節沒有抓到實處，出了問題，因此實踐環節從內容和形式上都有待改進和加強。當前計算機專業學生的實踐環節(即上機環節)中的內容一般都是重復性地驗證例題，遇不到真正的困難。對上機課認識不到位，認為上機課是主課程的輔助，是導致學生動手能力差的重要原因，這當然與課程的體系設置有關系。從形式上講，當前的上機方式也不利于學生的動手能力的提高。單人單機雖然改善了學生的上機條件，但不利于學生之間進行交流和溝通。我們把結對編程(也叫做結對上機)引入學生上機課，也就是讓兩個學生共用一臺計算機，共同編碼、調試。俗話說當局迷，旁觀者清，調試過程序的人對此都會有切身體會。兩個人共用一臺計算機編碼，一般不會發生相同的錯誤，容易及時發現對方的錯誤，對問題的理解又會各有所長，更利于問題的解決，同步的交流溝通不會出現理解的偏差，共同調試更容易發現錯誤，使一個人的經歷變成兩個人的財富，實現知識的共享和傳播。實際上，在上機過程中，同學們經常會三三兩兩地聚在一起調試程序，這就是一種結對方式，我們應因勢利導，鼓勵學生們相互合作，相互借鑒，取長補短，由自發的互助到有組織的團隊合作，是我們培養學生團隊合作的最好方式。

課程設計與畢業設計是教學的重要環節，我們利用課程設計與畢業設計，有目的地加強學生綜合素質的培養。對給定的課題，按照軟件工程思想，從分析到設計始終強調交流與溝通的重要作用。從獲取需求開始，學習用專業語言和伙伴進行交流與溝通，用領域語言和用戶進行交流與溝通，在分析與設計的迭代過程中理解溝通的重要作用，掌握交流的方法與技巧。針對實際需求的不斷變化，溝通在整個團隊中能起到控制步調一致的作用。而當前教學中的常用模式卻是單打獨斗，缺少交流，這樣不利于合作，更不利于競爭和創新。在一些關鍵的技術問題上，單人鉆研不但費時費力，而且很容易導致士氣低落。結伴而行，不僅會累加力量，更可以通過相互啟發促進智慧的交匯和迸發！

大學生的課余時間比較充足，利用這一點，我們通過組織興趣小組、計算機愛好者協會等多種形式，培養學生的團隊合作精神。興趣相同、共同探討、共同開發、共同進步，這是發展自己特長的最好方式。另外，從學校到社會也應向學生提供更好的發展環境。當前，由于學生的就業壓力大，許多學生只能循規蹈矩地進行學習，走考研、考博之路，這種情況下，只考慮升學之間有競爭，哪里還能想到合作，更不用說團隊。前幾年還時常有學生辦公司，現在已經很少，當然辦公司未必是行之有效的鍛煉合作創新能力的方法，我們需要考慮處一些好的方法、形式去培養學生的創新能力，培養學生的團隊合作能力，比如校企聯合，讓興趣小組與公司結合。一種好的創新模式可以更好地培養學生的創新能力，要讓學生走向社會，真正在社會中學會交流、溝通，養成與人合作的團隊精神，從多角度、多方位提高學生的綜合素質。

“程序=數據結構+算法”，數據結構的學習和實踐在程序設計中的地位非常重要，本書從敏捷軟件開發思想的角度出發，對數據結構進行研究，在討論綜合案例的過程中體現敏捷軟件開發思想，從設計到實現，強調響應變化，通過代碼傳播思想。

只有親身實踐才能體會方法論的作用，只有遵循實踐的規律才能豐富敏捷軟件開發方法論。