團隊學習：《構建之法》
一、典型使用者
二、用例(use case)
用例的侷限性：
1.比較適合故事/人物/場景互動的系統。但是對於演算法，速度，拓展性，安全性以及和系統技術相關等需求則不適用。
2.故事的粒度沒有統一標準與具體專案有關，初學者較難掌握。
3.既要把ui的細節嵌入每個故事，又要保證其簡明性是乙個難題。
三、功能說明書（spec）
四、功能驅動的設計
一、分析和設計方法
2.常用方法：
文件、圖形為主構造的模型（思維導圖，流程圖等）、數學語言的描述、用類自然語言 + **構造的描述（literate programming）、源**加注釋描述。
二、圖形建模和分析方法
三、其他設計方法
四、從spec到實現
五、開發階段的日常管理
六、實戰中的源**管理
七、**完成
一、使用者體驗的要素
二、使用者體驗設計的步驟和目標
三、評價標準
四、貫穿多種裝置的使用者體驗
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小時的情況下，產品搜尋必須保持穩定而不至於崩潰
**從**完成到最終發布軟體**
1、(1.1)我看了這一段文字：「乙個複雜的軟體還要有各種檔案和資料來描述各個程式檔案之間的依賴關係、編譯引數、鏈結引數等等」，有這個問題：再軟體構建的過程中，鏈結引數是什麼，能夠起到乙個什麼樣的功能？我查了資料，有很多種型別的鏈結引數，而且起到的作用也不大相同，根據我查資料後的總結，它們一定存在著一種共性，在軟體開發的各個地方都可以有鏈結引數的影子，但我不能真切說出它們的共性。
2、(1.1)我看到了這一段文字：「軟體團隊的人員也會流動，新的成員要盡快讀懂已有的程式，了解程式的設計，這叫程式理解。」，有這個問題：在程式理解階段，為了能夠使不同的人快速接受非自己的**，提高工作效率，打**的時候應該要注意什麼方面？我嘗試上網去查詢資料，但資料微乎其微，根據我的實踐，在**中新增注釋是最好讓別人理解的，但是這拖慢了自己的速度，總體效率仍然不夠高。我的困惑是：有沒有方法能夠最大地提高團隊合作的效率？
4、（1.1）我在書上看到乙個表，將軟體工程師：玩具階段、業餘愛好階段、先行者階段、成熟的產業階段，我有這樣乙個問題：在軟體開發階段中愛好者怎麼才能晉公升為先行者？根據我看書得到的結論：先行者比愛好者會接受更大更重要的計畫，況且還需要資金的支援。但我還有困惑：彼此都是遭遇失敗後仍然能夠再次去嘗試，那先行者的區別和愛好者的區別究竟在**？先行者遭遇失敗後，沒有資金的繼續支援，先行者的級別會發生怎麼樣的變化？
5、（1.2）我在書中看到關於軟體開發的幾個難題：複雜性，不可見性，易變性，服從性，非連續性。我有這麼乙個問題軟體工程開發有著較高的難度，但不代表不能進行開發，如何能使我們能夠克服軟體開發過程中的難題呢？根據我的實踐，團隊合作是應對這些困難的最好方法，團隊分工合作，可以減少工作量，提公升工作效率，但就回到之前的問題，程式設計師之間的**傳播該如何能夠容易上手？
6、(2.1)我在書上看到這麼一句話：「單元測試應該整合到自動測試的框架中」，我有這麼乙個問題：該如何使單元測試給自動化？
7、主治醫師模式：在乙個團隊中如何避免乙個學生幹活，其餘學生跟著打醬油？
8、明星模式：如何使團隊的利益最大化，而不是在明星光芒四射時使自身利益最大化？
9、如何在不影響效率的情況下有效記錄三個跟蹤的時間值：實際剩餘時間、預估剩餘時間、實際花費時間？
10、如何培養乙個人或者乙個團隊把重要和有效的做法發揮到極致的能力？
11、軟體工程和我們的課程程式設計與資料結構有什麼不同？構建之法上的哪些內容可以完全應用到我們的課程中？
12、在進行使用者調研的過程中，為什麼不能調研細微到毫釐，即做調研做過頭？
13、乙個團隊成熟的標記，就是對風險的管理，在《構建之法》中如是說，我們對待風險該採取什麼樣的態度呢？
14、關於專案經理pm，書中提到乙個團隊可以有很多pm，如果乙個團隊中針對乙個專案形成了多個決議，這種窘況該如何解決呢？
15、project manager 和 program manager 的區別在於前者管事也管人，後者只管事不管人，所以pm需要有很強的領導力嗎？
16、在設計用例時如何既鑲嵌ui的細節又保證故事的簡明性？
17、使用者的體驗和產品的質量同樣重要，那麼他們衝突時應該平衡至什麼地步？
18、在設計典型場景時需要保持模擬內容的簡明性還是模擬所有可能發生的事件，無論是否與需求有關？
19、成本的主要組成部分是由什麼而產生？
20、結構和實現又有什麼樣的關係？
21、**覆蓋率是什麼？它重要在哪？
22、理想的覆蓋率分析工具是怎樣的？
【注】第16、17章內容待完善，大部分問題不夠完整，缺少具體的資料**和分析過程，以後會做一些修改。
構建之法第五次作業 團隊專案測試
這個作業屬於哪個課程 課程的鏈結 這個作業要求在 作業要求的鏈結 團隊名稱 楊榮模傑和他的佶祥虎 這個作業的目標 測試與學習其他團隊的專案 作業正文 見下方其他參考文獻 團隊名稱 西柚排課王 團隊部落格 專案名稱 易奇排排課系統 本來是想測試這個 的，好像伺服器炸了，訪問特別慢，所以第乙個測試專案 ...
構建之法 第5章 團隊和流程
本章重點 團隊有一些共同的特點 就像在手術台上，有乙個主刀醫師，其他人 麻醉，器械 各司其職，為主刀醫師服務。這樣的團隊中，有首席程式設計師 chief programmer 來負責處理主要模組的設計和編碼，其他團隊成員從各種角度支援他。這一模式往往退化為 乙個人幹活，其他人跟著打醬油。作者以學校的...
構建之法第五章 團隊和流程
構建之法閱讀筆記05 團隊和流程 團隊和流程 這一章主要講述團隊的軟體團隊模式和開發流程。還有他們的優缺點。一 團隊模式。文章中介紹的團隊模式有很多種，這裡只選取其中的幾種來描述。1.一窩蜂模式 最混亂的一種模式，存活時間不會很長。2.主治醫師模式 就跟在手術台一樣，有乙個主刀醫師，其他人為主刀醫師...