軟體開發和團隊”最小模式”初探1

CMMI 2 , 1 還是1.5 ?

首先說個老實話,軟體開發是沒有什麼所謂最小模式的; 如果可以我並不希望去嘗試所謂的最小模式; 現在開開1-2萬的二手小車是沒辦法,並不代表我願意一輩子開這種車.

CMMI3 認證要求最少有20人蔘加,其實是給出了一個硬性的指標,要保證CMMI3所能達到了品質要求,大部分流程域是不能裁剪的,那麼就要保證有足夠的資源去做正確的事情.

也許是我沒有趕上好時節,我所經曆的項目和團隊,還真的沒有單個20人的規模,不過團隊是小但也是要活下去的,不管如何,生活還必須繼續,軟體還是要完成.

也許小團隊一定要上CMMI3 還是好高騖遠了,那麼我們來看看CMMI2, 但CMMI2也不是省油的燈, 裡面竟然已經包括了QA管理,組態管理,需求管理和度量管理, 這些東西已經不是5個人以下的團隊能夠運作的了,這4項工作我認為至少增加3-5人的輔助管理量,加上與之配套的Team Dev成員,整個規模保守估計應該在10-15人以上,說老實話, 對於一般的軟體公司,這個規模也有點勉為其難.

怎麼辦,再減? CMMI初級是完全”懵懂”模式,幾乎所有團隊都可以達到,這裡我就不加說明了,那麼CMMI2 似乎已經就是最底限度,小於10人的團隊真的與CMMI無緣嗎?那些過程域真的是一個都不能再剪嗎? 這個CMMI專家們是沒有答案的,唯一的途徑,只能靠自己去摸索—就像懷揣了1-2萬還想開車的吊絲們,唯一的辦法就是自己到二手車市場去淘.

於是乎,對這個介於CMMI2和CMMI初級之間的”最小模式”的探索開始了.

首先我必須說明我個人的3點看法:

1.       “最小模式”是我個人容忍的最底限度,如果這個都達不到,我個人認為你不是在做軟體,而是在玩軟體;也許有其他的高手也認為我的”最小模式”是在玩軟體,同理.

2.       “最小模式”的軟體品質必然低於CMMI2 標準,軟體開發沒有僥倖,減價不減量的好事情從來都是沒有的,當然我個人認為”最小模式”的品質還是可以接受的,否則我就是誤人子弟了. 當然有可能只是我接受,大家還需要自行判斷.

3.       “最小模式”是給現行的,迷茫的,一些小團隊們一個建議,一個起點,我還是希望大家能從這裡起飛而不是終止,正如我開頭說的那樣,沒有人願意一輩子做所謂的”最小模式”,人總是要有理想的,1-2萬的車剛工作開開是可以理解的,一輩子開是要被人鄙視的.

2條主線. 4個步驟

如果說真的存在一個最為簡單的模型，我認為軟體的開發過程必須存在2條主線和4個步驟。

 

2條主線就是管理和技術。

4個步驟就是需求,設計,開發與測試。

 

2個主線是雙軌，4個步驟是車廂。無軌車子無法行駛，無車――這就不談了，這個就沒意義了。

這裡需要說明的是，4個步驟僅僅是軟體執行過程的內容，其關注點是軟體開發的生命週期而不是項目，項目的運作還需要更多的考慮，就像火車的行駛，需要出站和進站的過程，行駛過程還需要監控，這樣才能保證安全。項目的運作我們暫且不提，我們就說軟體開發，看看我們最少需要點什麼內容。

管理

管理是什麼,如雷貫耳到不需要解釋了;專案管理,開發管理,團隊管理,這些名詞都是耳熟能詳. 我認為3個人以上的團隊就需要管理,不說別的,就是讓3個各自為戰的程式員能夠在規定的時間,規定的技術做出規定品質的軟體,這個就很像一個神話故事了. 一句話,管理者不可或缺,目前軟體的規模越來越大,孤膽英雄或者喋血雙雄式的Team Dev已經非常少見了,那麼絕大部分團隊都必須存在”管理者”這個穿針引線的角色.但很多場合下,大家對管理者都有偏見,大家都認為這是一個閑職,工作量估計比我們的公務員還低,不就是發個通知,買個晚飯的人嗎.所以大部分管理都是以兼職的身份而存在,最為常見的是,技術高手順便管理一下即可. 我想說的是,管理的工作其實非常的繁重,也非常的關鍵,管理對軟體的品質,時間,團隊,能力和最終成功與否,起到了至關重要的作用,

管理不但要有,而且要專職,沒有專職管理的團隊就是沒有司機的車,我真的建議你不要上去.

技術

技術,這個太簡單了,沒技術能做軟體嗎,團隊有大有小,但裡面的開發人員誰沒有2把刷子.所以,技術是最不是問題的問題.真的是這樣嗎.

這裡,我需要提出另外一個概念—構架,構架是什麼,軟體開發人員都有自己的看法,大家也知道構架師是一個了不起的崗位,也成為了很多軟體人的夢想.構架是什麼,我的理解就2個字:駕馭. 能駕馭的技術就是構架,不能駕馭的技術僅僅是理論. 構架代表的不僅僅是技術本身,而是對技術的理解,領悟,經驗和積累,就像開客車的司機,他不但要有特殊的駕照,還需要有多少年,多少路的客車經驗,如果什麼都沒有僅僅是會開車,這裡面的風險就足夠毀滅一次長途旅行.

構架和駕馭有3方面的問題需要考慮:

