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

1、Scrum敏捷軟件開發(fā)過程目錄 什么是敏捷軟件開發(fā)？ 敏捷方法的項(xiàng)目計(jì)劃 敏捷項(xiàng)目管理和傳統(tǒng)項(xiàng)目管理 為什么使用敏捷？ Scrum概述 Scrum的角色 Scrum實(shí)踐和工作產(chǎn)品 敏捷開發(fā)中的估計(jì)方法 測試驅(qū)動開發(fā) Scrum應(yīng)用 支持工具和模版 一些常見的誤解 敏捷開發(fā)方法什么是敏捷軟件開發(fā)? 敏捷軟件開發(fā)是軟件項(xiàng)目的一個概念框架. 有許多建立在敏捷概念上的方法，如 Scrum 和 Extreme Programming (XP). 與僵化的、重量級的、官僚式的方法形成對照，比如瀑布模型（指純粹形式的） 最大限度地降低短期固定時間的迭代式軟件的開發(fā)風(fēng)險.敏捷宣言（2001年） 人和交互勝過過

2、程和工具. Individuals and interactions over processes and tools 可以工作的軟件勝過完備的文檔. Working software over comprehensive documents 客戶協(xié)作勝過合同談判. Customer collaboration over contract negotiation 隨時應(yīng)對變化勝過遵循計(jì)劃. Responding to change over following a plan敏捷過程的限制 敏捷軟件開發(fā)過程包含過程、原則、工具，和最重要的-人 因此：誠信是基礎(chǔ) 沒有過程能夠?qū)φ\信進(jìn)行有效地約束，

3、誠信與否是有效實(shí)施敏捷過程的最大限制使用敏捷方法的項(xiàng)目計(jì)劃敏捷項(xiàng)目管理和傳統(tǒng)項(xiàng)目管理 傳統(tǒng)項(xiàng)目管理： 事先對整個項(xiàng)目進(jìn)行估計(jì)、計(jì)劃、分析 反對變更; 變更需要重新估計(jì)、重新規(guī)劃 嚴(yán)密的合同來減少風(fēng)險, 如果改變需求要走CR流程. 項(xiàng)目作為一個“黑盒子”，對客戶與供應(yīng)商的可視性差. 產(chǎn)品化和測試階段是分離的. 文檔和計(jì)劃驅(qū)動的方法. 軟件交付時間晚, 意識到風(fēng)險的時間晚. 敏捷項(xiàng)目管理: 對整個項(xiàng)目做一個粗略的估計(jì),每一次迭代都有詳細(xì)的計(jì)劃. 鼓勵變化, 客戶價值驅(qū)動開發(fā). 信任和賦予權(quán)力;合約使變更變得簡單，增加價值. 客戶和開發(fā)人員之間是緊密的連續(xù)的合作關(guān)系 每次迭代都產(chǎn)生可交付的軟件 專注

4、于交付軟件. 第一次迭代就可交付能工作的版本，風(fēng)險發(fā)現(xiàn)的早. 為什么采用敏捷? 預(yù)期的收益 采用敏捷方法得當(dāng)?shù)脑挘梢裕?更加透明; 隨時跟蹤項(xiàng)目的狀態(tài)和進(jìn)展情況，及早發(fā)現(xiàn)問題和風(fēng)險 . 快速交付, 每次迭代都能交付可運(yùn)行的軟件. 最高風(fēng)險和最高優(yōu)先級的需求，最優(yōu)先進(jìn)行開發(fā). 改善應(yīng)對變更能力, 減少大量的重計(jì)劃. 改善項(xiàng)目溝通. 更好的客戶參與, 避免錯誤的假設(shè). 總之: 提高了生產(chǎn)率; 減少“浪費(fèi)”（不需要的文檔，重復(fù)工作等），項(xiàng)目的每次迭代都有明確的目標(biāo). 提高客戶滿意度; 短期內(nèi)產(chǎn)生成效, 按預(yù)期交付軟件, 每次迭代結(jié)束產(chǎn)生可以運(yùn)行的軟件. 改善員工的滿意度; 團(tuán)隊(duì)精神，減少官僚，能夠

5、規(guī)劃和管理自己的工作，減少“恐慌” ，穩(wěn)定的工作量（可持續(xù)的步伐）. 敏捷方法何時有效？ 公司和客戶一致認(rèn)為應(yīng)當(dāng)使用敏捷方法，雙方都能理解敏捷方法. 敏捷方法對需求不完整以及經(jīng)常變換的項(xiàng)目比較有效. 項(xiàng)目可以劃分成固定時間間隔的迭代, 并且可以凍結(jié)正在進(jìn)行的迭代的范圍 公司和客戶都有能力擔(dān)當(dāng)角色尤其是Product Owner 和 Scrum Master. 項(xiàng)目的人員結(jié)構(gòu)能夠分成6到10人的團(tuán)隊(duì)，最好每個工作地點(diǎn)一個小組. 團(tuán)隊(duì)成員能夠以自組織的方式工作. 項(xiàng)目的合同允許變更. 固定價格的項(xiàng)目可以使用敏捷，但應(yīng)當(dāng)盡量避免。 最好在按時間和材料付費(fèi)或者按月付費(fèi)的項(xiàng)目中進(jìn)行使用 變更項(xiàng)目的范圍不

