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

A在2006年推廣過(guò)了CMM3,E在公司2008年推廣了Scrum ,B最近準(zhǔn)備過(guò)CMMI3，新近又參加了CMMI的培訓(xùn)，頗多感悟拿出來(lái)與同學(xué)們討論討論。

不像很多人的誤解，CMMI其實(shí)和Scrum并不矛盾，應(yīng)當(dāng)說(shuō)瀑布模型與Scrum矛盾，或者說(shuō)瀑布模型是由一系列的Scrum項(xiàng)目迭代而組成，更加適合大項(xiàng)目。


為什么這么說(shuō)呢，傳統(tǒng)的瀑布模型定義一個(gè)需求，然后進(jìn)行分解，評(píng)審，開發(fā)測(cè)試，現(xiàn)場(chǎng)驗(yàn)收。

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


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

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

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

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

原因：1、需求過(guò)于簡(jiǎn)單，當(dāng)時(shí)拿著一份老系統(tǒng)的測(cè)試規(guī)范就開始編程，測(cè)試規(guī)范只有20條。結(jié)果后來(lái)發(fā)現(xiàn)有好多細(xì)致的用戶需求沒有被記錄在文檔里，如用戶的號(hào)碼如果沒有區(qū)號(hào)時(shí)系統(tǒng)要給號(hào)碼自動(dòng)加上0+區(qū)號(hào)的前綴。后來(lái)使用時(shí)被投訴才發(fā)現(xiàn)，又不得不修改。

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

我們的交換機(jī)不發(fā)#，他們的發(fā)#，結(jié)果我們的系統(tǒng)down機(jī)了。

3、 沒有性能測(cè)試的目標(biāo)，當(dāng)時(shí)含含糊糊的說(shuō)要達(dá)到老系統(tǒng)的性能，并沒有開發(fā)實(shí)際的性能測(cè)試工具，沒有定義系統(tǒng)的工作方式，也不知道老系統(tǒng)的真實(shí)負(fù)載和實(shí)際處理 能力。后來(lái)發(fā)現(xiàn)系統(tǒng)一到周一和周五早上就Down機(jī)（其系統(tǒng)負(fù)荷是平時(shí)的2-3倍），搞得用戶每到這時(shí)候就特別緊張。

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


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

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

憑心而論，Standup Meeting,Demo to Customer,結(jié)對(duì)編程，固定發(fā)布周期，自動(dòng)編譯和自動(dòng)測(cè)試等都是非常好的實(shí)踐。

但是其忽略了一些問題，

1、其對(duì)Product Owner過(guò)于強(qiáng)調(diào)，實(shí)際發(fā)現(xiàn)產(chǎn)品的需求一開始很難被正確的定義優(yōu)先級(jí)，所以會(huì)導(dǎo)前面的白費(fèi)，但管理層顯然不喜歡這個(gè)后果，對(duì)ProductOwner很不滿意導(dǎo)致其受到責(zé)備。

2、 開發(fā)和測(cè)試都敏捷了，可是項(xiàng)目和需求并沒有敏捷。項(xiàng)目經(jīng)理在Scrum里是個(gè)可有可無(wú)的角色。那團(tuán)隊(duì)里有了矛盾怎么辦，進(jìn)度延誤了誰(shuí)負(fù)責(zé)？ 誰(shuí)對(duì)支付錢買產(chǎn)品的人做出承諾？ 這些問題Scrum并沒有回答，需求的改變本來(lái)是Scrum最歡迎的，項(xiàng)目經(jīng)理卻對(duì)其大加斥責(zé)，（因?yàn)槠鋵?dǎo)致了項(xiàng)目的額外付出和延誤），實(shí)際最后項(xiàng)目幾乎 所有的人都不滿意。

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

誰(shuí)給予Product Owner與客戶洽談的職責(zé)，誰(shuí)給予TeamLeader以考評(píng)組員的能力，客戶和外部的高層領(lǐng)導(dǎo)都不希望看到自己的意見有很多個(gè)不同的解決方案，而Team內(nèi)部成員卻爭(zhēng)論不休的現(xiàn)象。

