2017-2018-1 Java演繹法 第一週 做業

團隊學習：《構建之法》

• 【團隊成員】：

  學號	姓名	負責工做
  20162315	馬軍	平常統計，項目部分代碼
  20162316	劉誠昊	項目部分代碼，代碼質量測試
  20162317	袁逸灝	組長，項目 主要 代碼
  20162319	莫禮鍾	市場推廣，廣告策劃
  20162320	劉先潤	項目部分代碼，動畫效果
  20162330	劉偉康	項目總結博客，平常管理，代碼質量測試

  【注】個別成員在沒有具體工做時會進行動態分配。

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

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

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

  團隊貢獻及完成度

  Members	Personal Contribution	Completion and Time(h)
  袁逸灝	第一、二、3章及問題1~5	100%　　4.5
  劉偉康	第四、五、6章，建立團隊博客，編輯博客及問題6~9	100%　　8.5
  劉先潤	第七、八、9章及問題10~13	100%　　7.0
  馬軍	第十、十一、12章，問題14及交流會總結	100%　　3.0
  劉誠昊	第1三、1四、15章	70%　　 3.0
  莫禮鍾	第1六、17章	20%　　 1.0

第 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、典型用戶

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

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

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

2、用例(Use Case)

• 1.用例：與典型人物，典型場景的方法相似，一樣是很經常使用的需求分析工具包含這樣的一些基本元素：標題，角色，主要成功場景，步驟，拓展場景。
  用例的原則：
  • 1.經過簡單的故事來傳遞信息。
  • 2.保持對全系統的理解。
  • 3.關注用戶的價值。
  • 4.逐步構建整個系統，一次完成一個用力。
  • 5.增量開發，逐步構建整個系統。
  • 6.適應團隊不斷變化的需求。
• 用例的侷限性：
  1.比較適合故事/人物/場景交互的系統。可是對於算法，速度，拓展性，安全性以及和系統技術相關等需求則不適用。
  2.故事的粒度沒有統一標準與具體項目有關，初學者較難掌握。
  3.既要把UI的細節嵌入每一個故事，又要保證其簡明性是一個難題。

3、功能說明書（Spec）

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

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

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

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

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

4、功能驅動的設計

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

第 11 章 軟件設計與實現

1、分析和設計方法

• 1.四個過程：
  • 1.需求分析：抽象出咱們真正關心的屬性，實體之間的關係。用戶的需求，如何解決？
  • 2.設計與實現階段：軟件如何解決這些需求，現實生活中的實體和屬性在軟件系統中怎麼表現和交換信息？
  • 3.4.測試,發佈階段：真的解決了這些需求嗎，軟件解決需求的效率如何，用戶還有什麼新的需求嗎？
• 2.經常使用方法：
  文檔、圖形爲主構造的模型（思惟導圖，流程圖等）、數學語言的描述、用類天然語言 + 代碼構造的描述（Literate Programming）、源代碼加註釋描述。

2、圖形建模和分析方法

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

3、其餘設計方法

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

4、從Spec到實現

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

• 2. 把修改集集成到代碼庫中
  根據場景和開發任務來決定集成的次序、互相依賴的任務要一塊兒集成。
  在測試場景時，要保證端對端的測試。
  場景的全部者必須保證場景徹底經過測試，而後把場景的狀態改成「解決」。

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

5、開發階段的平常管理

• 1.閉門造車（Leave me alone）：集中於某一件事情，將本身投入其中，拒絕其餘人的干擾。
  2.每日構建（Daily Bulid）：打好基礎，精益求精。
  3.「構建大師」：對於一個致使構建失敗的成員，授予這個稱號，並讓他：
  負責管理構建服務器 --> 調試構建，負責找錯，並分析出錯的緣由 --> 將這個稱號和責任交予下一位致使構建失敗的成員 --> 構建大師爲團隊「構建之法基金」存入50元，以供你們團隊構建之用。
  4.寬嚴皆誤：制定寬嚴標準，以及根據團隊的狀況（勢）所反映的狀況。成員行爲影響我的的儘可能寬鬆，而影響團隊的則要嚴格處理。
  5.小強地獄（Bug Hell）：相似於構建大師的選取：選出那些超過bug數標準的成員，讓他們進入小強地獄專職於小強地獄處理bug，直到知足標準出獄，每週公佈進出獄名單。

6、實戰中的源代碼管理

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

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

7、代碼完成

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

第 12 章 用戶體驗

1、用戶體驗的要素

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

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

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

3、評價標準

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

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

第 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.1)我看到了這一段文字：

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

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

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

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

我有這個問題：商業模式包含什麼，光是商業模式是否可以真正地決定企業地成敗？我上百度百科查商業模式的概念，發現商業模式有這幾個要素：一、價值主張 二、消費者目標羣體 三、分銷渠道 四、客戶關係 五、價值配置 六、核心能力 七、價值鏈 八、成本結構 九、收入模式 十、裂變模式；個人困惑是：人才的比重以及公司文化是否也會是影響因素？

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

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

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

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

