【9.18 ~ 9.24】我們組第一周共同學習了《構建之法》，并總結出大致關鍵點，經修改整理發表如下。 【9.25 ~ 10.1】修改問題并重新整理。

團隊學習：《構建之法》

• 【團隊成員】：

【本次團隊貢獻及完成度】

• 團隊組長：袁逸灝
  本次編輯：劉偉康

• 【步驟】合作分工 → 大致內容框架 → 提出問題

團隊貢獻及完成度

第 1 章 概論

• 1.1 軟件 = 程序 + 軟件工程
  軟件工程的核心部分（狹義，廣義）、軟件工程的地位、軟件開發不同階段的不同表現。

• 1.2 軟件工程是什么
  軟件工程的定義、軟件工程所包含的領域、軟件開發的難點、工程的定義、軟件工程并不等于計算機科學，兩者有著不同的側重點，軟件工程的知識領域，軟件工程的目標，初步學會軟件工程需要達到的要求。

第 2 章 個人技術和流程

• 2.1 單元測試
  保證覆蓋率為100%，好的單元測試的標準，單元測試可以提高軟件開發的效率，回歸（回歸到以前不正常的狀態）測試。

• 2.2 效能分析工具：Visual Studio（抽樣、代碼注入）
  不經分析就盲目優化，也許會事倍功半。

• 2.3 個人開發流程（PSP）
  PSP任務清單（大學生VS工程師），PSP的特點。

• 2.4 實踐
  當前程序設計作業簡單，無太多擴展、擴展的方面、做項目的時候需要對項目的處理；
  開放 – 封閉原則：允許擴展，不允許修改。

第 3 章 軟件工程師的成長

• 3.1 個人能力的衡量與發展
  個人能力在團隊中的作用與影響、個人應當承擔的責任、個人的成長記方式。

• 3.2 軟件工程師的思維誤區
  不要總想著在短時間內搞個大新聞，要結合自身實際，求穩，然后再擴展。

• 3.3 軟件工程師的職業發展

• 3.4 技能的反面
  注重自己的技術，要避免懂得“技術”但仍然經常犯一些低層次的問題。

第 4 章 兩人合作

• 4.1 代碼規范（風格、設計）

• 4.2 代碼風格規范（簡明、易讀、無二義）
  縮進（4個空格）、行寬、括號、斷行與空白的{}行（每個{和}獨占一行）、分行、命名、下劃線、大小寫、注釋（What、Why）。

• 4.3 代碼設計規范
  函數、goto、錯誤處理（參數處理、斷言）、處理類。

• 4.4 代碼復審（自我、同伴、團隊）
  為什么（早發現早修復、互相了解）、步驟、核查表（概要、效能、可讀性等）。

• 4.5 結對編程（極致）
  為什么（高投入產出比）、不間斷地復審、角色互換。

• 4.6 兩人合作的不同階段和技巧（萌芽、磨合、規范、創造、解體）
  影響他人的方式、正確反饋（多層次）。

第 5 章 團隊和流程

• 5.1 非團隊和團隊
  非團隊（獨立、烏合之眾）、團隊（共同目標、合作）。

• 5.2 軟件團隊的模式（窩蜂模式）
  主治醫師、明星、社區（眾人拾柴火焰高）、業余劇團（不同角色）、秘密團隊（無干擾）、特工團隊（高手）、交響樂團（各司其職）、爵士樂（個性化表達）、功能團隊（小組交流）、官僚（不提倡）。

• 5.3 開發流程（統一體系）
  寫了再改、瀑布模型（分析-->設計-->實現-->銷售-->維護）、統一流程、漸進交付（MVP）、TSP原則

第 6 章 敏捷流程

• 6.1 敏捷的流程簡介（找出待解決的問題 --> 決定當前目標 -->沖刺（每日例會）--> 改進）

• 6.2 敏捷流程的問題和解法（計劃：體現依賴關系-->描述細化到技術層面 --> 跟蹤三個時間 --> 總結教訓）

• 6.3 敏捷的團隊
  自主管理（自己挑選任務）、自我組織（聯合負責）、多功能（全面負責）。

• 6.4 敏捷總結
  質量控制、短時間迭代、極致編程、經驗教訓。

