從瀑布模型、極限程式設計到靈活開發---軟體開發管理者思維的變化

軟體開發是一種對人類智慧的管理，對人大腦思維的“工廠化”管理。人是有感情的、有情緒的、變化的、相對獨立的工作單元，這與冰冷的機器是不可比的，是以在中國的曆史上，管理人是最難的工作；“學而優則仕”的觀點就是讓最聰明的人應該選出來做官，做官就是管理人的。軟體開發不僅是代碼程式設計，而是人員的有效組織，如何既發揮人的主觀能動性，避免情緒變化對工作的影響，又可以讓大家有效的交流，讓多個大腦的思路統一，快速完成目标呢？多年來軟體企業的管理者一直在不斷地探索。

另外有一個問題一直是軟體開發管理人員的心病：軟體是工具，開發的是客戶業務的應用，但客戶不了解軟體，開發者不了解業務，如何有效溝通是軟體品質的重大障礙。把開發者變成客戶業務的專家是個沒有辦法的辦法，讓軟體企業付出的代價也是昂貴的。

瀑布模型、極限程式設計、靈活開發是有代表性的開發模式，在對開發者、客戶、最終的産品的關注上的變化，展現了軟體開發管理者在管理模式上的變化。

一、瀑布開發

瀑布模型(Waterfall Model)是Royce在1970年提出的，他把大型軟體開發分為：分析與程式設計，象工廠流水線一樣把軟體開發過程分成各種工序，并且每個工序可以根據軟體産品的規模、參與人員的多少進一步細分成更細的工序。該模型非常符合軟體工程學的分層設計思路，是以成為軟體開發企業使用最多的開發模型。

瀑布模型的特點：

1、 強調文檔，前一個階段的輸出就是下一個階段的輸入，文檔是個階段銜接的唯一資訊。是以很多開發人員好象是在開發文檔，而不是開發軟體，因為要到開發的後期，才可以看到軟體的“模樣”。

2、 沒有疊代與回報。瀑布模型對回報沒有涉及，是以對變化的客戶需求非常不容易适應，瀑布就意味着沒有回頭路。

3、管理人員喜歡瀑布模型的原因是把文檔了解為開發的速度，可以友善地界定不同階段的裡程碑。

瀑布模型的使用者很多，也有一些反對的意見：

第一、瀑布模型不适合客戶需求不斷變化的軟體開發，尤其是客戶的業務管理的軟體，業務随着市場變化，而軟體初期的設計可能已經大大變化，而後期的需求更改成本是開始的10倍基數。在ERP盛行的軟體市場裡，一方面市場帶動需求變化，另一方面初期客戶對需求描述不清楚，都為瀑布模型的使用團隊帶來困難。

第二、瀑布模型是一種軟體文檔的開發，把開發者變成流水線上的機器，大量重複性的工作讓程式設計人員提不起興趣，工作很枯燥，沒有激情，程式設計成了一種沒有創意的機械勞動，這讓一向以高科技為标志的進階程式人員大為惱火。

在這種背景下，極限程式設計(extreme Programming, XP)帶來了新鮮的空氣。

二、極限程式設計

極限程式設計誕生于一種加強開發者與使用者的溝通需求，讓客戶全面參與軟體的開發設計，保證變化的需求及時得到修正。要讓客戶能友善地與開發人員溝通，一定要用客戶了解的語言，先測試再編碼就是先給客戶軟體的外部輪廓，客戶使用的功能展現，讓客戶感覺到未來軟體的樣子，先測試再編碼與瀑布模型顯然是背道而馳的。同時，極限程式設計注重使用者回報與讓客戶加入開發是一緻的，讓客戶參與就是随時回報軟體是否符合客戶的要求。有了回報，開發子過程變短，疊代也就很自然出現了，快速疊代，小版本釋出都讓開發過程變成更多的自回報過程，有些象更加細化的快速模型法。當然極限程式設計還加入了很多激勵開發人員的“措施”，如結隊程式設計、40小時工作等。

極限程式設計是一種開發管理模式，它強調的重點是：

