【正文】 批準 拿到最新源代碼 代碼集成要點 ? 每一個 Checkin必須有記錄 *必須發(fā) pickup郵件 *要有新 feature規(guī)格、 Bug號或說明 *代碼審核和伙伴編譯 ? 進入控制模式后 *Checkin之前需要申請 *必須是解決 Show Stopper bug或由經(jīng)理或作戰(zhàn)會議批準 Build Machine(編譯機） ? 獨立的專用機器（通常再專用實驗室里） ? 專人負責 ? 生成二進制代碼 *用于發(fā)布 *用于測試 ? 代碼、環(huán)境變量不能任意改動 *只接受源代碼服務器的修改 *正式的環(huán)境變量 Bug數(shù)據(jù)庫 ? 測試與開發(fā)人員的溝通界面 ? Open,resolve,and close bugs ? 優(yōu)先級 ? Show Stopper Exchange 公共文件夾 ? 論壇形式的公共文件夾 ? 批準、以及存儲 Checkin請求的地方 ? Checkin要求會轉(zhuǎn)發(fā)給郵件列表 開發(fā)人員應有的態(tài)度 開發(fā)者的使命 ? 不僅僅是寫程序和調(diào)試 ? 他和所有角色一樣，為了實現(xiàn)用戶需求 *PM定義用戶需求 *界面設計 描繪用戶需求 *開發(fā) 實現(xiàn)用戶需求 *測試 保障用戶需求 ? 程序員將把 Word文檔（需求說明書）“編譯”成執(zhí)行代碼 ? 不是項目組中 唯一 重要的角色 開發(fā)人員的管理 ? 程序員是特殊的群體 *創(chuàng)造力與完成任務 ? 任務管理高于時間管理 ? 設定優(yōu)先級 ? 激勵與懲罰程序員 *進度透明 *Bug數(shù)量和 Show Stopper透明 *違反制度 ? 鼓勵開發(fā)人員寫“ solid”代碼 *代碼審核 *積極處理 bug 代碼審核 ? 代碼審核的優(yōu)越性 *增強可靠性 *極早發(fā)現(xiàn)項目中的問題 *擴展開發(fā)人員的代碼知識 *培訓開發(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)威的領導者 ? 作為程序經(jīng)理，有所為，有所不為 什么是程序經(jīng)理 ? 這些年來，都處于模糊狀態(tài) ? 和開發(fā)，測試，市場和用戶助理等人員一起工作 ? 程序經(jīng)理和軟件的關系，就如同建筑師和房子的關系 程序經(jīng)理的來歷 ? 1984年， Multiplan項目首次設立了程序經(jīng)理的職位來管理整個項目并取得了巨大的成功，于是比爾 .蓋茨決定在全公司范圍內(nèi)實行程序經(jīng)理的管理模式 優(yōu)秀程序經(jīng)理的特征 ? 做事投入 ? 對產(chǎn)品前景的理解 ? 專注的精神 ? 促進發(fā)展的能力 ? 注意細節(jié)的能力 ? 做決策的能力 ? 做事有勇氣 程序經(jīng)理的幾大工作重點 ? 產(chǎn)品前景及其相關的工作 ? 產(chǎn)品高層次初步的設計 ? 產(chǎn)品詳細設計和日程安排 ? 問題的處理 ? 檢查產(chǎn)品開發(fā)進度（ Checkpoints) ? 發(fā)布產(chǎn)品 產(chǎn)品前景及其相關的工作 ? 什么時間該做什么： *何時開始一個項目 *了解顧客，業(yè)務，市場，技術 *程序經(jīng)理應做調(diào)研、訪問顧客 *調(diào)研、訪問的結(jié)果：產(chǎn)品前景闡述 ? 程序經(jīng)理要把握的關鍵點 *不要只是對顧客滔滔不絕 請學會傾聽 *明白調(diào)研的優(yōu)點和局限性 *為你的領域開發(fā)一片“子前景” *寫下你的想法，然后征求別人的意見 ? 前景是所有工作的起點 *每個人都能夠理解 *每個人都會同意 *這個標準將會讓你專注，并指導你解決難題 ? 了解你的顧客 *成熟產(chǎn)品的第一個版本發(fā)布 *了解所從事的行業(yè) *當你的產(chǎn)品發(fā)布了，這些產(chǎn)品會流向什么地方 ? 什么時候該做什么： *確定前景期間和之后的幾個月 *費用 /效益分析 *程序經(jīng)理書寫產(chǎn)品規(guī)格草案 *這是大多數(shù)項目失敗的地方 ? PM關鍵點： *前景應該成為做決定的指導 *清晰地設想的用戶產(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ī)格 *概述 *明確的成功的標準（包括測試設定） *詳細的資料 *表達整個團隊的想法 ? 如何進行產(chǎn)品規(guī)格的審核 *學習怎么檢測驗收產(chǎn)品的規(guī)格 *提前對產(chǎn)品規(guī)格進行的測試 *和整個團隊一起做審核 *不要拒絕接受別人的批評和意見 ? 程序經(jīng)理的其他注意事項 *徹底了解產(chǎn)品的前景 *徹底了解產(chǎn)品本身 *不斷訓練你自己的設計能力 *不要和開發(fā)人員在開發(fā)進程上爭論不停 *知道執(zhí)行的順序 成功的時間安排 ? 設定日程安排 ? 校準日程 ? 就跟蹤標準達成一致 ? 知道相互依賴的關系 ? 到達里程碑 ? 有一個后備計劃 ? 調(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關鍵點 *不要對 bugs視而不見 *你不可以解決任何問題 *在 RAID中記錄所有的細節(jié) *不要經(jīng)常推遲 bug的調(diào)正 *Overmunicate不要過多 /重復的交流 ? 什么時間該做什么： *每一個里程碑的結(jié)尾和通過產(chǎn)品發(fā)布 *按照標準檢查進程，調(diào)整日程表 *程序經(jīng)理也要廣泛的交流 ? PM關鍵點 *有你自己小的檢查點 *關于 beta測試版的計劃 *發(fā)現(xiàn)跟蹤 bugs *不要太快跳到下一個版本 ? 該在什么時候做什么 *安慰，害怕，驕傲，歡樂 *RTM后的事后總結(jié) ? PM關鍵點 *Bring a change of clothes to work *參觀 beta測試版用戶和首批采用本產(chǎn)品的用戶 *專門派人的負責人 RTM事后總結(jié)的一些問題 PM行為準則 ? 確保你的行動有益于你在開始的時候設定的目標和方向 正確的產(chǎn)品前景并在確定的時間發(fā)布產(chǎn)品 活動 實踐出真知 怎樣在競爭中取勝 在這個部分你將會學會如何創(chuàng)造在市場上能贏的產(chǎn)品 ? 研究競爭產(chǎn)品 ? 知道什么時候應該領導，什么時候跟從對手 ? 注意對手的競爭優(yōu)勢 四個方面下手 戰(zhàn)勝競爭對手的四個關鍵點。 ?總能利用各種渠道和方法來解決問題?，F(xiàn)行的Inter應用之間也存在互聯(lián)困難，沒有規(guī)模效益等傳統(tǒng)軟件的弊病 Web Service 由市場領導者制定應用框架，眾多開發(fā)商基于標準協(xié)議和 富應用，用戶享有極大的互聯(lián)其他應用軟件和個性化定制的便利。 整個框架完全開放，獨立于操作系統(tǒng)，對象模式和編程語言用標準的 Inter協(xié)議（ HTTP/XML/SOAP）可以存取訪問所有 Web Service應用可以無縫集成 ?互聯(lián)網(wǎng)的出現(xiàn)和迅猛發(fā)展形成了一種廉價的，充分尊重標準，互聯(lián)巨大 用戶資源和商業(yè)資源的基礎設施，為新的應用模式的出現(xiàn)提供了基本條 件 ?摩爾定律和吉爾德定律再互聯(lián)網(wǎng)德應用，使得計算能力和寬帶不再成為 稀缺資源；接入設備和接入手段的多樣化和簡單化使得互聯(lián)網(wǎng)應用成為 最普通應用場景 ?但是目前無論是互聯(lián)網(wǎng)應用和傳統(tǒng)軟件在利用互聯(lián)網(wǎng)的水平都處于相當 低的程度，沒有充分利用到互聯(lián)網(wǎng)所連接德巨大資源和商業(yè)價值 業(yè)界現(xiàn)狀 客戶需求 由廠商向企業(yè)個體提供基于局域網(wǎng)或單機德 解決方案 ?市場經(jīng)濟和社會化大生產(chǎn)的發(fā)展要求企業(yè)應用與上下游合作伙 伴，客戶， Marketplace進行集成互聯(lián) ?企業(yè)內(nèi)部也存在著新老系統(tǒng)，不同業(yè)務應用集成的問題 ?如今的應用集成面臨著難度大，費用高，時間長，效果差等問 題 業(yè)界現(xiàn)狀 客戶需求 為什么要 Web Service— 應用集成 應用模式 優(yōu)點 缺點 主要廠商 All in one 由單一廠商提供面向企業(yè)全方位管理的完整解決方案 由該廠商提供的應用之間集成度較高（但是該廠商在開發(fā)應用之時，也會面臨著構(gòu)架系統(tǒng)，集成模塊的問題 費用高，周期長，實施難度大，幾乎不能利用已有應用資源，沒有解決與外部應用相連的問題 SAP， Oracle,IBM,用友，金碟，通軟 EAI 由 EAI廠商提供連接不同應用的中間件或連接件 能夠利用以有應用資源 費用高，周期長 實施難度極大 應用集成程度較低 Web Methods B2B Microsoft Biz talk NEON/IBM MQSI ipla Solution Mercator Web Service 應用是以組件方式提供的，可用Inter標準協(xié)議存取的 Web Service 整個框架完全開放，獨立于操作系統(tǒng)，對象模式和編程語言用標準的Inter協(xié)議（ HTTP/XML/SOAP）可以存取訪問所有 Web Service 接口規(guī)范通過 WSDL和 UDDI完全公開，便于發(fā)現(xiàn)和集成 Service提供的是獨立于供應商的平臺，不同應用廠商的 Service應用可以無縫集成 尚無案例和經(jīng)驗可供借鑒，許多技術和操作領域尚待自行開拓 中國需要有一個強有力的領導者制定框架規(guī)范和基礎 Service應用 業(yè)界現(xiàn)狀 客戶需求 為什么要 Web Service— 軟件是服務 ?客戶不希望為那些很少用到或根本不用的功能支付費用 ?客戶希望購買到隨時隨地可用的“功能”和“服務”，而并非是受地理位置和 設備限制的軟件 ?客戶希望得到軟件的服務，而不是大費人力物力地為軟件服務 ?軟件的補丁，更新和升級應該更加容易和透明 Software 服務是軟件的附加值 Service 軟件是服務的載體 ?大量手持設備，信息家電，車載設備等智能設備的迅猛發(fā)展使得 PC 不再成為個人存取和管理信息的唯一設備 ?多種智能設備和接入手段的出現(xiàn)順應了人們希望無論何時，何地都 能夠存取信息的要求 ?人們希望對信息的體驗是基于信息本身，而不是受限于信息設備， 或被信息設備所控制 業(yè)界現(xiàn)狀 客戶需求 為什么要 Web Service— 智能設備 模式 模式特征 后果 現(xiàn)存設備 不同的設備彼此獨立 有不同的應用軟件和不同的用戶數(shù)據(jù) 用戶在不同設備之間維護著多份數(shù)據(jù)拷貝 用戶數(shù)據(jù)很難在不同設備之間共享，同步和更新 開發(fā)商需要為不同設備定制開發(fā)不同的應用 Service 不同設備低層是基于共同的 Framework基礎框架 開發(fā)商只需開發(fā)一套應用程序，便可用較小代價移植到不同設備 用戶可以在不同設備之間共享，同步和更新數(shù)據(jù) 用戶可以在不同設備之間享受