質量保證系列課件-敏捷項目過程介紹(V)

質量保證系列課件——敏捷項目過程介紹——2011年3月21.敏捷核心理念1.1敏捷宣言1.2.敏捷原則1.3.敏捷理念1.4.瀑布、迭代和敏捷的區(qū)別2.敏捷優(yōu)秀實踐3.敏捷流程介紹目錄1.1敏捷宣言3敏捷宣言本質是揭示一種更好的軟件開發(fā)方式，啟迪人們重新思考軟件開發(fā)中的價值和如何更好的工作。我們認為左項具有更大的價值－－當然這并不意味著右項沒有價值個體和交互過程和工具勝過可以工作的軟件面面俱到的文檔勝過客戶合作合同談判勝過響應變化遵循計劃勝過1.2敏捷原則4我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。可以工作的軟件是首要的進度度量標準。在整個項目開發(fā)期間，業(yè)務人員和開發(fā)人員必須天天都在一起工作。圍繞被激勵起來的個體來構建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。在團隊內部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。敏捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應該能夠保持一個長期的、恒定的開發(fā)速度。不斷地關注優(yōu)秀的技能和好的設計會增強敏捷能力。簡單

—

使未完成的工作最大化的藝術—是根本的。最好的構架、需求和設計出自于“自組織”的團隊。每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后響應地對自己的行為進行調整。敏捷=理念+優(yōu)秀實踐+應用理念（核心思想）應用1.3敏捷理念優(yōu)秀實踐（經驗積累）51.3.1Value：聚焦客戶價值，消除浪費6Source：《如何提升軟件開發(fā)效率》08年統(tǒng)計華為：研發(fā)版本廢棄特性07.1-08.6年某產品線所有產品中重要特性無應用的比例達22%（需求變更和分析不足占63%）軟件業(yè)：45%的軟件特性客戶沒有使用Source：StandishGroup來自5萬個軟件開發(fā)項目的調查可以工作的軟件面面俱到的文檔勝過客戶合作合同談判勝過1.3.2Team：激發(fā)團隊潛能，加強協(xié)作7團隊是價值的真正創(chuàng)造者，應加強團隊協(xié)作、激發(fā)團隊潛能。軟件開發(fā)是一種團隊活動，首先應做到提升溝通效率降低交流成本。效率流行度文檔錄制的視頻錄制的音頻2人郵件溝通2人白板溝通2人電話溝通不支持問答形式支持問答形式業(yè)界調查：50人團隊，每人平均30%時間用于編碼，70%的時間用于與其他成員交流。需求變更降低比例補充場景數TR4前發(fā)現缺陷比例版本周期縮短（周數）無線49.36%8855.90%2.82核心網45%19045.18%3.5網絡31%33042.5%2.6業(yè)軟30%30048.15%2.1公司平均38.84%90847.93%2.76華為試點調查：開發(fā)測試拉通，效率質量改善明顯個體和交互過程和工具勝過1.3.3Adapting：不斷調整以適應變化8能夠結合自身靈活應用才是真正敏捷，不斷的根據經驗調整，最終交付達到業(yè)務目標的產品軟件開發(fā)是復雜不可預測的經驗控制過程隨軟件規(guī)模增長，需求變化呈非線性增長響應變化遵循計劃勝過1.4瀑布、迭代和敏捷的區(qū)別9瀑布：開發(fā)模型重量級：所有需求統(tǒng)一步伐，全部分析完畢后再開始設計，全部設計完畢后再啟動編碼…重過程：有明顯的過程，每個過程不重疊，界線清晰—SRS、HLD、LLD、Coding、UT、IT、ST，開發(fā)完畢后集中轉測試。迭代：開發(fā)模型中量級：需求分成多批，每批一輪迭代，每輪內都是小瀑布；每輪迭代出一個版本交付測試。沒有明顯的過程。敏捷：開發(fā)模式輕量級：需求分解成更小粒度，每個小粒度需求1～3天實現，并立即轉測試。從瀑布、迭代到敏捷，是量變引起質變。（每輪迭代結束時出版本并不是測試的開始，更多的是開發(fā)和測試共同結束點）過程：在一個過程框架下，嵌入了很多敏捷實踐，并由很強的原則進行約束。開發(fā)模式之外，更是一種思想、理念、文化！101.敏捷核心理念2.敏捷優(yōu)秀實踐2.1.迭代開發(fā)2.2.持續(xù)集成2.3.Story驅動2.4.站立會議2.5.完整團隊2.6.可視化管理2.7.結對編程2.8.TDD2.9.RCA2.10.演示3.敏捷流程介紹目錄2.1.迭代開發(fā)11什么是迭代開發(fā)迭代開發(fā)是將整個軟件開發(fā)生命周期分成多個小的階段（一般2-4周），每個階段都開展需求分析、設計、實現和測試，每個階段都可以生成一個穩(wěn)定和被驗證過的軟件版本。通過將高技術風險的需求在早期迭代里實現，有助于盡早暴露問題和及時消除風險。通過提供功能漸增的產品，持續(xù)獲得客戶反饋，根據反饋及時調整，使產品更加符合客戶需要。確保每次迭代交付質量，避免形成技術債務，每一次迭代都必須建立在穩(wěn)定的質量基礎上，并做為下一輪迭代的基線，整個系統(tǒng)的功能隨著迭代穩(wěn)定地增長并不斷完善。每次迭代要邀請用戶代表（外部或內部）驗收，提供需求是否滿足的反饋。如果迭代周期已到，無論任務是否結束，也要求終止當前迭代，未完成任務放到下次迭代再做。迭代開發(fā)的好處迭代開發(fā)的關鍵點2.2.持續(xù)集成12