六、（5.2.1）書中提到軟件團隊的模式——「主治醫師模式」：

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

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

軟件經理很早就認識到優秀程序員和較差的程序員之間生產率的差別，但實際測量出的差別仍是令咱們全部的人吃驚。

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

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

那麼對於一個小型團隊來講，若是原有的開發隊伍也不是所謂的「理想的小型強有力的團隊」，那麼分配多人管理或者一直開除人員是不現實的。在這樣一種小型團隊的「主治醫師模式」下，該如何避免一個學生幹活，其他學生跟着打醬油的現象發生？

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

七、（5.2.2）書中提到軟件團隊的模式——「明星模式」：

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

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

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

固然，咱們的團隊並非全明星，可是也會有由於明星個性突出而致使自身墮落甚至團隊解體的可能。因此我和書中鄒老師提出的問題類似：如何在明星光芒四射時使團隊的利益最大化？其餘團隊成員要怎樣配合，才能讓明星時刻保持團隊意識？

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

八、（6.4.1）書中提到敏捷總結中的「極致編程」：

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

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

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

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

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

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

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

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

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

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

我以爲咱們的課程「程序設計與數據結構」與軟件工程既有重合的地方，又有各自的特殊要求，那麼相似於「敏捷的團隊」這一觀念，咱們的課程「程序設計與數據結構」在其餘的哪些方面還可以借鑑軟件工程課程中的作法或者內容？構建之法上的哪些內容能夠徹底應用到咱們的課程中？

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

十、在第7章，關於作用戶調研，書中舉了一個例子，

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

《論語》雲：「如切如磋，如琢如磨。」作事要求精益求精，在進行用戶調研的過程當中，爲何不能調研細微到毫釐，即作調研作過頭?或者說如何肯定作用戶調研的界限，究竟哪一種調研纔算是作過頭呢？好比當我作用戶調研時，我努力朝着最精確的方向去作，但我是否已經作過頭了呢？

十一、第9章中，

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

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

風險厭惡是一我的接受一個有不肯定的收益的交易時相對於接受另一個更保險可是也可能具備更低指望收益的交易的不情願程度。

風險中性是相對於風險偏好和風險厭惡的概念,風險中性的投資者對本身承擔的風險並不要求風險補償。咱們把每一個人都是風險中性的世界稱之爲風險中性世界(Risk-Neutral World)。

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

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

十二、第9章關於項目經理PM，提到Project Manager 和Program Manager的一個區別是一個團隊能夠有不少Program Manager，而且是和團隊其餘成員進行決議。
我提出一個疑問若是一個團隊中存在多個PM，他們針對一個項目造成了多個決議，這種窘況該如何解決呢?還有就是既然每一個團隊成員均可能當上PM，而這個職位又沒有實際權力，這對團隊的幫助做用真的大嗎？我認爲這設些帶有少量管理權力的職位例如小組長效果會比較好，由於小組長是能力佼佼者，自己又能管事和管必定範圍內的人，不就提升了小團隊效率嗎？

1三、project manager和program manager有一個區別在於前者管事也管人，後者只管事無論人，而且符合PM能力要求的程序員都有機會成爲PM。假若一個程序員能力很強，可是並不會管理和領導，像這樣領導力較弱的PM和能力不是特別強但領導力出衆的程序員相比，誰能更加勝任這一職位呢？因此PM須要有很強的領導力嗎?

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

若是軟件的關鍵性在於用戶體驗的細節，那麼如何把這些UI的細節嵌入每一個故事中，並仍然保持故事的簡明性。

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

討論與交流

　　今天咱們小組開展了第一次團隊例會活動。咱們小組將《構建之法》分爲了六個部分並由六位成員先分別學習並向組長上傳學習收穫，此次的活動內容即是 交流前兩週小組成員學習閱讀《構建之法》的收穫 。
　　在各位成員的交流中咱們將本身所讀的這部份內容的總結與其餘人的進行交換，從而對本身尚未讀到的內容有一個大體的瞭解。其中組員劉偉康提到的咱們要造成 「交響樂隊模式」 的團隊是此次團隊例會中你們共同同意的觀點，他提出要避免 「明星模式」 失控時一家獨大的狀態，讓每一個人都有明確的分工和職責，同時在某位成員工做暫時受到阻礙時，要有其餘成員可以有能力及時補上他的工做。這樣可讓團隊中的每一個人都最大化與格式化本身的力量，不會出現一我的幹活一人偷懶的局面。同時咱們也對還沒有完成本身閱讀項目的莫禮鍾同窗進行了鼓勵，但願他能努力學習，在下一次交流中展示本身的學習成果。

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

參考資料

• 構建之法（第三版）

• 程序設計思想發展

• 《人月神話》

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

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