團隊有一致的集體目標，團隊要一起完成這目標。一個團隊的成員不一定要同時工作，例如接力賽跑。

團隊成員有各自的分工，互相依賴合作，共同完成任務。

軟件團隊有各種形式，適用於不同的人員和需求。基於直覺形成的團隊模式未必是最合適的。軟件團隊的模式，最初是混沌的一窩蜂形式：一群人開始寫代碼，希望能寫出好軟件。隨著團隊的成熟和環境的變化。

團隊模式會演變成下面幾種模式之一。

1.主治醫師模式：有首席程序員，他/她負責處理主要模塊的設計和編碼，其他成員從各種角度支持他/她的工作（後備程序員、系統管理員、工具開發、編程語言專家、業務專家）。

2.明星模式：讓團隊的利益達到最大化

3.社區模式：每個人參與自己感興趣的項目，貢獻力量，

4.業余劇團模式：這樣的團隊在每一個項目中，不同的人會挑選不同的角色。但都聽從一個指揮的指導和安排。

5.秘密團隊： 團隊內部有極大的自由，沒有外界的幹擾，不用每周給別人介紹項目進展，聽領導的最新指示，團隊成員有極大的投入。

6.特工團隊：軟件行業的一些團隊由一些有特殊技能的專業人士組成，負責解決一些棘手而有緊迫性的問題。

7.交響樂團模式：家夥多，門類齊全。 各司其職，各自有專門場地，做項目期間沒有聊天、走動等現象，同時看指揮的，重在執行。

8.爵士樂模式：和上面的“交響樂團模式”在很多方面都對立，但不能簡單地說孰優孰劣。

9.功能團隊模式：具備不同能力的同事們平等協作，共同完成一個功能。

10.官僚模式:脫胎於大機構的組織架構，幾個人報告給一個小頭目，幾個小頭目報告給中頭目，依次而上。跨組織的合作變得比較困難，因為各自頭頂上都有不同的老板。

瀑布模型：這個模型描述了單向的、不可逆的生產過程。

軟件團隊進入了一個不斷演進的evolution循環中：[開發→發布→聽取反饋→根據反饋做改進]

這個軟件什麽時候才最後完成呢？

1.時間到了。

2.錢花光了。

3.用戶滿意了。

我們能否讓用戶更早地給產品團隊反饋？

MVP方法：Minimal Viable Product，最小可行產品，又稱為Minimal Feature Set，最小功能集。

具體的做法是：把產品最核心的功能用最小的成本實現出來（或者描繪出來），然後快速征求用戶意見。

我覺得團隊模式需要成員之間相互協作，成員間不一定要同時工作，但是是互相依賴著完成的，共同完成任務。我們做項目給用戶使用，當用戶看到第一個版本的時候，他們就對這個產品很不滿意，完全沒有任何購買或使用的意願。在這種情況下，整個團隊為第一版所做的各種投入都浪費了，是因為產品團隊得到用戶的反饋太晚了。所以我們就要用到MVP方法，用最小的成本實現最核心的功能，是我們所追求和向往的。

讀構建之法 第五章：團隊和流程