• 6.5 敏捷的問答
  敏捷是一種價值觀、總結思想、最佳實踐TDD、適用范圍、宣言（左項）。

第 7 章 MSF

• 微軟解決方案框架（Microsoft Solution Framework，MSF）,是微軟公司通過吸取各部門積累的業務經驗并隨著時代更新的軟件開發方法。其主要原則有9點：推動信息共享與溝通、為共同的遠景而工作、 充分授權和信任、各司其職，對項目共同負責（不僅要完成本職工作，更要對項目負責）、重視商業價值、保持敏捷，預期變化、投資質量（投資的效率，時期并要求長期）、學習所有的經驗（要堅持總結和分享）、與顧客合作（從用戶角度出發）。

• 用戶調研（User Study），A/B測試，通過態度、行為、定性、定量來規范調研的尺度。
  

第 8 章 需求分析

• 軟件需求
  將需求進行分類、清楚軟件產品的利益相關者、獲取用戶需求（用戶調研）、競爭性需求分析的框架、功能的定位和優先級、目標估計和決心、找出估計后面的假設、最后分而治之。

• 經驗公式： Y = X ± X ÷ N
  工程師的經驗公式實際時間花費主要取決于兩個因素—對 某件事的估計時間X，以及他做過類似開發工作的次數N。

• 提案，評估和WBS
  NABC model（N--need需求、Approach--做法、Benefit--好處、Competitors--競爭、Delivery--推廣方式）
  評估：目標（根據實際的需求來定）、決心（它承諾在特定日期交付預定義的功能，作為特定的質量級別）、估計（單個任務花費的人力、時間）
  WBS – Work Break Down
  分而治之，頂層（產品）→中層（功能）-用戶視角→較低級別（功能實現）-團隊透視圖（PM，test）→最低級別（模塊）-開發透視圖

第 9 章 項目經理

• 風險管理
  第一步：確認風險、根據不同的來源對風險進行分類；
  第二步：分析和優先級劃分；
  第三步：計劃和管理風險
  應對風險的方法：進一步研究、接受、 規避、轉移、 降低、制定應急計劃

• 項目經理（PM），PM負責除產品開發和測試之外的所有事情，包括正確地做產品和正確地做流程。
  PM的作用：收集需求、設計用戶界面，編寫規范、協調市場、文檔、測試、定位、帶領團隊達成決策
  【注】項目經理是和大家平等工作，并且做具體工作，和其他團員一起形成決議，只管事不管人的，和領導型經理是不一樣的。

第 10 章 典型用戶和場景

一、典型用戶

• 1.典型用戶
  定義： 描述了一組用戶的典型技巧，能力，需要，工作習慣和工作環境。
  電影用戶的角色：也有受歡迎的和不受歡迎之分。
  典型用戶的完善：定義了一部分典型用戶后繼續與其中代表進行溝通，進一步完善需求理解。

• 2.從典型用戶到場景
  場景：也可以是故事，用戶為達到目標使用系統時經歷的所有過程。
  場景的使用：設計者模擬用戶，設計一個場景入口，描述用戶在這個場景的內外部因素，給場景劃分優先級并寫場景。

• 3.從場景到任務
  分層：沿著子系統/模塊的所屬關系把場景劃分開。（例如：P221.UI層，邏輯層，數據庫）
  任務與場景：不同的任務將會把一個場景編織起來，得到開發任務后，可以創建和分配測試任務。

二、用例(Use Case)

• 1.用例：與典型人物，典型場景的方法類似，同樣是很常用的需求分析工具包含這樣的一些基本元素：標題，角色，主要成功場景，步驟，拓展場景。
  用例的原則：

  • 1.通過簡單的故事來傳遞信息。
  • 2.保持對全系統的理解。
  • 3.關注用戶的價值。
  • 4.逐步構建整個系統，一次完成一個用力。
  • 5.增量開發，逐步構建整個系統。
  • 6.適應團隊不斷變化的需求。

• 用例的局限性：
  1.比較適合故事/人物/場景交互的系統。但是對于算法，速度，拓展性，安全性以及和系統技術相關等需求則不適用。
  2.故事的粒度沒有統一標準與具體項目有關，初學者較難掌握。
  3.既要把UI的細節嵌入每個故事，又要保證其簡明性是一個難題。

