軟體開發和團隊”最小模式”初探2－6人模型（上）

6人模型

上一篇文章說到了“2條主線和4個步驟”；那麼順理成章的，我的軟體開發和團隊“最小模型”就是6人模型。在展開6人模型以前，我必須闡明以下幾個觀點作為6人模型的總則：

l 首先，我之所以要用6人而不是6角色，就是想暗示我認為6人各自獨立的必要性，而反對合并和兼職（雖然我對兼職也有一定的理解――請查看以後的章節：金剛合體和巨人肩膀），我認為6人可以不必全程參與，但不要合二為一。

l 6人是最小模型，6人缺一不可，缺一則傷及軟體品質的根本，或者說，軟體品質會減低到我能容忍的極限以下，但是否達到我的品質標準不等於軟體成功的標準，這個大家要有清楚的認知。

l 6人具有各自的專業領域，各自有獨特的方向和技能。也許我們的團隊暫時找不到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人的狀態下完成，因為軟體開發是一項神奇的活動――請參考我的《引論-談下我的軟體和團隊之路》，但缺少任何一人，對軟體會造成什麼缺陷呢，請讓我慢慢分解：

無管理：整個開發是無序狀態的，Team Dev不受控制難於瞭解，難以瞭解項目的計劃和進度，無任何資訊輸出，大部分風險都無法迴避和減輕，各種團隊矛盾難以化解。

無構架：項目的技術風險無法欲知，很容易進入技術雷區，即使勉強度過也很容易留下隱患；每個開發的技術無法統一，造成項目技術選擇混亂，即使僥倖完成項目，該會在項目的維護過程中吃盡苦頭。最後一點，團隊的水平永遠無法提高。

無需求：軟體會迷失於開發人員的自我想象，而大部分客戶都沒有確認需求的習慣，大家都希望做完了再看，看完了再改；而最後的結果是，導致開發成果與客戶預期偏差太大，大量修改返工，成本時間增加，程式員無窮壓力，導致團隊陷入泥潭，最終崩潰。

無設計：設計常常有實際開發人員獨自完成，其品質，內容完全決定於個人，品質水平，設計標準無法統一，使得項目出現風格迥異，瑕疵不斷的尷尬局面，雖然可能不傷及根本，但難以稱專業。另外開發和設計具有互斥性，設計繁複必然導致開發困難，大多數開發人員，在個人技術弱點和技術痛點上，常常趨利避害，簡化設計以減輕自身壓力，造成設計需求服從於開發需求，本末倒置。

無開發：這個大家都很清楚是不可能的，不加累述。

無測試：智者千慮，必有一失；說的是即使開發人員具有極強的自律和自檢能力，也需要一個審核者的輔助，何況一個連測試都不具備的團隊，其開發的自律和自檢能力不容樂觀，沒有測試大部分結局只能是錯誤百出。

 

下面我會陸續推出以下章節：

金剛合體和巨人肩膀： 討論不足6人的一些權益方法和我的看法

簡易團隊構建指南： 圍繞6人模式，來設想構建一個簡單的Team Dev。

6人模式還僅僅是起步： 總結和一些感想。