Scrum敏捷軟件開(kāi)發(fā)過(guò)程.ppt

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