敏捷開發(fā)基礎(chǔ).ppt

敏捷開發(fā)基礎(chǔ)介紹 國際業(yè)務(wù)部Larryhu2010 3 12 本次介紹的目標 使大家對敏捷開發(fā)有一個基本的概念基于部門現(xiàn)狀 我們能開始著手做什么更多的是洗腦 拋出問題可用的解決方案 正在探索中 為什么要敏捷開發(fā) 價值觀和核心理念 敏捷開發(fā)的工具和方法 我們?nèi)绾纹鸩?價值 和 質(zhì)量 產(chǎn)品的最終目的是實現(xiàn)用戶價值和商業(yè)價值 產(chǎn)品的質(zhì)量包括外部質(zhì)量和內(nèi)部質(zhì)量 有質(zhì)量的產(chǎn)品不一定有價值 有價值的產(chǎn)品必需有質(zhì)量做保障 敏捷開發(fā)針對這兩個維度都給出了方法和工具來保證 產(chǎn)品質(zhì)量 外部質(zhì)量 與 價值 直接相關(guān)用戶體驗 bug數(shù)量 性能指標 killerfeature目前部門對這塊較重視 內(nèi)部質(zhì)量 難以直觀衡量代碼規(guī)范 可讀性 架構(gòu) 性能 重構(gòu) 設(shè)計模式目前對這塊不夠重視 也沒有成型的衡量方法 技術(shù)債務(wù) 代碼經(jīng)過一段時間的修改 會越來越糟 除非我們花時間去解決代碼的 壞味道 敏捷開發(fā)的價值觀 個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循計劃雖然右項也有價值 但是認為左項具有更大的價值 我的理解 可用的軟件 應(yīng)該始終處于第一優(yōu)先級 總是先做價值最大 優(yōu)先級最高的事情 加快交付 反饋 修改的循環(huán) 需求變化是必然的 但是可以保證一段時間內(nèi) 一個迭代 不發(fā)生變化 一個功能完成了99 但是無法給到其他人體驗 價值為0 持續(xù)集成 敏捷開發(fā)的核心 持續(xù)集成 核心理念 Don tRepeatYourself重復(fù)勞動應(yīng)該由計算機去完成 持續(xù)集成的周期可以作為 敏捷程度 的衡量標準ZingChat的周期是2 3天 業(yè)界的 完美 指標是15分鐘 盡早測試 盡早體驗 解決 價值 的問題自動測試和部署 解決 內(nèi)部質(zhì)量 的問題 對于IBG的客戶端產(chǎn)品 難點在于自動測試自動部署與server更加相關(guān) 也有很大優(yōu)化空間 自動構(gòu)建 加快版本發(fā)布的速度減少重復(fù)工作防止人為造成的錯誤 ZingChat自動構(gòu)建的時間 0 5小時人工檢查 1小時機器build 靜態(tài)代碼檢查 衡量 技術(shù)負債 ZingChat正在考慮后續(xù)引入檢查工具 自動測試 測試不只是測試人員的事情 產(chǎn)品質(zhì)量是由開發(fā)和測試共同保證 人工黑盒測試是必不可少的 特別是對于新需求的完善很有價值 為了保證已有功能的可用性 采用人工的方式成本太大 而目前我們大量工作花費在這一點上 目標依然是 減少重復(fù)工作量 單元測試是開發(fā)人員的工作 手工做 自動做 單元測試 現(xiàn)狀 開發(fā)人員手工做自測 沒有單元測試代碼寫代碼做單元測試 可重用 是自動測試的一部分在C 中 進行測試的基本單元是類必須是可重復(fù)的 無論是在軟件修改 或是移植到新的運行環(huán)境的過程中 都要可用 所有單元測試用例必須一直進行維護 下面我們來列舉一些案例這些案例都有實際的原型作為對比 我設(shè)想了一些 完美世界 的場景 如果我們把敏捷做到極致 事情是否會不一樣 案例1 經(jīng)過幾天的開發(fā) 提交了一個客戶端轉(zhuǎn)測試版本 經(jīng)過2個小時的測試 發(fā)現(xiàn)該版本有嚴重問題 協(xié)議號不正確 測試被打回 而協(xié)議號設(shè)置是開發(fā)手工操作 新的版本提交還是要靠人工手段確保協(xié)議號正確性 完美世界 自動編譯腳本每半個小時就自動編譯一次 并且跑一遍自動化測試腳本 腳本中包含了檢查協(xié)議號正確性的用例 一旦出現(xiàn)錯誤 就會發(fā)出郵件知會相關(guān)人 提問 如何盡早的發(fā)現(xiàn)嚴重問題 案例2 測試 這個bug不是在上個版本已經(jīng)修復(fù)了么 怎么這個版本又出現(xiàn)了 開發(fā) 原因是blablabla測試 有沒辦法避免這種情況 不然測試老是做重復(fù)工作 完美世界 測試 這個bug不是在上個版本已經(jīng)修復(fù)了么 怎么這個版本又出現(xiàn)了 開發(fā) Sorry 我忘記把這個bug的單元測試用例加入dailybuild腳本 本來單元測試應(yīng)該能檢查出這個問題的 測試 那下次這個bug不會再出現(xiàn)了 開發(fā) Yes 如果又出現(xiàn)了 我會馬上收到單元測試沒通過的郵件 提問 如何避免重復(fù)犯相同的錯誤 案例3 測試 avatar功能是不是失效了 運維 服務(wù)器好像沒問題 客戶端能否幫忙聯(lián)調(diào)一下 開發(fā) OK 開始打開VC 開工程 設(shè)置斷點 定位問題 找到原因 解決了 兩天后 測試 avatar功能又失效了 開發(fā) 我再查下看看 開始打開VC 設(shè)置斷點 手工確認協(xié)議是否正常 找到原因 解決 完美世界 有avatar模塊的針對業(yè)務(wù)關(guān)鍵點的單元測試用例 之后 問題 如何快速定位問題 避免重復(fù)的工作量 案例4 PM 完成這個新需求工作量大么開發(fā) 挺大 原有的代碼太亂了 修改這里導(dǎo)致1 2 3 4處要一起改 開發(fā) 這塊可以考慮重構(gòu)甚至重寫 給出適應(yīng)我們需求的架構(gòu)測試 那是不是代表對于這塊的測試需要全部重做 開發(fā) 是的 我們沒有辦法保證重構(gòu)的代碼不造成新的bug 完美世界 在新需求提出前 開發(fā)就發(fā)現(xiàn)單元測試的編寫很痛苦 提出一些模塊應(yīng)該重構(gòu) 問題 重構(gòu) 代價大 我們離 完美世界 有多遠 重構(gòu) 設(shè)計模式 聽起來很好 但是似乎和我沒關(guān)系 項目進度都趕不急 哪有時間去重構(gòu) 我們的開發(fā)工作都是對已有系統(tǒng)的改造 似乎很少需要設(shè)計模式 誰來提重構(gòu)的需求 怎么平衡 設(shè)計 和 過度設(shè)計 是否在新開發(fā)一個功能之前就要盡量做好設(shè)計 敏捷開發(fā)的觀點 能很容易編寫單元測試用例的代碼 質(zhì)量是較高的 當單元測試不再容易編寫的時候 說明代碼需要重構(gòu) 在業(yè)界 重構(gòu)是有較為成熟的方法 可以系統(tǒng)學習的 設(shè)計模式為重構(gòu)過程提供模板和思路 自動測試是基礎(chǔ) 否則難以進行 現(xiàn)在 我們能做什么 自動構(gòu)建 初步成型 繼續(xù)優(yōu)化挑戰(zhàn) 如何自動化給出代碼的修改點 自動提交測試 Checkin 自動編譯 自動提交體驗測試 自動測試 自動測試 長路漫