團(tuán)隊學(xué)習(xí)：《構(gòu)建之法》

• 【團(tuán)隊成員】：

  　學(xué)號　　姓名　　負(fù)責(zé)工作　

  20162315	馬軍	日常統(tǒng)計，項目部分代碼
  20162316	劉誠昊	項目部分代碼，代碼質(zhì)量測試
  20162317	袁逸灝	組長，項目 主要 代碼
  20162319	莫禮鐘	市場推廣，廣告策劃
  20162320	劉先潤	項目部分代碼，動畫效果
  20162330	劉偉康	項目總結(jié)博客，日常管理，代碼質(zhì)量測試

  【注】個別成員在沒有具體工作時會進(jìn)行動態(tài)分配。

【本次團(tuán)隊貢獻(xiàn)及完成度】

• 團(tuán)隊組長：袁逸灝
  本次編輯：劉偉康

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

  團(tuán)隊貢獻(xiàn)及完成度

  　Members　　Personal Contribution　　Completion and Time(h)

  袁逸灝	第1、2、3章及問題1~5	100%　　4.5
  劉偉康	第4、5、6章，創(chuàng)建團(tuán)隊博客，編輯博客及問題6~9	100%　　8.5
  劉先潤	第7、8、9章及問題10~13	100%　　7.0
  馬軍	第10、11、12章，問題14及交流會總結(jié)	100%　　3.0
  劉誠昊	第13、14、15章	70%　　 3.0
  莫禮鐘	第16、17章	20%　　 1.0

第 1 章 概論

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

• 1.2 軟件工程是什么
  軟件工程的定義、軟件工程所包含的領(lǐng)域、軟件開發(fā)的難點、工程的定義、軟件工程并不等于計算機(jī)科學(xué)，兩者有著不同的側(cè)重點，軟件工程的知識領(lǐng)域，軟件工程的目標(biāo)，初步學(xué)會軟件工程需要達(dá)到的要求。

第 2 章 個人技術(shù)和流程

• 2.1 單元測試
  保證覆蓋率為100%，好的單元測試的標(biāo)準(zhǔn)，單元測試可以提高軟件開發(fā)的效率，回歸（回歸到以前不正常的狀態(tài)）測試。

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

• 2.3 個人開發(fā)流程（PSP）
  PSP任務(wù)清單（大學(xué)生VS工程師），PSP的特點。

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

第 3 章 軟件工程師的成長

• 3.1 個人能力的衡量與發(fā)展
  個人能力在團(tuán)隊中的作用與影響、個人應(yīng)當(dāng)承擔(dān)的責(zé)任、個人的成長記方式。

• 3.2 軟件工程師的思維誤區(qū)
  不要總想著在短時間內(nèi)搞個大新聞，要結(jié)合自身實際，求穩(wěn)，然后再擴(kuò)展。

• 3.3 軟件工程師的職業(yè)發(fā)展

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

第 4 章 兩人合作

• 4.1 代碼規(guī)范（風(fēng)格、設(shè)計）

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

• 4.3 代碼設(shè)計規(guī)范
  函數(shù)、goto、錯誤處理（參數(shù)處理、斷言）、處理類。

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

• 4.5 結(jié)對編程（極致）
  為什么（高投入產(chǎn)出比）、不間斷地復(fù)審、角色互換。

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

第 5 章 團(tuán)隊和流程

• 5.1 非團(tuán)隊和團(tuán)隊
  非團(tuán)隊（獨立、烏合之眾）、團(tuán)隊（共同目標(biāo)、合作）。

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

• 5.3 開發(fā)流程（統(tǒng)一體系）
  寫了再改、瀑布模型（分析-->設(shè)計-->實現(xiàn)-->銷售-->維護(hù)）、統(tǒng)一流程、漸進(jìn)交付（MVP）、TSP原則

第 6 章 敏捷流程

