2010年11月29日
16:31
有團隊就需要過程管理，以便協調資源，高效合作。我們公司的“青蛙王子”，“三頂法”都是這樣的代表。儘管透着樸實，但是曾經比較起作用的。
現成的主流方法論如何呢？現成的方法論有兩個大類，一個大類是以RUP，CMMI爲代表的重型方法；一類是集中於敏捷旗幟下的若干方法，如XP（極限編程），Scrum等。首先，我需要做一個聲明，就是我並不打算評價這些方面的優劣——我不是方法學家，不會對他們都有完整全面的瞭解，也談不上什麼公正的評價——而是表達從我們小型團隊的角度，看到了什麼，嘗試了什麼，爲和做出選擇或者不選擇的判斷。我希望能夠比較客觀的提出看法，而不太多的夾雜個人的喜好，儘管這一點幾乎不可避免——我提出的是“人”的看法。
RUP還好，我們有過第一手經驗。在幾個項目中都號稱用RUP來進行軟件開發過程的管理，然後幾個項目完成，我們對RUP的看法幾經變遷，留下的主要是“迭代開發”，“使用UML設計”這樣的實踐。大家決定後，在一個項目週期內就忘記了RUP的存在，而是每天面對屏幕，奮力敲入代碼，回到自己擅長的部分。當然有時候用Rational ClearCase的時候，偶爾想起“恩，我們好像在‘RUP’呢”，然後繼續code。實際上，RUP對我們的程序員的日常工作影響不多，我也不知道RUP引入後，我們因此和以往有什麼進步。也許並非RUP不好，而是對我們不適合：那麼多的文檔，那麼多的工件和工具，需要很多的時間去理解、消化、裁剪，然後爲我所用。
對CMMI的瞭解則是來自於一些二手的經驗。我曾經看過一家公司的CMMI的第四級實施，並和幾位實施者討論過。他們的開發部門共有50人左右，其中有8人在做這個實施，已經做了幾個月，並且還要做幾個月；他們都在編寫文檔，並且專門的一個會議室內堆了很多的文檔。可是，當我問及CMMI對他們有什麼好處的時候，他說：“過了級，更加容易拿到項目”。就是說，他們並沒有更多的改進方法，也缺乏一定的改進上的針對性。文檔和書也看了不少，講座也聽了N回，可是，我們該做什麼呢？面對這樣的一個基本問題，我承認我無話可說。
前些日子，我們做了scrum公開課。除了公司內的，還有其他公司的幾個經理也被邀請過來。講完後，我和其中一個經理談了談。他們公司剛好是用CMMI的！他們做了5年，並且這些年一直在伴隨着諮詢，文檔衆多，他說，“對於維護型的項目，我們共50多人做一個項目，CMMI顯得嚴謹而有效，尤其是其中的需求變更流程；不過現在也常常會需要做些小型的項目，本來就幾個月的時間，幾個人做，大家都反應這樣走流程，做很多工件太麻煩，幾個項目經理都在和我鬧，希望減少流程。”。他希望也考察下Scrum看看是否可以讓公司接受新的方法論。我的結論是，敏捷對於小型團隊是非常有用的，而大型些的項目，需要嚴謹的項目，CMMI也許更好。
XP 讓我們有了新的看法。XP很明顯是程序員創建的，因此面向代碼方面更多一些。XP裏談及的12項實踐，比如TDD,結對編程等都看來簡單，實施起來很難。以TDD爲例，在我們一個8000多個函數的項目中，通過TDD產生的函數不足100。這個項目中很多人都是老江湖了，他們依然要慨嘆，TDD很難真正的實施。
對小型團隊而言，CMMI，RUP太冗餘，XP太難，至於其他的，我係統瞭解過，結論是不值一提。因此Scrum上位也就是理所當然的了。