持續(xù)集成（CI）要求團隊成員經常集成他們的工作，以驗證新合入的變化沒有造成任何破壞，通常每人每天至少集成一次，每次集成通過自動化構建完成。維護單一的代碼配置庫，每個人每天將對代碼的改動提交配置庫。實現構建自動化

--自動的度量、檢查和測試，減少了重復的人力活動持續(xù)集成要盡量快，最好快到5分鐘內能完成本地構建，30分鐘內完成產品提交構建，8小時內完成每日構建。持續(xù)集成的問題是項目組最高優(yōu)先解決的問題。構建成功率和頻率是衡量CI效果的重要指標。每個人都較容易得到最新可正常運行的軟件。持續(xù)集成實現“無事件”局面，盡早發(fā)現項目存在的問題，減少返工。降低風險，在缺陷引入的時候即被發(fā)現，缺陷容易修復給頻繁的應用部署提供幫助，隨時都可能發(fā)布軟件。持續(xù)集成的好處持續(xù)集成操作關鍵點什么是持續(xù)集成2.3.Story驅動13Story驅動是指以Story為交付單元進行開發(fā)、測試、發(fā)布Story是能夠獨立交付，能夠被用戶感知的最小需求UserStory是Story開發(fā)的基準，它從客戶的角度描述Story所需要實現的功能傳統(tǒng)項目：所有功能Story驅動項目：測試測試Story…測試…Story1StoryN只一個開發(fā)周期，所有功能開發(fā)完成后，集成進行測試每個Story為一個開發(fā)周期，每完成一個Story即轉入測試狀態(tài)，并與已完成的Story不斷集成需求設計CODE測試2.4站立會議團隊成員的例行溝通機制，每天固定時間、固定地點、不超過15分鐘，Team成員全體站立參加：從上次會議之后完成了哪些工作？在下次會議之前準備完成哪些工作？在工作進行中存在哪些障礙？有哪些好的實踐或學到了哪些教訓？14增加團隊凝聚力，產生積極的工作氛圍,及時暴露風險和問題。整個團隊都清楚團隊內部所發(fā)生的事情。每日跟進工作進展，快速解決問題或提供幫助。會議中禁止針對問題的討論，如果需要討論，將在會后進行。會議提出的問題必須被記錄，并在會后鏟除障礙。團隊是在互相匯報和交流情況，并不是向PO、項目經理或敏捷教練匯報。站立會議的好處站立會議關鍵點2.4站立會議案例15目的：通過站立會議實現團隊自我管理陳述昨天開展什么工作時，以Story為中心，從工作對象、進展和工作質量等方面進行總結。比如“昨天我開展測試”＝＝》“昨天我開展哪個Story測試，測試了多少用例，發(fā)現了多少問題，其中哪些問題比較嚴重值得關注”；比如“昨天我編碼完成”＝＝》“完成Story代碼寫作，findbugs全部清零，自測試通過，合入服務器，編碼過程中，我發(fā)現某兩個類有重復代碼，可以優(yōu)化…”每個人都要把覺得對團隊有價值的想法說出來；昨天做了什么事情，或是想到什么事情對團隊有幫助；你知道哪些事情是大家需要知道的。切忌對別人的話漠不關心、描述從燃燒圖上就能看到的進度，比如昨天做某個Story，今天計劃做某個Story等,會后又發(fā)現很多問題。Team：