1、角色定位：極限程式設計把客戶非常明确地加入到開發的團隊中，并參與日常開發與溝通會議。客戶是軟體的最終使用者，使用是否合意一定以客戶的意見為準。不僅讓客戶參與設計讨論，而且讓客戶負責編寫擁護故事(User Story)，也就是功能需求，包括軟體要實作的功能以及完成功能的業務操作過程。使用者在軟體開發過程中的責任被提到與開發者同樣的重要程度。

2、靈活開發：靈活開發追求合作與響應變化。疊代就是縮短版本的釋出周期，縮短到周、日，完成一個小的功能子產品，可以快速測試、并及時展現給客戶，以便及時回報。小版本加快了客戶溝通回報的頻率，功能簡單，在設計、文擋環節大大簡化。極限程式設計中文擋不再重要的原因就是因為每個版本功能簡單，不需要複雜的設計過程。極限程式設計追求設計簡單，實作客戶要求即可，無需為擴充考慮太多，因為客戶的新需求随時可以添加。

3、追求價值：極限程式設計把軟體開發變成自我與管理的挑戰，追求溝通、簡單、回報、勇氣，展現開發團隊的人員價值，激發參與者的情緒，最大限度地調動開發者的積極性，情緒高漲，認真投入，開發的軟體品質就大大提高。結對程式設計就是激發隊員才智的一種方式。

    極限程式設計把軟體開發過程重新定義為聆聽、測試、編碼、設計的疊代循環過程，确立了測試->編碼->重構(設計)的軟體開發管理思路。

極限程式設計的12個實踐是極限程式設計者總結的實踐經典，是展現極限程式設計管理的原則，對極限程式設計具有指導性的意義，但并非一定要完全遵守12個實踐，主要看它給軟體過程管理帶來的價值。

1、小版本。為了高度疊代，與客戶展現開發的進展，小版本釋出是一個可交流的好辦法，客戶可以針對性提出回報。但小版本把子產品縮得很小，會影響軟體的整體思路連貫，是以小版本也需要總體合理的規劃。

2、規劃遊戲。就是客戶需求，以客戶故事的形式，由客戶負責編寫。極限程式設計不講求統一的客戶需求收集，也不是由開發人員整理，而是采取讓客戶編寫，開發人員進行分析，設定優先級别，并進行技術實作。當然遊戲規則可進行多次，每次疊代完畢後再行修改。客戶故事是開發人員與客戶溝通的焦點，也是版本設計的依據，是以其管理一定是有效的、溝通順暢的。

3、現場客戶。極限程式設計要求客戶參與開發工作，客戶需求就是客戶負責編寫的，是以要求客戶在開發現場一起工作，并為每次疊代提供回報。

4、隐喻。隐喻是讓項目參與人員都必須對一些抽象的概念了解一緻，也就是我們常說的行業術語，因為業務本身的術語開發人員不熟悉，軟體開發的術語客戶不了解，是以開始要先明确雙方使用的隐喻，避免歧異。

5、簡單設計。極限程式設計展現跟蹤客戶的需求變化，既然需求是變化的，是以對于目前的需求就不必過多地考慮擴充性的開發，講求簡單設計，實作目前需求即可。簡單設計的本身也為短期疊代提供了友善，若開發者考慮“通用”因素較多，增加了軟體的複雜度，開發的疊代周期就會加長。簡單設計包括四方面含義：1、通過測試。2、避免重複代碼。3、明确表達每步編碼的目的，代碼可讀性強。4、盡可能少的對象類和方法。由于采用簡單設計，是以極限程式設計沒有複雜的設計文檔要求。

6、重構。重構是極限程式設計先測試後編碼的必然需求，為了整體軟體可以先進行測試，對于一些軟體要開發的子產品先簡單模拟，讓編譯通過，到達測試的目的。然後再對子產品具體“優化”，是以重構包括子產品代碼的優化與具體代碼的開發。重構是使用了“實體學”的一個概念，是在不影響物體外部特性的前提下，重新優化其内部的機構。這裡的外部特性就是保證測試的通過。

7、測試驅動開發。極限程式設計是以測試開始的，為了可以展示客戶需求的實作，測試程式優先設計，測試是從客戶實用的角度出發，客戶實際使用的軟體界面着想，測試是客戶需求的直接表現，是客戶對軟體過程的了解。測試驅動開發，也就是客戶的需求驅動軟體的開發。