三、功能說明書（Spec）

• 1.規格說明書
  軟件功能說明書：說明軟件的外部功能和用戶的交互情況。（軟件是一個黑盒子，看不到內部）
  軟件技術說明書：又稱設計文檔，說明軟件的內部的設計規范。（透明盒子）

• 2.功能說明書
  從用戶的角度描述軟件產品的功能，輸入，輸出，界面，功能的邊界問題，功能的效率（to user），國際化，本地化，異常情況等，不涉及軟件內部的實現細節。

• 3.制定一份Spec
  定義好相關的概念，規范好一些假設；避免一些誤解，界定一些邊界條件（定性且定量）；描述主流的用戶/軟件交互步驟；一些好的功能還會有副作用，服務質量的說明。

• 4.Spec的弊端
  枯燥乏味，無法跟上時間的變化。

• 5.技術說明書
  設計文檔，用于描述開發者如何趨勢線某一功能，或相互聯系的一組功能。實現軟件功能沒有固定的模板，但總存在著一些規律。

四、功能驅動的設計

• 設計過程：
  構造總體模型 --> 構造功能列表 --> 制定開發計劃 --> 功能設計階段5實現具體功能

第 11 章 軟件設計與實現

一、分析和設計方法

• 1.四個過程：

  • 1.需求分析：抽象出我們真正關心的屬性，實體之間的關系。用戶的需求，如何解決？
  • 2.設計與實現階段：軟件如何解決這些需求，現實生活中的實體和屬性在軟件系統中怎么表現和交換信息？
  • 3.4.測試,發布階段：真的解決了這些需求嗎，軟件解決需求的效率如何，用戶還有什么新的需求嗎？

• 2.常用方法：
  文檔、圖形為主構造的模型（思維導圖，流程圖等）、數學語言的描述、用類自然語言 + 代碼構造的描述（Literate Programming）、源代碼加注釋描述。

二、圖形建模和分析方法

• 表達實體和實體的關系
  思維導圖、實體關系圖、ERD.UCD；表達數據的流動、表達控制流、統一的表達方式（UML）。

三、其他設計方法

• 1.形式化的方法：用無歧義的，形式化的語言描述我們要解決的問題，然后用嚴密的數學推理和交換一步步把軟件實現出來，或者證明我們的實現的確完整和正確地解決了問題。
  2.文學化編程：與“寫程序，時不時寫一些注釋”相反,“寫文檔，時不時寫一些代碼。”

四、從Spec到實現

• 1.預估開發時間
  2.寫一些快速成型代碼，看看成效，查找問題。
  3.看到初始效果與了解實現細節后，開始寫設計文檔，并與同事進行復審。
  4.按照設計文檔寫代碼，解決遇到的問題。
  5.寫好代碼后先根據設計文檔與代碼指南進行自我復審，重構代碼。
  6.重建或更新單元測試。
  7.得到一個可以測試的版本，交予相關測試人員測試或者公開測試。
  8.修復測試中發現的問題。
  9.根據代碼復審的意見修改代碼，完善單元測試和其他相關代碼，把新的代碼簽入到數據庫中。

• 2. 把修改集集成到代碼庫中
  根據場景和開發任務來決定集成的次序、互相依賴的任務要一起集成。
  在測試場景時，要保證端對端的測試。
  場景的所有者必須保證場景完全通過測試，然后把場景的狀態改為“解決”。

• 3.開發人員的標準工作流程（如下圖所示）
  

五、開發階段的日常管理

• 1.閉門造車（Leave me alone）：集中于某一件事情，將自己投入其中，拒絕其他人的干擾。
  2.每日構建（Daily Bulid）：打好基礎，精益求精。
  3.“構建大師”：對于一個導致構建失敗的成員，授予這個稱號，并讓他：
  負責管理構建服務器 --> 調試構建，負責找錯，并分析出錯的原因 --> 將這個稱號和責任交予下一位導致構建失敗的成員 --> 構建大師為團隊“構建之法基金”存入50元，以供大家團隊構建之用。
  4.寬嚴皆誤：制定寬嚴標準，以及根據團隊的情況（勢）所反映的情況。成員行為影響個人的盡量寬松，而影響團隊的則要嚴格處理。
  5.小強地獄（Bug Hell）：類似于構建大師的選取：選出那些超過bug數標準的成員，讓他們進入小強地獄專職于小強地獄處理bug，直到滿足標準出獄，每周公布進出獄名單。

