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

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

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


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

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


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

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

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

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

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

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

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

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

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


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

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

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

但是其忽略了一些問(wèn)題，

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

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

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

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

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


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

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

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

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


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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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