l 首先，我之所以要用6人而不是6角色，就是想暗示我認為6人各自獨立的必要性，而反對合併和兼職（雖然我對兼職也有一定的理解――請檢視以後的章節：金剛合體和巨人肩膀），我認為6人可以不必全程參與，但不要合二為一。
l 6人是最小模型，6人缺一不可，缺一則傷及軟體質量的根本，或者說，軟體質量會減低到我能容忍的極限以下，但是否達到我的質量標準不等於軟體成功的標準，這個大家要有清楚的認知。
l 6人具有各自的專業領域，各自有獨特的方向和技能。也許我們的團隊暫時找不到6個絕對合適的人，但我們必須承認這是我們的方向。
1.管理者
2.構架者
3.需求者
4.設計者
5.編碼者
6.測試者
管理者遵循管理主線的團隊領導,引領航行的舵手和船長.
管理者需要軟體專案管理的技能。
管理者是「閒職」嗎，答案肯定是否定的，我們不扯pmp 9大領域，5個環節，我們也不扯cmmi關於各種管理的長篇大論，我就指出我認為管理者不得不做的4件事情，大家來看看我們需不需要這個管理者。
1.時間管理：計畫告訴大家要做什麼，監督了解大家正在做什麼，做了多少；審核保證大家的工作已經完成。告訴我，如果沒有管理者，誰知道，大家需要做什麼，現在做了多少，未來什麼時候做完。
2.溝通管理：軟體開發不是獨立存在，有隨時要求更多的客戶，有期望永遠大於實際的高層，每天都有不同的人希望了解，交流和變更軟體開發的內容和程序，這些交流工作交給只願意帶著耳機悶頭開發的人合適嗎。
3.團隊管理：3人成黨，4人成幫，人的問題總是比**複雜的多，無論組織個小型的飯局，還是解決每個人的煩惱，這裡總需要乙個協調人的存在。
4.風險管理：軟體開發有風險嗎，有，而且大到任何人無法相信，從來沒有按時完成的軟體計畫，從來沒有符合需求的軟體產品；那麼誰來帶領大家未雨綢繆，在風險到來前做好一切準備，把風險的影響降到最低，只能是管理者。
構架者遵循技術主線的團隊領導,軟體開發最終還是技術活,技術高低決定軟體的層次高低。
構架者需要精通專案相關技術，並具有相當的應用經驗，能夠選擇和駕馭相關技術給出專案的合理解決方案。並且該解決方案可追蹤，可執行，可培訓。
首先構架者需要了解一定規模的該領域的相關技術，以便於根據不同專案要求進行選擇，構架者需要有足夠的技術儲備。
技術選擇了還不夠，構架者需要對其的可執行性具有相當的把握，自己都不會，奢求其他人無師自通？最典型的構架笑話是，大家就按某某構架自己做把，自由發揮，如果大家利用乙個構架都沒有你來的透徹，那麼你為什麼不能先行消化，讓大家少走彎路，減少質量損耗；反之，如果有人對構架的理解比你還高一籌，那麼為什麼讓你來當構架者。
最後構架不能僅僅考慮能否實現，還需要考慮延伸屬性，比如效能，穩定，併發等等問題。這個就需要積累，非一日之功。
需求者需求是軟體存在的理由,滿足需要是軟體成功的主要標準,需求者是原始需求的發掘者，並加以整理和抽象，成為軟體的需求.
在整個6人模式中，管理者應該是完全的非技術人員（雖然很多管理者是技術出生，但在我的模型裡面他的技術職能幾乎沒有）；而需求者是對半開，為什麼怎麼說，需求者分2個階段。
l 需求挖掘－客戶交流
l 需求開發－系統分析
需求挖掘需要的是交流能力，邏輯能力。
而系統分析，需要的是邏輯能力和軟體設計，分析和一定的技術功底。
需求人員需要從客戶那邊挖掘（請注意不僅僅是記錄，因為很多客戶不了解自己的實際需求），然後抽象，分析並設計出乙個軟體的雛形，給設計者提供前置範圍。同時，需求者需要在構架者的幫助下，基於自身一定的技術功底，保證所設計的軟體系統架設在可執行的技術構架之上。
設計者承上啟下，軟體最終形態的創造者,同時也是需求的監督者和編碼的指導員.
具有軟體具體表現的設計能力，他是系統分析的後續和細化，但為什麼不讓需求者進一步細化設計，這個理由我後面會說：如果沒有設計者，設計也不會消失，而是向需求或開發兩端轉移，一般是向開發轉移，設計和需求或開發合併會出現什麼問題，這個我後面會詳細闡述。
很多公司的美工會成隱性的軟體設計者，這個是有道理的，因為介面和人機互動的確是軟體設計最關鍵的一環。但我認為設計者最好還是具有一定的技術背景，無任何技術背景的設計者會給開發者帶來不小的困擾，所以我比較建議美工僅僅作為設計者的乙個外部資源來呼叫。
編碼者:
軟體的最終實現者。
編碼者的能力和事務我這裡不加累述了。大家都是對於開發都不陌生。
測試者軟體質量的守護神,需求,設計和編碼的監督者.
可以這麼說即使需求－設計－開發環節是無懈可擊的，測試者的作用依然是存在的，不同角度的需求驗證對軟體的質量起到定海神針的作用，況且，無懈可擊的開發流程，更象是乙個神話，不是嗎？
測試人員，需要具備測試的相關的工具和方法，他的主要責任是驗證需求的一致性，但很多時候他們會參與到技術糾正裡面去，如果出現了這種情況，他們就更顯得不可或缺，因為如果沒有他們，軟體的質量將會如何？
由上，我們可以得出乙個軟體團隊的標準：
有沒有管理
有沒有特定的構架
有沒有專業的需求人員
有沒有中層設計師
有沒有開發（這個不會沒有）
有沒有測試的最終防線，
以此6點，來了解乙個軟體團隊有沒有最基本的配備。
這些條件都極大的影響到了軟體的質量和專案的成敗。那麼如果達不到這些標準，是否軟體就沒辦法開展了呢，事實也不完全是這樣的，除了開發以外，軟體可以在缺少其他5人的狀態下完成，因為軟體開發是一項神奇的活動――請參考我的《引論-談下我的軟體和團隊之路》，但缺少任何一人，對軟體會造成什麼缺陷呢，請讓我慢慢分解：
無管理：整個開發是無序狀態的，開發團隊不受控制難於了解，難以了解專案的計畫和進度，無任何資訊輸出，大部分風險都無法迴避和減輕，各種團隊矛盾難以化解。
無構架：專案的技術風險無法欲知，很容易進入技術雷區，即使勉強度過也很容易留下隱患；每個開發的技術無法統一，造成專案技術選擇混亂，即使僥倖完成專案，該會在專案的維護過程中吃盡苦頭。最後一點，團隊的水平永遠無法提高。
無需求：軟體會迷失於開發者的自我想象，而大部分客戶都沒有確認需求的習慣，大家都希望做完了再看，看完了再改；而最後的結果是，導致開發成果與客戶預期偏差太大，大量修改返工，成本時間增加，程式設計師無窮壓力，導致團隊陷入泥潭，最終崩潰。
無設計：設計常常有實際開發者獨自完成，其質量，內容完全決定於個人，質量水平，設計標準無法統一，使得專案出現風格迥異，瑕疵不斷的尷尬局面，雖然可能不傷及根本，但難以稱專業。另外開發和設計具有互斥性，設計繁複必然導致開發困難，大多數開發人員，在個人技術弱點和技術難點上，常常趨利避害，簡化設計以減輕自身壓力，造成設計需求服從於開發需求，本末倒置。
無測試：智者千慮，必有一失；說的是即使開發者具有極強的自律和自檢能力，也需要乙個審核者的輔助，何況乙個連測試都不具備的團隊，其開發的自律和自檢能力不容樂觀，沒有測試大部分結局只能是錯誤百出。
下面我會陸續推出以下章節：
金剛合體和巨人肩膀： 討論不足6人的一些權益方法和我的看法
簡易團隊構建指南： 圍繞6人模式，來設想構建乙個簡單的開發團隊。
6人模式還僅僅是起步： 總結和一些感想。
軟體開發和團隊」最小模式」初探1
首先說個老實話,軟體開發是沒有什麼所謂最小模式的 如果可以我並不希望去嘗試所謂的最小模式 現在開開1 2萬的二手小車是沒辦法,並不代表我願意一輩子開這種車.cmmi3 認證要求最少有20人參加,其實是給出了乙個硬性的指標,要保證cmmi3所能達到了質量要求,大部分流程域是不能裁剪的,那麼就要保證有足...
軟體開發流程初探
一 瀑布模型 優點 缺點 二 增量模型 優點 缺點 三 螺旋模型 優點 缺點 unified process up 代表了一種軟體開發的主流方法，其三大特點是 1.受控的迭代式增量開發 允許在開發之初的不完整和不完美，但隨著迭代的推進，產品工件逐步趨向穩定 2.軟體開發是由用例驅動的 用例就是使用者...
小團隊軟體開發
軟體開發是自己的本行,這裡談談對乙個小團隊開發軟體的幾點思考 1 每個開發人員要對所要開發的東西在開發之前就要有一定的了解,最好是在開始的時候就把需求問的詳細一些,不要對著乙個全是文字的東西談需求,最好用圖形來互動,做軟體的都有個體會,往往到自己把介面做的差不多了,給使用者一看,使用者馬上就補充了一...