活用 XP： (一)發揮過程和人的力量

活用 XP： (一)發揮過程和人的力量

來自： IBM DeveloperWorks中國網站 作者：林星 [2003/10/08]

XP作為敏捷方法的一種，擁有很多優秀的實踐，用好這些實踐，在軟件組織中能夠起到很好的效果。問題在于，要用好這些實踐并不簡單，本系列文章的目標就是圍繞著 XP 的實踐，討論隱藏在實踐內部的敏捷性實質，研究如何靈活的應用 XP 的實踐，從而達到改進軟件過程的目的。
軟件開發雖然有多個環節，但是我們不能只強調某些環節，任何一個環節出問題最終都會影響產品的質量。因此我們在軟件開發中應該考慮整個過程，并且重視人這個因素。
質檢員的工作
在以前的工廠作業流程中，產品在生產出來之后，都需要經過質檢員的檢查。在質檢員身邊，有兩個筐，一個筐上寫著合格，一個筐上寫著不合格。對于合格的產品，貼上合格證，進入銷售的環節，對于不合格的產品，禁止出廠。很久以來，我們一直采用在產品的最終階段進行質量檢驗的方式，這種方式用來避免有質量缺陷的產品出廠，但是既沒有辦法提高產品的質量，也沒有辦法降低差錯率。這種質檢方法的基本思想是，產品出現廢品是正常的，只要能夠找出廢品，產品的質量就不受影響。
那我們看看軟件開發的工藝流程。當軟件經歷了需求、分析、設計、編碼之后，質檢員同樣需要檢驗軟件是否滿足質量要求。各種各樣的測試人員共同擔任了質檢員的角色。而質檢員的工序也不簡單。黑盒測試、白盒測試、集成測試、用戶測試、并行測試。和工廠不同的是，出現問題的軟件并不能夠簡單的扔到不合格的產品堆中。另一個不同，軟件產品一定會出現質量的問題。既然不能簡單的拋棄產品，那么只好把產品退回到生產線上。于是，需求人員、分析人員、設計人員、編碼人員開始對軟件進行調整，力圖使軟件能夠出廠。這個反復的過程往往要持續上一段時間。幸運的軟件可以順利出廠（交付），否則，可能會遭到項目失敗的命運。
很明顯，我們發現這種做法不夠聰明。把問題堆積起來，直到最后才來集中解決，這種做法的代價是非常高昂的。軟件開發的特性，決定了越是后期的變更，成本越高。那么，我們應該如何調整我們的做法，來降低成本，提高質量呢？
精益原則
軟件開發總是從其它學科中借鑒管理思路。最早的軟件工程從土木工程中借鑒經驗，但是后來人們發現建筑和軟件開發有很大的差異性。故而新的軟件開發方式開始興起，其中就包括了XP方法論。同樣的，新的軟件開發方式仍然在理論上尋找立足點，這一次眾人的焦點落在了現代管理理念上。土木工程管理的一個很大的問題就在于忽視了人的作用，而現代的管理理念將人的作用提到了一個新的高度，這和新興的軟件開發思想是相同的。而對軟件開發思路影響最大的，應該算是豐田公司提出的精益生產（Lean Production）的概念。

回顧這段歷史，和軟件開發的歷史何其相似。大規模制造理論認為，一定程度的浪費，一定程度的廢品是正常的，允許的。而在軟件開發中，浪費、成本居高不下也同樣成為阻止軟件開發邁向工程化的一大障礙。像XP這樣的敏捷方法從精益制造的思路中吸取了很多的優秀思想，例如，不斷改進質量，設計決策應該交給最貼近生產的人員，根據客戶的需求來推動生產。雖然我們一直在強調軟件開發和制造行業截然不同，但是，處于變革的十字路口的軟件開發行業，總是不斷的從其它的行業中尋找可借鑒的理論。這種借鑒來的思路就被稱為精益編程（Lean Programming）。精益編程的思路包括： 消除浪費。 任何不能夠為最終的產品增加用戶認可的價值的東西都是浪費。無用的需求是浪費，無用的設計是浪費，超出了功能范圍，不能夠被馬上利用的代碼也是浪費，工件在不同的開發組之間無意義的流轉，也是浪費。
強化學習，鼓勵改進。軟件開發是一個不斷發現問題，不斷解決問題的過程。而學習能力的強化，能夠令軟件開發工作不斷的獲得改進。
延遲決策。軟件開發如果工作在一個不確定的環境中，變化性會對軟件開發本身造成傷害。延遲決策，當環境變得逐漸清晰之后，才有充足的理由來進行決策。而對軟件設計而言，如何構建一個可支持變化的系統則成為關鍵的問題。
盡快交付。自從互聯網流行之后，速度成為了商業中的至關重要的因素，從而直接影響了快速軟件開發的成熟。軟件階段性交付的周期越快，軟件的風險就越容易識別，用戶的需求就越清洗，軟件的質量就越高。
誰做決策。誰做決策？是高高在上的高級經理，還是貼近代碼的編碼人員。決策取決于準確的信息，但是掌握這些信息的權威者往往就是做實際工作的編碼人員，將編碼人員的建議、決定和實踐納入到決策的范疇來，是成功決策的關鍵。
精益編程代表了一種思想，很多的Agile方法都從各自的理論基礎出發，支持了這種思想。而在我們的討論中，討論的重點就是放在XP上。XP方法論中最有價值的是他的思想。我們研究、學習XP，不能夠光了解他的實踐活動，還需要時刻注意XP的價值觀，并仔細的思考，在實踐活動的背后，到底隱藏著什么樣的思想。就好像我們在閱讀設計模式一書的時候，書中給出的是各種各樣的關于面向對象的設計方法，但是書中仍然有一條主線貫穿其中，那就是面向對象的編程原則。
過程
前一段時間，書店中很暢銷的書大多數都和6σ相關。6σ是全面質量管理理論的發展。其中一個很重要，和軟件開發非常類似的思路是，過程的每一個步驟，都會對產品最后的質量產生影響，要提高質量，降低成本，提升客戶的滿意度，最關鍵的是要對過程進行研究和分析，發現對產品影響較大的步驟，并制定改進的措施。