六、實戰中的源代碼管理

• 軟件 = 程序 + 軟件工程
  軟件的質量 = 程序的質量 + 軟件工程的質量

• 代碼需要版本管理
  在源代碼基礎上進行修改后，留下新版本以及對應的負責人記錄，記載bug的內容，處理人，處理時間，是否處理完成等內容以備查驗。

七、代碼完成

• 兩個階段：
  1.task完成了，設想變成了可以運行的現實。
  2.Bug仍等待著工程師去尋找，修正。

第 12 章 用戶體驗

一、用戶體驗的要素

• 1.用戶的第一印象：5W1H來判斷：Who When Where Why How，用以判斷用戶對產品的設計需求。
  2.從用戶的角度考慮問題：從用戶的立場上去使用自己的產品。而不是作為一個開發者，一個熟知產品構造的人去體驗。
  3.軟件服務始終都要記住用戶的選擇。
  4.短期刺激和長期影響：短期的刺激并不能成為客戶長期使用的依據。
  5.不讓用戶犯簡單的錯誤：設計能讓客戶盡可能地避免出錯。例如航班上的閱讀燈與呼叫空乘客按紐。如果把緊急彈射座椅放在常用按鈕面板按錯的后果。除了文字完全沒有區分度的Submit，Cancel按鈕。
  6.用戶質量和體驗：有時候質量要給用戶的體驗讓步，才能讓產品更具有吸引力。
  7.情感設計

二、用戶體驗設計的步驟和目標

• 用戶體驗設計的一個重要目標就是降低用戶的認知阻力，即用戶對于軟件界面的認知和實際結果的差距。
  如下表：
  

三、評價標準

• 1.盡快提供可感觸的反饋。
  2.系統界面符合用戶的現實管理。
  3.用戶有控制權。
  4.一致性和標準化。
  5.適合各種類型的用戶。
  6.幫助用戶識別，診斷并修復錯誤。
  7.有必要的提示和幫助文檔。

四、貫穿多種設備的用戶體驗

第 13 章 軟件測試

• 測試方法名稱非常多，但只不過是從各個方面描敘了軟件測試，并不是說有這么多獨立的測試方法，只要分類處理，也就不會很難理解。

• 13.1 基本名詞解釋與分類
  三個基本名詞：

  • Bug：軟件的缺陷
  • Test Case：測試用例
  • Test Suite：測試用例集

• Bug又可分解為：癥狀(Symptom)、程序錯誤(Fault)、根本原因(Foot Couse)。-
  測試設計有兩類方法：黑箱(Black Box)和白箱(White Box)。
  【注】是測試的“設計”方法，而非測試方法。

• 黑箱從軟件的行為，而非從內部設計出發來設計測試；白箱則可“看到”軟件系統內部。
  按測試的目的分類：功能測試、非功能測試。
  按測試的時機和作用分類：測試“烽火臺”，以及其他測試方法。

• 13.2 各種測試方法（該部分書中為舉例了解）
  ① 單元測試(Unit Test) 和 代碼覆蓋率測試(Code Coverage Analysis)
  ② 構建驗收測試：驗收系統的基本功能。
  ③ 驗收測試：拿到一個“可測”的構建以后，按測試計劃測試各自負責的模塊和功能。
  ④ “探索式”測試：為了某一特定目的而進行的測試，且僅此一次，以后一般不重復測試。
  ⑤ 回歸測試
  ⑥ 場景/集成/系統測試：在開發一定階段對軟件進行一個全面系統的測試以保證軟件的各個模塊都能共同工作。
  ⑦ 伙伴測試
  ⑧ 效能測試：軟件在設計負載能否提供令人滿意的服務質量。
  ⑨ 壓力測試：嚴格地說不屬于效能測試，驗證軟件在超過設計負載的情況下能否返回正常結果。
  ⑩ 內部/外部公開測試：讓特定用戶使用正在處于開發階段的版本，以便收集更多反饋。
  ? 易用性測試
  ? “Bug”大掃蕩