首先是深度和廣度: 構架必須涵蓋項目開發所有的問題,請注意是所有,任何開發中的問題最好都已經有一個成熟的方案來應對.這也許是一個很高的要求,但我們必須要明確這是我們構架發展的方向.比如說,這個項目某個問題沒有好的解決方案,那麼下一個項目就有了,若干項目以後,構架的深度和廣度就能有很大的提高. 其實不管是什麼等級的問題,就必須有成熟的方案而不是留給開發人員自我發揮,比如Web項目,不僅僅是效能,安全,報表這些進階問題需要解決方案,就一些基礎問題如轉頁,Session,上傳等等都必須有成熟的思路;這就是廣度和深度和含義; 很多人熱衷與遇到問題找Google百度,而且Google百度的確也找的到臨時方案,這裡暫不提臨時尋找方案對項目進度造成的衝擊,我就說一點,很多夢寐以求的構架師,難度就是Google百度一分鐘就能取代的嗎,其中奧秘大家一想便知.

其次是統一: 這個是很明顯的問題,構架必須統一,Team Dev裡面的每個人,其技術路線都是不同的,對構架的理解也不同,但一個項目的構架必須統一,統一才能駕馭和控制,統一才能保證項目品質的水平一致.構架的廣度對統一有很大的影響,廣度越大,每個人自我發揮的餘地就小,統一的部分就多,構架就越容易駕馭.這裡多說一句,很多新手程式員對既定的構架壓縮自己的發揮空間非常的反感,我這裡要誠心的告訴這些新人,構架定義良好的團隊是你的福音, 一個讓新人隨意發揮的團隊才是真正的坑爹,切記.

最後是積累和培訓: 構架絕對不是只存在於當下項目,當下團隊的產物,沒有一個構架師可以在他的第一個項目就形成一個”驚天地泣鬼神”的構架,構架需要在大量的項目中不斷的積累和提高;另外構架絕對不是一人或者一群人的專屬,離開了特殊的人或者群體,構架應該依然有強大的生命力,這就是培訓,構架應該便於向各種各樣的後人傳授,傳授的越快越便捷,構架的成熟度等級越高.

 

需求   

需求就是要明確做什麼，明確了做什麼才能作對；但軟體是一個很神奇的東西，不知道要做什麼就開始做了這個幾乎是經常發生的事情。不知道要做什麼也能做完這個也不是什麼稀奇的事情。

需求不僅僅是一個業務的東西，更是一個共識和契約；需求不可能窮盡，客戶想要的一定比我們能做的更多，而Team Dev則要求一個穩定而合理的範圍。

面上的需求雖然也是需要點技巧的，但大部分人還是能夠理解並交流的，這些需求大多流於客戶需求範疇，就是搞清楚客戶想要什麼樣的軟體。而需求的問題常常發生在2個方面： 可實現性和穩定性。 說白了，需求最終還是要技術拍板能不能做，另外還需要客戶和Team Dev達成共識，做到什麼範圍為止； 不知道大家有沒有發現，可實現性和構架有很大的關係，而穩定性則需要博弈，這裡就需要管理者的協調，當然這裡還有商務問題，這個就不在本文的範圍以內了。

 

設計

設計就是我們應該怎麼做，我們的軟體是什麼風格的，什麼套路的。開發人員經常忽視設計而相對重視需求，原因很簡單，開發人員不能決定需求，但可以決定設計，因為設計是技術範疇的東西，但這就恰恰是設計的問題所在。

         第一個問題是設計的合理性，這是大家常常忽略的問題，因為合理性不僅僅是技術問題還是需求問題，大多數項目中，客戶的需求常常延伸到設計，尤其是介面和使用者體驗。所以原型確認被越來越多的提上議事議程，在需求階段就加以解決，甚至作為需求的身份出現。這是一個問題.

         另外一個問題是設計的統一，因為設計是技術範疇，那麼開發人員幾乎人人可以設計，比如增刪改頁面，畢業生都會做，但大家的風格必然各不相同，但一個軟體必須有統一的設計，而且要統一所有的細節，這個問題就必須在設計階段給予解決。很多時候會出現形似神不似的問題，細節設計問題防不勝防，造成軟體大問題不多，小問題遍地的尷尬局面，面對嚴格的客戶，這樣的軟體難稱專業。想到這裡就不難去理解，小日本為什麼要寫那麼羅嗦的設計文檔了。

開發

         開發是大多數軟體人的看家本領了，但事實上大部分人並不是太會編程，或者在學會編程以前就去做其他事情了。

         開發注意2個問題：自律和自檢。

         首先看你有沒有規範，就是你寫的代碼有沒有套路，最明顯的標記就是注釋。這裡面的問題大部分人都有自己的心得，我就點到為止。

        第二個問題是開發的自檢，流行的方法是Code Review和單元測試，Code Review需要第三方的介入，比如雙人編程，而單元測試需要編程以外的能力，這些都需要人力和時間的投入，所以也常常被人忽略。開發的自檢不僅僅是為了公司和項目，也是為了自己，大家可以反思下，從自己開始編程以來，編程能力提高了多少，都是如何提高的，就能體會我這句話的深意。

測試

         測試是驗證軟體的正確性，當然主要是需求的一致性，不過很多測試都會忙於偵測代碼的漏洞，這個其實是在為整個Team Dev買單，包括構架人員。

也許，對於一個真正的開發人員來說，真的不需要測試了，他的代碼基本是完美的；但我還是想說，還是給我一個測試吧，古詩云“不識廬山真面目，只緣身在此山中”；再神奇的開發都不能完全發現自己代碼的問題，更何況，軟體是需要用另外一個視角去審核的。

         測試的東西說老實話我也沒有太多深入的研究，我只是想告訴大家一個好的測試人員是開發人員的守護者和老師。據說微軟用資深開發做測試，這個估計就是極致的模式了吧。

 

再下面，我想談談我的“6人模型”，對Team Dev的建設做一個“最小模式”的探索。