構建之法閱讀筆記05--團隊和流程
團隊和流程
這一章主要講述團隊的軟體團隊模式和開發流程。還有他們的優缺點。
一．團隊模式。
文章中介紹的團隊模式有很多種，這裡只選取其中的幾種來描述。
1.一窩蜂模式
最混亂的一種模式，存活時間不會很長。
2.主治醫師模式
就跟在手術台一樣，有乙個主刀醫師，其他人為主刀醫師服務。退化後會成為「一人幹活，其餘人跟著打醬油」。
3.明星模式
主治醫師模式運用到極致後是明星模式，明星模式的光芒蓋過了其他人的總和。這個往往會忽略團隊的作用。
4社群模式
是有很多志願者參與，每個人參與自己感興趣的專案，貢獻力大，大部分人不拿報酬，但是有可能會使專案的質量不高。
5**團隊
需要軟體團隊解決一些非常棘手而且緊迫的問題。
6功能團隊模式
很多軟體公司的團隊最後都演變成功能團隊，就是具備不同能力的同事們平等協作，共同完成乙個功能。
總結1：
我在以前還沒有接觸到過折磨多的團隊模式，我所能想到的就是主治醫師模式，由乙個有經驗的人帶領整個團隊，這樣可以有計畫的完成一項工程，一人幹活，其他人打醬油，這也是可以理解的，因為其他人有可能並不了解整個工程，所以很容易自甘墮落，只有幹活的人自己知道需要做什麼，這樣對於整個團隊的進步和成長是相當不利的。
我感覺這公司中的功能團隊是比較普遍的，這符合人盡其能的準則，每個員工都有自己擅長的地方，可以穩定的交付自己所負責的工程，這樣的團隊比較靠譜。
二．開發流程
1.寫了再改模式
2.瀑布模式
這個模式是單向和不可逆的。
流程：分析-》設計-》實現（製造）-》銷售-》維護。
改進後：系統需求《=》軟體需求《=》分析《=》程式設計《=》編碼《=》測試《=》執行。
3.rational unified process統一流程（rup）
rup把軟體開發的各個階段整合在乙個統一的框架內，要完成乙個複雜的軟體專案，團隊的各種成員要在不同階段做不同的事情，這些不同型別的工作在rup中叫做規程或者工作流。
流程：業務建模，需求，分析和設計，實現，測試，部署配置和變更管理，專案管理，環境。
四個階段：初始階段（分析軟體系統大概的構成），細化階段（分析問題領域，建立健全的體系結構基礎），構造階段（在這一階段，團隊開發出所有的功能集，並把功能集成為經過驗證過的產品），交付階段（團隊的重點是確保軟體能滿足終端使用者的實際需求）。
總結：正規的流程應該是第三種這樣的模式，我們以前的水平其實就是寫了再改的模式，想到那就寫到哪，感覺著離題了在進行修改，這屬於沒有計畫的完成，對整個工程和專案沒有乙個明確的把握和認識，這種模式對於我們的程式設計和以後得架構設計都是相當不利的。正確的方式應該是rup模式，在進行程式設計之前，要在頭腦中有乙個印象，能把當時的使用者場景模擬出來，然後針對各個功能進行完整和系統的設計，這樣的模式才是最好的。
建議：在老師規定任務以後，多花一些時間去想一想完整的過程，將思路理清，在紙上寫寫畫畫，先想清楚在寫的效果絕對要比沒有頭緒想起神魔寫神魔效果要好得多。
構建之法第五章
構建之法第五章 本章為團隊和流程，主要介紹了典型的軟體團隊模式和開發流程以及它們的優缺點 tsp mvp mbp rup團隊 並不是幾個人湊到一起就叫團隊，稱之為團隊 1 應該有一致的集體目標，團隊要一起完成這目標 2 團隊成員有各自的分工，互相依賴合作，共同完成任務 軟體團隊的模式 1 主治醫師模...
構建之法 第五章讀書筆記 團隊模式和開發流程
這一章主要敘述了軟體開發的團隊模式和開發流程。團隊模式 團隊結構 主要解決團隊間交流效率的問題 開發流程主要關注團隊在結構確定的情況下，具體開發軟體的流程。請注意 就像其他方 一樣，每個模式和流程都有其優缺點和適用情景，學習的時候可以結合實際工作所在的團隊，使用本章的知識觀察團隊的模式和開發流程，最...
閱讀構建之法讀後感第五章
軟體的設計與實現。一 我們寫軟體就是為了解決使用者的需求，我們要表達和傳遞下面的這些資訊。在問題解決中的現實世界裡，都有哪些實體，如何抽象出我們真正關心的屬性，實體之間的關係是什麼，在這個基礎上，使用者的需求是什麼，軟體如何解決使用者的需求。在 設計與實現段 我們要搞清楚軟體如何解決這些問題的需需求...