系統(tǒng)、開發(fā)、測試、資料在一個團隊內，并且全程參與項目團隊之間采用最高效的溝通方式——面對面的溝通角色主要職責POProductOwner（產品所有者），負責將客戶的需求信息化并傳遞給項目組，代表利益相關人（如用戶、Marketing、用服、管理者等），對產品投資回報負責Story分解和澄清，確保需求理解一致項目組內維護架構、確保設計思路一致劃分Story并輸出迭代backlog，隨時澄清需求參與showcase、驗收storyMaster團隊的教練和組織者，幫助團隊正確應用敏捷實踐，引導團隊建立并遵守規(guī)則組織開工會、站立會議、回顧會議監(jiān)控整個項目的進度、質量、風險CI-COCICoordinator（持續(xù)集成協(xié)調員），負責持續(xù)集成的正常運轉2.5.完整團隊16HSS質量部PM開發(fā)測試資料CMO(兼)CI-CO(兼)MasterPOQA質量保證項目組2.6.可視化管理故事墻（展示Story進度）缺陷走勢圖（展示缺陷解決進展）特性墻項目組計劃墻燃盡圖（BurnDownChart）17可視化管理的好處簡單，一目了然，降低管理成本；實時狀態(tài)顯示，及時暴露問題；信息同源，使團隊理解一致，提升團隊凝聚力；激勵先進，鞭策后進，增強團隊進取心?？梢暬芾硇问脚e例2.7.結對編程什么是結對編程結對編程是指兩位程序員在一臺電腦前工作，一個負責敲代碼，另外一個實時檢視。負責操作鍵盤和鼠標的程序員被稱為“駕駛員”，負責實時評審和協(xié)助的程序員被稱為“領航員”；領航員檢視的同時還必須負責考慮下一步的工作方向，比如可能出現的問題以及改進等。18有助于提升代碼設計質量，大幅促進團隊能力提升和知識傳播。幫助快速培訓新手。來自同伴的競爭壓力，能起到有效的激勵作用。知識和良好的實踐在兩人之間共享。結對的兩人時間要同步。結對編程要多花15％的時間，在時間緊迫時結對是比較困難的事情。結對編程的好處結對編程的風險和挑戰(zhàn)2.8.TDD19TestDriveDevelop測試驅動開發(fā)，是驅動軟件設計和實現的有效手段，是在有測試保證的環(huán)境下以一種簡單的、增量式的方法構建軟件。TDD可以借助測試的約束幫助開發(fā)人員在正確的時間作出正確的決策。不需要強調一次性把代碼寫到最好，通過使用TDD和不斷地重構代碼和測試代碼可以讓軟件最終滿足客戶需求。TDD五部曲針對要新增的功能，編寫測試用例（代碼）。運行測試用例不能通過。編寫產品代碼，直至運行測試通過。重構代碼，以消除重復設計，優(yōu)化設計結構。執(zhí)行所有用例通過。RCA（RootCauseAnalysis）缺陷根源分析，目的是為了更好地做好缺陷預防,問題如何在后續(xù)迭代開發(fā)中改進和避免。20

缺陷預防的成本最低。

RCA和缺陷預防是CMM的優(yōu)秀實踐，希望我們在敏捷項目繼續(xù)發(fā)揚光大。2.9.RCA

ShowCase（迭代演示）

也稱客戶驗收，在迭代測試階段PO或測試人員向客戶代表做一個全面的演示,能及時定期地提供反饋信息，加強對產品的信心，對于客戶反饋的問題可以選擇在當前迭代周期內解決或遺留到下一次迭代（也許就是下一次迭代的需求），問題一定要記錄跟蹤關閉。212.10.演示演示注意事項：不需要刻意準備，我們只演示已完成的特性要重點關注功能，不要過多地糾纏細節(jié)，要知道參加演示的人員時間都很寶貴。