• 13.3 實戰中的測試觀念：
  1.從項目開始測試人員便要開始介入，從源頭防止問題的發生。
  2.測試并非一定要根據規格說明書來測，更要從用戶的角度出發來測試軟件。
  3.測試人員的代碼質量一定要特別高，因為測試人員是最后一道防線。
  4.若為了讓問題盡快顯現，用Debug版本；若為了盡可能測試用戶所看到的軟件，用Release版本。
  文檔：在計劃階段就寫出測試總綱與測試計劃，它們主要說明產品是什么，要做什么樣的測試，時間安排如何，誰負責哪方面，各種資源在哪等。

• 13.4 運用測試工具
  運用工具記錄手工測試及自動測試。
  測試效能：除功能方面的測試，還有“服務質量”
  【例子】效能測試： 100個用戶的情況下，產品搜索必須3S內返回結果。
  負載測試： 2000個用戶的情況下，產品搜索必須5S內返回結果。
  壓力測試： 壓力高峰期（4000個用戶）持續48小時的情況下，產品搜索必須保持穩定而不至于崩潰

第 14 章 質量保障

• 14.1 軟件的質量
  軟件質量 = 程序質量 + 軟件工程質量
  程序質量體現在軟件外在功能。例如一個字處理軟件能否拷貝/粘貼等
  軟件工程質量：軟件在功能、成本、時間三方面滿足利益相關者的需求。
  軟件工程的質量以一套比較成熟的理論CMMI進行衡量。
  質量成本組成部分包括預防、評審、內部故障、外在故障四個方面。

• 14.2 軟件質量的保存工作
  軟件的質量保障（QA）和軟件測試（Test）是有很大區別的，因此——測試的角色要獨立出來，所有人都可以參與QA工作，但最后要有一個人對QA這件事負責，最后軟件發布時，必須得到此角色的簽字保證。盡管有專人負責測試工作，但保證質量仍是所有成員的職責。
  不能盲目信任“專業人士”扮演的角色，即使有專業人士扮演的角色，還得有專人獨立地檢查驗證質量。
  分工不能“畫地為牢”，為了避免出現局部最優而全局未必最優，同時也避免由于軟件被切碎而導致整體不太行。
  分工不能無明確責任。

第 15 章 穩定和發布階段

• 15.1 從代碼的完成到發布
  軟件生命周期的最后階段往往是最考驗團隊的，不但考驗團隊項目管理水平、應變能力，也考驗團隊的“血型”。
  原計劃的軟件發布時間快到了，但是軟件還存在各種問題，于是有了4種團隊血型：
  A型：他們知道優秀的軟件公司會發布有已知缺陷的軟件。
  B型：他們不相信這一點。
  O型：他們不知道這一點，因此嘴巴驚訝成O型。
  AB型：他們對于自己開發的軟件是A型，對于別人開發的軟件是B型。
  
  

  從代碼完成到最終發布軟件

• 會診小組：軟件團隊的各個代表組成會診小組，處理每個影響產品發布的問題，對于每一個Bug，會診小組要決定采取何種行動：1.修復 2.設計本來如此 3.不修復 4.推遲
  復雜項目的會診招數：
  設計變更、搞定所有已知Bug、最后回歸測試、砍掉功能（不能因為以前花了成本，就要求以后一定要完成某個任務）、修復Bug的門檻逐漸提高、逐步凍結。

• 15.2 使用不同頻率和不同覆蓋范圍的漸進發布
  產品同時對不同的目標用戶用不同的頻率發布，以適應不同群體的需求。

• 15.3 發布之后——事后諸葛亮會議
  這個軟件生命的周期結束以后，如尸體解剖一樣，把給軟件的開發流程剖析一下。

問題集錦

1、(1.1)我看了這一段文字：

一個復雜的軟件還要有各種文件和數據來描述各個程序文件之間的依賴關系、編譯參數、鏈接參數等等。

有這個問題：再軟件構建的過程中，鏈接參數是什么，能夠起到一個什么樣的功能？我查了資料，有很多種類型的鏈接參數，而且起到的作用也不大相同，根據我查資料后的總結，它們一定存在著一種共性，在軟件開發的各個地方都可以有鏈接參數的影子，但我不能真切說出它們的共性。

2、(1.1)我看到了這一段文字：

軟件團隊的人員也會流動，新的成員要盡快讀懂已有的程序，了解程序的設計，這叫程序理解。