做任何一件事情，都需要經歷一個過程。從外賣店接到客戶的訂貨電話開始，一個過程就已經啟動了。記錄客戶的地址、地址特征、菜名，給廚房下單，分配外送人員，將地址信息傳遞給外送人員，送貨，尋找目的地，交付外賣并收款，后續過程忽略。一個似乎平常的生活活動，其背后都包含了復雜的過程。對軟件開發而言也是一樣的。從客戶提出軟件的構想，一直到客戶真正開始使用軟件，其間的過程非常的復雜，充滿了各種各樣的不可預測的因素。 送外賣的過程，每一步都會對最終的質量（客戶滿意度）產生影響。對客戶來說，從打電話到收到外賣的時間，外賣的好吃程度，這些都是屬于滿意度的組成成分。接到電話后，可能客戶的口音較重，記錄員聽錯了地址，導致后續過程全部白費，除非客戶等的不耐煩，打電話來重新記錄一次地址。下單給廚房之后，可能廚房的電風扇會將單子吹到了地上，客戶的要求就被忽略了。記錄員把客戶的地址描述信息寫的很潦草，送貨人員可能看不懂，這時候他需要打電話回來問，這就擔擱了送貨時間。送貨人員可能對客戶所在不熟悉，找到地址花費了很多的時間。好不容易送到了客戶手上，客戶已經等的不耐煩了，更糟的是，由于時間太長，外賣已經涼了�？蛻魶Q定，下一次更換一家外賣店。雖然每一個環節出錯的概率都不是很大，但是各個環節組合起來之后，出錯的概率就大的驚人。在分析了這樣一個流程之后，我們的感慨往往是，居然能夠送到，真是不容易！軟件開發的過程難道不是這樣嗎？每一個環節都有可能出問題，需求未必就代表了客戶的需要，設計不能夠很好的代表需求，反而對編碼增加了一些不穩定的因素，由于進度較緊，編碼的工作也比較馬虎。這樣的過程，我們能夠開發出客戶滿意的軟件，那么只有一個解釋，以前客戶接觸的軟件開發人員，比我們還要爛。
好吧，我們如何改善這一情況呢？對了，對過程進行改進。既然記錄員可能會和客戶之間出現錯配的情況，那我們就要求記錄員在聽完客戶的要求之后，重復一遍。既然，菜單可能會遺失，我們就在廚房中專門設計一個位置，按先進先出的順序排列這些菜單，而且保證菜單不會被遺失。既然送貨員可能會看不懂記錄員的字，那么就讓送貨員和記錄員花費一些時間溝通，要么送貨員能夠習慣記錄員的字，要么記錄員寫出送貨員能夠理解的字。既然送貨員可能未必認識路，那么就對送貨員劃片，有專門送A區的，有專門送B區的，每個人熟悉的范圍減小了，熟悉的程度自然就上升了。好吧，有了這樣的思想，我們也準備對軟件過程進行改進了。不過，并不是現在，本文的剩余部分將會圍繞著這一點來進行。
過程中的人
除了過程的重要性，我們還需要考慮人的因素，過程是要依靠人去推動的，沒有人，過程就沒有任何意義。對軟件開發更是如此，開發過程的每一個環節都需要人的參與。從來沒有一個方法論象XP這樣充分的強調人的作用。因此，在XP的全過程中，人的因素是始終處于首位的。而XP的實踐也是根據人的優點和弱點進行精心的設計。我們這里做一些簡單的討論：
計劃游戲：我們常常掛在嘴邊的一句話是計劃趕不上變化。計劃，往往都是很多軟件組織的一塊心病。所有人都知道計劃的重要性，可是計劃又是最難做的。沒有計劃，軟件過程無從遵循；有了計劃，軟件過程又常常偏離計劃。在變化越來越頻繁的現在，計劃更是難上加難。對待捉摸不定的計劃，XP的態度是：與其在一開始就費時耗力地制定一堆不切實際的計劃，倒不如花費少量的精力做一個簡單的計劃，然后在隨后的軟件過程中不斷的進行調整。

