| 一．團隊組織
1．常見問題
沒有人愿意做測試
覺得養不起那么多測試人員
開發人員不遵循規范，隨心所欲
項目經理事必躬親，分身乏術
2．微軟團隊模型
各角色的職責
| 角色 |
職責 |
| 項目經理 |
編寫功能規范，協調各角色關系 |
| 產品經理 |
客戶聯系的橋梁，進行需求分析 |
| 用戶教育 |
讓產品容易使用 |
| 發布經理 |
保證產品順利發布 |
二．項目管理
1．常見問題
無法決定項目所需的資源（人力和預算）
無法決定項目的進度表
無法控制外包項目的進度和質量
2．微軟項目管理-- 多里程碑式流程
每個里程碑完成部分功能
便于團隊集中力量完成一個又一個功能
提供多個機會以適應需求的更改
如何完成一個里程碑
步驟一： 達成共識
基本完成需求調研和分析 （產品經理負責）
確定大方向和長中短期目標
所有角色都參與討論并真正認同結論
產生的文檔：
常見用戶情景：覆蓋80%以上功能
Vision：言簡意賅地說明大方向，并有激勵團隊的作用
步驟二： 完成項目計劃
編寫詳細的功能規范（項目經理負責）
在編程前想清楚所有功能流程，并引導用戶明確需求
所有角色都參與審閱功能規范
制訂開發計劃和進度表（開發團隊）
制訂測試計劃和進度表（測試團隊）
分配資源（人力和預算）
形成項目綜合計劃和綜合進度表
產生的文檔：
功能規范，開發計劃，測試計劃（用例），項目綜合計劃
開發進度表，測試進度表，綜合進度表
步驟三： 完成功能
開發人員分別完成自己的功能
使用版本控制工具
使程序員及時check out和check in，避免積累大量代碼
及時進行模塊間的整合，及時發現問題（daily build）
對每一項可測試的功能進行測試，無需等待
使用測試用例工具，對功能進行完整和重復的檢驗
使用BMS進行缺陷跟蹤
記錄所有程序問題
實現解決Bug的自動流程
按照綜合進度表不斷檢查進度
使用的工具：
版本控制工具 VSS
缺陷跟蹤工具 Raid/BMS
測試用例管理工具
步驟四： 穩定與發布
測試組全面地測試功能，包括性能和穩定性
開發組全力配合解決Bug
使用BMS進行
監測質量情況
預測發布日期
專家會診機制：
決定Bug的優先度
決定哪些Bug可以等到下個里程碑或版本中解決
決定由誰解決某個Bug
使用的工具：
版本控制工具 VSS
缺陷跟蹤工具 BMS
測試用例管理工具
三． 微軟的開發管理經驗：100%以Bug為核心
1．Bug 及常見類型
功能未實現，和規格說明書不一致
不能工作：死機，沒反應
不兼容
邊界條件
界面、消息、提示不夠準確，不友好
把尚未完成的工作也作為一個Bug
文檔與幫助信息中的缺陷也是Bug
2．RAID/BMS的基本功能
完整的Bug數據庫
整個產品組的中央記錄和控制
強大的查詢功能，有效地跟蹤項目的狀態
所有的記錄無法刪除，對于每個記錄只能一直添加內容
豐富的報表功能，為產品發布提供判斷標準
3．Bug 記錄中的有效信息 狀態
負責人
問題種類
嚴重級
優先級
修改時間
登記時間
缺陷來源
解決方案
運行環境
缺陷關聯
附件
附圖
缺陷細節
4．Bug 的嚴重程度
死機，數據丟失，主要功能組完全喪失，系統懸掛
主要功能喪失，導致嚴重的問題，或致命的錯誤聲明
次要功能喪失， 不太嚴重，如提示信息不太準確
微小的問題，對功能幾乎沒有影響，產品及屬性仍可使用. 如有個錯別字
5．激活的Bug數量的趨勢
代碼完成前：很少
代碼完成后：增長很快
接近Beta: 下降
接近RC: 奔向零
產品質量和里程碑的信號
每天新建的Bug 與 修正的 Bug 相比較
Active 狀態 Bug 的總數
四．微軟的一天
1． 讓我們看看項目中每個角色的一天是如何度過的
開發
測試
項目經理
注：里程碑的每個階段每個角色的工作有不同側重點，我們以“完成功能”階段為例
微軟的一天從幾點開始？
答案：半夜
為什么？
因為Daily Build是所有工作的核心，而且是在半夜自動啟動。
每日構造Daily Build
你知道自己所用Windows的版本號嗎？
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。
開發人員的正事
經歷對Build的提心吊膽和爭分奪秒之后，第一件事做什么
答案：打開缺陷跟蹤工具，查看指定給自己的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. 根據需要調整團隊結構 | 
