問題
原來問題是這麼寫的:“一家企業既要過CMMI,又要過ISO,還要實施敏捷,應該怎樣做?”
之所以改成“哪個好”,是因為如果要多頭並存,就要有主次關係。
那麼,到底哪個好,應該以哪個為主呢?
分析
每次說到這個問題,都會有不同的角度可以分析。
一個常見的角度是說:CMMI比較完整“大氣”,可以做整個公司的管理框架,而敏捷更適合團隊級別的管理。
另外一個角度是說:兩個是可以共存的,可以用敏捷開發的實踐來滿足CMMI的要求。
那麼,到底哪個角度是優先考慮的呢?
商業目標是優先考慮的角度。
這是一個經常被廉價販賣以至於不太引起重視的角度了,大致說的是:要理解自己的現狀和目標,以便決策自己的研發方法。
有時候過程改進人員或質量人員也常常研究這個目標,但常常僅限於研究個別度量資料的目標,而極少有人有足夠的高度來看整體框架的目標(本人當年也是如此)。
基於這一點,下面方案中分為幾個場景一一描述。
方案
方案1:軍工、航空航天——生命攸關和潛在重大損失的——CMMI為主
在敏捷與CMMI系列之一http://blog.csdn.net/cheny_com/article/details/6423463 中曾經提到,CMMI的本質是美國國防部(DOD)用於篩選供應商的標準,其核心價值觀是利用需求、計劃的可追溯性、一致性,來達成對生命攸關和潛在重大損失專案的保障。
這一要求可以令其基本忽略我們常常引以為豪的“創新”“激勵”這些因素,或至少堅定地把這些因素排在一致性、可追溯性之後。
方案2:銀行、證券——潛在重大損失的——CMMI為主,輔以RUP
IBM是CMMI的重要推手之一,此外他們還是軍工和製造業軟體研發管理工具的提供者——Rational系列產品及後來收購的Telelogic DOORs、SA等產品,廣泛應用於軍工、航空航天、製造業,但IBM最喜歡的,不是瀑布模型,而是RUP。
RUP可以理解為瀑布被迭代化了,允許業務的“不斷精進”,而不是最初把需求就要一次定好。
RUP也可以理解為迭代被瀑布化了,允許迭代的目標不完全是“生產可執行軟體”,或者雖然如此,但比重不同;比如開始做“可執行軟體”的目的,不是交付,而是用作需求溝通的原型。
RUP是IBM這個與銀行業打交道由來已久的老牌供應商的工作方式,無疑是這個行業的代表方法。
方案3:一般外包——CMMI為框架,輔以敏捷
為什麼以CMMI為框架?
因為CMMI除了有軍工、國防部這些標籤外,還有幾個標籤:外包,供應商,供應商篩選。甚至可以說CMMI整體就是為外包雙方準備的。而敏捷開發中,就無法直接看到有直接相關的內容。
方案4:網際網路,網路遊戲——Scrum為主
這個行業建議一點都不要看CMMI。
不是說CMMI完全無用,而是說有比CMMI適合地多的東西值得去做,比如產品創新,使用者體驗。
這就有點像多數人都學點英語,但不學日語,不是學日語無用,而是對自己的職業生涯影響不很直接。
方案5:創新產品,移動互聯小程式,網路遊戲的初期——XP,“原始的”原型法,乃至混沌
各種神奇的創業公司在初期的時候幾乎都沒有任何管理體系,然而其生產率估計到後來“正規化管理”後也無法超越,難道“管理”“開發方法”這些東西起的是反作用嗎?
不是。
各種管理及方法,整體上有兩個大的目標:
1. 保證正在做一個正確的產品,需求符合使用者的需要。
2. 保證人員在正確地做事(包括正確的技術,被激勵的工作態度等),確保產品被及時完成。
在創業團隊中,雖然沒有“正規管理”,但卻有其他的方法在保證這兩件事情。換言之,如果“正規管理”沒有聚焦於這兩點,或沒有充分做到這兩點,那麼就顯得用處不大。
在方案5涉及的語境中,“正規管理”能起到的作用是很小的,或者說無需正規管理,1和2應該也是能做到的(否則只能說找錯了人,比如“我們用嚴格管理進行創新”就是錯誤的,應該是“我們找到一群激情的人進行創新”),因此過程應該儘量輕量化,去完成真正應該完成的創新工作。
方案6:隨時隨地按實際情況決策
並非所有行業都是一成不變的,也不是所有行業的所有產品都符合行業特徵。
為什麼CMMI中開始出現了敏捷的內容?很多人會想:“敏捷開發過於熱火,CMMI不得不考慮一下廣大程式設計師的心情。”其實不然,美國國防部是不會基於程式設計師的心情或業界的呼聲而改變自己選擇供應商的標準的,除非行業自身發生了變化。隨著裝置小型化,原來主要用於大型航空航天載具、指揮管控系統的軟體已經逐漸走向單兵或單個小型器械,如果經常看《未來武器》系列紀錄片,就會意識到這一點。這些產品很多對“一致的、可追溯的”需求沒有太大的追求,反而是快速響應變化變成了一個看得見的價值。
為什麼IBM也開始做RTC了呢?(RTC是IBM Rational開發的敏捷開發管理工具)因為原來銀行業的業務一直變化很慢,就是存取款貸款之類,但最近大家應該能感受到,銀行隊伍的長度,和股市、基金、理財、黃金的關係更大,這些業務的需求變化很快,敏捷開發變得勢在必行。
因此應該理解自己的行業,也要理解自己正在面對的具體產品,才能決定那種方法更適合,哪種方法為主。