車子，應該這樣騎�？纯催h處的目標，估算距離和時間，得出一個粗糙的速度，然后我們就上路了。在前進的過程中，我們不斷的目測目標，察看時間，并調整速度和方向。目標越來越接近，我們的調整越來越熟練，最后，我們成功的抵達的目標點。 傳統的計劃方法和第一種騎車方法一樣不切實際，花費大量的時間思考幾個月后發生的事情是很難的。只有根據變化不斷的調整，才是正確的態度。
注意，不把時間花費在計劃上，并不等于不重視計劃。計劃仍然是軟件開發的核心。你必須有一個當前的迭代計劃，當前的周計劃，甚至當前的計劃。只有保證每一個小計劃的嚴謹性，才能夠保證整個項目計劃的成功。
XP對計劃的態度是：你不需要把計劃做的多么精密，但是你必須去做計劃。計劃趕不上變化，這句話說的一點都沒錯，我們不需要逃避變化，花大力氣進行精確的計劃既浪費，又沒有意義。但是這并不是說不做計劃。凡事預則立，我們需要簡單明了的計劃，然后在軟件開發的過程中，不斷的修正并完善計劃。
學習變化：XP最適合那些需求容易發生變化的過程，在現實中，我們發現這種情況實在是太多了�？赡苘浖�的目標市場發生了變化，要求軟件同步變化；可能客戶對需求沒有充分的了解，導致需求的變化；可能客戶的組織或業務流程發生了改變，要求軟件變化。種種的可能性表示，在一個一成不變的環境下開發軟件已經稱為一種奢望。在這樣一個殘酷的環境中，我們不得不去學習變化。
變化包括兩個方面：軟件過程如何適應變化，以及軟件設計如何適應變化。傳統的軟件過程往往要求上游的軟件階段確定之后，才能夠進行下一個軟件階段。但是變化的需要要求軟件過程在多個軟件階段之間切換。
由于變化的殘酷性，XP建議開發人員必須建立變化的意識。你必須去改變你的心態，接受變化，變化是合理的，一成不變的東西壓根就不存在。
這里插一句題外話。強烈建議在XP的項目中使用面向對象技術。雖然面向對象并沒有對軟件過程或是軟件管理提出任何的要求。但是，一個使用面向對象的團隊（注意，是使用面向對象技術，而不是使用面向對象語言，這么說是因為有著大量的開發人員使用面向對象的編程語言編碼面向過程式的代碼），其管理過程也會隨之變化。用戶參與、迭代開發、重用、使用框架。這些都是在使用了面向對象技術之后自然而然出現的變化。使用面向對象技術，能夠和XP方法進行更加緊密的銜接。
除了上面討論的兩個簡單的思路，本文的其它部分都會針對XP中過程和人兩方面的因素進行討論。
本文的定位
本文不是一篇介紹XP基本知識的文章，這方面的資料已經很多了，要想全面的了解XP，人民郵電的一套XP系列叢書是非常好的一個開始。而本書的定位是討論在實際的軟件開發中，如何靈活的應用XP，如何遵循XP的思想，但又根據實際情況進行折衷。雖然本文沒有介紹任何的XP基礎知識，但是仍然適合XP的初學者閱讀，剛接觸XP的人往往都有各種各樣的困惑，而從國外翻譯過來的注解卻未必適合國內的環境，因此閱讀本文能夠從實踐的角度更深的理解XP的思想。
和其它的方法論一樣，XP不是萬能的。一個軟件組織能否從XP中獲益，不是取決于XP，而是取決于這個軟件組織自身。正如我們在一開始就強調的，學習XP，關鍵在于學習思想。軟件組織應該根據自身的情況，活學、活用XP，而不是人云亦云。XP可不是制作一堆卡片。切記，切記。
文章沒有全面的介紹XP的所有實踐。因為作者并不是XP的絕對擁護者，我們以一種客觀的態度審視XP，我們介紹的內容，是在采用了XP的實踐或是吸收了XP實踐中的思想之后的經驗；我們沒有介紹的部分，是因為環境原因無法實踐或是不對其表示贊同（但并不是不贊同）。
其實本文介紹的很多知識并不是XP的專利，其它的敏捷方法也都提到了這些優點，例如自適應軟件方法。所以，更準確的描述是本文如何從XP中學習先進的軟件開發理念。
作者簡介
林星，辰訊軟件工作室項目管理組資深項目經理，有多年項目實施經驗。辰訊軟件工作室致力于先進軟件思想、軟件技術的應用，主要的研究方向在于軟件過程思想、Linux集群技術、OO技術和軟件工廠模式。您可以通過電子郵件 iamlinx@21cn.com 和他聯系