CMMI與Scrum實踐之思考-大專案規劃的實踐探討

先簡介一下背景情況，我在一個外資通訊企業A 工作了7年，後來到另一個外企E呆了三年，算算共呆了十年，最近到了一個民營企業B。

A在2006年推廣過了CMM3,E在公司2008年推廣了Scrum ,B最近準備過CMMI3，新近又參加了CMMI的培訓，頗多感悟拿出來與同學們討論討論。

不像很多人的誤解，CMMI其實和Scrum並不矛盾，應當說瀑布模型與Scrum矛盾，或者說瀑布模型是由一系列的Scrum專案迭代而組成，更加適合大專案。


為什麼這麼說呢，傳統的瀑布模型定義一個需求，然後進行分解，評審，開發測試，現場驗收。

表面上看很合理，但是它忽視了一個問題，人不大可能對未知的東西能做出正確的判斷，哪怕你的需求再完美，如果沒有一系列的設計程式碼測試環節的跟上，還是會陷入失敗的泥沼。


The only not changed thing is changing.大專案本身在規劃兩年，三年的交付時，就已經面臨著很高概率的失敗風險了。市場環境在變，使用者需求在變，開發環境在變，部署環境在變， 開發人員和開發工具在變。按照統計學正向分佈的理論，實際上一個大和模糊的任務，發生大的概率是非常高的，專案的總偏差=每個子任務偏差平方的累加。

一個新專案本身不確定的因子太多，所以全新專案的失敗率幾乎高達40%，如何避免或減小公司的損失呢，辦法只有一個，抓住關鍵點，定義清晰的目標，儘可能早的交付和客戶討論演示，取得反饋不斷修改和提高。（正是Scrum的精華之處）

先舉一個CMMI之前的開發案例吧。

當年從事一個現場升級專案，開發只花了兩個月，（每天從8點15到晚上9點半，週六上班），然後一個月就通過驗收測試，並且上了線，但是後來BUG直到一年後才完全穩定下來。還發現容量不夠，高峰時總是Down機，最後只能修改合同，賠了使用者款項了事。

原因：1、需求過於簡單，當時拿著一份老系統的測試規範就開始程式設計，測試規範只有20條。結果後來發現有好多細緻的使用者需求沒有被記錄在文件裡，如使用者的號碼如果沒有區號時系統要給號碼自動加上0+區號的字首。後來使用時被投訴才發現，又不得不修改。

2、沒有安排真實環境整合測試，當時測一下就交付了，後來發現和本公司的交換機正常工作，和其他廠商的交換機無法工作。檢查後發現是我們對異常引數的處理能力不夠，規範上是某個號碼是4-12位，我們少支援了一位，並且不支援#值。

我們的交換機不發#，他們的發#，結果我們的系統down機了。

3、 沒有效能測試的目標，當時含含糊糊的說要達到老系統的效能，並沒有開發實際的效能測試工具，沒有定義系統的工作方式，也不知道老系統的真實負載和實際處理 能力。後來發現系統一到週一和週五早上就Down機（其系統負荷是平時的2-3倍），搞得使用者每到這時候就特別緊張。

（PS,這個問題一直沒有解決，最後是3年後上了新系統才完全解決了這個問題。）


-- 現在看，CMMI的對功能和非功能的需求開發和驗證能比較好的解決這種需求不清的問題。

後來到另一個公司，很讓我吃驚的是，這個公司的產品質量並不象名聲那麼好。領導層決定引入Scrum流程提高交付的質量和縮短交付週期及降低開發成本。

憑心而論，Standup Meeting,Demo to Customer,結對程式設計，固定釋出週期，自動編譯和自動測試等都是非常好的實踐。

但是其忽略了一些問題，

1、其對Product Owner過於強調，實際發現產品的需求一開始很難被正確的定義優先順序，所以會導前面的白費，但管理層顯然不喜歡這個後果，對ProductOwner很不滿意導致其受到責備。

2、 開發和測試都敏捷了，可是專案和需求並沒有敏捷。專案經理在Scrum裡是個可有可無的角色。那團隊裡有了矛盾怎麼辦，進度延誤了誰負責？ 誰對支付錢買產品的人做出承諾？ 這些問題Scrum並沒有回答，需求的改變本來是Scrum最歡迎的，專案經理卻對其大加斥責，（因為其導致了專案的額外付出和延誤），實際最後專案幾乎 所有的人都不滿意。

究其原因專案經理做的事情在很多公司裡還是需要的，而Scrum雖然想以TeamLeader,ScrumMaster,Product Owner來分解專案經理的任務，但是並沒有給出比較好的解決問題的辦法。

誰給予Product Owner與客戶洽談的職責，誰給予TeamLeader以考評組員的能力，客戶和外部的高層領導都不希望看到自己的意見有很多個不同的解決方案，而Team內部成員卻爭論不休的現象。

這些問題都是需要每個實行Scrum的公司考慮的。


3、 對團隊的要求過高，希望成員能夠幹好每一件事。我認為這是一個非常錯誤和不可能達到的偽假設。包括Product Owner,沒有人能夠做好每件事，IT的技術千變萬化，市場的環境不斷改變。一個人總有不知道的領域。一個人和一個團隊很少能夠做兩個重複的專案，而現 實情況時當你說不時就有人說你能力不夠。