這些問題都是需要每個(gè)實(shí)行Scrum的公司考慮的。


3、 對(duì)團(tuán)隊(duì)的要求過(guò)高，希望成員能夠干好每一件事。我認(rèn)為這是一個(gè)非常錯(cuò)誤和不可能達(dá)到的偽假設(shè)。包括Product Owner,沒有人能夠做好每件事，IT的技術(shù)千變?nèi)f化，市場(chǎng)的環(huán)境不斷改變。一個(gè)人總有不知道的領(lǐng)域。一個(gè)人和一個(gè)團(tuán)隊(duì)很少能夠做兩個(gè)重復(fù)的項(xiàng)目，而現(xiàn) 實(shí)情況時(shí)當(dāng)你說(shuō)不時(shí)就有人說(shuō)你能力不夠。

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

一個(gè)人做好一件事都很難，如何讓他在短期內(nèi)一會(huì)做好這件，一會(huì)做好那件呢？　

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


實(shí)際上E公司有一點(diǎn)是非常不好的，其不鼓勵(lì)事前項(xiàng)目成員和不同部門的互相討論，喜歡搞某個(gè)專家的獨(dú)立決策，并且喜歡事后對(duì)各種決策做事后的所謂RouteCause分析和總結(jié)。弄得不好就演化為批判會(huì)，而不是項(xiàng)目前期的多方準(zhǔn)備和風(fēng)險(xiǎn)決策的尋找和解決，接受過(guò)程。


我認(rèn)為對(duì)于一些技術(shù)的關(guān)鍵點(diǎn)應(yīng)當(dāng)事前廣泛聽取群眾的抱怨和意見，少部分人參與討論和選擇，獨(dú)立的作出判斷和決策才是一個(gè)好的決策者的工作方式，不過(guò)這種方式在E公司是不受肯定的。

４、到底是不是需要強(qiáng)調(diào)文檔。

CMMI中非常重視文檔和過(guò)程的定義，而Scrum里面強(qiáng)調(diào)代碼為王，鼓勵(lì)少寫和不寫文檔。

我個(gè)人的感覺是各有利弊，過(guò)分強(qiáng)調(diào)文檔會(huì)增加公司的生產(chǎn)和維護(hù)成本。用戶需求，產(chǎn)品需求，概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)，測(cè)試方案，測(cè)試用例加其他很多文檔，可能要比真正的交付產(chǎn)品的Effort多得多，在有的客戶小項(xiàng)目中可能真的沒有必要。

而Scrum又走向另一個(gè)極端，多模塊和復(fù)雜的項(xiàng)目光看代碼是很難讓人知道它的設(shè)計(jì)思想和難以維護(hù)的，所以對(duì)于平臺(tái)級(jí)的構(gòu)件和關(guān)鍵的一些項(xiàng)目還是需要概要設(shè)計(jì)等任務(wù)的安排的，而標(biāo)準(zhǔn)也是需要每個(gè)決策者考慮的。


５、如何判斷項(xiàng)目和需求的關(guān)鍵點(diǎn)

這個(gè)我感悟是最深的，CMMI和Scrum對(duì)這個(gè)都作了定義，就是Priority最高的需求或CMM　里面的關(guān)鍵路徑的任務(wù)（到項(xiàng)目后就變?yōu)槟稠?xiàng)任務(wù)或活動(dòng)了）。

回顧我做過(guò)的項(xiàng)目，成功的占了５／４，大部分都是二次開發(fā)和規(guī)模較小的項(xiàng)目或者大項(xiàng)目被分解成小的項(xiàng)目。不成功的幾乎都是錯(cuò)誤的定義或判斷了關(guān)鍵點(diǎn)，總結(jié)下來(lái)有幾點(diǎn)原因：

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

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

２）、內(nèi)存泄漏的問題。

我們?cè)瓉?lái)公司都是C++或JAVA語(yǔ)言開發(fā)的，幾乎所有的項(xiàng)目最后都是內(nèi)存泄漏而延誤了進(jìn)度。而不是功能需求的未完成耽誤進(jìn)度。這個(gè)問題是任何流程無(wú)法直接解決的。

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

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

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