十年總結（12）：軟體開發思想之爭 － RUP VS XP

對我過去感興趣的朋友們，請看十年總結系列文章

－－－
正式回到原來公司就職後，開發這邊的管理團隊形成了一個三足鼎立的局面，
田田，十幾年工作經驗，不怎麼懂具體技術，負責純管理，以及協調開發與市場，
樂樂，8－10年工作經驗，03下半年，他牽頭做了一個2.0版本的架構，java c/s架構，年底要移民澳洲，
我和樂樂各帶了幾個開發人員一起主持開發工作。

雖然多頭領導並不是一件好事兒，但對我來講並不是一件壞事兒，
因為來北京這幾年，開發方面都是以我為主，很多時候我也不知道自己的決定是不是對，
我相信大家都有這種感受，自己做出的決策，雖然內心相信是正確的，但還是希望通過其它途徑得到證實，
這就是常說的“他山之石，可以攻玉”，“外來的和尚會念經”。
我現在覺得，需要別人來證明自己的時候，正是自己還不成熟的時候，不過從青澀變得成熟，不都要經曆這個階段嘛！

04年，我的課程學分拿的差不多了，因為專業是軟體工程，所以課程包括：流程改善、軟體度量、演算法設計、物件導向設計等等，
我當時的感覺就像一個熟讀了武功秘籍的人，迫切的希望通過修鍊來印證功法所說的種種妙用，
田田和樂樂都比我有經驗，我自然樂得好好學習。

我有幾年的軟體開發經驗，也切身體會到不少的問題，我也經常思考如何更合理的組織開發，
我的目標有些理想化，在我看來：
1、管理應該實現“無為而治”，也就是說管理者的精力應該不在管，而在於看，看結果，看未來
2、軟體開發過程應該是可視、可控的。
3、軟體開發的結果是可預期的。

我所學的各種管理課程都信誓旦旦的保證，規範的流程可以滿足我的要求（除了第一條），
所以當樂樂提出Team Dev要採用RUP的時候，我積極響應，表示大力支援。
於是，我們剪裁文檔、安裝Rational Rose、招聘測試人員和組態管理人員，制定版本管理規範等等。
我也在這一時期，閱讀了《人月神話》、《IT專案管理》、《UML》等很多相關書籍。

然而，問題很快就出現了。

在小公司，我們雖然是產品研發團隊，但我們無法做到和項目的完全隔離，我們發布出去的版本還不能穩定的像Window，office一樣out of the box，
在流程的作用下，實施人員開始抱怨對問題的響應太慢（因為大家都習慣了有問題直接找開發，而現在我們要評審、修改文檔然後改代碼發布），
使用者的“緊急”需求被我們安排到下一版本，但市場通過老闆來改變我們的版本發布計劃，插入更加急迫的需求。

由於規範的實施，導致開發與實施＋市場產生了一定的對立（我不清楚這是我們公司的特例還是普遍情況），
因為中國公司的客戶總是很急，市場壓力很大，於是每隔一段時間，當矛盾激化的時候，田田就召集我們和負責市場和實施的人開會，
討論的結果往往是如下幾種：
1、這個問題，需進一步“最佳化流程”，還是寄希望流程解決問題。
2、我們開發力量不夠，需要繼續加人（但公司的實力是有限的啊）
3、實施方面保證目前面臨的是一個特殊情況，開發方面暫時妥協，儘快解決問題（一個項目總有足夠多的“特殊”理由）
4、要麼沒有結論，保持問題依舊（實際上是實施方面妥協）

在一次次的摩擦中，雖然樂樂一直堅定不移的倡導他的“RUP”，並將很多問題歸結為“流程不夠最佳化”和“人員不足”時，
我卻在疑惑和反思。
在一家小公司，什麼樣的開發過程才是合理的？
產品化之路在小公司行的通嗎？
RUP實施的越徹底，所帶來的管理消耗越大，到底有多少小公司可以承受？

正當我為此鬱悶不已的時候，聽到了“XP”一詞。
那是04年第一學期結束的時候，回學校給導師彙報畢業論文的計劃，
她提到最近參加一次國際會議，會上有人講解國外方興未艾的軟體開發思路：極限編程（eXtreme Programming，簡稱XP）。
老師描繪的由XP帶來的快速交付能力和代碼品質的巨大提升，讓我覺得心動不已，但又將信將疑。

