Scrum敏捷軟件開發(fā)過程.ppt

Scrum敏捷軟件開發(fā)過程 2008 12 03 JinghuaLiQualityManagerTietoEnatorCorporationT MMDRMIDjinghua li 2 目錄 什么是敏捷軟件開發(fā) 敏捷方法的項目計劃敏捷項目管理和傳統(tǒng)項目管理為什么使用敏捷 Scrum概述Scrum的角色Scrum實踐和工作產(chǎn)品敏捷開發(fā)中的估計方法測試驅(qū)動開發(fā)Scrum應(yīng)用支持工具和模版一些常見的誤解 敏捷開發(fā)方法 4 什么是敏捷軟件開發(fā) 敏捷軟件開發(fā)是軟件項目的一個概念框架 有許多建立在敏捷概念上的方法 如Scrum和ExtremeProgramming XP 與僵化的 重量級的 官僚式的方法形成對照 比如瀑布模型 指純粹形式的 最大限度地降低短期固定時間的迭代式軟件的開發(fā)風(fēng)險 5 敏捷宣言 2001年 人和交互勝過過程和工具 Individualsandinteractionsoverprocessesandtools可以工作的軟件勝過完備的文檔 Workingsoftwareovercomprehensivedocuments客戶協(xié)作勝過合同談判 Customercollaborationovercontractnegotiation隨時應(yīng)對變化勝過遵循計劃 Respondingtochangeoverfollowingaplan 6 敏捷過程的限制 敏捷軟件開發(fā)過程包含過程 原則 工具 和最重要的 人因此誠信是基礎(chǔ)沒有過程能夠?qū)φ\信進行有效地約束誠信與否是有效實施敏捷過程的最大限制 7 使用敏捷方法的項目計劃 ProductBacklog Features 5213858 32 InitialSizeEstimatesAsStoryPoints Longtermplanning bestguessatthemoment 32SPoffunctionality TeamVelocity8SP Sprint 4SprintsTargetSprintforeachPBLitemset feasibleimplementationOrder SprintBacklog Tasks Sprintful oftop priorityPBLtothenextSprint Moreaccurateestimatesasmanhours Shorttermplanning commitmentbyTeam Maybeconstantlyupdated Scopefrozen newPBLitemstonextSprint 8 敏捷項目管理和傳統(tǒng)項目管理 傳統(tǒng)項目管理 事先對整個項目進行估計 計劃 分析反對變更 變更需要重新估計 重新規(guī)劃嚴密的合同來減少風(fēng)險 如果改變需求要走CR流程 項目作為一個 黑盒子 對客戶與供應(yīng)商的可視性差 產(chǎn)品化和測試階段是分離的 文檔和計劃驅(qū)動的方法 軟件交付時間晚 意識到風(fēng)險的時間晚 敏捷項目管理 對整個項目做一個粗略的估計 每一次迭代都有詳細的計劃 鼓勵變化 客戶價值驅(qū)動開發(fā) 信任和賦予權(quán)力 合約使變更變得簡單 增加價值 客戶和開發(fā)人員之間是緊密的連續(xù)的合作關(guān)系每次迭代都產(chǎn)生可交付的軟件專注于交付軟件 第一次迭代就可交付能工作的版本 風(fēng)險發(fā)現(xiàn)的早 9 為什么采用敏捷 預(yù)期的收益 采用敏捷方法得當(dāng)?shù)脑?可以 更加透明 隨時跟蹤項目的狀態(tài)和進展情況 及早發(fā)現(xiàn)問題和風(fēng)險 快速交付 每次迭代都能交付可運行的軟件 最高風(fēng)險和最高優(yōu)先級的需求 最優(yōu)先進行開發(fā) 改善應(yīng)對變更能力 減少大量的重計劃 改善項目溝通 更好的客戶參與 避免錯誤的假設(shè) 總之 提高了生產(chǎn)率 減少 浪費 不需要的文檔 重復(fù)工作等 項目的每次迭代都有明確的目標 提高客戶滿意度 短期內(nèi)產(chǎn)生成效 按預(yù)期交付軟件 每次迭代結(jié)束產(chǎn)生可以運行的軟件 改善員工的滿意度 團隊精神 減少官僚 能夠規(guī)劃和管理自己的工作 減少 恐慌 穩(wěn)定的工作量 可持續(xù)的步伐 10 敏捷方法何時有效 公司和客戶一致認為應(yīng)當(dāng)使用敏捷方法 雙方都能理解敏捷方法 敏捷方法對需求不完整以及經(jīng)常變換的項目比較有效 項目可以劃分成固定時間間隔的迭代 并且可以凍結(jié)正在進行的迭代的范圍公司和客戶都有能力擔(dān)當(dāng)角色尤其是ProductOwner和ScrumMaster 項目的人員結(jié)構(gòu)能夠分成6到10人的團隊 最好每個工作地點一個小組 團隊成員能夠以自組織的方式工作 項目的合同允許變更 固定價格的項目可以使用敏捷 但應(yīng)當(dāng)盡量避免 最好在按時間和材料付費或者按月付費的項目中進行使用 變更項目的范圍不需要高級管理層的批準 11 警告 敏捷開發(fā)過程是一個艱苦的過程AgileWorkisHardWork這種狀態(tài)也許會存在很長時間 不舒服疑惑有挫折感 Scrum概述 13 Scrum概述 1 3 Scrum是管理軟件項目的一個輕量級的敏捷方法 名字來源于橄欖球運動中的scrum過程簡單 但高度的紀律性依賴迭代和增量的敏捷方法 Scrum是一種工作管理的方法 不僅僅限于軟件開發(fā) 可以用來管理其它活動 Scrum不包含技術(shù)方法或?qū)嵺` 14 Scrum概述 2 3 項目的階段 項目分成增量的迭代過程 在Scrum中稱為迭代任務(wù)清單 通常持續(xù)2 4周的時間 Sprint的時間是限定好的 不能從外部改變正在進行中的sprint持續(xù)時間和范圍 每個sprint都可以產(chǎn)生可交付的迭代 即測試過并具備文檔的的功能點原則上 當(dāng)產(chǎn)品開發(fā)到一定程度時 如實現(xiàn)了足夠的客戶價值 項目可以在任何一個sprint后結(jié)束 如同任何項目 敏捷的項目有三個主要階段 產(chǎn)品定義 規(guī)劃 運行Sprints所需要的準備 規(guī)劃 技術(shù)分析 執(zhí)行Sprints 執(zhí)行 在增量時間段內(nèi)實現(xiàn)需求 產(chǎn)品需求清單 結(jié)束 準備最終發(fā)布 結(jié)束項目 15 Scrum概述 3 3 SprintPlanningMeeting NextSprintGoalSprintBacklogUpdatedProductBacklog DailyScrummeetings WhatdidyoudoyesterdayWhatwillyoudotoday Whatobstaclesareinyourway Source DailyScrum SprintRetrospective ShippableProductIncrement Scrum角色 實踐和工作產(chǎn)品 17 Scrum中的三種角色 ProductOwner 產(chǎn)品所有者個人 代表所有的干系人ScrumMaster 個人 負責(zé)指導(dǎo)過程的執(zhí)行ScrumTeam Scrum團隊 承諾完成工作 向干系人交付產(chǎn)品價值 18 Scrum角色 Scrum團隊 Scrum團隊是Scrum的中心角色 產(chǎn)品交付要依靠團隊 Scrum團隊自我組織 自我管理Scrum團隊是職能交叉的 包含產(chǎn)品交付的所有角色 開發(fā)人員 測試人員 buildmanagers 文檔編寫 界面設(shè)計人員 Scrum團隊中的角色是不分等級的 不應(yīng)當(dāng)出現(xiàn) 我是開發(fā)人員我不作測試 團隊按照最有利于項目的原則來分擔(dān)責(zé)任 如組件的所有權(quán)等 敏捷是建立在信任和授權(quán)的基礎(chǔ)上 因此團隊是自發(fā)組織的 組員選擇自己的任務(wù) 而不是別人強制加以分配的 另一方面 Scrum團隊有交付的責(zé)任 他們需要能夠自我激勵和對工作目標進行承諾 團隊最佳規(guī)模 6 10人 19 Scrum角色 Scrum團隊 主要職責(zé)參與迭代任務(wù)清單的創(chuàng)建執(zhí)行為干系人創(chuàng)造價值的工作根據(jù)團隊的承諾完成所需的各項任務(wù)將工作中的各項障礙迅速與ScrumMaster進行溝通全面參與所有的各項會議更新任務(wù)狀態(tài)自發(fā)選擇任務(wù)標識任務(wù)的完成標識發(fā)現(xiàn)的新的任務(wù)與其它團隊共同進行工作 20 Scrum角色 ScrumMaster ScrumMaster不是一個管理者 而是一個教練和推動者 Scrum團隊是一種自發(fā)的組織 是自我管理的 ScrumMaster的角色通常由項目組的成員擔(dān)當(dāng) 組長或者項目經(jīng)理 ScrumMaster應(yīng)當(dāng)是項目中的成員 主要職責(zé) 評價過程的健康狀況加強過程消除障礙促進過程改進支持團隊開發(fā)ScrumMaster的主要工作是做決策 消除障礙 保證團隊能順利交付產(chǎn)品 21 Scrum角色 ScrumMaster ScrumMaster還有如下責(zé)任與其它角色配合 訓(xùn)練團隊 提高生產(chǎn)率 培訓(xùn)產(chǎn)品所有者和干系人 確保Scrum流程的執(zhí)行確保一切工作按照既定的規(guī)范來運行 規(guī)劃并進行必要的改進 推動會議的召開 維護障礙列表維護Scrum過程改進列表優(yōu)秀的ScrumMaster應(yīng)當(dāng)是專注的 有決心的 有領(lǐng)導(dǎo)才能 22 Scrum角色 ProductOwner 產(chǎn)品所有者代表投資方的利益 確保交付的產(chǎn)品與期望的一致 提供更好的投資回報 ProductOwner決定產(chǎn)品具有哪些功能 ProductOwner s的主要責(zé)任是創(chuàng)建和維護產(chǎn)品需求清單 即管理項目的范圍 ProductOwner不斷的把產(chǎn)品需求清單按優(yōu)先級進行排序 使得最重要的功能能優(yōu)先實現(xiàn) 對于團隊來說 只有一個需求集 所有的需求申請都歸口到ProductOwner管理商業(yè)價值 投資回報 ProductOwner還有如下責(zé)任 計劃項目的發(fā)布 什么時間 向什么人等 對每次Sprint的結(jié)果進行評審和批準 23 Scrum角色 ProductOwner 參與Scrum會議迭代計劃會議團隊進展跟蹤會議迭代評審和回顧會議能夠隨時回答團隊工作中產(chǎn)生的各項和產(chǎn)品 業(yè)務(wù)相關(guān)的問題ProductOwner的角色一般由客戶擔(dān)當(dāng) 作為服務(wù)提供商的公司無法設(shè)定優(yōu)先級 24 Scrum角色 客戶與管理層 客戶和管理的角色是可選的 需要時才設(shè)立客戶 是產(chǎn)品的最終用戶通過ProductOwner來設(shè)定對產(chǎn)品的期望把當(dāng)前的業(yè)務(wù)傳達給項目 管理層 公司高級管理層 代表公司在項目中的利益 通過ProductOwner來傳達公司的利益和優(yōu)先級 priorities 25 產(chǎn)品需求清單ProductBacklog 1 4 概論 基本上 產(chǎn)品需求清單是為了實現(xiàn)產(chǎn)品的功能所需要的工作的列表 包括 功能方面的需求 功能點 非功能方面的需求 如性能改進 要修改的Bug 上一版本的已知錯誤 新技術(shù) 如支持新的操作系統(tǒng)或者平臺 問題 日后的不確定項 如新的功能 產(chǎn)品需求清單是不斷完善的 ProductOwner在項目進行過程中可以隨時更新 增加 刪除 修改功能 變更優(yōu)先級等 下一次迭代中要包含較高優(yōu)先級的需求 產(chǎn)品需求清單也可稱為UserStories 用例 因為它們能夠給產(chǎn)品的用戶帶來價值 在一次迭代中要能夠?qū)崿F(xiàn)產(chǎn)品需求清單 如果不能全部實現(xiàn)要進行分解 26 產(chǎn)品需求清單 2 4 構(gòu)成 ProductOwner負責(zé)創(chuàng)建最初的產(chǎn)品需求清單 一開始是不完整的 最初的清單應(yīng)當(dāng)包含足夠的需求 清單應(yīng)當(dāng)包含多少需求 取決于定價模型 black box 更多的計劃時間 產(chǎn)品需求清單來源于 客戶 標書 需求規(guī)格說明等 Scrum團隊的想法 增強型新功能等 現(xiàn)有產(chǎn)品的迭代增量 已知錯誤 技術(shù)問題等 比較好的做法是ProductOwner Scrum團隊 客戶 管理以及其它相關(guān)方 如相關(guān)的Scrum團隊 舉行一次或者多次研討會ScrumMaster或者ProductOwner來促成會議的召開 必須要有人來做 要有效率 要圍繞主題 溝通良好 避免不同的假設(shè) 承諾并且共通合作 確定優(yōu)先級 27 產(chǎn)品需求清單 3 4 估計 Scrum團隊對產(chǎn)品需求清單的每一項的規(guī)模提供初步的估計 通常采用事件點作為單位StoryPoints 模糊的 也可采用人天或者人小時作為單位 但容易混淆 a 實際的規(guī)模b 時間的單位 精確的估計值可以在Sprint規(guī)劃時給出 當(dāng)前階段沒有足夠的信息 規(guī)模的相對值才有意義 這個估計值有助于確定優(yōu)先級 所需時間 團隊速度 產(chǎn)品規(guī)模 28 產(chǎn)品需求清單 4 4 優(yōu)先級 優(yōu)先級是產(chǎn)品需求清單中的主要問題 優(yōu)先級不但反映了客戶的價值也反映了風(fēng)險 產(chǎn)品所有者 PO設(shè)定優(yōu)先級 清單中的每一項的優(yōu)先級是唯一的 但可以對它們進行分類優(yōu)先級可以在項目的任何時候進行更改 如新的重要的功能可以直接給較高的優(yōu)先級 確定優(yōu)先級考慮 價值風(fēng)險依賴關(guān)系 29 產(chǎn)品需求清單 示例 Priority ID likeinanyrequirementsdocument Descriptionoftheitem UserStory ThesewilllikelyendupinthefirstSprint 30 版本發(fā)布計劃 在Scrum中 不是每個Sprints都要發(fā)布一個版本 迭代的結(jié)果主要是要實現(xiàn)功能的演示 不一定就是發(fā)布的版本 版本發(fā)布計劃決定了每次迭代應(yīng)當(dāng)包含產(chǎn)品需求清單的哪些功能 根據(jù)現(xiàn)有的信息制定的項目總體的長期的計劃 根據(jù)產(chǎn)品需求清單和團隊的進度來決定 實施的范圍 迭代 e g inStoryPoints Scrum團隊參與版本發(fā)布計劃的制定 架構(gòu) 風(fēng)險 依賴性決定了可行的實現(xiàn)順序 版本發(fā)布計劃很大程度上依賴于客戶的時間表和發(fā)布周期 即什么時候客戶的產(chǎn)品需要包含我們的模塊 交付物 版本發(fā)布計劃不是一成不變的 每個迭代結(jié)束后都可以更改 31 完成的定義 當(dāng)?shù)蝿?wù)清單上的任務(wù)都完成時 變?yōu)?已完成 狀態(tài)定義 已完成 的含義是非常重要的 例如 如何記錄軟件的變化 使用什么樣的代碼分析工具 發(fā)現(xiàn)的問題應(yīng)當(dāng)如何處理 進行了什么樣的測試 結(jié)果是如何記錄的 通過標準 如覆蓋率 修正的錯誤 是什么 定義 已完成 意味著定義質(zhì)量上的需求 已完成 是0 1變量 完成或者未完成 所有的任務(wù) task 都完成了迭代任務(wù)才算完成 在第一個迭代開始之前應(yīng)該定義好 因為它會影響工作量 而且必須文檔化 這樣團隊和產(chǎn)品所有者的理解是一致的 32 完成的定義 完成的范圍隨著團隊的成熟程度會逐漸發(fā)生變化 潛在的可交付的軟件 33 完成的定義 Example 完成的定義遵循編碼規(guī)范能在模擬器上演示使用PCLint進行靜態(tài)代碼分析具有EUnit測試套件的通過率和執(zhí)行率 或者使用結(jié)對編程 或者進行代碼走查 34 迭代任務(wù)清單規(guī)劃 1 5 總論 迭代任務(wù)清單規(guī)劃的主要目的是從產(chǎn)品任務(wù)清單中挑選高優(yōu)先級的任務(wù)包含在下一次迭代中 即確定迭代的范圍 至于能夠包含多少產(chǎn)品任務(wù)清單中的任務(wù)取決于Scum團隊能夠承諾完成多少 承諾總是來自于內(nèi)部 不能從外部強加 迭代不應(yīng)當(dāng)有空閑時間 因此規(guī)劃迭代范圍時要保證工作量是穩(wěn)定的 進度是持續(xù)的速度 依賴多個因素 團隊的能力 技術(shù)的成熟度 當(dāng)前迭代增量的情況等 迭代的范圍在迭代任務(wù)清單中描述 團隊設(shè)定優(yōu)先級 產(chǎn)品所有者PO定義每個迭代的任務(wù)說明 missionstatement 目標 sprintgoal 使迭代更具有針對性 如 實現(xiàn)一個可擴展的列表控件 其項目是可以選擇的 35 Sprint迭代計劃 2 5 輸入和輸出 SprintPlanningMeeting SprintBacklog ProductOwner ScrumTeam Management Customers SprintGoal 36 迭代任務(wù)清單規(guī)劃 3 5 邏輯 迭代任務(wù)清單規(guī)劃是 鐵三角 法則的另一個例子在Scrum 邊界是一個變量 因為 資源 Scrum團隊 是確定的 進度表 迭代的時間 是不能變的 質(zhì)量是無法協(xié)商的團隊在一個迭代內(nèi)能完成的任務(wù) 可以用團隊進度來衡量 StoryPoints Sprint 如果可能的話利用同一個團隊上個迭代的進度 yesterday sweather 30 daysprint 20workdays1dayforplanning 1forreview retrospective 18workdays5personsinteam 90theoreticalmandays7 5 hourworkingday average85 toprojectwork90 7 5 0 85 574manhours5 reservedforre estimationandre planning545manhours 37 迭代任務(wù)清單規(guī)劃 4 5 規(guī)劃會議 召開迭代任務(wù)清單規(guī)劃會議的目的是確定迭代的邊界 時間是限定的 最長時間是一個工作日 對持續(xù)4個星期的迭代 迭代持續(xù)的時間越短 用在規(guī)劃上的時間也應(yīng)該越少 由ScrumMaster推動會議 由于會議時間有限 ProductOwner和Scrum團隊都應(yīng)該事前進行準備 前提 產(chǎn)品需求清單是有效的 valid 最新的 標注了優(yōu)先級并且表述清楚 規(guī)劃會議要解決兩個問題 下次迭代要做什么 確定迭代的目標 包含產(chǎn)品需求清單上高優(yōu)先級的功能 給Bug修改留一定的余地怎么樣實現(xiàn)下次增量所需要的功能 改進設(shè)計以實現(xiàn)產(chǎn)品需求清單上的功能 38 迭代任務(wù)清單規(guī)劃 5 5 工作流程 產(chǎn)品所有者向團隊介紹起草的產(chǎn)品需求清單和迭代目標 產(chǎn)品所有者傳達迭代的起止日期 Scrum團隊從產(chǎn)品需求清單中選取高優(yōu)先級的功能作為迭代的任務(wù) 如果有必要 更新其規(guī)模估計 Scrum團隊改進架構(gòu)和設(shè)計以便能夠?qū)崿F(xiàn)提出的產(chǎn)品需求 Scrum團隊把產(chǎn)品需求清單的每一項劃分成小的任務(wù) 并估算每個任務(wù)要花費的小時數(shù) 撲克規(guī)劃 方法是估算工作量的有效方法 Scrum團隊決定一個迭代中能夠?qū)崿F(xiàn)產(chǎn)品需求清單的多少功能產(chǎn)品所有者和Scrum團隊明確了各自要承擔(dān)的義務(wù) 39 SprintBacklog示例 Personsworkingonthetask Descriptionofthetask Effortestimate Taskblockedbyanimpediment Sprintgoal Meetsthedefinitionofdone 40 執(zhí)行迭代任務(wù)清單 執(zhí)行迭代任務(wù)清單意味著團隊在迭代期間自行開發(fā) 團隊清楚要達到什么的目標以及怎樣達到目標 每人每一時間只有一個任務(wù)團隊是自發(fā)組織的 成員自己挑選任務(wù) ScrumMaster提供指導(dǎo)并清除障礙 不能從外部改變迭代的范圍或者迭代的周期 為了達到迭代的目標 團隊可以增加 刪除任務(wù)或者改變其優(yōu)先次序 如果要重新設(shè)定迭代的范圍時需要產(chǎn)品所有者的配合 迭代周期短 意味著工期緊 應(yīng)該把重點放在剩余的工作和風(fēng)險的消除 要區(qū)分任務(wù)的優(yōu)先級 重要的事情應(yīng)當(dāng)先做 迭代應(yīng)當(dāng)達到項目的質(zhì)量要求 definitionof done 沒有獨立的測試階段 41 迭代進度圖 BurndownChart Scrum注重成果 它關(guān)心的是要花多少時間達到目標 而不是已經(jīng)花費的時間 團隊能否在既定的時間達到迭代的目標 可以查看要完成產(chǎn)品需求清單的功能所剩余的工作Remainingwork EstimatetoComplete ETC 描述剩余工作量和時間關(guān)系的圖表稱為SprintBurndown圖 是Scrum中非常重要的控制方法 controlmeasure 給Scrum團隊和產(chǎn)品所有者提供直觀的信息 術(shù)語burndown表明Scrum團隊在迭代過程中消耗剩余工作的能力 迭代結(jié)束時其值為0 每個任務(wù) task 的工作量由Scrum團隊來估計 每天都要進行估計 以便進行跟蹤 可以使用電子表格或者專門的工具 如ScrumWorks 42 迭代進度圖 BurndownChart Idealburndown Actualburndown Remainingworkincreasing Tasksunderestimatedand orworkremainingnotupdated TasksremovedfromtheSprintBacklogtomeetSprintGoal fasterdecline Sumofremainingwork h foralltasksintheSprintBacklogonaparticularday Initialestimate 752h InthebeginningoftheSprint 43 迭代進度圖 BurndownChart 44 Scrum每日例會 1 4 小雞和豬的故事 Achickenandapigaretogetherwhenthechickensays Let sstartarestaurant Thepigthinksitoverandsays Whatwouldwecallthisrestaurant Thechickensays Hamn Eggs Thepigsays Nothanks I dbecommitted butyou donlybeinvolved InaDailySprint onlyScrumMasterandScrumTeamarecommitted andthusallowedtospeak Othersareonlyinvolved 45 Scrum每日例會 2 4 概述 例會最長15分鐘 在整個迭代過程中每天的同一時間召開 團隊成員之間交流信息 了解項目的真實的進展情況交流風(fēng)險和存在的問題 面對面的會議加強了承諾 ScrumMaster負責(zé)整個會議 會議地點 邀請等 其他人可以參與 但只允許ScrumMaster和Scrum團隊成員講話 小雞和豬 例會之前團隊要更新工作量估計 使進度表保持最新 46 Scrum每日例會 3 4 形式 為使會議簡短而富有成效 要遵循嚴格的規(guī)程每個成員向其他人匯報以下內(nèi)容 上次會議以后所做的工作 下次會議之前要做的工作 工作中是否有什么障礙 如果出現(xiàn)其它的問題 如設(shè)計的問題 應(yīng)當(dāng)在會議后處理 紀錄會議紀要 例如wiki 要養(yǎng)成良好的會議習(xí)慣 47 Scrum每日例會 4 4 48 障礙 基本上 任何阻止團隊正常工作的 都可稱之為障礙 例如 無法訪問信息系統(tǒng) 所需要的信息不能及時提供或者提供的不正確 如界面規(guī)格或者其它軟件模塊不到位或不正確開發(fā)環(huán)境或者原型系統(tǒng)出現(xiàn)問題其他的任務(wù)分配 培訓(xùn) 售前支持缺乏必要的信息或者相應(yīng)的知識對于團隊提出的各項障礙 ScrumMaster要以列表形式進行記錄 49 誰來清除障礙 每個人自我管理 自我組織的團隊ScrumMaster產(chǎn)品所有者管理層其他相關(guān)的干系人ScrumMaster負責(zé)確定障礙已經(jīng)清除 不一定親自自己清除 50 清除障礙 某些障礙是浪費部分地完成工作額外的過程額外的功能任務(wù)轉(zhuǎn)換等待缺陷 清除障礙的過程是團隊和組織學(xué)習(xí)的過程 51 浪費產(chǎn)生的原因 多問幾個 為什么 對于每個標識的障礙或者浪費 問一問 為什么 浪費會存在多問幾個 為什么 找到造成浪費的根本原因 52 迭代中的同步工作 每次迭代不是小的瀑布項目 而是 每件事情同時都做一點 53 迭代的非正常終止 在Scrum中 結(jié)束正在進行的迭代是一種極端的行為 只有在萬不得以的情況下才能這么做 有時候確實需要停下來重新規(guī)劃 而不是一味的蠻干 bangingyourheadagainstthewall 迭代終止可能由下面的人發(fā)起 Scrum團隊 如果他們認為達不到目標或者目標不清楚 ScrumMaster 如果迭代沒有進展 或者無法克服某個困難 客戶 管理層 如果目標已經(jīng)陳舊 過時 目標產(chǎn)品被取消 平臺過時 或者其它的原因 資源問題等 迭代終止以后 啟動新迭代的計劃 導(dǎo)致迭代終止的原因不應(yīng)該在新的迭代中再次出現(xiàn) 要考慮到合同方面的問題 如時間表的變更等 54 迭代評審 概述 迭代評審 在迭代結(jié)束后進行 展示迭代的成果 功能運行 確保成果與預(yù)期的一致 收集反饋為項目提供一個參考點 根據(jù)目前的位置計劃下一期的旅程為下次迭代提供輸入 改正 修改 新的想法 可以由產(chǎn)品所有者添加到產(chǎn)品需求清單 與其它Scrum會議一樣 ScrumMaster主持迭代評審會議 Scrum團隊負責(zé)演示 參加會議的其他人包括 產(chǎn)品所有者ProductOwner 必須參加 客戶 管理人員 以及其它感興趣的人 例如其他Scrum團隊 注意保密協(xié)議的要求 評審會議的時間是固定的 最長4個小時 評審會議應(yīng)當(dāng)是非正式的 創(chuàng)造性的 不用幻燈片等正式的東西 55 迭代評審 流程 在評審會議召開之前 團隊要做好準備 有組織 有效地進行演示 不要超過4個小時 誰來演示 演示什么 怎樣演示 計劃準備的時間不要超過一個小時 迭代評審流程的一個例子 ScrumMaster介紹本次迭代的總體情況 目標和清單vs 實際的結(jié)果 如果存在差距 原因是什么 Scrum團隊簡要介紹所涉及的技術(shù)問題 如架構(gòu)及其變更 Scrum團隊演示已經(jīng)實現(xiàn)的功能 演示并進行功能說明在場的人能夠親自嘗試使用不同的功能 ScrumMaster推動自由討論 集思廣益 迭代評審應(yīng)當(dāng)是互動的 有問題提出 問題解答 并歡迎提出想法和建議 56 迭代評審 可能的措施 產(chǎn)品所有者根據(jù)評審的結(jié)果可能采取如下行動 更新產(chǎn)品需求清單 重新設(shè)定優(yōu)先級 包含沒有按計劃實現(xiàn)的功能 進度比預(yù)期的要慢 任務(wù)未完成 不在計劃中當(dāng)卻已經(jīng)實現(xiàn)的功能 進度比預(yù)期的快 迭代評審中出現(xiàn)的新的想法 與ScrumMaster一起解決團隊的變動問題 要求把演示的功能 或者把上次迭代的功能 作為一個版本發(fā)布給客戶 決定項目不再持續(xù)下去 不再進行迭代 認為產(chǎn)品已完備 要求把產(chǎn)品需求清單授權(quán)給另外的團隊來一起工作 57 迭代回顧會議SprintRetrospective 回顧的目的是評價本次迭代并醞釀改進 使得下一個迭代進行的更好 類似于項目的最終評審 但經(jīng)常舉行 障礙列表具有很好的參考價值 ScrumMaster主持召開 持續(xù)半天 Scrum團隊參加 產(chǎn)品所有者也可參加 簡單流程 ScrumMaster總結(jié)本次迭代 迭代任務(wù)清單 重要的事情和決策 預(yù)期的 實際進度 每個組員陳述迭代中那些方法進行的較好 哪些需要改進 ScrumMaster進行記錄 對重要的問題計劃相應(yīng)的措施 團隊自己解決 或者提交給公司的管理層 Scrum方法應(yīng)用 59 敏捷開發(fā)中使用撲克Poker方法進行估計 1 3 盡管名字有好笑 但卻非常可靠和有效 可以來估算產(chǎn)品需求清單中每項的規(guī)模 規(guī)模估算 用例點storypoint 以及迭代任務(wù)清單中任務(wù)的估計 工作量估算 人時 ScrumMaster推動活動的進行 一個以上的專家參與估算 而且最好是項目團隊中的人 估算時使用卡片 寫有一系列的離散數(shù)據(jù) 如0 1 2 3 5 8 13 無法估計 60 敏捷開發(fā)中使用撲克Poker方法進行估計 2 3 前提條件 提前準備好要估算的任務(wù) UserStories等 迭代任務(wù)清單和產(chǎn)品需求清單都已經(jīng)起草好 對某個任務(wù)最有經(jīng)驗的開發(fā)者做一個簡短的概述 可以通過簡短的討論澄清任務(wù)的具體含義 找出存在的風(fēng)險以及不確定性 各自對任務(wù)進行估計 所有的人將寫有各自估計數(shù)據(jù)的撲克 卡片扣上 單位事先進行約定 工時 事件點 大家同時把撲克 卡片翻過來 如果撲克 卡片上的數(shù)差距比較明顯 如一個13 2個5 一個1 就要討論一下為什么會出現(xiàn)這么大的差距 估計值所基于的假定要進行澄清 如果差距較小 如三個8兩個5 主持人幫助確定最終的估值 對于不確定性 估算數(shù)據(jù)中可以多包含一些余量 不斷的重復(fù)該過程直到達成一致 將這些估值記錄到相應(yīng)的文檔中 產(chǎn)品需求清單 迭代任務(wù)清單 61 敏捷開發(fā)中使用撲克Poker方法進行估計 3 3 為什么使用離散的數(shù)字 比使用任意數(shù)字更加容易進行估算 在整個項目中或者迭代中 每個人估計值的錯誤會相互抵消掉 對每個任務(wù) 16小時是上限 不確定性會隨著規(guī)模的增加而增加 為什么要有 將較大的任務(wù)進行分解 幫助更加精確的估計同時減少不確定性 為什么要 討論并重復(fù) 弄清不同的假設(shè) 利用重用代碼或者重新編碼 和可能的誤解 更為可靠的估計 對于那些偏離平均值的估計 即使由有經(jīng)驗的人給出的 也必須要有充分的理由 62 練習(xí) 在一個小時之內(nèi)編寫一個三只小豬的連環(huán)畫冊使用Scrum實踐自組織團隊迭代每日Scrum會議產(chǎn)品需求清單迭代任務(wù)清單 63 練習(xí) 進度安排 5分鐘 迭代目標團隊與產(chǎn)品所有者共同協(xié)作 從產(chǎn)品需求列表中選擇本次迭代要完成的項目5分鐘 迭代任務(wù)清單團隊從所選擇的產(chǎn)品需求列表中產(chǎn)生任務(wù)10分鐘 第一天團隊完成任務(wù)和產(chǎn)品需求列表中的項目產(chǎn)品所有者負責(zé)回答問題5分鐘 每日 Scrum會議每個人回答三個問題 10分鐘 第二天團隊繼續(xù)完成任務(wù)和產(chǎn)品需求列表中的項目產(chǎn)品所有者負責(zé)回答問題5分鐘 每日 Scrum會議每個人回答三個問題10分鐘 第三天團隊完成產(chǎn)品的一個版本產(chǎn)品所有者負責(zé)回答問題每組5分鐘 演示團隊向產(chǎn)品所有者展示完成的連環(huán)畫冊 64 練習(xí) 給出優(yōu)先級的產(chǎn)品需求清單 展示基本的故事用鉛筆畫展示的故事每頁圖畫配有說明給出寫有標題的封面故事用9頁進行說明展示版權(quán)信息添加色彩廣告教小孩數(shù)數(shù)1 2 3寓教于樂 堅固的重要性封皮吸引人硬的封皮3D效果的卡通形象展示所有的故事內(nèi)容 產(chǎn)品所有者 ProductOwner充分考慮市場情況 對產(chǎn)品進行規(guī)劃并進行簡要地說明規(guī)劃當(dāng)前該產(chǎn)品如何占有更多的市場份額規(guī)劃今后該產(chǎn)品的發(fā)展前景Scrum團隊根據(jù)產(chǎn)品所有者的產(chǎn)品規(guī)劃進行開發(fā) 65 測試驅(qū)動開發(fā)TestDrivenDevelopment 什么是測試驅(qū)動 一種能夠支持Scrum的敏捷實踐方法 開發(fā)滿足DoD的軟件首先創(chuàng)建測試用例 然后開發(fā)軟件通過測試 在開發(fā)代碼前 首先編寫測試代碼 一種設(shè)計軟件的方法 而不僅僅是一種測試方法所創(chuàng)建的測試用例用來指導(dǎo)和約束項目中的各項工作 對未來的各項工作提供一個安全的保護不需要測試的工作不需要完成所創(chuàng)建的測試用例通常替代詳細的業(yè)務(wù)和技術(shù)需求定測試也有效地驅(qū)動設(shè)計 使設(shè)計更加趨向于可行的設(shè)計通常情況下需要自動測試的支持 EUnit JUnitetc 對于UI軟件應(yīng)用TDD方法有一定的困難 66 測試驅(qū)動開發(fā) TDD 測試用例的作用 確定所要完成的工作溝通工具產(chǎn)生一致的結(jié)果對軟件開發(fā)提供一個安全的保障 67 Scrum的核心 反饋檢查接受 68 應(yīng)用 1 4 概述 基本原則 不能只挑自己喜歡的 不管其它的Scrum非常簡單 為了有效地發(fā)揮作用 應(yīng)當(dāng)具備 所有的角色 所有的實踐 所有的產(chǎn)品 Scrum可以進行裁剪 但應(yīng)當(dāng)明白裁剪對工程的影響 需要經(jīng)驗和仔細考慮 69 應(yīng)用 2 4 大型 跨地域項目 6到10人在同一房間進行工作時 Scrum能夠發(fā)揮最大效用 Scrum也可應(yīng)用在大型的跨地域的項目 一些指導(dǎo)原則 將大的項目分成多個團隊 每個團隊6到10人 有各自的ScrumMaster 對跨地域的項目 盡量不要把一個Scrum團隊分到多個地方 一個Scrum團隊就在一個地方 有自己的ScrumMaster 但是 如果團隊的跨地域是不可避免的 可以使用網(wǎng)絡(luò)工具遠程召開Scrum例會 劃分團隊時 團隊之間應(yīng)該有一個 自然界面 如為避免混亂 不同的團隊負責(zé)產(chǎn)品的不同部分 對于整個項目 產(chǎn)品 一個產(chǎn)品 項目只能有一個產(chǎn)品所有者和產(chǎn)品需求清單 團隊之間的協(xié)調(diào)利用ScrumofScrums方法 70 應(yīng)用 3 4 ScrumofScrums ScrumTeam6 10persons ScrumTeam6 10persons ScrumTeam6 10persons ScrumofScrums ScrumonTeamLevel 1 3times week orondemand Eachteamrepresentedbydedicatedpersons onlyoneifnoissuestoescalate ProjectdividedtoScrumteamsbasedonprojectsizeorgeographicallocationScrumTeamshaveDailyScrummeetings ScrumofScrumscanbeheldlessfrequently Teleandvideoconferencingutilizedasneeded 71 應(yīng)用 4 4 固定價格的項目 Scrum不鼓勵固定價格的項目每次迭代時進行項目預(yù)算 產(chǎn)品需求清單可以根據(jù)當(dāng)前的優(yōu)先級進行調(diào)整 某些項目中 客戶需要我們對整個項目給一個報價或者預(yù)算 價格固定限制了靈活性 對變化的響應(yīng) 如果價格和進度是固定的 那么整個項目的范圍也是固定的 PB 必須對項目所有的迭代都進行詳細的計劃和規(guī)模估計 變更項目的范圍 以及隨之而來的預(yù)算 進度的變更需要提交CR 當(dāng)然可以改變產(chǎn)品需求清單的優(yōu)先級 或者不改變工作量前提下把其中的某一項換成另一項 仍然可以使用Scrum 并從中獲益 72 支持工具和模版 Tasksnotstarted Tasksinprogress Taskscompleted done Priority SprintGoal SprintBurndownChart Tasks DescriptionResponsiblepersonWorkremaining 73 一些常見的誤解 敏捷是拯救任何項目的銀彈 敏捷方法只有運用得當(dāng)才有效果 敏捷意味著ad hochacking 不需要任何文檔 敏捷是有嚴格要求的 也是面向質(zhì)量的根據(jù)溝通的需要產(chǎn)生相應(yīng)的文檔 敏捷只是開發(fā)者的問題基本的開發(fā)方法與傳統(tǒng)相比有顯著不同 影響項目的各個方面 合同 角色 定價模型 項目管理等 采用敏捷方法的開發(fā)組 項目不需要制定計劃敏捷項目需要經(jīng)常制定計劃 但是不需要試圖超前制定項目計劃 通常這也是不可能的 敏捷項目的范圍可以隨時改變 變更可以等到下一次迭代開始 當(dāng)前正在進行中的迭代不能變更只對小項目適用在中型和大型的項目中一樣取得了成功 74 敏捷開發(fā)各階段的主要活動 JinghuaLiQualityManagerTietoEnatorCorporationT MMDRMIDjinghua li 76 項目生命周期 主要包含三個階段 產(chǎn)品定義 計劃 進行迭代所需要的項目準備 項目計劃和技術(shù)分析迭代開發(fā) 執(zhí)