• 6.1 敏捷的流程簡介（找出待解決的問題 --> 決定當(dāng)前目標(biāo) -->沖刺（每日例會）--> 改進(jìn)）

• 6.2 敏捷流程的問題和解法（計劃：體現(xiàn)依賴關(guān)系-->描述細(xì)化到技術(shù)層面 --> 跟蹤三個時間 --> 總結(jié)教訓(xùn)）

• 6.3 敏捷的團(tuán)隊
  自主管理（自己挑選任務(wù)）、自我組織（聯(lián)合負(fù)責(zé)）、多功能（全面負(fù)責(zé)）。

• 6.4 敏捷總結(jié)
  質(zhì)量控制、短時間迭代、極致編程、經(jīng)驗教訓(xùn)。

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

第 7 章 MSF

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

• 用戶調(diào)研（User Study），A/B測試，通過態(tài)度、行為、定性、定量來規(guī)范調(diào)研的尺度。
  

第 8 章 需求分析

• 軟件需求
  將需求進(jìn)行分類、清楚軟件產(chǎn)品的利益相關(guān)者、獲取用戶需求（用戶調(diào)研）、競爭性需求分析的框架、功能的定位和優(yōu)先級、目標(biāo)估計和決心、找出估計后面的假設(shè)、最后分而治之。

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

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

第 9 章 項目經(jīng)理

• 風(fēng)險管理
  第一步：確認(rèn)風(fēng)險、根據(jù)不同的來源對風(fēng)險進(jìn)行分類；
  第二步：分析和優(yōu)先級劃分；
  第三步：計劃和管理風(fēng)險
  應(yīng)對風(fēng)險的方法：進(jìn)一步研究、接受、 規(guī)避、轉(zhuǎn)移、 降低、制定應(yīng)急計劃

• 項目經(jīng)理（PM），PM負(fù)責(zé)除產(chǎn)品開發(fā)和測試之外的所有事情，包括正確地做產(chǎn)品和正確地做流程。
  PM的作用：收集需求、設(shè)計用戶界面，編寫規(guī)范、協(xié)調(diào)市場、文檔、測試、定位、帶領(lǐng)團(tuán)隊達(dá)成決策
  【注】項目經(jīng)理是和大家平等工作，并且做具體工作，和其他團(tuán)員一起形成決議，只管事不管人的，和領(lǐng)導(dǎo)型經(jīng)理是不一樣的。

第 10 章 典型用戶和場景

一、典型用戶

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

• 2.從典型用戶到場景
  場景：也可以是故事，用戶為達(dá)到目標(biāo)使用系統(tǒng)時經(jīng)歷的所有過程。
  場景的使用：設(shè)計者模擬用戶，設(shè)計一個場景入口，描述用戶在這個場景的內(nèi)外部因素，給場景劃分優(yōu)先級并寫場景。

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

二、用例(Use Case)

• 1.用例：與典型人物，典型場景的方法類似，同樣是很常用的需求分析工具包含這樣的一些基本元素：標(biāo)題，角色，主要成功場景，步驟，拓展場景。
  用例的原則：
  • 1.通過簡單的故事來傳遞信息。
  • 2.保持對全系統(tǒng)的理解。
  • 3.關(guān)注用戶的價值。
  • 4.逐步構(gòu)建整個系統(tǒng)，一次完成一個用力。
  • 5.增量開發(fā)，逐步構(gòu)建整個系統(tǒng)。
  • 6.適應(yīng)團(tuán)隊不斷變化的需求。
• 用例的局限性：
  1.比較適合故事/人物/場景交互的系統(tǒng)。但是對于算法，速度，拓展性，安全性以及和系統(tǒng)技術(shù)相關(guān)等需求則不適用。
  2.故事的粒度沒有統(tǒng)一標(biāo)準(zhǔn)與具體項目有關(guān)，初學(xué)者較難掌握。
  3.既要把UI的細(xì)節(jié)嵌入每個故事，又要保證其簡明性是一個難題。

