謝謝大家能來看我的博客，這是我第一次寫博客，大概也會石沈大海吧。但我會逐漸成長，寫出更優秀的博客。

那麽下面開啟正文吧。

　　《構建之法》一書面向初級程序開發者，講述個人開發、小組開發、團隊開發中所要註意到的問題。有助於本學期軟工課程的機會，我第一次能夠擔任一個較大小組（8人）的組長，並帶領大家完成自己的小項目。但我深知自身的管理知識是非常貧乏的，又因本書章節很多，所以我特別挑選了幾個章節借鑒經驗，並且遴選了最有意義的兩個章節將精華部分記錄下來與大家分享。

第5章團隊和流程

團隊模式問題是由人數漸增而產生的，2、3人的團隊大多不需要多少事前規劃就可以沒有多少沖突地將事情解決，而人數漸增所帶來的角色、任務分配問題幾乎無法避免

1、團隊模式：軟件團隊有各種形式，適用於不同的人員和需求，有幾種較為流行的模式及其優劣如下：

1）主治醫生模式：首席程序員負責處理主要的設計和編碼，其他人從各個方面協助其工作。

優：最大限度發揮首席程序員的能力。

劣：“明星”也是人，也會受傷、犯錯誤。

評：如何讓團隊的利益最大化，而不是“明星”的利益最大化？（IBM SYSTEM 360）

2）社區模式：由許多誌願者參與，每個人參與自己感興趣的項目，大部分人不拿報酬。

優：眾人拾柴火焰高。

劣：如果大家不願拾柴或柴火質量差，最後火就滅了。

評：成功的社區項目需要很嚴格的代碼復審和質量控制。（Linux操作系統）

3）秘密團隊模式：一些軟件項目在秘密狀態下進行，別人不知道他們具體在做什麽。

優：團隊內部有極大自由、較高熱情、較少外界幹擾。

劣：士氣會隨著時間推移而下降。

評：若發揮得好，很大的驅動力能讓團隊發揮超高的效率。（蘋果研發Macintosh之後的系統）

4）交響樂模式

優：門類齊全、各司其職。

劣：進行的都是很有經驗的項目。

評：適合大規模的，有明確任務細分的軟件工程。（Office97~2013…）

5）功能團隊模式：具備不同能力的同事們平等寫作，共同完成一個功能（Dev、UX、AQ、PM）。在一個功能完成後，這些人又重新組織，共同完成下一個功能。

優：每個小組都是一個有自主權的單元，自由度高而帶來了開發時的高效。

劣：零散的小團隊就要求團隊間需要頻繁的交流，從而一定程度上降低效率。較高的自由度不適用於一些等級制度森嚴的公司。

評：很多公司最後都會演變為這一模式，能充分利用每一個人的能力，整體團隊分工又不死板。（FORTRAN語言項目）

2、開發流程：一群人一起開發軟件，必定需要有一定的流程，否則一窩蜂地毫無章法地幹，最後有可能做成，但也是一堆沒有意義的程序。開發流程的選擇關乎到軟件開發的效率、容錯程度、開發周期、對風險的規避能力。

1）瀑布模型：將硬件開發領域的分析->設計->實現->銷售->維護運用到了軟件工程中，先有一個模擬版本，在此基礎上收集反饋，再走一次流程，最後交付最終版本。

優：1）各個階段非常明晰，更容易把握項目的進展。

2）不需要頻繁的交流。

劣：1）最終產品出現過晚，各個階段相互獨立，難以應對客戶變化的需求。

2）各個過程難以回溯，但軟件生產過程中需要時時回溯。

評：適用於客戶要求非常穩定、技術人員較為分散、團隊成員對所用的技術非常熟悉的情況。

2）統一流程：在系統的主要需求和架構明確之後，軟件團隊進入了一個不斷演進的循環中：【開發->發布->聽取反饋->根據反饋做改進】。為了早日聽取客戶的意見，把產品最核心的功能用最小的成本實現出來，然後快速征求用戶意見。

優：1）能盡快地聽取客戶的意見，及時糾正軟件開發的走向，規避風險。

劣：1）不適用於創造性、顛覆性的技術開發。