有這個問題：在程序理解階段，為了能夠使不同的人快速接受非自己的代碼，提高工作效率，打代碼的時候應該要注意什么方面？我嘗試上網去查找資料，但資料微乎其微，根據我的實踐，在代碼中添加注釋是最好讓別人理解的，但是這拖慢了自己的速度，總體效率仍然不夠高。我的困惑是：有沒有方法能夠最大地提高團隊合作的效率？

3、(1.1)我看到這一段文字：

商業模式決定了一個軟件企業的成敗。

我有這個問題：商業模式包含什么，光是商業模式是否能夠真正地決定企業地成敗？我上百度百科查商業模式的概念，發現商業模式有這幾個要素：1、價值主張 2、消費者目標群體 3、分銷渠道 4、客戶關系 5、價值配置 6、核心能力 7、價值鏈 8、成本結構 9、收入模式 10、裂變模式；我的困惑是：人才的比重以及公司文化是否也會是影響因素？

4、（1.1）我在書上看到一個表，將軟件工程師分為玩具階段、業余愛好階段、先行者階段、成熟的產業階段，
我有這樣一個問題：在軟件開發階段中愛好者怎么才能晉升為先行者？根據我看書得到的結論：先行者比愛好者會接受更大更重要的計劃，況且還需要資金的支持。但我還有困惑：彼此都是遭遇失敗后仍然能夠再次去嘗試，那先行者的區別和愛好者的區別究竟在哪里？先行者遭遇失敗后，沒有資金的繼續支持，先行者的級別會發生怎么樣的變化？

5、（1.2）我在書中看到關于軟件開發的幾個難題：

復雜性，不可見性，易變性，服從性，非連續性。

我有這么一個問題軟件工程開發有著較高的難度，但不代表不能進行開發，如何能使我們能夠克服軟件開發過程中的難題呢？根據我的實踐，團隊合作是應對這些困難的最好方法，團隊分工合作，可以減少工作量，提升工作效率，但就回到之前的問題，程序員之間的代碼傳播該如何能夠容易上手？

6、（5.2.1）書中提到軟件團隊的模式——“主治醫師模式”：

就像在手術臺上那樣，有一個主刀醫師，其他人（麻醉，護士，器械）各司其職，為主刀醫師服務。這樣的軟件團隊中，有首席程序員，他/她負責處理主要模塊的設計和編碼，其他成員從各種角度支持他/她的工作（后備程序員、系統管理員、工具開發、編程語言專家、業務專家）。佛瑞德·布魯克斯在主管 IBM System 360 項目時就采用了這種模式。

然而在1960 年代中期開始爆發了第一次軟件危機,典型表現有軟件質量低下、項目無法如期完成、項目嚴重超支等,因為軟件而導致的重大事故時有發生。軟件危機最典型的例子莫過于 IBM 的 System/360 的操作系統開發。在佛瑞德·布魯克斯后來總結的《人月神話》一書中又提到：

軟件經理很早就認識到優秀程序員和較差的程序員之間生產率的差異，但實際測量出的差異還是令我們所有的人吃驚。

得出的結論很簡單：如果一個200人的項目中，有25個最能干和最有開發經驗的項目經理，那么開除剩下的175名程序員，讓項目經理來編程開發。

現在我們來驗證一下這個解決方案。一方面，原有的開發隊伍不是理想的小型強有力的團隊，因為通常的共識是不超過10個人，而該團隊規模如此之大，以至于至少需要兩層的管理，或者說大約5名管理人員。另外，它需要額外的財務、人員、空間、文秘和機器操作方面的支持。

那么對于一個小型團隊來說，如果原有的開發隊伍也不是所謂的“理想的小型強有力的團隊”，那么分配多人管理或者一直開除人員是不現實的。在這樣一種小型團隊的“主治醫師模式”下，該如何避免一個學生干活，其余學生跟著打醬油的現象發生？

• 參考：程序設計思想發展，《人月神話》

7、（5.2.2）書中提到軟件團隊的模式——“明星模式”：