三、功能說明書（Spec）

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

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

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

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

• 5.技術(shù)說明書
  設(shè)計文檔，用于描述開發(fā)者如何趨勢線某一功能，或相互聯(lián)系的一組功能。實現(xiàn)軟件功能沒有固定的模板，但總存在著一些規(guī)律。

四、功能驅(qū)動的設(shè)計

• 設(shè)計過程：
  構(gòu)造總體模型 --> 構(gòu)造功能列表 --> 制定開發(fā)計劃 --> 功能設(shè)計階段5實現(xiàn)具體功能

第 11 章 軟件設(shè)計與實現(xiàn)

一、分析和設(shè)計方法

• 1.四個過程：
  • 1.需求分析：抽象出我們真正關(guān)心的屬性，實體之間的關(guān)系。用戶的需求，如何解決？
  • 2.設(shè)計與實現(xiàn)階段：軟件如何解決這些需求，現(xiàn)實生活中的實體和屬性在軟件系統(tǒng)中怎么表現(xiàn)和交換信息？
  • 3.4.測試,發(fā)布階段：真的解決了這些需求嗎，軟件解決需求的效率如何，用戶還有什么新的需求嗎？
• 2.常用方法：
  文檔、圖形為主構(gòu)造的模型（思維導(dǎo)圖，流程圖等）、數(shù)學(xué)語言的描述、用類自然語言 + 代碼構(gòu)造的描述（Literate Programming）、源代碼加注釋描述。

二、圖形建模和分析方法

• 表達(dá)實體和實體的關(guān)系
  思維導(dǎo)圖、實體關(guān)系圖、ERD.UCD；表達(dá)數(shù)據(jù)的流動、表達(dá)控制流、統(tǒng)一的表達(dá)方式（UML）。

三、其他設(shè)計方法

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

四、從Spec到實現(xiàn)

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

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

• 3.開發(fā)人員的標(biāo)準(zhǔn)工作流程（如下圖所示）
  

五、開發(fā)階段的日常管理

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

六、實戰(zhàn)中的源代碼管理

• 軟件 = 程序 + 軟件工程
  軟件的質(zhì)量 = 程序的質(zhì)量 + 軟件工程的質(zhì)量

• 代碼需要版本管理
  在源代碼基礎(chǔ)上進(jìn)行修改后，留下新版本以及對應(yīng)的負(fù)責(zé)人記錄，記載bug的內(nèi)容，處理人，處理時間，是否處理完成等內(nèi)容以備查驗。

七、代碼完成

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

第 12 章 用戶體驗

一、用戶體驗的要素

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

二、用戶體驗設(shè)計的步驟和目標(biāo)

• 用戶體驗設(shè)計的一個重要目標(biāo)就是降低用戶的認(rèn)知阻力，即用戶對于軟件界面的認(rèn)知和實際結(jié)果的差距。
  如下表：
  

三、評價標(biāo)準(zhǔn)

• 1.盡快提供可感觸的反饋。
  2.系統(tǒng)界面符合用戶的現(xiàn)實管理。
  3.用戶有控制權(quán)。
  4.一致性和標(biāo)準(zhǔn)化。
  5.適合各種類型的用戶。
  6.幫助用戶識別，診斷并修復(fù)錯誤。
  7.有必要的提示和幫助文檔。

四、貫穿多種設(shè)備的用戶體驗

第 13 章 軟件測試

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

• 13.1 基本名詞解釋與分類
  三個基本名詞：
  • Bug：軟件的缺陷
  • Test Case：測試用例
  • Test Suite：測試用例集

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

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

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

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

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

第 14 章 質(zhì)量保障

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

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

第 15 章 穩(wěn)定和發(fā)布階段

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

  從代碼完成到最終發(fā)布軟件

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

