來自：微軟 蔡鉳
(2002.12.11)
一．團隊組織
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. 根據需要調整團隊結構
微軟開發者大會主題演講2 微軟計畫擴充套件雲計算觸角
在華盛頓雷德蒙德舉辦的2012微軟開發者大會的第二天，微軟伺服器與工具部門總裁satya nadella在華盛頓雷德蒙德開始了他的keynote做了一場主題演講。nadella強調，微軟正在為全世界的應用提供乙個現代化的平台。u0026 xd n nadella描述的雲作業系統由windows az...
微軟應以開發者為中心
正如在 joel on software 中所言，現在微軟的msdn竭力告訴你在微軟的世界盡力去遵循它的規則，而不是努力為開發者和使用者提供良好的向後相容。這一點無不令開發者擔憂，是的，我現在用的是windows xp但是，我不敢保證我開發的軟體是否能在那個被稱之為vista的作業系統上良好的執行，...
2009 Drupal 開發者大會主題演講
非常值得一看，dries 在演講中講述了 drupal 的現狀與未來，特別談到 drupal 7，以及 drupal.org 站點的重新設計。drupal 4 在易用性上有了顯著改善。drupal 5 加入自動安裝工具 布魯塞爾的 drupalcon 2007 開發者大會有150人參加，sunnyv...