Chapter 5 團隊和流程
Chapter 5 團隊和流程
一、非團隊和團隊
1.非團隊：只是一群烏合之眾，臨時聚集在一起。
2.團隊：①有一致的目標。
②成員不一定要同時工作。（如接力跑）
③成員有各自的分工，互相依賴合作，共同完成任務。一個人的工作對另一個人有影響。
二、軟件團隊的模式
適用於不同的人員和需求的團隊的各種形式。
1.一蜂窩模式：（比較混亂）
就是大家一哄而上去搶。可能是一個歡樂而隨意的模式。
2.主治醫生模式：（1主多從）
有一個主刀的人，還有其他幫助他的人。
也就是有一個首席程序員負責主要模塊的設計和編碼，其他人從各種角度支持他的工作（後備程序員、系統管理者、工具開發、編程語言專家、業務專家）
3.明星模式：（是主治醫生模式的升級版，就是明星能有團隊意識）
明星的光芒蓋過了團隊其他人的總和。
*明星也是人，也會有錯誤，如何讓團隊的利益最大化，而不是明星的利益最大化，如何讓團隊的價值在明星隕落之後仍然能保持？
真正有巨大成就的明星都能意識到團隊的作用。
說實話，不是很明白主治醫生模式和明星模式的區別？
4.社區模式：（人多，分工合作，保證質量，不隨意
社區由很多誌願者組成，每個人參與自己感興趣的項目，貢獻力量，大部分人不拿報酬。
好處：眾人拾柴火焰高，但是也要每個人均勻的分工合作，並且提高質量。
並不意味著“隨意”。
5.業余劇團模式：（每次每個人的角色不同，有導演）
在每一個不同的項目中，每個人挑選的角色也不同。
且每個人在團隊中聽從一個中央指揮（導演）的指導和安排。
6.秘密團隊：（神秘）
項目在秘密狀態下進行，別人不知道他們具體在做什麽。
好處：團隊內部有極大的自由，較高的熱情，沒有外界的幹擾（不用每周給別人介紹項目進展，聽領導的最新指示等）。
7.特工團隊：（有特殊技能的專業人士）
由一些有特殊技能的專業人士組成，負責解決一些棘手而又緊迫的問題。
現在還包括專門做網站安全性服務的團隊。
8.交響樂模式：（種類多，統一，執行力強）
家夥多，種類豐富。
各司其職。
有統一的套路（譜子），同時看指揮。
曲子練習了多次，重在執行。
9.爵士樂模式：（個性化，互動，創意）
同交響樂模式似乎有些相對。
沒有統一的譜子。
沒有現場指揮。
即興發揮。
強調個性化的表達，強有力的互動，對變化的內容有創意的回應。
10.功能團隊模式：（能力不同，平等，交流頻繁）
具備不同能力的同事們平等協作。
在一個功能完成後又重新組合，和別的角色一起去完成下一個功能。
沒有管理和被管理的關系。
小組內的交流比較頻繁。
11.官僚模式：（領導和被領導）
幾個人報告給一個小頭目，幾個小頭目報告給中頭目，依次而上。
成員之間不光有技術方面的合作和領導。
組織上有領導和被領導的關系。
跨組織的合作變得比較困難，因為各自頭頂上都有不同的老板。
三、開發流程
一群人一起做軟件開發的方式方法。
1.寫了再改模式：（適用於小場面的一些程序）
就是不管三七二十一，先寫了再說，如果有問題就再改動不斷的進行修改。
好處：不需要太多其他準備或相關知識，大家上來就寫代碼，也許就能寫出來，寫不出來就改，也許能改好。
eg.只用一次的程序，看過就扔的程序，一些不實用的程序。
壞處：在要寫到比較有實際用戶、解決實際需求的軟件時就不適用了。
2.瀑布模型：（單向、不可逆）
硬件行業中：產品一般遵循：【分析->設計->實現（制造）->銷售->維護】的流程。
且一旦大規模生產，要再返回去修改時就非常困難，甚至是不可能的。
在設計大型系統時，要做相鄰步驟的回溯，解決上一階段未能解決的問題。
要讓產品成功，最好把這個模型走兩邊，先有一個模擬版本，在此基礎上收集反饋，改進各個步驟，並交付一個最終的版本。
用戶的及早介入、討論、復審是很重要的。要讓顧客正式的、深入的、持續的參與到項目中來。
軟件行業中的局限性：
①各步驟之間是分離的，但是軟件生產過程中的各個步驟不能這樣嚴格分離出來。
②回溯修改很困難甚至不可能，但是軟件生產的過程需要時時回溯。
③最終產品直到最後才出現。但是軟件的客戶，甚至軟件工程師本人都需要盡早知道產品的原型並試用。
適用範圍：
①產品的正確性非常重要，需要每一步的驗證。
②產品模塊之間的接口、輸入和輸出能很好的用形式化的方法定義和驗證。
③使用的技術非常成熟，團隊成員都很熟悉這些技術。
④負責各個步驟的子團隊分屬不同的機構，或在不同的的地理位置，不可能做到頻繁的交流。
3.瀑布模型的各種變形：
1）生魚片模型（各相鄰模塊像生魚片那樣部分重疊）：
解決了各個步驟之間分離的缺點，但也有問題：上一個階段什麽時候結束的？
2）大瀑布帶著小瀑布（步步嵌套）：
解決不同子系統之間進度不一，技術要求迥異，需要區別對待的問題。
要把各個子系統統一到最後做系統測試，用戶只有到了最後才能看到結果。
4.統一流程（RUP）：
從瀑布模型開始的各種模型都有一個共同點：重計劃，重事先設計，重文檔表達。
團隊的各種成員要在不同階段做不同的事情，這些不同類型的工作在RUP中叫做規程或工作流。
包括：業務建模。
需求。
分析和設計。
實現。
測試。
部署。
配置和變更管理。
項目管理。
環境。
RUP四個階段：
①初始階段。分析軟件系統大概的構成。（開始階段）
②細化階段。分析問題領域，建立健全的體系結構基礎，編制項目計劃，按優先級處理項目中的風險。（具體的去做）
③構造階段。開發出所有的功能集，把功能集成為經過各種測試驗證過的產品。什麽是功能集？？？
④交付階段。確保軟件能滿足最終用戶的實際需求。
5.老板驅動的流程：（ 由行政領導主導或是公司老板驅動。）
原因：老板的能力決定了一個團隊是否能獲得訂單。
在大型企業內部，軟件功能往往由行政體系來決定。
有些老板比一般人更懂市場和競爭。
軟件團隊尚未成熟。
缺點：領導對很多技術細節是外行。
領導未必懂得軟件項目的管理很有可能太過權威性。
領導管理是行政命令。
領導精力有限。
6.漸進交付的流程：（開發->發布->聽取反饋->根據反饋做改進）不斷的循環
（直到）軟件最後完成： 時間到了，錢花光了，用戶滿意了（或是不滿意不繼續給錢）。
但有問題是：產品團隊得到用戶的反饋太晚了。
MVP(最小可行產品，最小功能集)：
把產品最核心的功能用最小的成本實現出來，然後快速征求用戶的意見。
指導思想與漸進交付相似，但是更強調更早獲得用戶反饋，為此可以在產品完成之前就發布，
也強調產品的核心價值，為了突出核心功能，不考慮輔助功能。
MBP(最強最美產品)：
對用戶的需求了然於心，或者產品團隊比用戶更了解用戶的需求。
7.TSP（Team Software Process）的原則：
①流程中的每一步都是可以重復、可以衡量結果的。
②各個成員對團隊的目標，角色，產品都有統一的理解。
③盡量使用成熟的技術和做法。
④盡量多的收集數據。
⑤指定切實的計劃和承諾。計劃要由具體執行的角色來制定。
⑥增加團隊的自我管理能力。
⑦專註於提高質量。
Chapter 5 團隊和流程