主治醫師模式運用到極點，可以蛻化為明星模式，在這里，明星的光芒蓋過了團隊其他人的總和，2004年到2012年的“翔之隊”就是一個例子。明星也是人，也會也會受傷，犯錯誤，如何讓團隊的利益最大化，而不是明星的利益最大化？如何讓團隊的價值在明星隕落之后仍然能夠保持？是這個模式要解決的問題。

對于明星來說，很容易被突如其來的成功或者被一個華麗的瞬間迷惑，從而失去自我，失去團隊意識，籃球中的全明星賽就是一個很好的例子：

美國當地作家弗蘭克·德福特表示：“全明星賽將成為NBA聯盟最好的明星陳列館，但是這僅僅是一個全明星而已。具有諷刺意味的是，那只是一個華麗的瞬間而已，但實際上這將被載入NBA史冊，這只會讓人們想起這個聯盟是一個缺乏團隊意識的聯盟。”

當然，我們的團隊并不是全明星，但是也會有因為明星個性突出而導致自身墮落甚至團隊解體的可能。所以我和書中鄒老師提出的問題相似：如何在明星光芒四射時使團隊的利益最大化？其他團隊成員要怎樣配合，才能讓明星時刻保持團隊意識？

• 參考：全明星比賽缺乏團隊意識 偉大聯盟應完美結合

8、（6.4.1）書中提到敏捷總結中的“極致編程”：

Sprint/Scrum 對項目的眾多需求采取分而治之的辦法，能讓相關人員集中精力，在一定期限內解決部分問題。它強調短時間內的迭代，在多次迭代中不斷總結，改進團隊的流程和產品功能。

推而廣之，所謂極限編程，就是把一些認為重要和有效的做法發揮到極致，在這層意義上，“極限編程”應該叫“極致編程”。

在書中的表6-2中舉例：如果了解客戶的需求很重要，那么發揮到極致就變成每時每刻都有客戶在身邊，時時了解需求；如果計劃沒有變化快，那就別做詳細的設計，做頻繁的增量開發、重構和頻繁地發布。對于一個持久合作的團隊來說，他們有足夠的時間來分而治之和在迭代中不斷總結經驗，那么在一個短期合作的團隊中，要如何快速培養一個人或者一個團隊把重要和有效的做法發揮到極致的能力？

9、（6）書中提到的敏捷團隊：

在軟件工程的語境里，“敏捷流程”是一系列價值觀和方法論的集合。

軟件開發流程有好多種，......

軟件項目的團隊各式各樣，......

敏捷的團隊大多是針對軟件工程的團隊而言的，但是對于我們專業也有一定的借鑒價值，在某些方面也存在一些區別。我在一篇關于軟件工程和計算機專業的區別的資料中找到：

我不是專業人士,但我知道有很大區別。 軟件工程是一類工程。工程是將理論和知識應用于實踐的科學。就軟件工程而言,它借鑒了傳統工程的原則和要領,以求高效地研發高質量軟件。

軟件工程這一概念,主要是針對 20 世紀 60 年代"軟件危機"而提出的。

我覺得我們的課程“程序設計與數據結構”與軟件工程既有重合的地方，又有各自的特殊要求，那么類似于“敏捷的團隊”這一觀念，我們的課程“程序設計與數據結構”在其他的哪些方面還能夠借鑒軟件工程課程中的做法或者內容？構建之法上的哪些內容可以完全應用到我們的課程中？

• 參考：軟件工程專業與計算機專業的區別是什么

10、在第7章，關于做用戶調研，書中舉了一個例子，

Bowman是谷歌的視覺設計主管，谷歌的一個團隊不能在兩個藍色之間做出決定，所以他們在每一個藍色之間測試41個陰影，看看哪一個表現更好。他最近就邊界是否應該是3, 4，或5像素寬進行了辯論，并要求證明他的情況。我已經厭倦了辯論這種微小的設計決策

《論語》云：“如切如磋，如琢如磨。”做事要求精益求精，在進行用戶調研的過程中，為什么不能調研細微到毫厘，即做調研做過頭?或者說如何確定做用戶調研的界限，究竟哪種調研才算是做過頭呢？比如當我做用戶調研時，我努力朝著最精確的方向去做，但我是否已經做過頭了呢？

11、第9章中，

一個團隊成熟的標記，就是對風險的管理。