提前進行：如果開發(fā)過程中，通過口頭交流還是難以把握需求（比如界面類需求），可以在功能基本跑通時，就進行showcase，以盡早獲得反饋，盡早調整。221.敏捷核心理念2.敏捷優(yōu)秀實踐3.敏捷流程3.1.實踐選擇原則3.2.敏捷開發(fā)框架3.2.1.迭代準備3.2.2.迭代3.2.3.發(fā)布測試目錄RCA???3.1.實踐選擇注意項23在充分理解敏捷理念的前提下，因地制定宜地選擇適合的敏捷實踐站立會議持續(xù)集成TDD結對編程迭代開發(fā)Story驅動完整團隊可視化管理……演示軟件公司敏捷項目，要求開展四個基本實踐、三類測試活動、三類項目管理會議四個基本實踐：迭代開發(fā)、持續(xù)集成、Story驅動、完整團隊三類測試活動：Story測試、迭代測試、SIT測試三類項目管理會議：迭代計劃會議、每日站立會議、迭代回顧會議驗收準入評估點立項計劃實施驗收發(fā)布生命周期可行性評估點計劃評估點迭代N迭代2迭代1迭代發(fā)布評審點......發(fā)布測試發(fā)布測試發(fā)布測試迭代準備迭代開發(fā)發(fā)布測試3.2.敏捷開發(fā)框架243.2.1.迭代準備(1/2)25

組建團隊敏捷辦公環(huán)境布置

可視化管理準備

搭建持續(xù)集成環(huán)境3.2.1.迭代準備(2/2)26評估項目交付范圍、規(guī)模、復雜度、項目周期、準備采用哪些敏捷實踐以及需要哪些培訓等。制定項目的整體計劃（粗略的迭代計劃）：根據項目人力、時間等資源，劃分迭代，確定迭代輪次、每輪迭代的范圍（主要包含Story列表）、最終SIT時間等。項目初始評估、制定項目計劃

項目啟動會議Story分析、估計項目啟動是很正式的事情，由所有的利益相關人參加。收集各職能團隊的承諾，這些團隊包括開發(fā)組、測試組、資料開發(fā)組、質量組、客戶、管理組以及其它項目相關的組織。

PO對需求規(guī)格進行分解，轉換成story條目，設置優(yōu)先級，完成Story的初步估計，并挑選迭代1的story完成分析。伴隨Story要同時輸出可接受性測試用例（AcceptanceTestCase，簡稱AT）--必須要通過軟件開發(fā)人員、測試人員、資料開發(fā)人員、客戶的評審3.2.2.迭代–迭代流程27持續(xù)集成

迭代開發(fā)迭代驗收迭代測試需求澄清、Story分解迭代計劃收尾評估、回顧Story開發(fā)過程不斷重復，直到迭代計劃Story結束3.2.2.迭代–迭代計劃28PM按照Story的優(yōu)先級和相關度，將最佳或對客戶最為重要的Story作為初始迭代的一部分進行規(guī)劃，確定本次迭代的目標。召開迭代計劃會議，PO按優(yōu)先級澄清本次迭代將實現的Story，以明確需求要做成什么樣子、驗收條件是什么，由團隊對每個Story做估算，達成一致，并進行認領，故事交付計劃由故事認領人來確定，并作出承偌。如果會議中，團隊覺得Story的粒度需要分解，可以對Story進一步的拆分。3.2.2.迭代–迭代開發(fā).流程29故事開發(fā)過程不斷重復，直到迭代計劃故事結束Story分析代碼和測試碼評審測試代碼，代碼準備、運行

和重構故事卡AT測試測試用例

