一種更加合理、高效、符合客觀規律的軟件開發團隊組成模式和工做方式

本文探討了一種更加合理、高效、符合客觀規律的軟件開發團隊組成模式和工做方式。做者經歷並帶領太小做坊開發、小團隊開發、五十人以上的團隊開發，也嘗試過瀑布、敏捷等開發形式，所以更多的着眼點是從實際經驗、從現實條件、從人的本性出發思考問題。

問題分析

在軟件開發領域中，資源的浪費是廣泛的。

其中一條重要的緣由在於沒有尊重客觀規律：要麼教條主義的學了幾本書、看了一些理論之後就妄圖付諸實踐；要麼是被客觀規律戰勝之後沉淪，連客觀規律都不肯意嘗試去理解。

也許下面做者的一家之言之後也被證實是癡人說夢，可是發現客觀規律、理解客觀規律、從客觀規律出發解決問題的思路毫不會是癡人說夢。

客觀規律是什麼？客觀規律就是：軟件做爲一個思惟的產物，是很難用工程的方法進行衡量和計算的。許多浪費就是勉爲其難套用了一些項目管理、工程實踐的方法形成的。

因此，與其把軟件開發看作是造樓房，不如把軟件開發視爲寫小說。看作造樓房，就會有許多加工人、趕進度的想法；視爲寫小說，就不太會有：「多加幾個做者天天多寫幾章出來」的奇葩要求。

所以，首先必須強調的是：軟件是思惟的結晶！

其次，國產程序員總體上來講的特色是，有較強的進取和自我學習精神，有必定團隊協做意願，可是廣泛內向、溝通能力、交流技巧欠缺。

最後，做爲一個開發團隊，必然存在新人加入、舊人離去、代碼移交、績效考覈等諸多現實問題。

一種可能手段

基於上述緣由，理想狀態下，針對1個軟件項目的1個高效的軟件開發團隊的組成只應該有3-5人：

• 船長角色：核心程序員x1，制定時間節點，構架設計和編碼，完成75%-65%的代碼量。

• 大副角色：程序員x1，按照指示編碼和對外溝通交流，完成20%代碼量，而且做爲船長的備份。

• 水手角色：程序員1-3人，按照需求測試，少許代碼維護和修改，完成5%-15%代碼量。

針對上述團隊形式的說明：

1. 這裏的1個軟件項目並不必定是傳統意義上的軟件系統。例如一套軟件系統是由iOS、Android和後臺組成的系統，則其中能夠算做包含了3個軟件項目。反過來，若是軟件功能不復雜，算成1個軟件項目也何嘗不可。事實上，合理準確地劃分好1個又一個軟件項目是很是關鍵的。

2. 關於計劃時間的評估問題，因爲軟件開發的過程當中須要相應的知識儲備、須要解決未知的技術性問題、須要填平一些看不到的「坑」，所以很難有固定的模式去計算，更多的須要依賴船長的經驗。

3. 若是船長表示沒法完成任務，須要慎重考慮兩種可能性：任務劃分的確不合理，或者此人能力不夠不適合當船長。若是船長表示能夠完成，可是須要遠超前述的水手角色，請參考前面兩種可能性。

4. 付出和回報必須對應，特別是主心骨，完成總體結構設計和最多代碼工做的人。

5. 因爲只討論軟件開發，所以設計師、產品經理等角色沒有說起，可是不表明這些角色不重要。

6. 人數能不能更多？能夠，可是儘可能避免。特別須要警戒其中是否存在資源浪費的可能。若是發現10我的都不夠用的狀況，就要認真考慮分爲2個項目2個團隊的可能性。

優點分析

1. 採用這種方式，最大的優點在於最大限度的減小了溝通的成本。

2. 使得未來的代碼重構、甚至結構調整都處於比較受掌控的範圍。減小冗餘代碼、重複代碼的出現可能性。

3. 最大限度激發成員的主觀能動性，調動開發人員積極性。流水線出來的只是能用的產品，而惟有激情創造的纔有可能成爲傑做。

難點分析

1. 成員能力不足以支撐這種結構，沒有人願意承擔主心骨的責任。這點須要合理的激勵機制來保證。

2. 系統龐雜之後，任務分割、團隊界限不清晰。這點儘可能依靠將含糊的邏輯部分放入惟一的軟件內部實現，避免在接口層面含糊。

後續手段

舉例說說一些手段來驗證一個軟件的開發是簡潔、易懂的：

1. 軟件可以全部功能，即：在軟件交付之後，按照全部需求文檔要求的功能均可以使用，包含性能要求

2. 每一行代碼/資源都是有效的，即：刪除任何一個源代碼包中的文件或者任何一行代碼，都會致使編譯錯誤或者運行bug（此處和軟件的擴展性是有衝突的，可是出於減小後續交接的複雜度的考量，能夠考慮捨棄）

3. 軟件的結構是容易理解的，即：整個軟件的框架設計能夠在15分鐘內被講解完畢，在此基礎上，每個具體的功能項能夠在5分鐘以內被講解完畢。講解完畢指面對有必定開發基礎、可是對該項目並沒有瞭解的開發人員，使他們明白軟件的基本結構。若是超過此程度，則軟件須要被劃分。

完。