在《構建之法》中如是說，幾乎每個優秀的團隊都會有自己獨特的一套風險應對措施。關于如何應對風險，首先就應該確立態度，書上給了三種不同的態度，通過查閱百度百科，我了解到風險態度是一個專業名詞，總共分為三種態度，引用該知識點如下：

風險厭惡是一個人接受一個有不確定的收益的交易時相對于接受另外一個更保險但是也可能具有更低期望收益的交易的不情愿程度。

風險中性是相對于風險偏好和風險厭惡的概念,風險中性的投資者對自己承擔的風險并不要求風險補償。我們把每個人都是風險中性的世界稱之為風險中性世界(Risk-Neutral World)。

風險偏好是指人們在實現其目標的過程中愿意接受的風險的數量。

如上三種態度是一個從保守到開放的過程，這三種態度中任何一種都有其存在的理由，是不是風險中性一定是最好的選擇呢，或者是求穩發育還是冒險一搏呢？

12、第9章關于項目經理PM，提到Project Manager 和Program Manager的一個區別是一個團隊可以有很多Program Manager，并且是和團隊其他成員進行決議。
我提出一個疑問如果一個團隊中存在多個PM，他們針對一個項目形成了多個決議，這種窘況該如何解決呢?還有就是既然每個團隊成員都可能當上PM，而這個職位又沒有實際權力，這對團隊的幫助作用真的大嗎？我認為這設些帶有少許管理權力的職位例如小組長效果會比較好，因為小組長是能力佼佼者，本身又能管事和管一定范圍內的人，不就提高了小團隊效率嗎？

13、Project Manager 和 Program Manager，有一個區別在于前者管事也管人，后者只管事不管人，并且符合PM能力要求的程序員都有機會成為PM。倘若一個程序員能力很強，但是并不會管理和領導，像這樣領導力較弱的PM和能力不是特別強但領導力出眾的程序員相比，誰能更加勝任這一職位呢？所以PM需要有很強的領導力嗎?

14、我讀了第十章用例中的這一段文字：

如果軟件的關鍵性在于用戶體驗的細節，那么如何把這些UI的細節嵌入每個故事中，并仍然保持故事的簡明性。

經過繼續的閱讀和查閱資料，我知道了很多團隊把目前的技術拓展為Use Case Storyboard，用一個簡明的故事加上很多附加說明和圖畫，也就是形成功能說明書。根據我的生活經驗，生活中有些藥品的使用方法會使用相似的方法，例如噴霧的開啟方法說明書：用圖片加上文字說明的方式來介紹這個用例。我的困惑是這固然是一種解決方案，但這樣將故事轉變為圖片經常使用例失去其故事性，變成索然無味的陳述說明。或者變成某些在圖片故事穿插功能說明的有趣的引導，但這樣的小故事又沒有前者的包容性，通常只能涵蓋很小的功能細節，但確實讓使用者能夠更加主動和輕松的了解其功能。那么，這兩者哪一種更優或者說怎么將這兩者結合起來呢？

討論與交流

　　今天我們小組開展了第一次團隊例會活動。我們小組將《構建之法》分為了六個部分并由六位成員先分別學習并向組長上傳學習收獲，這次的活動內容便是 交流前兩周小組成員學習閱讀《構建之法》的收獲 。
　　在各位成員的交流中我們將自己所讀的這部分內容的總結與其他人的進行交換，從而對自己還沒有讀到的內容有一個大致的了解。其中組員劉偉康提到的我們要形成 “交響樂隊模式” 的團隊是這次團隊例會中大家共同贊成的觀點，他提出要避免 “明星模式” 失控時一家獨大的狀態，讓每個人都有明確的分工和職責，同時在某位成員工作暫時受到阻礙時，要有其他成員能夠有能力及時補上他的工作。這樣可以讓團隊中的每個人都最大化與格式化自己的力量，不會出現一個人干活一人偷懶的局面。同時我們也對尚未完成自己閱讀項目的莫禮鐘同學進行了鼓勵，希望他能努力學習，在下一次交流中展現自己的學習成果。

【此次交流總結由 馬軍 記錄】
【2017.10.11晚】

參考資料

• 構建之法（第三版）

• 程序設計思想發展

• 《人月神話》

• 全明星比賽缺乏團隊意識 偉大聯盟應完美結合

• 軟件工程專業與計算機專業的區別是什么