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

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

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


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

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


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

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

先舉一個CMMI之前的開發(fā)案例吧。

當年從事一個現場升級項目，開發(fā)只花了兩個月，（每天從8點15到晚上9點半，周六上班），然后一個月就通過驗收測試，并且上了線，但是后來BUG直到一年后才完全穩(wěn)定下來。還發(fā)現容量不夠，高峰時總是Down機，最后只能修改合同，賠了用戶款項了事。

原因：1、需求過于簡單，當時拿著一份老系統的測試規(guī)范就開始編程，測試規(guī)范只有20條。結果后來發(fā)現有好多細致的用戶需求沒有被記錄在文檔里，如用戶的號碼如果沒有區(qū)號時系統要給號碼自動加上0+區(qū)號的前綴。后來使用時被投訴才發(fā)現，又不得不修改。

2、沒有安排真實環(huán)境集成測試，當時測一下就交付了，后來發(fā)現和本公司的交換機正常工作，和其他廠商的交換機無法工作。檢查后發(fā)現是我們對異常參數的處理能力不夠，規(guī)范上是某個號碼是4-12位，我們少支持了一位，并且不支持#值。

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

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

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


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

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

憑心而論，Standup Meeting,Demo to Customer,結對編程，固定發(fā)布周期，自動編譯和自動測試等都是非常好的實踐。

但是其忽略了一些問題，

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

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

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

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

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


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

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

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

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


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


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

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

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

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

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


５、如何判斷項目和需求的關鍵點

這個我感悟是最深的，CMMI和Scrum對這個都作了定義，就是Priority最高的需求或CMM　里面的關鍵路徑的任務（到項目后就變?yōu)槟稠椚蝿栈蚧顒恿耍?br>
回顧我做過的項目，成功的占了５／４，大部分都是二次開發(fā)和規(guī)模較小的項目或者大項目被分解成小的項目。不成功的幾乎都是錯誤的定義或判斷了關鍵點，總結下來有幾點原因：

１）、項目的外部接口文檔或資料沒有得到就開始開發(fā)任務。

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

２）、內存泄漏的問題。

我們原來公司都是C++或JAVA語言開發(fā)的，幾乎所有的項目最后都是內存泄漏而延誤了進度。而不是功能需求的未完成耽誤進度。這個問題是任何流程無法直接解決的。

實際上，每個程序員都應當培養(yǎng)代碼評審的習慣，還應當從開發(fā)模塊級別發(fā)布一些內存跟蹤工具，模擬在實際用戶應用的內存變化情況。另外公司建立一個Bug知識庫也是一種好的方法。

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

我 經歷過的一個項目其實非常復雜，里面有三個不同領域的專家，彼此對自己的領域都很精通，但都不了解對方的知識，定義規(guī)范和任務時，靠郵件和電話會議溝通了 很久也沒有找到解決方案，我向領導提出當面開會，卻沒有得到明確的答復。在沒有相應的外部資源支持（要投入交流和培訓的成本）和對外部的推動力不夠得情況 下基于自己的假設完成了開發(fā)，做出來后一集成測試發(fā)現很多需求理解得并不充分，都站在自己的層面去實現，沒有考慮整個方案的目標和制定相應的接口。后來由 各方高層出面，在新項目中安排了培訓和開會討論等任務，基本解決了前個項目中的遺留問題。
CMMI中提出了一種方法，是項目經理根據需求把任務本身進行分解。先找到關鍵任務和其風險的解決方案。
CMMI中列出了一份項目失敗的原因列表，我覺得非常好，它不是為了給誰抓小辮子，而是給了大家一個經驗庫讓大家少犯類似的錯誤和更早的對問題提出多的解決方案?！?br>
最后總結一句，盡管好像有點廢話，任何一種流程都不是放之四海皆準的，需要根據每個公司，每個項目，每個團隊，每個客戶而去甄別，去調試，出了問題不要埋怨流程有問題，而是要想想自己如何去理解和應用這個流程的和如何去改進它。