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

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

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

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

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

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

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

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

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

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

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

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

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

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

瀑布模型：（單向、不可逆）

硬件行業中：產品一般遵循：【分析->設計->實現（制造）->銷售->維護】的流程。

且一旦大規模生產，要再返回去修改時就非常困難，甚至是不可能的。

在設計大型系統時，要做相鄰步驟的回溯，解決上一階段未能解決的問題。

要讓產品成功，最好把這個模型走兩邊，先有一個模擬版本，在此基礎上收集反饋，改進各個步驟，並交付一個最終的版本。

用戶的及早介入、討論、復審是很重要的。要讓顧客正式的、深入的、持續的參與到項目中來。

軟件行業中的局限性：

①各步驟之間是分離的，但是軟件生產過程中的各個步驟不能這樣嚴格分離出來。

②回溯修改很困難甚至不可能，但是軟件生產的過程需要時時回溯。

③最終產品直到最後才出現。但是軟件的客戶，甚至軟件工程師本人都需要盡早知道產品的原型並試用。

適用範圍：

①產品的正確性非常重要，需要每一步的驗證。

②產品模塊之間的接口、輸入和輸出能很好的用形式化的方法定義和驗證。

③使用的技術非常成熟，團隊成員都很熟悉這些技術。

④負責各個步驟的子團隊分屬不同的機構，或在不同的的地理位置，不可能做到頻繁的交流。

第五章 團隊和流程