2）過早地發布可能帶來更激烈的商業競爭。

評：這是很實用的流程，尤其適用於高校內尚不成熟的學生在規定時間內開發代碼，不斷地更新換代保證了時刻有可以交付的版本。當然這不是說就不適用於大企業的開發，微軟的MSF模型正是來源於這一構想。

第7章實戰中的軟件工程

分析實戰中的軟件工程，莫過於分析最成熟的大公司的開發過程。本章選取了經典的微軟公司的MSF模型進行分析，從它的基本原則、團隊模型、過程模型入手，描述了微軟開發團隊內的開發精神、開發方式、開發過程。

基本原則：

一、推動信息共享與溝通：

1、 在整個軟件生命周期中使用團隊協作服務器（GitHub或TFS），推動信息共享。

2、 借助於以上平臺，團隊成員之間的交流簡明扼要即可。

3、保留並公開所有的信息，以便讓項目進度和項目中存在的問題及時為所有人知道。

二、為共同的遠景而工作：

1、 在設定項目時，所有成員需要明確項目的預期目標，統一思想，否則團隊內的分歧會隨時間而累加，對項目的發展是很有害的。

三、充分授權和信任：

1、 微軟的MSF團隊模型就是建立在兩個原則之上：1）平等協作2）充分授權給團隊和成員。

優：每個人都有權利估計並決定自己的任務需要的時間，所以人人都會支持計劃和時間表。

劣：充分的授權可能會導致倦怠的滋生，不停地追蹤會加重主管的負擔。

評：在團隊工具VSTS的幫助下，所有工作的進展都記錄在案（這也是要推動信息共享的原因），任何延遲都會被及時發現。當然授權的管理理念又和一些集權類企業格格不入。

四、重視商業價值，提供漸進的價值

1、 首先，團隊需要明確1）產品解決的問題2）為誰解決問題3）為什麽你的產品能解決這些問題4）客戶怎樣付錢讓你解決問題。因為項目需要重視市場和客戶，技術是處於第三位的。

五、重視商業價值需要保持敏捷，預期和適應變化

1、項目需求的生存期是有限的，一旦開發過久，需求可能已經發生了很大的變化，而一個經驗值是18個月。

2、客戶的需求也是會變化的，我們需要預期變化而不是期望變化，這對開發流程和團隊模式也帶來了挑戰。

六、在變化中需要抓住投資價值

1、投資講究效率。我們並沒有提質量第一，而是解決用戶的問題第一，不惜一切代價達到最高質量往往錯過了最佳的發布時機，而大型項目發布後追蹤式的修補也是允許的。

2、投資講究時機。為了盡量在產品中減少上述中的bug，1）在構想時充分討論各種可能缺陷2）發展與測試應該並行發展。3）為迎合客戶的時間需求，可以有針對性地取舍功能。

七、投資是長期的。

1、團隊的成長、成熟需要時間，生搬硬套大公司的開發模型與團隊構成大多是南橘北枳。

團隊模型：

在MSF團隊模型中，每一個部分都是非常重要的，任何一個角色無法實現其目標都會危及整個項目。這也和微軟內部的理念相契合，即：每個成員之間都是平等的。

這樣的團隊中，需要的是直言不諱，例如為了團隊方案的爭吵、因為產品質量而不贊同增加功能，每個人都參與設計規劃、具體執行是指導思想，在對立中尋找共同利益，在沖突中達到平衡是團隊的目標。

MSF過程模型

每一個項目都要經過一個生命周期，圖示是MSF過程模型的生命周期簡圖，它吸收了瀑布模型基於裏程碑的規劃優勢和漸進式交付的不斷完善的長處。

優勢：裏程碑式的規劃：團隊裏用裏程碑來檢查工作和同步各個角色的進度。

漸進式交付的不斷完善：利於盡快交付產品，獲得內外反饋。

劣勢：各個階段並不是理想化的，但可以通過設置緩沖區，不需要強求一律，但可以通過統一整體步驟，從而調節好團隊間的依賴關系。

評：這是一個內外兼顧的模型，既考慮了外部的客戶因素，又考慮了內部的成員間相互依賴的關系。

讀書筆記——《構建之法》