而Scrum這個假定並沒有規定如何度量一個人的成就，最後導致從事困難的專案人員就被考評得比較差，並且團隊士氣低落，對上隱瞞自己的困難，專案經理不斷增加Buffer，團隊和管理層互不信任.

一個人做好一件事都很難，如何讓他在短期內一會做好這件，一會做好那件呢？　

這 一點上我認為CMMI及我後來呆這個公司比較有些解決方法，首先每個專案讓專案經理制定培訓計劃，然後採用Delphi法（很多個專家一起拍腦袋定技術難 點和專案的Effort)，每週對困難狀態跟蹤和不斷的發現和解決新的困難。一句話，去擁抱困難，積極的解決，消除它而不是抱怨它，躲避它。


實際上E公司有一點是非常不好的，其不鼓勵事前專案成員和不同部門的互相討論，喜歡搞某個專家的獨立決策，並且喜歡事後對各種決策做事後的所謂RouteCause分析和總結。弄得不好就演化為批判會，而不是專案前期的多方準備和風險決策的尋找和解決，接受過程。


我認為對於一些技術的關鍵點應當事前廣泛聽取群眾的抱怨和意見，少部分人蔘與討論和選擇，獨立的作出判斷和決策才是一個好的決策者的工作方式，不過這種方式在E公司是不受肯定的。

４、到底是不是需要強調文件。

CMMI中非常重視文件和過程的定義，而Scrum裡面強調程式碼為王，鼓勵少寫和不寫文件。

我個人的感覺是各有利弊，過分強調文件會增加公司的生產和維護成本。使用者需求，產品需求，概要設計，詳細設計，測試方案，測試用例加其他很多文件，可能要比真正的交付產品的Effort多得多，在有的客戶小專案中可能真的沒有必要。

而Scrum又走向另一個極端，多模組和複雜的專案光看程式碼是很難讓人知道它的設計思想和難以維護的，所以對於平臺級的構件和關鍵的一些專案還是需要概要設計等任務的安排的，而標準也是需要每個決策者考慮的。


５、如何判斷專案和需求的關鍵點

這個我感悟是最深的，CMMI和Scrum對這個都作了定義，就是Priority最高的需求或CMM　裡面的關鍵路徑的任務（到專案後就變為某項任務或活動了）。

回顧我做過的專案，成功的佔了５／４，大部分都是二次開發和規模較小的專案或者大專案被分解成小的專案。不成功的幾乎都是錯誤的定義或判斷了關鍵點，總結下來有幾點原因：

１）、專案的外部介面文件或資料沒有得到就開始開發任務。

有 一個專案，功能需求和非功能需求（效能，可用性等），專案交付，整合測試計劃及人員安排都定義得相當完美。但是忽略了一點，當時說某個關鍵介面源程式拿來 直接測就可以了，後來發現其實源程式只實現了其介面的一部分，而這個介面是對方不同意公佈給外部廠商的，為了做完這個專案，派了人員到現場去開發，但最後 還是沒有得到領導的認可。

２）、記憶體洩漏的問題。

我們原來公司都是C++或JAVA語言開發的，幾乎所有的專案最後都是記憶體洩漏而延誤了進度。而不是功能需求的未完成耽誤進度。這個問題是任何流程無法直接解決的。

實際上，每個程式設計師都應當培養程式碼評審的習慣，還應當從開發模組級別釋出一些記憶體跟蹤工具，模擬在實際使用者應用的記憶體變化情況。另外公司建立一個Bug知識庫也是一種好的方法。

３）、交流不充分或沒有建立良好的溝通渠道。

我 經歷過的一個專案其實非常複雜，裡面有三個不同領域的專家，彼此對自己的領域都很精通，但都不瞭解對方的知識，定義規範和任務時，靠郵件和電話會議溝通了 很久也沒有找到解決方案，我向領導提出當面開會，卻沒有得到明確的答覆。在沒有相應的外部資源支援（要投入交流和培訓的成本）和對外部的推動力不夠得情況 下基於自己的假設完成了開發，做出來後一整合測試發現很多需求理解得並不充分，都站在自己的層面去實現，沒有考慮整個方案的目標和制定相應的介面。後來由 各方高層出面，在新專案中安排了培訓和開會討論等任務，基本解決了前個專案中的遺留問題。
CMMI中提出了一種方法，是專案經理根據需求把任務本身進行分解。先找到關鍵任務和其風險的解決方案。
CMMI中列出了一份專案失敗的原因列表，我覺得非常好，它不是為了給誰抓小辮子，而是給了大家一個經驗庫讓大家少犯類似的錯誤和更早的對問題提出多的解決方案。　

最後總結一句，儘管好像有點廢話，任何一種流程都不是放之四海皆準的，需要根據每個公司，每個專案，每個團隊，每個客戶而去甄別，去除錯，出了問題不要埋怨流程有問題，而是要想想自己如何去理解和應用這個流程的和如何去改進它。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24478210/viewspace-671735/，如需轉載，請註明出處，否則將追究法律責任。