• 15.2 使用不同頻率和不同覆蓋范圍的漸進(jìn)發(fā)布
  產(chǎn)品同時對不同的目標(biāo)用戶用不同的頻率發(fā)布，以適應(yīng)不同群體的需求。

• 15.3 發(fā)布之后——事后諸葛亮?xí)h
  這個軟件生命的周期結(jié)束以后，如尸體解剖一樣，把給軟件的開發(fā)流程剖析一下。

問題集錦

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

一個復(fù)雜的軟件還要有各種文件和數(shù)據(jù)來描述各個程序文件之間的依賴關(guān)系、編譯參數(shù)、鏈接參數(shù)等等。

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

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

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

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

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

商業(yè)模式?jīng)Q定了一個軟件企業(yè)的成敗。

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

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

5、（1.2）我在書中看到關(guān)于軟件開發(fā)的幾個難題：

復(fù)雜性，不可見性，易變性，服從性，非連續(xù)性。

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

6、（5.2.1）書中提到軟件團(tuán)隊的模式——“主治醫(yī)師模式”：

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

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

軟件經(jīng)理很早就認(rèn)識到優(yōu)秀程序員和較差的程序員之間生產(chǎn)率的差異，但實際測量出的差異還是令我們所有的人吃驚。

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

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

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

• 參考：程序設(shè)計思想發(fā)展，《人月神話》

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

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

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

美國當(dāng)?shù)刈骷腋ヌm克·德福特表示：“全明星賽將成為NBA聯(lián)盟最好的明星陳列館，但是這僅僅是一個全明星而已。具有諷刺意味的是，那只是一個華麗的瞬間而已，但實際上這將被載入NBA史冊，這只會讓人們想起這個聯(lián)盟是一個缺乏團(tuán)隊意識的聯(lián)盟。”

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

• 參考：全明星比賽缺乏團(tuán)隊意識 偉大聯(lián)盟應(yīng)完美結(jié)合

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

Sprint/Scrum 對項目的眾多需求采取分而治之的辦法，能讓相關(guān)人員集中精力，在一定期限內(nèi)解決部分問題。它強調(diào)短時間內(nèi)的迭代，在多次迭代中不斷總結(jié)，改進(jìn)團(tuán)隊的流程和產(chǎn)品功能。

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

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

9、（6）書中提到的敏捷團(tuán)隊：

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

軟件開發(fā)流程有好多種，......

軟件項目的團(tuán)隊各式各樣，......

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

我不是專業(yè)人士,但我知道有很大區(qū)別。 軟件工程是一類工程。工程是將理論和知識應(yīng)用于實踐的科學(xué)。就軟件工程而言,它借鑒了傳統(tǒng)工程的原則和要領(lǐng),以求高效地研發(fā)高質(zhì)量軟件。

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

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

• 參考：軟件工程專業(yè)與計算機(jī)專業(yè)的區(qū)別是什么

10、在第7章，關(guān)于做用戶調(diào)研，書中舉了一個例子，

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

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

11、第9章中，

一個團(tuán)隊成熟的標(biāo)記，就是對風(fēng)險的管理。

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

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

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

風(fēng)險偏好是指人們在實現(xiàn)其目標(biāo)的過程中愿意接受的風(fēng)險的數(shù)量。

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

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

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

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

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

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

討論與交流

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

【此次交流總結(jié)由 馬軍 記錄】
【2017.10.11晚】

參考資料

• 構(gòu)建之法（第三版）

• 程序設(shè)計思想發(fā)展

• 《人月神話》

• 全明星比賽缺乏團(tuán)隊意識 偉大聯(lián)盟應(yīng)完美結(jié)合

• 軟件工程專業(yè)與計算機(jī)專業(yè)的區(qū)別是什么

轉(zhuǎn)載于:https://www.cnblogs.com/SuperGroup/p/7586687.html

總結(jié)

以上是生活随笔為你收集整理的2017-2018-1 Java演绎法 第一周 作业的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。