微軟的一天

1．每日構造daily build

daily build是所有工作的核心，而且是在半夜自動啟動。

• daily build的意義：模組得以及時整合；要求程式設計師及時把最新**放入**庫

• 用指令碼語言和編譯/鏈結工具實現

• bvt build verification test ：對build進行驗證

• blocking bug ：讓build無法完成的問題； bvt中發現的問題

2．程式設計師每天上班前最擔心什麼？

答案：因為自己昨天的**check-in，造成blocking bug.每天的build是所有人當天工作的基礎，程式設計師需要build驗證與其他模組的介面；測試需要build發現新bug，並驗證新build中已解決的bug。

有blocking bug怎麼辦？　解決問題，並對今天的build打patch。

答案：開啟缺陷跟蹤工具，檢視指定給自己的bug，解決高優先度的bug；為質量重於新功能。

從版本控制工具中check out**；修改**（解決bug或實現新功能）；取得版本工具中最新變化，在本機build和單元測試；請開發組同事作code review ； check in**

3．測試人員第一件事做什麼？

答案：開啟raid/bms，檢視指定給自己的bug，驗證已解決的bug；根據測試用例檢驗今天的build ；在raid/bms中記錄新發現的bug

4．專家會診

• 參加者：專案經理和開發組長、測試組長

• 通過raid/bms評估每個未解決的bug：決定bug優先度；可否等到下個里程碑或版本？誰來解決

• **專案實際進度和發布時間

缺陷走勢圖

5．回顧微軟的一天

• 構造: daily build ；開發: 解決blocking bugs, 實現功能, check-out, code review, check-in

• 測試: bvt, 使用測試用例進行測試；專案經理/組長: 專家會診

6．微軟的做法解決了那些常見問題？

質量問題

• 以前解決過的問題發布時又出現了，需要返工；無法預估發布時間過早發布，帶來質量和維護問題

• 測試發現的問題被忘卻或不了了之；無法衡量測試員和開發員的工作；程式中的問題往往在發布後才發現

文件管理問題

• 文件與程式脫節，文件成為程式結果的描述；專案組把寫文件看成負擔

團隊協調問題

• 開發人員各自為戰，進行整合時發現模組銜接中的嚴重問題需要作大的改動

• 沒有保管好公司以往的版本和**，無法滿足使用者對舊版本的更改要求；開發人員離職對專案帶來很大衝擊，沒有人知道**在哪，或無法讀懂

五．提高軟體管理的步驟

1. 使用raid/bms，將流程管理自動化； 2. 使用測試用例管理工具； 3. 使用文件管理工具；

4. 使用版本控制工具，進行daily build　　　5. 建立**標準； 6. 建立code review機制；

7. 建立專家會診機制； 8. 建立團隊溝通機制；　　　　　　　　9. 根據需要調整團隊結構

產品設計考慮問題

1 who : 為誰設計，使用者是誰？不能為所有人服務；

2 what：要解決哪些使用者問題？

設計之源：在於使用者；設計之本：要滿足使用者需求，方便使用者使用，並且使生產製造工藝盡可能簡單；不能把軟體設計單純當作自我技術水準，個人才智表達的方式。（使用者場景：使用者使用軟體的特定環境或場合。）