首先說個老實話,軟體開發是沒有什麼所謂最小模式的; 如果可以我並不希望去嘗試所謂的最小模式; 現在開開1-2萬的二手小車是沒辦法,並不代表我願意一輩子開這種車.
cmmi3 認證要求最少有20人參加,其實是給出了乙個硬性的指標,要保證cmmi3所能達到了質量要求,大部分流程域是不能裁剪的,那麼就要保證有足夠的資源去做正確的事情.
也許是我沒有趕上好時節,我所經歷的專案和團隊,還真的沒有單個20人的規模,不過團隊是小但也是要活下去的,不管如何,生活還必須繼續,軟體還是要完成.
也許小團隊一定要上cmmi3 還是好高騖遠了,那麼我們來看看cmmi2, 但cmmi2也不是省油的燈, 裡面竟然已經包括了qa管理,配置管理,需求管理和度量管理, 這些東西已經不是5個人以下的團隊能夠運作的了,這4項工作我認為至少增加3-5人的輔助管理量,加上與之配套的開發團隊成員,整個規模保守估計應該在10-15人以上,說老實話, 對於一般的軟體公司,這個規模也有點勉為其難.
怎麼辦,再減? cmmi初級是完全」懵懂」模式,幾乎所有團隊都可以達到,這裡我就不加說明了,那麼cmmi2 似乎已經就是最底限度,小於10人的團隊真的與cmmi無緣嗎?那些過程域真的是乙個都不能再剪嗎? 這個cmmi專家們是沒有答案的,唯一的途徑,只能靠自己去摸索—就像懷揣了1-2萬還想開車的吊絲們,唯一的辦法就是自己到二手車市場去淘.
於是乎,對這個介於cmmi2和cmmi初級之間的」最小模式」的探索開始了.
首先我必須說明我個人的3點看法:
1.「最小模式」是我個人容忍的最底限度,如果這個都達不到,我個人認為你不是在做軟體,而是在玩軟體;也許有其他的高手也認為我的」最小模式」是在玩軟體,同理.
2.「最小模式」的軟體質量必然低於cmmi2 標準,軟體開發沒有僥倖,減價不減量的好事情從來都是沒有的,當然我個人認為」最小模式」的質量還是可以接受的,否則我就是誤人子弟了. 當然有可能只是我接受,大家還需要自行判斷.
3.「最小模式」是給現行的,迷茫的,一些小團隊們乙個建議,乙個起點,我還是希望大家能從這裡起飛而不是終止,正如我開頭說的那樣,沒有人願意一輩子做所謂的」最小模式」,人總是要有理想的,1-2萬的車剛工作開開是可以理解的,一輩子開是要被人鄙視的.
如果說真的存在乙個最為簡單的模型，我認為軟體的開發過程必須存在2條主線和4個步驟。
2條主線就是管理和技術。
4個步驟就是需求,設計,開發和測試。
2個主線是雙軌，4個步驟是車廂。無軌車子無法行駛，無車――這就不談了，這個就沒意義了。
這裡需要說明的是，4個步驟僅僅是軟體執行過程的內容，其關注點是軟體開發的生命週期而不是專案，專案的運作還需要更多的考慮，就像火車的行駛，需要出站和進站的過程，行駛過程還需要監控，這樣才能保證安全。專案的運作我們暫且不提，我們就說軟體開發，看看我們最少需要點什麼內容。
管理管理是什麼,如雷貫耳到不需要解釋了;專案管理,開發管理,團隊管理,這些名詞都是耳熟能詳. 我認為3個人以上的團隊就需要管理,不說別的,就是讓3個各自為戰的程式設計師能夠在規定的時間,規定的技術做出規定質量的軟體,這個就很像乙個神話故事了. 一句話,管理者不可或缺,目前軟體的規模越來越大,孤膽英雄或者喋血雙雄式的開發團隊已經非常少見了,那麼絕大部分團隊都必須存在」管理者」這個穿針引線的角色.但很多場合下,大家對管理者都有偏見,大家都認為這是乙個閒職,工作量估計比我們的公務員還低,不就是發個通知,買個晚飯的人嗎.所以大部分管理都是以兼職的身份而存在,最為常見的是,技術高手順便管理一下即可. 我想說的是,管理的工作其實非常的繁重,也非常的關鍵,管理對軟體的質量,時間,團隊,能力和最終成功與否,起到了至關重要的作用,
管理不但要有,而且要專職,沒有專職管理的團隊就是沒有司機的車,我真的建議你不要上去.
技術 技術,這個太簡單了,沒技術能做軟體嗎,團隊有大有小,但裡面的開發人員誰沒有2把刷子.所以,技術是最不是問題的問題.真的是這樣嗎.
這裡,我需要提出另外乙個概念—構架,構架是什麼,軟體開發者都有自己的看法,大家也知道構架師是乙個了不起的崗位,也成為了很多軟體人的夢想.構架是什麼,我的理解就2個字:駕馭. 能駕馭的技術就是構架,不能駕馭的技術僅僅是理論. 構架代表的不僅僅是技術本身,而是對技術的理解,領悟,經驗和積累,就像開客車的司機,他不但要有特殊的駕照,還需要有多少年,多少路的客車經驗,如果什麼都沒有僅僅是會開車,這裡面的風險就足夠毀滅一次長途旅行.
構架和駕馭有3方面的問題需要考慮:
其次是統一: 這個是很明顯的問題,構架必須統一,開發團隊裡面的每個人,其技術路線都是不同的,對構架的理解也不同,但乙個專案的構架必須統一,統一才能駕馭和控制,統一才能保證專案質量的水平一致.構架的廣度對統一有很大的影響,廣度越大,每個人自我發揮的餘地就小,統一的部分就多,構架就越容易駕馭.這裡多說一句,很多新手程式設計師對既定的構架壓縮自己的發揮空間非常的反感,我這裡要誠心的告訴這些新人,構架定義良好的團隊是你的福音, 乙個讓新人隨意發揮的團隊才是真正的坑爹,切記.
最後是積累和培訓: 構架絕對不是只存在於當下專案,當下團隊的產物,沒有乙個構架師可以在他的第乙個專案就形成乙個」驚天地泣鬼神」的構架,構架需要在大量的專案中不斷的積累和提高;另外構架絕對不是一人或者一群人的專屬,離開了特殊的人或者群體,構架應該依然有強大的生命力,這就是培訓,構架應該便於向各種各樣的後人傳授,傳授的越快越便捷,構架的成熟度越高.
需求 需求就是要明確做什麼，明確了做什麼才能作對；但軟體是乙個很神奇的東西，不知道要做什麼就開始做了這個幾乎是經常發生的事情。不知道要做什麼也能做完這個也不是什麼稀奇的事情。
需求不僅僅是乙個業務的東西，更是乙個共識和契約；需求不可能窮盡，客戶想要的一定比我們能做的更多，而開發團隊則要求乙個穩定而合理的範圍。
面上的需求雖然也是需要點技巧的，但大部分人還是能夠理解並交流的，這些需求大多流於客戶需求範疇，就是搞清楚客戶想要什麼樣的軟體。而需求的問題常常發生在2個方面：可實現性和穩定性。
說白了，需求最終還是要技術拍板能不能做，另外還需要客戶和開發團隊達成共識，做到什麼範圍為止；
不知道大家有沒有發現，可實現性和構架有很大的關係，而穩定性則需要博弈，這裡就需要管理者的協調，當然這裡還有商務問題，這個就不在本文的範圍以內了。
設計設計就是我們應該怎麼做，我們的軟體是什麼風格的，什麼套路的。開發者經常忽視設計而相對重視需求，原因很簡單，開發者不能決定需求，但可以決定設計，因為設計是技術範疇的東西，但這就恰恰是設計的問題所在。
第乙個問題是設計的合理性，這是大家常常忽略的問題，因為合理性不僅僅是技術問題還是需求問題，大多數專案中，客戶的需求常常延伸到設計，尤其是介面和使用者體驗。所以原型確認被越來越多的提上議事日程，在需求階段就加以解決，甚至作為需求的身份出現。這是乙個問題.
另外乙個問題是設計的統一，因為設計是技術範疇，那麼開發者幾乎人人可以設計，比如增刪改頁面，畢業生都會做，但大家的風格必然各不相同，但乙個軟體必須有統一的設計，而且要統一所有的細節，這個問題就必須在設計階段給予解決。很多時候會出現形似神不似的問題，細節設計問題防不勝防，造成軟體大問題不多，小問題遍地的尷尬局面，面對嚴格的客戶，這樣的軟體難稱專業。想到這裡就不難去理解，小日本為什麼要寫那麼羅嗦的設計文件了。
開發開發是大多數軟體人的看家本領了，但事實上大部分人並不是太會程式設計，或者在學會程式設計以前就去做其他事情了。
開發注意2個問題：自律和自檢。
首先看你有沒有規範，就是你寫的**有沒有套路，最明顯的標記就是注釋。這裡面的問題大部分人都有自己的心得，我就點到為止。
第二個問題是開發的自檢，流行的方法是code review和單元測試，code review需要第三方的介入，比如雙人程式設計，而單元測試需要程式設計以外的能力，這些都需要人力和時間的投入，所以也常常被人忽略。開發的自檢不僅僅是為了公司和專案，也是為了自己，大家可以反思下，從自己開始程式設計以來，程式設計能力提高了多少，都是如何提高的，就能體會我這句話的深意。
測試測試是驗證軟體的正確性，當然主要是需求的一致性，不過很多測試都會忙於偵測**的漏洞，這個其實是在為整個開發團隊買單，包括構架人員。
也許，對於乙個真正的開發人員來說，真的不需要測試了，他的**基本是完美的；但我還是想說，還是給我乙個測試吧，古詩雲「不識廬山真面目，只緣身在此山中」；再神奇的開發都不能完全發現自己**的問題，更何況，軟體是需要用另外乙個視角去審核的。
測試的東西說老實話我也沒有太多深入的研究，我只是想告訴大家乙個好的測試人員是開發者的守護者和老師。據說微軟用資深開發做測試，這個估計就是極致的模式了吧。
再下面，我想談談我的「
6人模型」，對開發團隊的建設做乙個「最小模式」的探索。
軟體開發和團隊」最小模式」初探2 6人模型（上）
l 首先，我之所以要用6人而不是6角色，就是想暗示我認為6人各自獨立的必要性，而反對合併和兼職 雖然我對兼職也有一定的理解 請檢視以後的章節 金剛合體和巨人肩膀 我認為6人可以不必全程參與，但不要合二為一。l 6人是最小模型，6人缺一不可，缺一則傷及軟體質量的根本，或者說，軟體質量會減低到我能容忍的...
軟體開發流程初探
一 瀑布模型 優點 缺點 二 增量模型 優點 缺點 三 螺旋模型 優點 缺點 unified process up 代表了一種軟體開發的主流方法，其三大特點是 1.受控的迭代式增量開發 允許在開發之初的不完整和不完美，但隨著迭代的推進，產品工件逐步趨向穩定 2.軟體開發是由用例驅動的 用例就是使用者...
小團隊軟體開發
軟體開發是自己的本行,這裡談談對乙個小團隊開發軟體的幾點思考 1 每個開發人員要對所要開發的東西在開發之前就要有一定的了解,最好是在開始的時候就把需求問的詳細一些,不要對著乙個全是文字的東西談需求,最好用圖形來互動,做軟體的都有個體會,往往到自己把介面做的差不多了,給使用者一看,使用者馬上就補充了一...