6、需要高級管理層的批準(zhǔn).Scrum 概述Scrum 概述(1/3) Scrum是管理軟件項(xiàng)目的一個輕量級的敏捷方法, 名字來源于橄欖球運(yùn)動中的scrum 過程 簡單，但高度的紀(jì)律性 依賴迭代和增量的敏捷方法. Scrum 是一種工作管理的方法，不僅僅限于軟件開發(fā)，可以用來管理其它活動. Scrum 不包含技術(shù)方法或?qū)嵺`.Scrum 概述 (2/3) 項(xiàng)目的階段 項(xiàng)目分成增量的迭代過程，在Scrum中稱為迭代任務(wù)清單, 通常持續(xù)2-4周的時間. Sprint 的時間是限定好的; 不能從外部改變正在進(jìn)行中的sprint持續(xù)時間和范圍. 每個sprint都可以產(chǎn)生可交付的迭代, 即測試過并具備文檔的的

7、功能點(diǎn) 原則上, 當(dāng)產(chǎn)品開發(fā)到一定程度時，如實(shí)現(xiàn)了足夠的客戶價值，項(xiàng)目可以在任何一個sprint后結(jié)束. 如同任何項(xiàng)目，敏捷的項(xiàng)目有三個主要階段： 產(chǎn)品定義 (規(guī)劃); 運(yùn)行Sprints 所需要的準(zhǔn)備、規(guī)劃、技術(shù)分析. 執(zhí)行Sprints (執(zhí)行): 在增量時間段內(nèi)實(shí)現(xiàn)需求(產(chǎn)品需求清單). 結(jié)束: 準(zhǔn)備最終發(fā)布，結(jié)束項(xiàng)目 Scrum 概述 (3/3)Scrum 的流程 1、 將整個產(chǎn)品Backlog 分解成Sprint Backlog ，按照目前的人力物力條件可以完成的。2、 召開Sprint 計(jì)劃會議，劃分、確定這個Sprint 內(nèi)需要完成的任務(wù)，標(biāo)注任務(wù)的優(yōu)先級并分配給每個成員。注意這

8、里的任務(wù)是以小時計(jì)算的，并不是按人天計(jì)算，長度不超過8 小時。3、 進(jìn)入Sprint 開發(fā)周期,每個Sprint 迭代周期為連續(xù)30 個日例日（2-4周）。在這個周期內(nèi)，每天需要召開每日Scrum 簡會，時間為15 分鐘。在會議中每個團(tuán)隊(duì)成員僅就以下三點(diǎn)發(fā)言:自上次Scrum 會議后你做了什么?從現(xiàn)在到下次Scrum 會議的時間里你準(zhǔn)備做什么? 你在工作中遇到了哪些困難?4、 整個Sprint 周期結(jié)束，召開Sprint 評審會議(Sprint review meeting)，將成果演示給Product Owner ，該會議限定時間為4 小時。5、 團(tuán)隊(duì)成員最后召開沖刺回顧會議( Sprint

9、 retrospective meeting) ，總結(jié)問題和經(jīng)驗(yàn)，該會議限定時間為3 小時。6、這樣周而復(fù)始，按照同樣的步驟進(jìn)行下一次Sprint 。Scrum角色、實(shí)踐和工作產(chǎn)品Scrum中的三種角色 Product Owner- 產(chǎn)品所有者 個人：代表所有的干系人 Scrum Master: 個人：負(fù)責(zé)指導(dǎo)過程的執(zhí)行 Scrum Team Scrum團(tuán)隊(duì): 承諾完成工作，向干系人交付產(chǎn)品價值u Scrum 角色 Scrum 團(tuán)隊(duì) Scrum 團(tuán)隊(duì)是Scrum的中心角色， 產(chǎn)品交付要依靠團(tuán)隊(duì). Scrum 團(tuán)隊(duì)自我組織、自我管理 Scrum 團(tuán)隊(duì)是職能交叉的， 包含產(chǎn)品交付的所有角色:開發(fā)人

10、員、測試人員、build managers, 文檔編寫, 界面設(shè)計(jì)人員. Scrum 團(tuán)隊(duì)中的角色是不分等級的; 不應(yīng)當(dāng)出現(xiàn)“我是開發(fā)人員我不作測試”. 團(tuán)隊(duì)按照最有利于項(xiàng)目的原則來分擔(dān)責(zé)任 (如組件的所有權(quán)等 ). 敏捷是建立在信任和授權(quán)的基礎(chǔ)上，因此團(tuán)隊(duì)是自發(fā)組織的，組員選擇自己的任務(wù)，而不是別人強(qiáng)制加以分配的. 另一方面，Scrum團(tuán)隊(duì)有交付的責(zé)任，他們需要能夠自我激勵和對工作目標(biāo)進(jìn)行承諾. 團(tuán)隊(duì)最佳規(guī)模： 6-10 人 主要職責(zé) 參與迭代任務(wù)清單的創(chuàng)建 執(zhí)行為干系人創(chuàng)造價值的工作 根據(jù)團(tuán)隊(duì)的承諾完成所需的各項(xiàng)任務(wù) 將工作中的各項(xiàng)障礙迅速與Scrum Master 進(jìn)行溝通 全面參與所有

11、的各項(xiàng)會議 更新任務(wù)狀態(tài) 自發(fā)選擇任務(wù) 標(biāo)識任務(wù)的完成 標(biāo)識發(fā)現(xiàn)的新的任務(wù) 與其它團(tuán)隊(duì)共同進(jìn)行工作u Scrum 角色 Scrum Master Scrum Master不是一個管理者，而是一個教練和推動者 - Scrum團(tuán)隊(duì)是一種自發(fā)的組織，是自我管理的. Scrum Master的角色通常由項(xiàng)目組的成員擔(dān)當(dāng)，組長或者項(xiàng)目經(jīng)理。Scrum Master 應(yīng)當(dāng)是項(xiàng)目中的成員. 主要職責(zé): 評價過程的健康狀況 加強(qiáng)過程 消除障礙 促進(jìn)過程改進(jìn) 支持團(tuán)隊(duì)開發(fā) Scrum Master 的主要工作是做決策、消除障礙，保證團(tuán)隊(duì)能順利交付產(chǎn)品 Scrum Master 還有如下責(zé)任 與其它角色配合. 訓(xùn)

12、練團(tuán)隊(duì)，提高生產(chǎn)率. 培訓(xùn)產(chǎn)品所有者和干系人，確保Scrum流程的執(zhí)行 確保一切工作按照既定的規(guī)范來運(yùn)行. 規(guī)劃并進(jìn)行必要的改進(jìn). 推動會議的召開. 維護(hù)障礙列表 維護(hù)Scrum過程改進(jìn)列表 優(yōu)秀的 Scrum Master 應(yīng)當(dāng)是專注的,、有決心的、有領(lǐng)導(dǎo)才能.u Scrum 角色 Product Owner 產(chǎn)品所有者代表投資方的利益，確保交付的產(chǎn)品與期望的一致 （提供更好的投資回報(bào)). Product Owner決定產(chǎn)品具有哪些功能. Product Owners的主要責(zé)任是創(chuàng)建和維護(hù)產(chǎn)品需求清單, 即管理項(xiàng)目的范圍. Product Owner不斷的把產(chǎn)品需求清單按優(yōu)先級進(jìn)行排序 ，使

13、得最重要的功能能優(yōu)先實(shí)現(xiàn). 對于團(tuán)隊(duì)來說，只有一個需求集。所有的需求申請都?xì)w口到Product Owner 管理商業(yè)價值（投資回報(bào)） Product Owner 還有如下責(zé)任: 計(jì)劃項(xiàng)目的發(fā)布，什么時間、向什么人等. 對每次Sprint的結(jié)果進(jìn)行評審和批準(zhǔn) 參與Scrum會議 迭代計(jì)劃會議 團(tuán)隊(duì)進(jìn)展跟蹤會議 迭代評審和回顧會議 能夠隨時回答團(tuán)隊(duì)工作中產(chǎn)生的各項(xiàng)和產(chǎn)品/業(yè)務(wù)相關(guān)的問題 Product Owner 的角色一般由客戶擔(dān)當(dāng)，作為服務(wù)提供商的公司無法設(shè)定優(yōu)先級.u Scrum 角色 客戶與管理層 客戶和管理的角色是可選的，需要時才設(shè)立 客戶: 是產(chǎn)品的最終用戶 通過 Product Ow

14、ner來設(shè)定對產(chǎn)品的期望 把當(dāng)前的業(yè)務(wù)傳達(dá)給項(xiàng)目. 管理層: 公司高級管理層,代表公司在項(xiàng)目中的利益. 通過Product Owner來傳達(dá)公司的利益和優(yōu)先級（priorities ）產(chǎn)品需求清單 Product Backlog 概論 基本上，產(chǎn)品需求清單是為了實(shí)現(xiàn)產(chǎn)品的功能所需要的工作的列表，包括: 功能方面的需求; 功能點(diǎn). 非功能方面的需求, 如性能改進(jìn). 要修改的Bug; 上一版本的已知錯誤. 新技術(shù), 如支持新的操作系統(tǒng)或者平臺. 問題; 日后的不確定項(xiàng), 如新的功能. 產(chǎn)品需求清單是不斷完善的. Product Owner 在項(xiàng)目進(jìn)行過程中可以隨時更新：增加、刪除、修改功能，變更優(yōu)

15、先級等. 下一次迭代中要包含較高優(yōu)先級的需求. 產(chǎn)品需求清單也可稱為User Stories (用例) ，因?yàn)樗鼈兡軌蚪o產(chǎn)品的用戶帶來價值. 在一次迭代中要能夠?qū)崿F(xiàn)產(chǎn)品需求清單，如果不能全部實(shí)現(xiàn)要進(jìn)行分解. 構(gòu)成 Product Owner負(fù)責(zé)創(chuàng)建最初的產(chǎn)品需求清單，一開始是不完整的. 最初的清單應(yīng)當(dāng)包含足夠的需求. 清單應(yīng)當(dāng)包含多少需求, 取決于定價模型 (black-box, 更多的計(jì)劃時間). 產(chǎn)品需求清單來源于: 客戶; 標(biāo)書, 需求規(guī)格說明等. Scrum團(tuán)隊(duì)的想法; 增強(qiáng)型新功能等. 現(xiàn)有產(chǎn)品的迭代增量; 已知錯誤, 技術(shù)問題等. 比較好的做法是Product Owner 、Scr

16、um團(tuán)隊(duì)、客戶/管理以及其它相關(guān)方（如相關(guān)的Scrum團(tuán)隊(duì)）舉行一次或者多次研討會 Scrum Master 或者 Product Owner 來促成會議的召開，必須要有人來做. 要有效率、要圍繞主題、 溝通良好 、避免不同的假設(shè)， 承諾并且共通合作，確定優(yōu)先級.估計(jì) Scrum團(tuán)隊(duì)對產(chǎn)品需求清單的每一項(xiàng)的規(guī)模提供初步的估計(jì)，通常采用事件點(diǎn)作為單位Story Points (模糊的). 也可采用人天或者人小時作為單位，但容易混淆： a) 實(shí)際的規(guī)模 b) 時間的單位. 精確的估計(jì)值可以在Sprint 規(guī)劃時給出, 當(dāng)前階段沒有足夠的信息. 規(guī)模的相對值才有意義. 這個估計(jì)值有助于確定優(yōu)先級;

17、優(yōu)先級 優(yōu)先級是產(chǎn)品需求清單中的主要問題. 優(yōu)先級不但反映了客戶的價值也反映了風(fēng)險. 產(chǎn)品所有者-PO 設(shè)定優(yōu)先級. 清單中的每一項(xiàng)的優(yōu)先級是唯一的, 但可以對它們進(jìn)行分類 優(yōu)先級可以在項(xiàng)目的任何時候進(jìn)行更改; 如新的重要的功能可以直接給較高的優(yōu)先級. 確定優(yōu)先級考慮： 價值 風(fēng)險 依賴關(guān)系示例版本發(fā)布計(jì)劃 在 Scrum中,不是 每個Sprints 都要發(fā)布一個版本. 迭代的結(jié)果主要是要實(shí)現(xiàn)功能的演示, 不一定就是發(fā)布的版本. 版本發(fā)布計(jì)劃決定了每次迭代應(yīng)當(dāng)包含產(chǎn)品需求清單的哪些功能. 根據(jù)現(xiàn)有的信息制定的項(xiàng)目總體的長期的計(jì)劃. 根據(jù)產(chǎn)品需求清單和團(tuán)隊(duì)的進(jìn)度來決定 (實(shí)施的范圍/迭代, e.

18、g. in Story Points). Scrum團(tuán)隊(duì)參與版本發(fā)布計(jì)劃的制定; 架構(gòu)、風(fēng)險、依賴性決定了可行的實(shí)現(xiàn)順序. 版本發(fā)布計(jì)劃很大程度上依賴于客戶的時間表和發(fā)布周期，即什么時候客戶的產(chǎn)品需要包含我們的模塊（交付物）. 版本發(fā)布計(jì)劃不是一成不變的;每個迭代結(jié)束后都可以更改.完成的定義 當(dāng)?shù)蝿?wù)清單上的任務(wù)都完成時，變?yōu)椤耙淹瓿伞睜顟B(tài) 定義“已完成”的含義是非常重要的, 例如: 如何記錄軟件的變化. 使用什么樣的代碼分析工具 ，發(fā)現(xiàn)的問題應(yīng)當(dāng)如何處理. 進(jìn)行了什么樣的測試, 結(jié)果是如何記錄的, 通過標(biāo)準(zhǔn)（如覆蓋率、修正的錯誤）是什么. 定義“已完成”意味著定義質(zhì)量上的需求. “已完成”

19、是0/1變量：完成或者未完成. 所有的任務(wù)（task)都完成了迭代任務(wù)才算完成. 在第一個迭代開始之前應(yīng)該定義好，因?yàn)樗鼤绊懝ぷ髁? 而且必須文檔化，這樣團(tuán)隊(duì)和產(chǎn)品所有者的理解是一致的. 完成的范圍隨著團(tuán)隊(duì)的成熟程度會逐漸發(fā)生變化完成的定義 - Example 完成的定義 遵循編碼規(guī)范 能在模擬器上演示 使用PCLint 進(jìn)行靜態(tài)代碼分析 具有EUnit 測試套件的通過率 和執(zhí)行率. 或者使用結(jié)對編程，或者進(jìn)行代碼走查 迭代任務(wù)清單Sprint Backlog總論 迭代任務(wù)清單規(guī)劃的主要目的是從產(chǎn)品任務(wù)清單中挑選高優(yōu)先級的任務(wù)包含在下一次迭代中，即確定迭代的范圍. 至于能夠包含多少產(chǎn)品任務(wù)清

20、單中的任務(wù)取決于Scum團(tuán)隊(duì)能夠承諾完成多少. 承諾總是來自于內(nèi)部，不能從外部強(qiáng)加. 迭代不應(yīng)當(dāng)有空閑時間, 因此規(guī)劃迭代范圍時要保證工作量是穩(wěn)定的 (進(jìn)度是持續(xù)的速度). 依賴多個因素; 團(tuán)隊(duì)的能力, 技術(shù)的成熟度, 當(dāng)前迭代增量的情況等. 迭代的范圍在迭代任務(wù)清單中描述; 團(tuán)隊(duì)設(shè)定優(yōu)先級. 產(chǎn)品所有者 PO 定義每個迭代的任務(wù)說明（mission statement），目標(biāo)(sprint goal)，使迭代更具有針對性，如. “實(shí)現(xiàn)一個可擴(kuò)展的列表控件，其項(xiàng)目是可以選擇的” 輸入和輸出邏輯 迭代任務(wù)清單規(guī)劃 是“鐵三角”法則的另一個例子 在Scrum, 邊界是一個變量，因?yàn)? 資源 (Sc

21、rum團(tuán)隊(duì)) 是確定的. 進(jìn)度表（迭代的時間）是不能變的. 質(zhì)量是無法協(xié)商的 團(tuán)隊(duì)在一個迭代內(nèi)能完成的任務(wù)，可以用團(tuán)隊(duì)進(jìn)度來衡量 (Story Points / Sprint). 如果可能的話利用同一個團(tuán)隊(duì)上個迭代的進(jìn)度, “yesterdays weather”.規(guī)劃會議 召開迭代任務(wù)清單規(guī)劃會議的目的是確定迭代的邊界. 時間是限定的, 最長時間是一個工作日 (對持續(xù)4個星期的迭代, 迭代持續(xù)的時間越短，用在規(guī)劃上的時間也應(yīng)該越少. 由 Scrum Master推動會議. 由于會議時間有限，Product Owner 和Scrum 團(tuán)隊(duì)都應(yīng)該事前進(jìn)行準(zhǔn)備. 前提: 產(chǎn)品需求清單是有效的（va

22、lid）; 最新的, 標(biāo)注了優(yōu)先級并且表述清楚. 規(guī)劃會議要解決兩個問題: 下次迭代要做什么. 確定迭代的目標(biāo)，包含產(chǎn)品需求清單上高優(yōu)先級的功能. 給Bug修改留一定的余地 怎么樣實(shí)現(xiàn)下次增量所需要的功能. 改進(jìn)設(shè)計(jì)以實(shí)現(xiàn)產(chǎn)品需求清單上的功能.工作流程 產(chǎn)品所有者向團(tuán)隊(duì)介紹起草的產(chǎn)品需求清單和迭代目標(biāo). 產(chǎn)品所有者傳達(dá)迭代的起止日期. Scrum 團(tuán)隊(duì) 從產(chǎn)品需求清單中選取高優(yōu)先級的功能作為迭代的任務(wù)，如果有必要，更新其規(guī)模估計(jì). Scrum 團(tuán)隊(duì)改進(jìn)架構(gòu)和設(shè)計(jì)以便能夠?qū)崿F(xiàn)提出的產(chǎn)品需求. Scrum團(tuán)隊(duì)把 產(chǎn)品需求清單的每一項(xiàng)劃分成小的任務(wù)，并估算每個任務(wù)要花費(fèi)的小時數(shù). “撲克規(guī)劃”方法是

23、估算工作量的有效方法. Scrum 團(tuán)隊(duì)決定一個迭代中能夠?qū)崿F(xiàn)產(chǎn)品需求清單的多少功能 產(chǎn)品所有者和Scrum團(tuán)隊(duì)明確了各自要承擔(dān)的義務(wù).Sprint Backlog 示例執(zhí)行迭代任務(wù)清單 執(zhí)行迭代任務(wù)清單意味著 團(tuán)隊(duì)在迭代期間自行開發(fā). 團(tuán)隊(duì)清楚要達(dá)到什么的目標(biāo)以及怎樣達(dá)到目標(biāo). 每人每一時間只有一個任務(wù) 團(tuán)隊(duì)是自發(fā)組織的；成員自己挑選任務(wù), Scrum Master 提供指導(dǎo)并清除障礙. 不能從外部改變迭代的范圍或者迭代的周期. 為了達(dá)到迭代的目標(biāo)，團(tuán)隊(duì)可以增加、刪除任務(wù)或者改變其優(yōu)先次序. 如果要重新設(shè)定迭代的范圍時需要產(chǎn)品所有者的配合. 迭代周期短，意味著工期緊; 應(yīng)該把重點(diǎn)放在剩余的工

24、作和風(fēng)險的消除，要區(qū)分任務(wù)的優(yōu)先級，重要的事情應(yīng)當(dāng)先做. 迭代應(yīng)當(dāng)達(dá)到項(xiàng)目的質(zhì)量要求 (definition of “done”);沒有獨(dú)立的測試階段.迭代進(jìn)度圖- Burndown Chart Scrum 注重成果，它關(guān)心的是要花多少時間達(dá)到目標(biāo)，而不是已經(jīng)花費(fèi)的時間;. 團(tuán)隊(duì)能否在既定的時間達(dá)到迭代的目標(biāo),可以查看要完成產(chǎn)品需求清單的功能所剩余的工作 Remaining work = Estimate to Complete (ETC). 描述剩余工作量和時間關(guān)系的圖表稱為Sprint Burndown圖, 是Scrum中非常重要的控制方法(control measure). 給Scrum

25、團(tuán)隊(duì)和產(chǎn)品所有者提供直觀的信息. 術(shù)語 burndown 表明Scrum團(tuán)隊(duì)在迭代過程中消耗剩余工作的能力; 迭代結(jié)束時其值為0. 每個任務(wù) （ task ）的工作量由Scrum團(tuán)隊(duì)來估計(jì). 每天都要進(jìn)行估計(jì)，以便進(jìn)行跟蹤. 可以使用電子表格或者專門的工具（如 ScrumWorks ） Scrum每日例會 小雞和豬的故事 A chicken and a pig are together when the chicken says, "Let's start a restaurant!“ The pig thinks it over and says, "What w

26、ould we call this restaurant?“ The chicken says, "Ham n' Eggs!“ The pig says, "No thanks. I'd be committed, but you'd only be involved!“ In a Daily Sprint, only Scrum Master and Scrum Team are committed, and thus allowed to speak. Others are only involved.概述 例會最長15分鐘，在整個迭代過程中每天

27、的同一時間召開. 團(tuán)隊(duì)成員 之間交流信息. 了解項(xiàng)目的真實(shí)的進(jìn)展情況 交流風(fēng)險和存在的問題. 面對面的會議加強(qiáng)了承諾. Scrum Master 負(fù)責(zé)整個會議 (會議地點(diǎn),邀請等). 其他人可以參與, 但只允許Scrum Master 和 Scrum 團(tuán)隊(duì)成員講話 (小雞和豬). 例會之前團(tuán)隊(duì)要更新工作量估計(jì)，使進(jìn)度表保持最新.形式 為使會議簡短而富有成效，要遵循嚴(yán)格的規(guī)程 每個成員向其他人匯報(bào)以下內(nèi)容: 上次會議以后所做的工作? 下次會議之前要做的工作? 工作中是否有什么障礙? 如果出現(xiàn)其它的問題（如設(shè)計(jì)的問題），應(yīng)當(dāng)在會議后處理. 紀(jì)錄會議紀(jì)要，例如wiki. 要養(yǎng)成良好的會議習(xí)慣障礙 基

28、本上，任何阻止團(tuán)隊(duì)正常工作的，都可稱之為障礙，例如: 無法訪問信息系統(tǒng). 所需要的信息不能及時提供或者提供的不正確，如界面規(guī)格或者其它軟件模塊不到位或不正確 開發(fā)環(huán)境或者原型系統(tǒng)出現(xiàn)問題 其他的任務(wù)分配：培訓(xùn)，售前支持 缺乏必要的信息或者相應(yīng)的知識 對于團(tuán)隊(duì)提出的各項(xiàng)障礙，Scrum Master要以列表形式進(jìn)行記錄， 誰來清除障礙？ 每個人 自我管理、自我組織的團(tuán)隊(duì) Scrum Master 產(chǎn)品所有者 管理層 其他相關(guān)的干系人 Scrum Master 負(fù)責(zé)確定障礙已經(jīng)清除，不一定親自自己清除清除障礙 某些障礙是浪費(fèi) 部分地完成工作 額外的過程 額外的功能 任務(wù)轉(zhuǎn)換 等待 缺陷 清除障礙的

29、過程是團(tuán)隊(duì)和組織學(xué)習(xí)的過程浪費(fèi)產(chǎn)生的原因 多問幾個“為什么” 對于每個標(biāo)識的障礙或者浪費(fèi)，問一問“為什么”浪費(fèi)會存在 多問幾個“為什么”，找到造成浪費(fèi)的根本原因迭代中的同步工作 每次迭代不是小的瀑布項(xiàng)目 而是，每件事情同時都做一點(diǎn)迭代的非正常終止 在Scrum中，結(jié)束正在進(jìn)行的迭代是一種極端的行為，只有在萬不得以的情況下才能這么做. 有時候確實(shí)需要停下來重新規(guī)劃，而不是一味的蠻干(banging your head against the wall). 迭代終止可能由下面的人發(fā)起: Scrum團(tuán)隊(duì),如果他們認(rèn)為達(dá)不到目標(biāo)或者目標(biāo)不清楚. Scrum Master, 如果迭代沒有進(jìn)展, 或者無法

30、克服某個困難. 客戶/管理層, 如果目標(biāo)已經(jīng)陳舊/過時(目標(biāo)產(chǎn)品被取消，平臺過時)，或者其它的原因 (資源問題等). 迭代終止以后, 啟動新迭代的計(jì)劃. 導(dǎo)致迭代終止的原因不應(yīng)該在新的迭代中再次出現(xiàn). 要考慮到合同方面的問題，如時間表的變更等.迭代評審會議概述 迭代評審，在迭代結(jié)束后進(jìn)行，展示迭代的成果 (功能運(yùn)行). 確保成果與預(yù)期的一致，收集反饋 為項(xiàng)目提供一個參考點(diǎn)，根據(jù)目前的位置計(jì)劃下一期的旅程 為下次迭代提供輸入（改正、修改、新的想法à可以由產(chǎn)品所有者添加到產(chǎn)品需求清單. 與其它 Scrum 會議一樣, Scrum Master 主持迭代評審會議, Scrum 團(tuán)隊(duì)負(fù)責(zé)演示

31、. 參加會議的其他人包括: 產(chǎn)品所有者Product Owner (必須參加) 、客戶、 管理人員, 以及其它感興趣的人, 例如其他Scrum團(tuán)隊(duì) (注意保密協(xié)議的要求). 評審會議的時間是固定的: 最長4個小時. 評審會議應(yīng)當(dāng)是非正式的、創(chuàng)造性的，不用幻燈片等正式的東西.迭代評審 流程 在評審會議召開之前，團(tuán)隊(duì)要做好準(zhǔn)備: 有組織、有效地進(jìn)行演示，不要超過4個小時. 誰來演示，演示什么，怎樣演示? 計(jì)劃準(zhǔn)備的時間不要超過一個小時. 迭代評審流程的一個例子: Scrum Master 介紹本次迭代的總體情況. 目標(biāo)和清單 vs. 實(shí)際的結(jié)果, 如果存在差距，原因是什么. Scrum 團(tuán)隊(duì)簡要介

32、紹所 涉及的技術(shù)問題，如架構(gòu)及其變更. Scrum 團(tuán)隊(duì)演示已經(jīng)實(shí)現(xiàn)的功能: 演示并進(jìn)行功能說明 在場的人能夠親自嘗試使用不同的功能. Scrum Master 推動自由討論，集思廣益. 迭代評審應(yīng)當(dāng)是互動的; 有問題提出, 問題解答，并歡迎提出想法和建議. 迭代評審 可能的措施 產(chǎn)品所有者根據(jù)評審的結(jié)果可能采取如下行動: 更新產(chǎn)品需求清單，重新設(shè)定優(yōu)先級: 包含沒有按計(jì)劃實(shí)現(xiàn)的功能 (進(jìn)度比預(yù)期的要慢, 任務(wù)未完成). 不在計(jì)劃中當(dāng)卻已經(jīng)實(shí)現(xiàn)的功能 (進(jìn)度比預(yù)期的快). 迭代評審中出現(xiàn)的新的想法. 與 Scrum Master 一起解決團(tuán)隊(duì)的變動問題. 要求把演示的功能，或者把上次迭代的功能

33、，作為一個版本發(fā)布給客戶. 決定項(xiàng)目不再持續(xù)下去，不再進(jìn)行迭代; 認(rèn)為產(chǎn)品已完備. 要求把產(chǎn)品需求清單授權(quán)給另外的團(tuán)隊(duì)來一起工作. 迭代回顧會議 Sprint Retrospective 回顧的目的是評價本次迭代并醞釀改進(jìn)，使得下一個迭代進(jìn)行的更好. 類似于項(xiàng)目的最終評審，但經(jīng)常舉行. 障礙列表具有很好的參考價值! Scrum Master主持召開, 持續(xù)半天, Scrum團(tuán)隊(duì)參加 (產(chǎn)品所有者也可參加). 簡單流程: Scrum Master 總結(jié)本次迭代; 迭代任務(wù)清單, 重要的事情和決策, 預(yù)期的/實(shí)際進(jìn)度. 每個組員陳述迭代中那些方法進(jìn)行的較好、哪些需要改進(jìn), Scrum Master

34、 進(jìn)行記錄. 對重要的問題計(jì)劃相應(yīng)的措施：團(tuán)隊(duì)自己解決, 或者提交給公司的管理層.Scrum方法應(yīng)用撲克Poker方法敏捷開發(fā)中使用撲克Poker方法進(jìn)行估計(jì)(1/3) 盡管名字有好笑, 但卻非?？煽亢陀行? 可以來估算產(chǎn)品需求清單中每項(xiàng)的規(guī)模（規(guī)模估算: 用例點(diǎn)story point）以及迭代任務(wù)清單中任務(wù)的估計(jì) (工作量估算： 人時). Scrum Master推動活動的進(jìn)行, 一個以上的專家參與估算, 而且最好是項(xiàng)目團(tuán)隊(duì)中的人. 估算時使用卡片：寫有一系列的離散數(shù)據(jù)，如0, 1, 2, 3, 5, 8, 13, ? (無法估計(jì)).敏捷開發(fā)中使用撲克Poker方法進(jìn)行估計(jì)(2/3) 前提條

35、件: 提前準(zhǔn)備好要估算的任務(wù)、User Stories等; 迭代任務(wù)清單和產(chǎn)品需求清單都已經(jīng)起草好. 對某個任務(wù)最有經(jīng)驗(yàn)的開發(fā)者做一個簡短的概述. 可以通過簡短的討論澄清任務(wù)的具體含義，找出存在的風(fēng)險以及不確定性. 各自對任務(wù)進(jìn)行估計(jì)，所有的人將寫有各自估計(jì)數(shù)據(jù)的撲克/卡片扣上。 (單位事先進(jìn)行約定：工時、事件點(diǎn)). 大家同時把撲克/卡片翻過來. 如果撲克/卡片上的數(shù)差距比較明顯 (如一個13，2個5，一個1), 就要討論一下為什么會出現(xiàn)這么大的差距，估計(jì)值所基于的假定要進(jìn)行澄清. 如果差距較小 (如三個8兩個5) ，主持人幫助確定最終的估值. 對于不確定性，估算數(shù)據(jù)中可以多包含一些余量. 不

36、斷的重復(fù)該過程直到達(dá)成一致. 將這些估值記錄到相應(yīng)的文檔中 (產(chǎn)品需求清單, 迭代任務(wù)清單). 敏捷開發(fā)中使用撲克Poker方法進(jìn)行估計(jì) (3/3) 為什么使用離散的數(shù)字? 比使用任意數(shù)字更加容易進(jìn)行估算. 在整個項(xiàng)目中或者迭代中, 每個人估計(jì)值的錯誤會相互抵消掉. 對每個任務(wù), 16 小時是上限, 不確定性會隨著規(guī)模的增加而增加. 為什么要有 “?”. 將較大的任務(wù)進(jìn)行分解，幫助更加精確的估計(jì)同時減少不確定性. 為什么要 “討論并重復(fù)”? 弄清不同的假設(shè) (利用重用代碼或者重新編碼) 和可能的誤解 à 更為可靠的估計(jì). 對于那些偏離平均值的估計(jì)，即使由有經(jīng)驗(yàn)的人給出的，也必須要有充

37、分的理由. 測試驅(qū)動開發(fā) Test Driven Development 什么是測試驅(qū)動？ 一種能夠支持Scrum的敏捷實(shí)踐方法，開發(fā)滿足DoD的軟件 首先創(chuàng)建測試用例，然后開發(fā)軟件通過測試(在開發(fā)代碼前，首先編寫測試代碼) 一種設(shè)計(jì)軟件的方法，而不僅僅是一種測試方法 所創(chuàng)建的測試用例用來指導(dǎo)和約束項(xiàng)目中的各項(xiàng)工作，對未來的各項(xiàng)工作提供一個安全的保護(hù) 不需要測試的工作不需要完成 所創(chuàng)建的測試用例通常替代詳細(xì)的業(yè)務(wù)和技術(shù)需求定 測試也有效地驅(qū)動設(shè)計(jì)，使設(shè)計(jì)更加趨向于可行的設(shè)計(jì) 通常情況下需要自動測試的支持 (EUnit, JUnit etc.). 對于UI軟件應(yīng)用TDD方法有一定的困難測試驅(qū)動開

38、發(fā) TDD 測試用例的作用： 確定所要完成的工作 溝通工具 產(chǎn)生一致的結(jié)果 對軟件開發(fā)提供一個安全的保障Scrum的核心 反饋 檢查 接受Scrum的應(yīng)用u 概述 基本原則: 不能只挑自己喜歡的，不管其它的 Scrum非常簡單，為了有效地發(fā)揮作用，應(yīng)當(dāng)具備: 所有的角色. 所有的實(shí)踐. 所有的產(chǎn)品. Scrum 可以進(jìn)行裁剪, 但應(yīng)當(dāng)明白裁剪對工程的影響 à 需要經(jīng)驗(yàn)和仔細(xì)考慮.u 大型/跨地域項(xiàng)目 6到10人在同一房間進(jìn)行工作時，Scrum能夠發(fā)揮最大效用. Scrum也可應(yīng)用在大型的跨地域的項(xiàng)目. 一些指導(dǎo)原則: 將大的項(xiàng)目分成多個團(tuán)隊(duì)，每個團(tuán)隊(duì)6到10人，有各自的Scrum M

39、aster. 對跨地域的項(xiàng)目，盡量不要把一個Scrum團(tuán)隊(duì)分到多個地方，一個Scrum團(tuán)隊(duì)就在一個地方，有自己的Scrum Master. 但是，如果團(tuán)隊(duì)的跨地域是不可避免的，可以使用網(wǎng)絡(luò)工具遠(yuǎn)程召開Scrum例會. 劃分團(tuán)隊(duì)時，團(tuán)隊(duì)之間應(yīng)該有一個“自然界面” ，如為避免混亂，不同的團(tuán)隊(duì)負(fù)責(zé)產(chǎn)品的不同部分. 對于整個項(xiàng)目/產(chǎn)品：一個產(chǎn)品/項(xiàng)目只能有一個產(chǎn)品所有者和產(chǎn)品需求清單. 團(tuán)隊(duì)之間的協(xié)調(diào)利用Scrum of Scrums方法 u Scrum of Scrumsu 固定價格的項(xiàng)目 Scrum 不鼓勵固定價格的項(xiàng)目 每次迭代時進(jìn)行項(xiàng)目預(yù)算, 產(chǎn)品需求清單可以根據(jù)當(dāng)前的優(yōu)先級進(jìn)行調(diào)整. 某些項(xiàng)

40、目中, 客戶需要我們對整個項(xiàng)目給一個報(bào)價或者預(yù)算. 價格固定限制了靈活性 (對變化的響應(yīng)): 如果價格和進(jìn)度是固定的，那么整個項(xiàng)目的范圍也是固定的 (PB). 必須對項(xiàng)目所有的迭代都進(jìn)行詳細(xì)的計(jì)劃和規(guī)模估計(jì). 變更項(xiàng)目的范圍，以及隨之而來的預(yù)算/進(jìn)度的變更需要提交CR. 當(dāng)然可以改變產(chǎn)品需求清單的優(yōu)先級，或者不改變工作量前提下把其中的某一項(xiàng)換成另一項(xiàng). 仍然可以使用Scrum，并從中獲益支持工具和模版一些常見的誤解 敏捷是拯救任何項(xiàng)目的銀彈. 敏捷方法只有運(yùn)用得當(dāng)才有效果. 敏捷意味著 ad-hoc hacking ，不需要任何文檔. 敏捷是有嚴(yán)格要求的，也是面向質(zhì)量的 根據(jù)溝通的需要產(chǎn)生相應(yīng)的文檔. 敏捷只是開發(fā)者的問題 基本的開發(fā)方法與傳統(tǒng)相比有顯著不同, 影響項(xiàng)目的各個方面: 合同, 角色, 定價模型, 項(xiàng)目管理等. 采用敏捷方法的開發(fā)組/項(xiàng)目不需要制定計(jì)劃 敏捷項(xiàng)目需要經(jīng)常制定計(jì)劃，但是不需要試圖超前制定項(xiàng)目計(jì)劃，通常這也是不可能的. 敏捷項(xiàng)目的范圍可以隨時改變. 變更可以等到下一次迭代開始，當(dāng)前正在進(jìn)行中的迭代不能變更 只對小項(xiàng)目適用 在中型和大型的項(xiàng)目中一樣取得了成功敏捷開發(fā)各階段的主要活動項(xiàng)目生命周期 主要包含三個階段： 產(chǎn)品定義(計(jì)劃)：進(jìn)行迭代所需要的項(xiàng)目準(zhǔn)備、項(xiàng)目計(jì)劃和技術(shù)分析 迭代開發(fā)(執(zhí)行)：在固定時間的迭代中實(shí)現(xiàn)需求（產(chǎn)品需