【文章內(nèi)容簡介】 ve,and close bugs ? 優(yōu)先級 ? Show Stopper Exchange 公共文件夾 ? 論壇形式的公共文件夾 ? 批準、以及存儲 Checkin請求的地方 ? Checkin要求會轉(zhuǎn)發(fā)給郵件列表 開發(fā)人員應(yīng)有的態(tài)度 開發(fā)者的使命 ? 不僅僅是寫程序和調(diào)試 ? 他和所有角色一樣，為了實現(xiàn)用戶需求 *PM定義用戶需求 *界面設(shè)計 描繪用戶需求 *開發(fā) 實現(xiàn)用戶需求 *測試 保障用戶需求 ? 程序員將把 Word文檔（需求說明書）“編譯”成執(zhí)行代碼 ? 不是項目組中 唯一 重要的角色 開發(fā)人員的管理 ? 程序員是特殊的群體 *創(chuàng)造力與完成任務(wù) ? 任務(wù)管理高于時間管理 ? 設(shè)定優(yōu)先級 ? 激勵與懲罰程序員 *進度透明 *Bug數(shù)量和 Show Stopper透明 *違反制度 ? 鼓勵開發(fā)人員寫“ solid”代碼 *代碼審核 *積極處理 bug 代碼審核 ? 代碼審核的優(yōu)越性 *增強可靠性 *極早發(fā)現(xiàn)項目中的問題 *擴展開發(fā)人員的代碼知識 *培訓(xùn)開發(fā)人員的最佳途徑 ? 定出時間不要放棄 *每周固定時間 *明確規(guī)定為每個 feature完成的一個步驟 積極處理 Bugs ? “ Bug不是不可以避免的” ? 測試是開發(fā)人員的基本功 *讓源代碼容易測試 *成為自己產(chǎn)品的客戶 *調(diào)查遇到的每一個問題 ? 用測試來驗證質(zhì)量，而不是創(chuàng)造質(zhì)量 *不要依賴測試人員來發(fā)現(xiàn) bug *與測試人員成為合作伙伴 問題 微軟程序經(jīng)理 日程表 ? 什么是程序經(jīng)理？程序經(jīng)理的來歷和種類 ? 優(yōu)秀程序經(jīng)理的特征 ? 程序經(jīng)理的幾大工作重點 ? 怎樣在競爭中取勝 ? 做沒有權(quán)威的領(lǐng)導(dǎo)者 ? 作為程序經(jīng)理，有所為，有所不為 什么是程序經(jīng)理 ? 這些年來，都處于模糊狀態(tài) ? 和開發(fā)，測試，市場和用戶助理等人員一起工作 ? 程序經(jīng)理和軟件的關(guān)系，就如同建筑師和房子的關(guān)系 程序經(jīng)理的來歷 ? 1984年， Multiplan項目首次設(shè)立了程序經(jīng)理的職位來管理整個項目并取得了巨大的成功，于是比爾 .蓋茨決定在全公司范圍內(nèi)實行程序經(jīng)理的管理模式 優(yōu)秀程序經(jīng)理的特征 ? 做事投入 ? 對產(chǎn)品前景的理解 ? 專注的精神 ? 促進發(fā)展的能力 ? 注意細節(jié)的能力 ? 做決策的能力 ? 做事有勇氣 程序經(jīng)理的幾大工作重點 ? 產(chǎn)品前景及其相關(guān)的工作 ? 產(chǎn)品高層次初步的設(shè)計 ? 產(chǎn)品詳細設(shè)計和日程安排 ? 問題的處理 ? 檢查產(chǎn)品開發(fā)進度（ Checkpoints) ? 發(fā)布產(chǎn)品 產(chǎn)品前景及其相關(guān)的工作 ? 什么時間該做什么： *何時開始一個項目 *了解顧客，業(yè)務(wù)，市場，技術(shù) *程序經(jīng)理應(yīng)做調(diào)研、訪問顧客 *調(diào)研、訪問的結(jié)果：產(chǎn)品前景闡述 ? 程序經(jīng)理要把握的關(guān)鍵點 *不要只是對顧客滔滔不絕 請學(xué)會傾聽 *明白調(diào)研的優(yōu)點和局限性 *為你的領(lǐng)域開發(fā)一片“子前景” *寫下你的想法，然后征求別人的意見 ? 前景是所有工作的起點 *每個人都能夠理解 *每個人都會同意 *這個標準將會讓你專注，并指導(dǎo)你解決難題 ? 了解你的顧客 *成熟產(chǎn)品的第一個版本發(fā)布 *了解所從事的行業(yè) *當你的產(chǎn)品發(fā)布了，這些產(chǎn)品會流向什么地方 ? 什么時候該做什么： *確定前景期間和之后的幾個月 *費用 /效益分析 *程序經(jīng)理書寫產(chǎn)品規(guī)格草案 *這是大多數(shù)項目失敗的地方 ? PM關(guān)鍵點： *前景應(yīng)該成為做決定的指導(dǎo) *清晰地設(shè)想的用戶產(chǎn)品的情節(jié) *Protospecs最初的產(chǎn)品規(guī)格 ? 什么時間做什么？ *在“里程碑 0）（ MO）”期間 *在程序經(jīng)理和開發(fā)人員之間有更多的交流 *程序經(jīng)理寫產(chǎn)品規(guī)格 ? 結(jié)果 *詳細的日程安排 *詳細的里程碑結(jié)束標準 *“里程碑 1”產(chǎn)品規(guī)格完成 ? 怎樣才是一個好的產(chǎn)品規(guī)格 *概述 *明確的成功的標準（包括測試設(shè)定） *詳細的資料 *表達整個團隊的想法 ? 如何進行產(chǎn)品規(guī)格的審核 *學(xué)習(xí)怎么檢測驗收產(chǎn)品的規(guī)格 *提前對產(chǎn)品規(guī)格進行的測試 *和整個團隊一起做審核 *不要拒絕接受別人的批評和意見 ? 程序經(jīng)理的其他注意事項 *徹底了解產(chǎn)品的前景 *徹底了解產(chǎn)品本身 *不斷訓(xùn)練你自己的設(shè)計能力 *不要和開發(fā)人員在開發(fā)進程上爭論不停 *知道執(zhí)行的順序 成功的時間安排 ? 設(shè)定日程安排 ? 校準日程 ? 就跟蹤標準達成一致 ? 知道相互依賴的關(guān)系 ? 到達里程碑 ? 有一個后備計劃 ? 調(diào)整日程 主要日程 Planning Specification Development Stabilization Spec Complete Code Complete Goals Closure Milestone 0 RTM Spec/Shedule Iterations Design Changee Triage ? 什么時間該做什么 *跟蹤進程和處理問題 *在編寫代碼和發(fā)布的過程中 *程序經(jīng)理更新產(chǎn)品規(guī)格和 resolve bugs ? PM關(guān)鍵點 *不要對 bugs視而不見 *你不可以解決任何問題 *在 RAID中記錄所有的細節(jié) *不要經(jīng)常推遲 bug的調(diào)正 *Overmunicate不要過多 /重復(fù)的交流 ? 什么時間該做什么： *每一個里程碑的結(jié)尾和通過產(chǎn)品發(fā)布 *按照標準檢查進程，調(diào)整日程表 *程序經(jīng)理也要廣泛的交流 ? PM關(guān)鍵點 *有你自己小的檢查點 *關(guān)于 beta測試版的計劃 *發(fā)現(xiàn)跟蹤 bugs *不要太快跳到下一個版本 ? 該在什么時候做什么 *安慰，害怕，驕傲，歡樂 *RTM后的事后總結(jié) ? PM關(guān)鍵點 *Bring a change of clothes to work *參觀 beta測試版用戶和首批采用本產(chǎn)品的用戶 *專門派人的負責人 RTM事后總結(jié)的一些問題 PM行為準則 ? 確保你的行動有益于你在開始的時候設(shè)定的目標和方向 正確的產(chǎn)品前景并在確定的時間發(fā)布產(chǎn)品 活動 實踐出真知 怎樣在競爭中取勝 在這個部分你將會學(xué)會如何創(chuàng)造在市場上能贏的產(chǎn)品 ? 研究競爭產(chǎn)品 ? 知道什么時候應(yīng)該領(lǐng)導(dǎo)，什么時候跟從對手 ? 注意對手的競爭優(yōu)勢 四個方面下手 戰(zhàn)勝競爭對手的四個關(guān)鍵點。 ? ? ? ? ? 問你所知道的使用該產(chǎn)品的人 ? Dog food內(nèi)部測試 ? 產(chǎn)品回顧（ Product Review) *Product Planning may help產(chǎn)品計劃會有幫助 *Promise ? 研究公司策略 ? 知道他們的顧客希望從他們那里得到什么 ? 認識產(chǎn)品方向上的變化 ? 假定你的對手是聰明能干的 ? 扮演角色 ? 你將會在所有的時間使用這些信息，比如頭腦風暴，產(chǎn)品規(guī)格審核等等 ? 得到正確的產(chǎn)品性能 *知道什么時候應(yīng)該領(lǐng)導(dǎo)，什么時候跟從 *找到平衡，檢查 /質(zhì)疑 /提問產(chǎn)品特征 ? 進行你自己的競爭回顧 ? 牢記競爭對手是一個動態(tài)的目標 ? 讓他們在你的監(jiān)視范圍之中 *Dow Jones Interactive Custom Clips *Exeews ? 最大化投資（為你自己和別人） PM行為準則 ? 知道是什么激發(fā)了人們的斗志，并且利用它來發(fā)揮團隊的力量 ? 關(guān)注大局 ? 建立個人信譽并維護它 ? 保持積極的態(tài)度，影響別人是有樂趣的 回答問題 微軟軟件測試 議程 ? 軟件測試概述 ? 軟件測試組 ? 測試計劃和級別 ? Bug的發(fā)現(xiàn)和管理 I 軟件測試概述 ? 什么是軟件測試 ? 測試的目的與任務(wù) ? 軟件質(zhì)量的定義 ? 測試與軟件成本 ? 測試部分常用術(shù)語 什么是軟件測試？ ?質(zhì)量是保證 — 系統(tǒng) 的監(jiān)督和評估項目 的各個方面以確保 滿足質(zhì)量標準 ?測試是分析并確定 產(chǎn)品是否滿足客戶 的需求和期望的所 有活動 測試的目的與任務(wù) ? 目的 — 確保軟件質(zhì)量，確保產(chǎn)品滿足設(shè)計和客戶的要求，同時降低軟件的開發(fā)成本和維護成本，并最終簽發(fā)（ Signoff)產(chǎn)品質(zhì)量 ? 任務(wù) *根據(jù)特性規(guī)格說明制訂測試計劃 *開發(fā)必要的測試工具 *編寫測試用例 *執(zhí)行系統(tǒng)、全面、深入的測試，在開發(fā)過程中找出所有可能存在的 Bug *跟蹤并管理產(chǎn)品質(zhì)量，定期報告質(zhì)量狀態(tài) *負責最終的發(fā)布認可（ Signoff) 測試與軟件成本 ? 成本 越早發(fā)現(xiàn) bug，修正的機會越大，開發(fā)和后期維護的代價越小 *Spec review *編碼階段 *Beta階段 *本地化 *發(fā)布后 ? 質(zhì)量越高，軟件發(fā)布后維護費用越底 開發(fā) 費用 需求分析 編碼 發(fā)布 部分常用術(shù)語 ? QAQuality Assurance 質(zhì)量保證 ? Bug缺陷，問題 ? Blocking Bug ? Show Stopper Bug/Release Kill致命問題 ? Milestone里程碑 ? Test Case測試用例 ? Stress Test壓力測試 ? BVTBuild Verification Test ? Adhoc 測試 隨機測試 ? Buddy Test ? Hot Fixing ? Dog Food ? ZBB(Zero Bug Bounce) ? ZBR(Zero Bug Release) ? RTM/RTW II 軟件測試組 ? 軟件測試組在整個項目中的位置 ? 與程序員的關(guān)系 ? 與程序經(jīng)理的關(guān)系 ? 測試組的主要職責 ? 測試組成員的職責 微軟測試組在整個項目中的位置 ?和設(shè)計組，開發(fā)組 及用戶教育等并列 的隊伍 ?測試組負責產(chǎn)品的 質(zhì)量控制 ?測試人員和開發(fā)人 員的比例大約是 1： 1 開發(fā) 測試 后勤 用戶教育 產(chǎn)品經(jīng)理 產(chǎn)品規(guī)劃 溝通和聯(lián)絡(luò) 與程序員的關(guān)系 ?測試組不是開發(fā)組的助手， 合作又各司其職 ?程序員不能寫完代碼就扔過 墻，等待測試工程師找到所 有的 Bug ?RAID是橋梁 ?對有分歧的 Bug程序員不能 擅自關(guān)閉 ?測試人員對發(fā)現(xiàn)的 Bug要盡 可能的提供詳細的資料 與程序經(jīng)理的關(guān)系 ?沒有隸屬關(guān)系，合作 又各司其職 ?程序經(jīng)理提供詳細的 規(guī)格說明 ?程序經(jīng)理要參與 Review 測試計劃 ?測試人員要報告測試狀 態(tài)及產(chǎn)品狀態(tài) 測試隊伍的主要職責 ?測試隊伍組成 *經(jīng)理、組長、測試工程師 ?主要職責 *測試計劃 *測試 *測試過程 *項目與資源管理 *交流與資源管理 *交流與業(yè)務(wù) 測試工程師的主要責任 ?撰寫相關(guān)的測試計劃和測試用例 ?設(shè)計或改編相關(guān)的測試工具 ?識別可自動測試區(qū)域 ?參與組內(nèi)的測試計劃和測試用例以及測試腳本分析工作 ?手動 /自動測試 ?AdHoc測試 ?按照需求規(guī)格說明查證并驗證各項功能 ?