回家後，我立刻上網搜尋相關資訊，閱讀XP的最佳實務，
從XP又找到了敏捷建模、敏捷思想，並熟知了一些大師們的名字。
這些先進的思想，當時給我的感覺就是“天上掉下個林妹妹，似一朵輕雲剛出岫”，讓人眼前一亮，
我隱約覺得我所追尋的東西，就蘊含在這些大師們的思想之中。

經過初步分析，我覺得XP對Team Dev來講過於激進，而“敏捷”這個宗旨是比較有現實價值的，
於是毫不猶豫的買下了大師們寫的幾本書，包括：
《敏捷建模》，《測試驅動開發》等。

以最快的速度看完這些書後（要知道，解決問題式的學習和無目標的純學習那是太不一樣了），
我在一次團隊會議上提出嘗試讓Team Dev變得“敏捷一點”的想法。
在我介紹了XP以及敏捷的核心思路後，樂樂表示不相信這樣做會有效，而田田則不置可否，認為需要證實，
於是，我建議講相關資料分發給大家去學習，然後再開會討論此事。

大家經過學習後（我其實很懷疑有些開發人員是不是真的在意過這些事情），只有軍軍這個小夥子表現出跟我一樣的興趣，
在後來安排的會議上，我就像諸葛亮舌戰群儒一樣，跟大家辯論敏捷和RUP哪個更適合我們。
經過辛苦的辯論（這可比我論文答辯辛苦多了），我們終於達成一致，在Team Dev試行“敏捷”的開發方式。

真正實施起來，敏捷建模或者XP編程遠沒有想象的那麼簡單，以我的經驗來看，敏捷的成敗取決於如下幾點：
1、成員對這種思想的認知和認同
2、對參與者的水平普遍要求較高
3、要防止XP演變成自由主義

我們團隊中試行的“敏捷”雖然沒有達到老外們“宣稱”的效果，但在改善代碼品質，提升團隊的響應速度方面，有比較明顯的作用，
因此，在以後的日子裡，RUP也慢慢不再被人提及。

以後幾年裡，我經曆了幾家有CMM資質的公司，但發現一個現象，那就是“資質是公司的，而不是團隊的”，
也就是說，雖然公司過了認證，但團隊在做開發的時候，風格更多的取決於團隊的領導。
我在實際的軟體專案管理過程中逐漸形成了如下信念：
1、無法執行的規定還不如沒有規定。
2、代碼品質應該在一切可能的情況下成為開發人員的第一目標。

而我從關注方法過渡到關注結果（代碼品質），是04年下半年的事情。

－－－

我並不否認RUP的偉大意義，但以我目前的經驗來看，不是每家公司都適合，至少以項目為本的公司，不適合。
然而敏捷或者XP也有較高的實施門檻，所以，實施起來也並不容易。
但對於個人來講，提升自己提交物（無論是代碼還是文檔）的品質，是經營個人品牌的重要舉措。

以前也討論過讀不讀研的問題。學校的課程不是沒有價值，但如果不考慮學曆文憑，我們不上學一樣可以學到，
但有一點，學校是一個思想交匯的地方，藉助你的導師和同學，能夠發現一些有價值的知識或者機會，這一點自己不容易成就。
就像我接觸到XP一樣。

在工作中，不要讓流程或者制度成為推卸責任的借口。

我覺得剛開始接觸XP的時候，其思想比現在要極端的多（也許是我當年的感覺比較極端），而今天我看到RUP for XP之類的字眼，實在感覺有些哭笑不得，

以RUP為代表的“工程化”軟體開發管理思想，很重要的一個思路就是拿軟體開發和建築開發做比較，希望能夠像蓋房子一樣來做軟體。
但蓋房子和做軟體最大的差異在於，軟體品質的度量比建築品質的度量要複雜太多。
傳統軟體工程思想是希望穩定需求，通過關注過程而保證結果，
而以XP為代表的敏捷陣營，關注的是參與開發的人，以及提交物的品質，強調溝通、協作，主張擁抱變化。
我個人覺得，這兩者真的蠻難融合的。

很多人說我寫的慢，每篇寫的太少。
呵呵，沒辦法啊，我有我的家庭，我有我的工作，
寫點東西，都是在業餘時間中抽時間，我的每一篇文章，通常都要花2－3個晚上，大家沒法發現我經常淩晨發貼子嗎？
我要回憶，我要有取捨，我還要注意行文的流暢，最重要的，我還要從中思考與總結。
我也不可能把所有的精力都來寫這一個系列，我還得隨時捕捉思想中的靈感，因為我目前的人生課題是“思考”。

這不是在寫小說，各位擔待啊。