8、持續內建。內建的了解就是送出軟體的展現，由于采用測試驅動開發、小版本的方式，是以不斷內建(整體測試)是與客戶溝通的依據，也是讓客戶提出回報意見的參照。持續內建也是完成階段開發任務的标志。

9、結對程式設計。這是極限程式設計最有争議的實踐。就是兩個程式員合用一台計算機程式設計，一個編碼，一個檢查，增加專人審計是為了提供軟體編碼的品質。兩個人的角色經常變換，保持開發者的工作熱情。這種程式設計方式對培養新人或開發難度較大的軟體都有非常好的效果。

10、代碼共有。在極限程式設計裡沒有嚴格文檔管理，代碼為開發團隊共有，這樣有利于開發人員的流動管理，因為所有的人都熟悉所有的編碼。

11、編碼标準。編碼是開發團隊裡每個人的工作，又沒有詳細的文檔，代碼的可讀性是很重要的，是以規定統一的标準和習慣是必要的，有些象編碼人員的隐喻。

12、每周40小時工作。極限程式設計認為程式設計是愉快的工作，不輕易加班，今天的工作今天做，小版本的設計也為了機關時間可以完成的工作安排。

三、靈活開發

極限程式設計的思想展現了适應客戶需求的快速變化，激發開發者的熱情，也是目前靈活開發思維的重要支援者。

2001年，17名程式設計大師分别代表極限程式設計、Scrum(“棒球”團隊開發模式)、特征驅動開發、動态系統開發方法、自适應軟體開發、水晶方法、實用程式設計等開發流派，發表“靈活軟體開發”宣言。靈活軟體開發是一個開發軟體的管理新模式，用來替代以檔案驅動開發的瀑布開發模式。靈活方式也稱輕量級開發方法。靈活軟體開發宣言内容：

個體和互動勝過過程和工具

可以工作的軟體勝過面面具到的文檔

可戶合作勝過合同談判

響應變化勝過遵循計劃

靈活開發內建了新型開發模式的共同特點，它重點強調：

1. 以人為本，注重程式設計中人的自我特長發揮。

2. 強調軟體開發的産品是軟體，而不是文檔。文檔是為軟體開發服務的，而不是開發的主體。

3.客戶與開發者的關系是協作，不是合約。開發者不是客戶業務的“專家”，要适應客戶的需求，是要客戶合作來闡述實際的需求細節，而不是為了開發軟體，把開發人員變成客戶業務的專家，這是傳統開發模式或行業軟體開發企業的最大面臨問題。

4.設計周密是為了最終軟體的品質，但不表明設計比實作更重要，要适應客戶需求的不斷變化，設計也要不斷跟進，是以設計不能是“閉門造車”、“自我良好”，能不斷根據環境的變化，修改自己的設計，指導開發的方向是靈活開發的目标。

靈活開發避免了傳統瀑布方式的弊端，主要是吸收了各種新型開發模式的“動态”特性，關注點從文檔到開發者，管理方式也從工廠的流水線到團隊的自我放松式的組織。總結靈活開發與瀑布模式的不同，主要是下面幾個“靈活”的關注點：

疊代。軟體的功能是客戶的需求，界面的操作是客戶的“感覺”，對疊代的強調是縮短了軟體版本的周期

客戶參與。以人為本，客戶是軟體的使用者，是業務了解的專家，沒有客戶的參與，開發者很難了解客戶的真實需求

小版本。快速功能的展現，看似簡單，但對于複雜的客戶需求，合理地分割與總體上的統一，要很好地二者兼顧是不容易的。

靈活就是“快”，快才可以适應目前社會的快節奏；要快就要發揮個人的個性思維多一些，個性思維的增多，雖然通過結隊程式設計、代碼共有、團隊替補等方式減少個人對軟體的影響力，但也會造成軟體開發繼承性的下降，是以靈活開發是一個新的思路，但不是軟體開發的終極選擇。對于長時間、人數衆多的大型軟體應用的開發，文檔的管理與銜接作用還是不可替代的。如何把靈活的開發思路與傳統的“流水線工廠式”管理有機地結合，是軟體開發組織者面臨的新課題。