準備測試用例評審故事測試檢查表更新故事交付檢查表更新故事卡相關資料文檔開發(fā)資料開發(fā)人員進行同行評審軟件開發(fā)人員評審資料原型Story測試Story簽收SDV測試用例自動化測試代碼評審資料交付檢查表更新3.2.2.迭代–迭代開發(fā).Story分析30在開發(fā)某個故事前，PO、開發(fā)、測試、資料對復雜的Story進行一個簡短的頭腦風暴，側重Story如何實現以及各種測試場景。建議在頭腦風暴之前，熟悉story和驗收條件，開發(fā)輸出Story設計文檔，測試輸出測試點，然后再召開會議。有思考后再與會，效果往往會更好。直接澄清需求是正向理解需求，討論測試點和實現方案是逆向理解需求，“正向+逆向”能確保需求理解的更充分。簡單的story可以在需求澄清后直接進入編碼。會議簡短高效，在座位上召開即可，一般10～30分鐘。31什么是Story簽收？Story簽收是轉ST的入口，用于檢驗開發(fā)者與客戶在功能理解上的一致性，簽收責任人--開發(fā)人員（Pair）、故事測試人員、資料人員、PO

3.2.2.迭代-迭代開發(fā).Story簽收

Story簽收必須在持續(xù)構建版本上進行，不能在程序員本機環(huán)境操作。用于簽收的AT（可接受性測試用例），必須是已經過團隊的評審并達成一致理解的，簽收通過的基本條件是AT必須通過。

簽收過程中提出的新需求，盡量啟動新的Story跟蹤。

簽收的形式可以多樣化，可以是簽收者直接體驗，也可以是開發(fā)者演示。

Story必須經過開發(fā)人員的自測試，才能進入簽收，正常情況下單個Story的簽收時間是非常短暫的，大概是幾分鐘到十幾分鐘的樣子。Story簽收注意事項：323.2.2.迭代-迭代開發(fā).Story測試Story測試Story測試是針對單個Story的功能和非功能測試，并分析其對整個系統(tǒng)的影響。Story測試的主體是測試人員。Story測試及問題回歸必須在持續(xù)構建版本上進行，不能在程序員本機環(huán)境操作Story測試出的問題，開發(fā)人員需要停下手頭新Story的開發(fā)工作優(yōu)先處理問題單，以保證已完成工作的有效性及完整性。當前的Story測試需要考慮與已完成Story的依賴關系。盡量避免只能到迭代末才能提供版本給測試。Story測試注意事項：3.2.2.迭代–迭代驗收迭代測試在完成ST（故事級測試）后，測試組再針對整個迭代范圍的所有Story（也會有針對前次迭代的回歸）進行完整的功能和非功能測試。測試的入口條件：所有ST通過。迭代測試要走正式的轉測試電子流。資料開發(fā)組評審也是在迭代測試范圍內進行。迭代測試的主體是測試人員。測試結束后需要給出測試報告。在迭代測試期間，測試人員的重點是進行探索性測試，重點關注非功能測試，比如性能測試設計測試用例以便在探索性測試中查找缺陷，使該過程自動化33回看過去，分析問題、明確措施、進行改進?；仡檿h內容：1.總結本輪迭代哪些地方做得好。2.總結本輪迭代哪些地方可以做得更好。3.得出最主要的改進建議（約3條），并在以后的迭代中持續(xù)跟蹤。343.2.2.迭代–收尾.回顧353.2.2.迭代–收尾.回顧每輪迭代末，或進展不暢時，都應召開回顧會議。迭代回顧會議是促進團隊持續(xù)改進的最有效手段。建議議程：開場：致歡迎詞；每個人用一兩個形容詞描述對本次回顧會議的期望；分析：回顧本輪迭代所有度量數據、圖表、完成的特性、重要問題、周邊評價等信息；信息收集：發(fā)給每人貼紙，10分鐘寫出白板上要求的內容，并自行貼到白板上；快速歸類：主持人發(fā)動大家一起歸類；快速分享：主持人念出貼紙上的內容，讓大家知道；探討TOP問題根因&解決方法：針對TOP3～5問題，使用頭腦風暴進行討論，并得出措施（可以分組也可以一起討論）；會后跟蹤：解決措施在下輪迭代就應立即實施，努力讓本輪TOP問題不再是下輪TOP問題。準備開會跟蹤關鍵道具3.2.3.發(fā)布測試發(fā)布測試（ReleaseTest），有時也稱SIT、系統(tǒng)驗收測試。測試范圍：所有迭代的綜合測試，包括功能和非功能測試，尤其關注性能測試等非功能測試。測試的主體在測試人員，要給出測試報告。每次正式的release前建議都要有這樣的測試。3637參考資料端到端定制敏捷開發(fā)生命周期.ppt軟件公司敏捷項目過程介紹V2.