關(guān)于我們
書單推薦
新書推薦
|
Scrum精髓:敏捷轉(zhuǎn)型指南 短短幾年時間,Scrum躍升為敏捷首選方法,在全球各地得以普遍應(yīng)用。針對如何用好、用巧這個看似簡單的框架,本書以通俗易懂的語言、條理清晰的脈絡(luò)闡述和提煉出Scrum的精髓。全書共4部分23章,闡述了七大核心概念:Scrum框架,敏捷原則,沖刺,需求和用戶故事,產(chǎn)品訂單,估算與速率,技術(shù)債;五大角色:產(chǎn)品負責(zé)人,ScrumMaster,開發(fā)團隊,Scrum團隊結(jié)構(gòu),經(jīng)理:Scrum規(guī)劃原則及四大規(guī)劃活動:多層次規(guī)劃、產(chǎn)品組合規(guī)劃、產(chǎn)品規(guī)劃和長期規(guī)劃;沖刺四大活動:規(guī)劃、執(zhí)行、評審和回顧。 本書取自作者十多年的實踐經(jīng)驗,對員工個體和管理層都具有重要的指導(dǎo)和參考意義,可以幫助企業(yè)導(dǎo)入Scrum方法實現(xiàn)敏捷轉(zhuǎn)型,從而在動態(tài)的商業(yè)環(huán)境中以積極的心態(tài)擁抱變化,做出優(yōu)秀、卓越的產(chǎn)品,成就創(chuàng)業(yè)、守業(yè)、常青基業(yè)。
上市以來雄踞亞馬遜敏捷類暢銷書榜首,熱評如潮 Scrum精髓,一點就通,一本就夠 揭示同類書不告訴你的主題和秘笈 適用于大多數(shù)敏捷過程的實用指南 適合團隊成員、經(jīng)理和執(zhí)行負責(zé)人閱讀的知識讀本 如果想用Scrum來開發(fā)足以引爆流行的產(chǎn)品和服務(wù),本書就是你夢寐以求的完全參考。作為業(yè)內(nèi)領(lǐng)先的敏捷教練和培訓(xùn)師,KennethRubin用通俗易懂的語言和豐富的實例與我們分享他十多年的實踐經(jīng)驗,詮釋Scrum的價值觀、原則和實踐,描述一些靈活、可行的方法幫助我們用好Scrum! ♂槍crum新手和達人,本書從團隊、產(chǎn)品和產(chǎn)品組合這三個層面來介紹、澄清和深化Scrum的相關(guān)原則和應(yīng)用。Rubin曾幫助數(shù)百個組織成功應(yīng)用Scrum,積累了相當(dāng)豐富的實踐經(jīng)驗和表達能力。作為這些經(jīng)驗和能力的結(jié)晶,本書圖文并茂,通過通俗易懂的描述和兩百多幅圖對Scrum進行了闡述,這些圖采用的是一種全新的視覺圖標語言,用于描述Scrum的角色、工件和活動! ”緯梢詭椭鷪F隊成員、經(jīng)理和執(zhí)行主管了解Scrum常識,掌握可以拿來即用的通用詞匯表,充分攫取Scrum的潛力,最終實現(xiàn)優(yōu)秀團隊能夠做到持續(xù)、穩(wěn)健發(fā)展的目標。
什么是Scrum?2 Scrum的起源3 為什么要用Scrum?5 Genomica取得的成果6 Scrum能給你帶來幫助嗎?6 復(fù)雜域9 繁雜域10 簡單域10 混亂域10 無序11 事務(wù)性工作11 結(jié)語12 第Ⅰ部分 核 心 概 念 第2章 Scrum框架17 概述17 Scrum角色19 產(chǎn)品負責(zé)人20 ScrumMaster20 開發(fā)團隊21 Scrum活動與工件21 產(chǎn)品列表23 沖刺25 制定沖刺計劃26 沖刺執(zhí)行28 每日例會29 完成31 沖刺評審32 沖刺回顧33 結(jié)語34 第3章 敏捷原則35 概述35 可變性和不確定性37 積極采用有幫助的可變性38 采用迭代和增量開發(fā)39 通過檢視、調(diào)整和透明充分利用可變性42 同時減少各種各樣的不確定因素43 預(yù)測和適應(yīng)44 不到最后時刻,不輕易做決定44 承認無法一開始就把事情做對45 偏好適應(yīng)性、探索式的方法46 用經(jīng)濟合理的方法接受變化48 平衡預(yù)測性的事前工作和適應(yīng)性的剛好及時工作之間的關(guān)系51 經(jīng)驗認知52 快速驗證重要的假設(shè)52 利用多個認知循環(huán)并行的優(yōu)勢53 妥善組織工作流程以獲得快速反饋54 WIP56 批量大小要經(jīng)濟合理56 識別并管理庫存以達到良好的流動57 關(guān)注閑置工作,而非閑置人員59 考慮延期成本61 進度63 根據(jù)實時信息來重新制定計劃63 通過驗證工作結(jié)果來度量進度63 聚焦于以價值為中心的交付64 執(zhí)行65 快速前進,但不匆忙65 以質(zhì)量為魂65 采用最小夠用的儀式66 結(jié)語68 第4章 沖刺71 概述71 時長限定72 設(shè)定WIP數(shù)量限制72 強制排列優(yōu)先順序73 展示進度73 避免不必要的完美主義73 促進結(jié)束74 增強可預(yù)測性74 持續(xù)期短74 容易規(guī)劃74 反饋快74 投入產(chǎn)出比高75 錯誤有限75 有助于“滿血復(fù)活”75 檢查點多76 一致的持續(xù)期77 有節(jié)奏感78 簡化規(guī)劃活動79 鎖定沖刺目標80 什么是沖刺目標?80 共同承諾80 是變更,還是澄清?80 變更引起的后果81 注重實效83 異常終止84 完成的定義85 什么是完成的定義?86 完成的定義可以隨時間演變88 完成的定義還是接收標準?89 完成還是完成-完成90 結(jié)語91 第5章 需求與用戶故事93 概述93 利用對話96 逐步細化97 用戶故事是什么?97 卡片98 對話99 確認100 詳細程度101 好故事的INVEST原則104 獨立104 可協(xié)商105 有價值106 可估算107 大小合適108 可測試108 非功能性需求109 知識獲取型故事110 收集故事112 用戶故事寫作研討會112 繪制故事地圖113 結(jié)語115 第6章 產(chǎn)品列表117 概述117 PBI118 產(chǎn)品列表的四大特征119 詳略得當(dāng)119 涌現(xiàn)的120 做過估算的121 排列優(yōu)先順序的122 梳理123 什么是梳理?123 由誰來梳理?124 何時梳理?125 就緒的定義127 工作流管理128 版本的工作流管理129 沖刺的工作流管理130 產(chǎn)品列表有哪些,應(yīng)該有多少?131 什么是產(chǎn)品?132 大型產(chǎn)品,層級化列表133 多個團隊,一個產(chǎn)品列表135 一個團隊,多個產(chǎn)品136 結(jié)語137 第7章 估算與速率139 概述139 何時估,估什么?141 組合列表條目的估算141 產(chǎn)品列表條目的估算142 任務(wù)估算143 PBI估算的概念143 團隊估算144 估算不是承諾145 準確與精確146 估算相對大小147 PBI估算的單位149 故事點149 理想天149 規(guī)劃撲克150 估算151 活動規(guī)則152 好處155 什么是速率?155 計算速率范圍156 預(yù)測速率157 影響速率的因素158 速率的誤用160 結(jié)語161 第8章 技術(shù)債163 概述163 技術(shù)債的后果165 爆發(fā)點不可預(yù)期165 交付時間延長166 缺陷數(shù)量可觀167 開發(fā)和支持成本上升167 產(chǎn)品萎縮168 可預(yù)測性降低168 表現(xiàn)越來越差168 挫折感四處彌漫168 客戶滿意度降低169 技術(shù)債的起因169 如期完工的壓力169 試圖以錯誤的方式提高速率170 誤區(qū):減少測試可以提高速率171 債累債172 技術(shù)債必須加以管理173 管理應(yīng)計技術(shù)債174 使用良好的技術(shù)實踐174 使用強完成定義175 正確理解技術(shù)債經(jīng)濟175 讓技術(shù)債可見178 讓技術(shù)債在業(yè)務(wù)層面可見178 讓技術(shù)債在技術(shù)層面可見180 償還技術(shù)債181 并非所有技術(shù)債都應(yīng)該償還182 行將就木的產(chǎn)品183 一次性原型183 短命產(chǎn)品183 應(yīng)用童子軍規(guī)則 (有債就還)184 分期償還技術(shù)債185 先償還高息技術(shù)債186 一邊做有客戶價值的工作,一邊償還技術(shù)債186 結(jié)語188 第Ⅱ部分 Scrum的角色 第9章 產(chǎn)品負責(zé)人191 概述191 主要職責(zé)192 管理經(jīng)濟效益193 版本層面的經(jīng)濟考量193 沖刺級別的經(jīng)濟考量194 產(chǎn)品列表的經(jīng)濟考量195 參與規(guī)劃195 梳理產(chǎn)品列表195 定義接收標準并驗證196 與開發(fā)團隊協(xié)作196 與利益干系人協(xié)作198 特征∕技能198 領(lǐng)域能力199 人際交往能力200 決策力200 責(zé)任心201 日常工作內(nèi)容201 誰來擔(dān)任產(chǎn)品負責(zé)人?204 內(nèi)部開發(fā)205 商業(yè)開發(fā)206 外包開發(fā)項目208 組件開發(fā)209 產(chǎn)品負責(zé)人兼任其他角色210 產(chǎn)品負責(zé)人團隊210 產(chǎn)品負責(zé)人代理211 首席產(chǎn)品負責(zé)人212 結(jié)語213 第10章 ScrumMaster215 概述215 主要職責(zé)215 教練215 服務(wù)型領(lǐng)導(dǎo)217 過程權(quán)威217 “保護傘”217 “清道夫”218 變革代言人218 特征/技能218 見多識廣218 善于提問219 有耐心219 有協(xié)作精神220 保護團隊220 公開透明220 日常工作內(nèi)容221 履行角色222 誰來擔(dān)任ScrumMaster?222 ScrumMaster是全職工作嗎?223 ScrumMaster兼任其他角色223 結(jié)語225 第11章 開發(fā)團隊227 概述227 專職團隊227 主要職責(zé)228 沖刺執(zhí)行229 每日檢視和調(diào)整229 梳理產(chǎn)品列表229 沖刺規(guī)劃229 檢視和調(diào)整產(chǎn)品與過程230 特征/技能230 自組織231 跨職能的多樣化和全面化233 T型技能234 火槍手態(tài)度236 溝通廣泛237 透明溝通239 規(guī)模適中239 專注、有責(zé)任感240 工作步調(diào)可持續(xù)242 團隊人員穩(wěn)定243 結(jié)語245 第12章 Scrum團隊結(jié)構(gòu)247 概述247 特性團隊與組件團隊248 多團隊之間的協(xié)調(diào)253 SoS253 版本火車255 結(jié)語258 第13章 經(jīng)理259 概述259 塑造團隊261 定義邊界261 提供一個清晰而鼓舞人心的目標262 組建團隊262 改變團隊的人員組成263 授權(quán)團隊264 培育團隊265 激勵團隊265 發(fā)展團隊能力266 建立職能領(lǐng)導(dǎo)力267 保持團隊的完整性267 整改環(huán)境268 傳播敏捷價值觀268 移除組織層面的障礙268 使內(nèi)部各個團隊一致269 使外部合作伙伴一致269 管理價值創(chuàng)造流程270 采用系統(tǒng)化視角270 管理經(jīng)濟效益270 測量和報告271 項目經(jīng)理272 Scrum團隊中的項目管理職責(zé)272 保留單獨的項目經(jīng)理角色274 結(jié)語278 第Ⅲ部分 規(guī) 劃 第14章 Scrum的規(guī)劃原則283 概述283 假設(shè)事先無法制定完美計劃284 事先規(guī)劃有幫助,但不宜過度284 最后責(zé)任時刻才敲定計劃286 關(guān)注適應(yīng)與重新規(guī)劃勝于遵循計劃286 正確管理規(guī)劃庫存288 提倡更小、更頻繁發(fā)布289 計劃快速學(xué)習(xí)并在必要時 調(diào)頭291 結(jié)語291 第15章 多層級規(guī)劃293 概述293 組合規(guī)劃295 產(chǎn)品規(guī)劃(構(gòu)想)295 愿景295 概要產(chǎn)品列表296 產(chǎn)品路線圖296 版本規(guī)劃298 沖刺規(guī)劃300 日常規(guī)劃301 結(jié)語302 第16章 產(chǎn)品組合規(guī)劃303 概述303 時間安排303 參與者304 流程304 進度安排策略306 優(yōu)先考慮生命周期利潤307 計算延期成本308 估算要準確,不必精確311 流入策略312 應(yīng)用經(jīng)濟過濾器313 到達率和離開率要平衡314 快速擁抱新涌現(xiàn)的機會316 為更小、更頻繁發(fā)布做計劃317 流出策略318 關(guān)注閑置工作, 而非閑置人員318 設(shè)立WIP限制319 等待整個團隊一起行動320 WIP策略321 使用邊際效益321 結(jié)語323 第17章 構(gòu)想(產(chǎn)品規(guī)劃)325 概述325 時間安排326 參與者327 過程327 示例:SR4U329 建立愿景330 創(chuàng)建概要產(chǎn)品列表333 定義產(chǎn)品路線圖334 其他活動337 從經(jīng)濟合理的角度構(gòu)想產(chǎn)品339 瞄準一個實際的信心閾值340 關(guān)注短期收益341 動作要快342 花錢買經(jīng)驗認知343 使用遞增/暫行的資助方式344 快速學(xué)習(xí)并調(diào)頭 (即快速失。345 結(jié)語346 第18章 版本規(guī)劃(長期規(guī)劃)347 概述347 時間安排348 參與者349 過程349 版本約束351 固定一切352 固定范圍和日期352 固定范圍354 固定日期354 可變質(zhì)量355 更新約束355 梳理產(chǎn)品列表356 細化最小可發(fā)布特性357 沖刺映射(PBI歸位)358 版本規(guī)劃:固定日期版本360 版本規(guī)劃:固定范圍版本365 計算成本367 溝通進展情況368 固定范圍版本如何溝通369 固定日期版本如何溝通371 結(jié)語373 第Ⅳ部分 沖 刺 第19章 沖刺規(guī)劃377 概述377 時間安排377 參與者378 流程378 沖刺規(guī)劃的兩種方式380 兩段式?jīng)_刺規(guī)劃381 一次性沖刺規(guī)劃382 確定生產(chǎn)能力382 什么是生產(chǎn)能力?382 用故事點來表示生產(chǎn)能力384 用工時來表示生產(chǎn)能力385 選取PBI386 獲得信心386 細化沖刺目標388 敲定承諾388 結(jié)語389 第20章 沖刺執(zhí)行391 概述391 時間安排391 參與者391 流程392 沖刺執(zhí)行規(guī)劃393 工作流程管理394 并行工作和蜂擁式394 從哪個PBI開始397 如何安排任務(wù)397 需要完成哪些工作?398 誰來做具體工作?398 每日例會399 任務(wù)執(zhí)行:強調(diào)技術(shù)實踐399 溝通401 任務(wù)板401 沖刺燃盡圖402 沖刺燃燒圖404 結(jié)語406 第21章 沖刺評審407 概述407 參與者408 準備工作410 確定邀請誰參加410 安排活動日程411 確認沖刺工作完成411 演示準備工作412 確定誰做什么413 方式(方法)413 總結(jié)414 演示415 討論416 調(diào)整416 沖刺評審的問題417 簽字接收417 斷斷續(xù)續(xù)地參與417 大型開發(fā)工作418 結(jié)語419 第22章 沖刺回顧421 概述421 參與者423 準備工作424 定義回顧重點425 選擇練習(xí)活動425 收集客觀數(shù)據(jù)426 安排回顧日程426 方式(方法)427 營造氛圍429 建立共同背景429 事件時間線431 情緒測震儀431 得出見解432 確定采取行動437 回顧結(jié)束438 貫徹執(zhí)行438 沖刺回顧的問題439 結(jié)語442 第23章 前進之路443 Scrum,有完?沒完!443 修行靠個人444 分享最佳實踐444 使用Scrum探明未來之路446 整裝待發(fā)!447 后記449 詞匯表453 參考文獻475
KennethRubin
Ken提供Scrum和敏捷培訓(xùn)與教導(dǎo)服務(wù),旨在幫助企業(yè)以更高效、更經(jīng)濟合理的方式開發(fā)產(chǎn)品。作為一名認證的Scrum培訓(xùn)師,他曾為1.8萬人提供過Scrum和敏捷培訓(xùn),管理過面向?qū)ο箜椖颗c企業(yè)轉(zhuǎn)型管理過程。他還為數(shù)千家公司(從初創(chuàng)公司到財富十強的企業(yè))提供教練服務(wù)。Rubin是全球Scrum聯(lián)盟的首任常務(wù)董事,Scrum聯(lián)盟是一家非盈利機構(gòu),著眼于推廣Scrum的成功應(yīng)用。從事開發(fā)工作期間,Rubin也是一個能干的多面手,先后擔(dān)任過Scrum產(chǎn)品負責(zé)人、ScrumMaster和開發(fā)人員。他的管理經(jīng)歷也很豐富,擔(dān)任過CEO,COO,工程副總,產(chǎn)品管理副總和專業(yè)服務(wù)副總。他還是SucceedingwithObjects:DecisionFrameworksforProjectManagement一書的合著者,此書出版于1995年。他還獨立開發(fā)了業(yè)內(nèi)享有盛譽的OBA/D(對象行為分析與設(shè)計)方法論。 姜信寶喜歡新鮮事物,喜歡讀書,喜歡分享,愿意和大家共同進步。Agile1001公開課聯(lián)合發(fā)起人之一。CSP,CSM,PMP。熱衷和推廣敏捷,是國內(nèi)敏捷社區(qū)的主要推動者之一。 米全喜IT行業(yè)的一名老兵,敏捷愛好者,在軟件開發(fā)、測試、項目管理和運行方面都有一定的工作經(jīng)驗,目前從事金融行業(yè)IT流程管理工作。參與過《團隊之美》、《編程 KennethRubin
推薦序—Mike Cohn
推薦序—Ron Jeffries 推薦序—李國彪 前言 致謝 第1 章引言 什么是Scrum? Scrum 的起源 為什么要用Scrum? Genomica 取得的成果 Scrum 能給你帶來幫助嗎? 復(fù)雜域 繁雜域 簡單域 推薦序—Mike Cohn 推薦序—Ron Jeffries 推薦序—李國彪 前言 致謝 第1 章引言 什么是Scrum? Scrum 的起源 為什么要用Scrum? Genomica 取得的成果 Scrum 能給你帶來幫助嗎? 復(fù)雜域 繁雜域 簡單域 混亂域 無序 常常被打斷的工作 結(jié)語 第Ⅰ部分 核心概念 第 2 章 Scrum 框架 概述 Scrum 角色 產(chǎn)品負責(zé)人 ScrumMaster 開發(fā)團隊 Scrum 活動與工件 產(chǎn)品 Backlog 沖刺 制定沖刺計劃 目錄 沖刺執(zhí)行 每日例會 完成 沖刺評審 沖刺回顧 結(jié)語 第 3 章敏捷原則 概述 可變性和不確定性 積極采用有幫助的可變性 采用迭代和增量開發(fā) 通過檢查、調(diào)整和透明性充分利用可變性 同時減少各種形式的不確定因素 預(yù)測與適應(yīng) 保持選擇開放 承認無法一開始就把事情做對 偏好適應(yīng)性、探索式的方法 用經(jīng)濟合理的方法接受變化 平衡預(yù)測性的事前工作和適應(yīng)性的剛好及時工作之間的關(guān)系 經(jīng)過驗證的認知 快速驗證重要的假設(shè) 利用多個認知循環(huán)并行的優(yōu)勢 組織妥善工作流程以獲得快速反饋 在制品 批量大小要經(jīng)濟、合理 識別并管理庫存以達到良好的流動 考慮延遲成本 進度 根據(jù)實時信息來重新制定計劃 通過驗證工作結(jié)果來度量進度 聚焦于以價值為中心的交付 執(zhí)行 快速前進,但不匆忙 內(nèi)建質(zhì)量 采用最小夠用的儀式 結(jié)語 第 4 章沖刺 概述 時長限定 設(shè)定在制品數(shù)量限制 強制排列優(yōu)先順序 展示進度 避免不必要的完美主義 促進結(jié)束 增強可預(yù)測性 持續(xù)期短 容易制定計劃 快速反饋 提高投入產(chǎn)出比 有限的錯誤 重新煥發(fā)活力 頻繁的檢查點 一致的持續(xù)期 節(jié)奏感的好處 簡化計劃過程 所做的變化不允許改變目標 什么是沖刺目標? 共同的承諾 是變更,還是澄清 變更所引起的后果 注重實效 異常終止 完成的定義 什么是完成的定義 完成的定義可以隨時間演變 完成的定義與驗收標準的比較 完成還是完成-完成 結(jié)語 第 5 章需求與用戶故事 概述 利用對話 逐步細化 用戶故事是什么 卡片 確認 細化程度 好故事的INVEST 原則 獨立 可協(xié)商 有價值 可估算 大小合適(。 可測試 非功能性需求 目錄 知識獲取型故事 收集故事 用戶故事編寫研討會 繪制故事地圖 結(jié)語 第 6 章產(chǎn)品 Backlog 概述 PBI 哪種方法更適合好的產(chǎn)品Backlog 有何特征 詳略得當(dāng) 涌現(xiàn)的 做過估算的 排列好優(yōu)先順序的 修整 什么是修整 由誰來修整? 何時修整? 就緒的定義 工作流管理 版本工作流管理 沖刺工作流管理 有哪些產(chǎn)品Backlog,有多少個? 什么是產(chǎn)品? 大型產(chǎn)品——層級式Backlog 多個團隊,一個產(chǎn)品Backlog 一個團隊,多個產(chǎn)品 結(jié)語 第 7 章估算與速率 概述 何時估算,估算什么 產(chǎn)品組合Backlog 條目的估算 產(chǎn)品 Backlog 的估算 任務(wù)估算 PBI 估算的概念 團隊估算 估算不是承諾 準確相比精確 相對大小估算 PBI 估算單位 故事點 理想天數(shù) 規(guī)劃撲克 估算規(guī)模 活動規(guī)則 好處 什么是速率? 計算速率范圍 預(yù)測速率 影響速率 速率的誤用 結(jié)語 第 8 章技術(shù)債 概述 技術(shù)債的后果 目錄 不知何時爆發(fā) 交付時間增長 缺陷數(shù)量可觀 開發(fā)支持成本上升 產(chǎn)品萎縮 可預(yù)測度降低 表現(xiàn)欠佳 普遍的挫敗感 客戶滿意度降低 技術(shù)債的起因 按期完工的壓力 嘗試錯誤地提速 誤區(qū):減少測試可以提速 債累債 技術(shù)債必須加以管理 管理技術(shù)債的增長 使用良好的技術(shù)實踐 使用強完成標準 正確理解技術(shù)債的經(jīng)濟效果 讓技術(shù)債可見 讓技術(shù)債在業(yè)務(wù)層面可見 讓技術(shù)債在技術(shù)層面可見 維護技術(shù)債 并非所有技術(shù)債都應(yīng)償還 行將就木型產(chǎn)品 即扔原型 短命型產(chǎn)品 應(yīng)用童子軍規(guī)則(即遇技術(shù)債即維護) 增量地償還技術(shù)債 先償還高利息技術(shù)債 邊做有客戶價值工作邊償還技術(shù)債 結(jié)語 第Ⅱ部分 Scrum 的角色 第 9 章產(chǎn)品負責(zé)人 概述 主要職責(zé) 管理經(jīng)濟因素 版本發(fā)布層面的經(jīng)濟情況 沖刺級的經(jīng)濟情況 產(chǎn)品 Backlog 的經(jīng)濟因素 參與制定計劃 修整產(chǎn)品Backlog 定義驗收標準并驗證這些標準是否得到滿足 與開發(fā)團隊協(xié)作 與利益干系人協(xié)作 特征∕技能 領(lǐng)域能力 人際交往能力 決策力 責(zé)任心 日常一天 誰應(yīng)當(dāng)成為產(chǎn)品負責(zé)人? 內(nèi)部開發(fā) 商業(yè)開發(fā) 外包開發(fā)項目 組件開發(fā) 目錄 產(chǎn)品負責(zé)人兼任其他角色 產(chǎn)品負責(zé)人團隊 產(chǎn)品負責(zé)人代理 首席產(chǎn)品負責(zé)人 結(jié)語 第 10 章 ScrumMaster 概述 主要職責(zé) 教練 服務(wù)型領(lǐng)導(dǎo) 過程專家 屏蔽干擾(在Scrum 中通常說“保護團隊”) 移除障礙 變革推動者 特征/技能 知識淵博 善于提問 有耐心 有協(xié)作精神 給予保護的 透明 日常一天 履行角色 誰應(yīng)該成為ScrumMaster ScrumMaster 是全職工作嗎? ScrumMaster 兼任其他角色 結(jié)語 第 11 章開發(fā)團隊 概述 專門角色的團隊 主要責(zé)任 沖刺執(zhí)行 每日檢查和調(diào)整 修整產(chǎn)品Backlog 規(guī)劃沖刺 檢查和調(diào)整產(chǎn)品和過程 特點和技能 自組織 跨職能的多樣化和全面化 T 型技能 火槍手態(tài)度 高效溝通 透明溝通 大小合適 專注與承諾 可持續(xù)的工作節(jié)奏 保持團隊持久 結(jié)語 第 12 章 Scrum 團隊結(jié)構(gòu) 概述 特性團隊與組件團隊 多個團隊的協(xié)調(diào) Scrum of Scrums 版本火車 結(jié)語 目錄 第 13 章經(jīng)理 概述 塑造團隊 定義邊界 提供一個清晰而鼓舞人心的目標 組建團隊 改變團隊的組成 授權(quán)團隊 培育團隊 激勵團隊 發(fā)展團隊能力 建立職能領(lǐng)導(dǎo)力 保持團隊完整性 調(diào)整并改造環(huán)境 傳播敏捷價值觀 移除組織層面的障礙 協(xié)調(diào)內(nèi)部多個團隊合作 使外部合作伙伴保持一致 管理價值創(chuàng)造的流程 采用系統(tǒng)性視角 管理經(jīng)濟狀況 監(jiān)控測量和報告 項目經(jīng)理 Scrum 團隊中項目管理的職責(zé) 保留單獨的項目經(jīng)理角色 結(jié)語 第 14 章 Scrum 的規(guī)劃原則 概述 前期做不好計劃 少量前期規(guī)劃仍有益 最后責(zé)任時刻前仍可改變規(guī)劃 關(guān)注適應(yīng)與重新規(guī)劃多過遵循計劃 正確管理規(guī)劃庫存 偏好更小、更頻繁地發(fā)布 必要時為快速學(xué)習(xí)與關(guān)鍵轉(zhuǎn)折作規(guī)劃 結(jié)語 第 15 章多層次規(guī)劃 概述 產(chǎn)品組合的規(guī)劃 產(chǎn)品規(guī)劃(愿景) 愿景 高層次產(chǎn)品Backlog 產(chǎn)品路線圖 制定版本計劃 制定沖刺計劃 制定每日計劃 結(jié)語 第 16 章產(chǎn)品組合規(guī)劃 概述 時機 參與者 流程 進度安排策略 為生命周期利潤而優(yōu)化 計算延期成本 目錄 準確估算,而不用精確估算 流入策略 應(yīng)用經(jīng)濟指標 平衡到達日期和離開日期 快速擁抱新涌現(xiàn)的機會 為更小、更頻繁的發(fā)布做計劃 流出策略 關(guān)注閑置工作,而非閑置人員 設(shè)定在制品限制 等待一個完整的團隊 在制品策略 使用邊際效益 結(jié)語 第 17 章構(gòu)想(產(chǎn)品規(guī)劃) 概述 時機 參與者 流程 SR4U 實例 愿景 建立概要產(chǎn)品Backlog 定義產(chǎn)品路線圖 其他活動 以經(jīng)濟合理合理的方式建立構(gòu)想 瞄準切實可行的信心門檻 關(guān)注短期范圍 快速行動 為經(jīng)驗知識付出代價 使用遞增的/暫行資金 快速學(xué)習(xí)和調(diào)頭(也稱快速失敗) 第 18 章版本計劃(長期計劃) 概述 時間安排 參與者 過程 版本限制條件 固定全部特性 固定范圍和日期 固定范圍 固定日期 可變質(zhì)量 更新限制條件 修整產(chǎn)品Backlog 細化最小可發(fā)布特性(MRF) 沖刺映射(插入PBI) 固定日期的版本計劃 固定范圍的版本計劃 計算成本 溝通 對固定范圍版本的進展情況進行溝通 對固定范圍版本的燃盡圖進行溝通 固定范圍版本的燃燒圖 結(jié)語 第Ⅳ部分 沖刺 第 19 章沖刺計劃 概述 時機 參與者 流程 沖刺計劃的方法 兩段式?jīng)_刺計劃 一次性沖刺計劃 確定生產(chǎn)能力 什么是生產(chǎn)能力? 用故事點表示的生產(chǎn)能力 用工時表示生產(chǎn)能力 選取 PBI 獲得信心 優(yōu)化沖刺目標 敲定承諾 結(jié)語 第 20 章沖刺執(zhí)行 概述 時間安排 參與者 流程 沖刺執(zhí)行計劃 工作流動管理 并行工作和蜂擁式 從哪項工作開始 如何安排任務(wù) 需要完成什么工作 誰來做具體的工作? 每日例會 任務(wù)執(zhí)行——技術(shù)實踐 溝通 任務(wù)板 沖刺燃盡圖 沖刺燃燒圖 結(jié)語 第 21 章沖刺評審 概述 參與者 準備工作 確定邀請誰參加 安排活動日程 確認沖刺工作完成了 為演示做準備 確定誰做什么 方法 總結(jié) 演示 討論 調(diào)整 有關(guān)沖刺評審的問題 簽字驗收 斷斷續(xù)續(xù)地參與 大型開發(fā)工作 結(jié)語 第 22 章沖刺回顧 概述 參與者 準備工作 定義回顧的重點 選擇需要完成的任務(wù) 收集客觀數(shù)據(jù) 安排回顧工作 方法 營造氛圍 共同的上下文 事件的時間線 情緒測震儀 找出見解 確定措施 選擇見解 確定行動 見解 Backlog 結(jié)束回顧 進行到底 有關(guān)沖刺回顧的問題 結(jié)語 第 23 章前進的道路 終極狀態(tài)是不存在的 找到自己的道路 共享最佳實踐 使用 Scrum 發(fā)現(xiàn)前進的道路 心動不如行動__
預(yù)測與適應(yīng)
在使用Scrum時,經(jīng)常需要平衡預(yù)測性的事前工作與適應(yīng)性的適時工作之間的關(guān)系。下面五個敏捷原則與這個主題相關(guān): 保持選擇開放 承認無法一開始就把事情做對 偏好適應(yīng)性、探索式的方法 用經(jīng)濟合理的方法積極主動接受變化 在預(yù)測性的事前工作和適應(yīng)性的適時工作之間做出平衡 保持選擇開放 對于需求或設(shè)計,計劃驅(qū)動的順序開發(fā)方式要求在當(dāng)前這個階段就做出重要的決策并進行審批。而且,在進入下一個階段之前必須先做出決策,即使這些決策依據(jù)的知識有限。 Scrum認為,不該單單因為通用過程要求此時做出決定,我們就得做出不成熟的決定。相反,在使用Scrum時,我們傾向于“保持選擇開放”這個策略。這個原則常被稱為“最后責(zé)任時刻”(LastResponsibleMoment,LRM)(PoppendieckandPoppendieck,2003),意思是推遲做出承諾,直到最后責(zé)任時刻再做出重要的、不可逆轉(zhuǎn)的決定。那么,最后責(zé)任時刻是什么時候呢?這個時刻就是不做決定的成本大于做決定的成本時(參見圖3.6)。此時,就需要做出決定了。 圖3.6在最后責(zé)任時刻做出決定 為了領(lǐng)會這個原則,我們考慮下面這種情況。在產(chǎn)品開發(fā)工作的第一天,我們對自己的工作內(nèi)容了解得最少。隨后的每一天,我們的了解都能多一點點。既然如此,為什么要在第一天或者很早就做出所有最關(guān)鍵且(也許)無法逆轉(zhuǎn)的決定呢?大多數(shù)人都傾向于等有更多信息之后再做出更明智的決定。在處理重要的或不可逆轉(zhuǎn)的決定時,如果決策太早且有錯,就會處于圖3.6中決策成本的指數(shù)部分。更好理解決策之后,決策成本會下降(因為市場和技術(shù)的確定性增加,做出錯誤決策的可能性降低了)。這說明我們應(yīng)該在掌握更多信息之后再做決策。 承認無法一開始就把事情做對 計劃驅(qū)動的過程不僅要求有完整的需求和全面的計劃,還想當(dāng)然地認為事先就能“把事情做對”。但實際情況是我們基本上不可能事先就能以正確的方式得到所有需求,也不可能基于這些需求以正確方式得出詳盡的計劃。更糟糕的是,一旦需求有變,還得修改需求和計劃基線以適應(yīng)當(dāng)時的實際情況(詳情參見第5章)。 在Scrum中,我們承認自己不可能事先確定所有需求或計劃。事實上,我們認為這樣做可能很危險,因為可能漏掉重要的知識而產(chǎn)生大量低質(zhì)量的需求(參見圖3.7)。 圖3.7計劃驅(qū)動的需求獲取與產(chǎn)品知識積累 圖3.7表明,在使用計劃驅(qū)動的順序過程時,在早期產(chǎn)品知識積累有限的時候就產(chǎn)生了大量需求。這樣做是有風(fēng)險的,因為它使我們產(chǎn)生錯覺,認為自己已經(jīng)消除了結(jié)果不確定性。一旦了解得更多或事情有變,可能還會造成巨大的浪費(詳情參見后文)。 在Scrum中,我們也會預(yù)先產(chǎn)生需求和計劃,但原則是夠用就好,一旦了解更多在建產(chǎn)品的相關(guān)知識,我們就會填充需求和計劃的細節(jié)。畢竟,在開始構(gòu)建前,即使我們篤定要以什么方式構(gòu)建哪些特性,但在把早期的增量可交付物放到目標使用環(huán)境之后,還是會發(fā)現(xiàn)不對勁兒的地方。此時,種種實際情形都會推動我們改變初衷,去做真正適用、適時的東西。 偏好適應(yīng)性、探索式的方法 使用(或利用)現(xiàn)在已知的東西并對未知的東西進行預(yù)測,這是計劃驅(qū)動的順序過程關(guān)注的重點。Scrum則更傾向于恰當(dāng)運用探索式方法,在此基礎(chǔ)上采用適應(yīng)性的試錯法。 探索指的是通過某些活動來獲得知識,例如構(gòu)建原型、創(chuàng)建概念驗證、實施研究或進行試驗。換句話說,則是面對不確定,我們通過探索來獲取信息。 工具和技術(shù)對探索成本有很大的影響。在過去,軟件產(chǎn)品開發(fā)的探索成本很高,因而采用預(yù)測性的、盡量一開始時做對的方法是有利的(參見圖3.8)。 圖3.8過去的探索成本 舉個例子,我在佐治亞理工學(xué)院讀大一時(上世紀80年代初),我用過幾次打孔卡——跟打字機似的,如果出錯或需要修改,是很煩人的。必須非常小心地為所有解決方案逐個做打孔卡,然后再排隊等待使用大型機,可能得等上24小時才能驗證解決方案是否正確,在這樣的背景下,“快點試一試,看情況”這個理念是讓人很難接受的。即使微不足道的排版錯誤,也至少得耽誤一天的工夫。瀑布過程在面對不確定性時可以仔細考慮當(dāng)前知識并做出預(yù)測,以求找到優(yōu)化的解決方案,這種做法在經(jīng)濟上是合理的。 幸運的是,現(xiàn)在的工具和技術(shù)越來越好,探索成本也隨之下降。從經(jīng)濟層面上不再是探索的阻礙。事實上,到如今,快速構(gòu)建少量內(nèi)容并根據(jù)用戶反饋進行調(diào)整,其成本往往低于事先投入精力試圖一次性做對所有事情。解決方案的目標使用環(huán)境(技術(shù))如今已變得更加復(fù)雜,所以能夠采取這種做法也是很值得慶幸的。 在Scrum中,只要具備足夠的知識,就可以得出明智、合理的最終解決方案。然而,在面對不確定性時,不要一廂情愿地預(yù)測,要用低成本的探索方式來換取相關(guān)信息,并綜合利用這些信息得出明智、合理的最終解決方案。通過行動所獲得的反饋可以幫助我們確定是否還需要進一步探索以及何時進行。 用經(jīng)濟合理的方法接受變化 我們都知道,使用順序開發(fā)方式時,后期變更成本比早期變更成本高很多(參見圖3.9,基于Boehm1981)。 圖3.9順序開發(fā)方式的變更成本曲線圖 舉個例子,分析階段的變更可能只花1美元,但在后期測試階段,同樣的變更卻可能花1000美元。為什么會這樣呢?如果分析階段出現(xiàn)的錯誤能在現(xiàn)階段被發(fā)現(xiàn),那么修正成本肯定不高。但如果直到設(shè)計階段才發(fā)現(xiàn)這個錯誤,則不僅需要修正錯誤需求,可能還要修復(fù)基于這個錯誤需求所做的設(shè)計。每往后延一個階段,錯誤的影響也越大,甚至出現(xiàn)這樣的情況:分析階段的小錯誤到測試或運行階段演變成大錯誤。 為避免后期變更,順序開發(fā)過程的做法是設(shè)法提高預(yù)測的準確度,澄清系統(tǒng)需求及其實現(xiàn)過程,再加以嚴格控制,力求最小化需求和設(shè)計變更。 不幸的是,早期活動階段的過度預(yù)測往往適得其反。不僅無法消除變更,反而成為交付延期和預(yù)算超支的原因之一。為什么會出現(xiàn)這種有悖常理的事實呢?首先,為了消除昂貴的變更,我們被迫在每個階段進行過度投資,即做一些不必要、不切實際的工作。其次,在尚未得到干系人對工作產(chǎn)品的反饋以驗證我們的假設(shè)之前,我們被迫在過程早期對重要的假設(shè)進行決策。結(jié)果,根據(jù)這些假設(shè)而產(chǎn)生大量工作產(chǎn)品。后來,在這些假設(shè)被證實(或被推翻)或發(fā)生變更的時候(例如,需求的出現(xiàn)或演變),很可能得修改或放棄原有的工作成果,這樣的情況時有發(fā)生。自我實現(xiàn)的預(yù)言,其經(jīng)典模式莫過于此(參見圖3.10)。 在Scrum中,我們認為變更是很正常的。我們相信,產(chǎn)品開發(fā)所固有的不確定性是無法事先通過加班加點來預(yù)測的。因此,必須準備好積極主動迎接變更。不過,在出現(xiàn)變更時,我們希望能比傳統(tǒng)開發(fā)更經(jīng)濟的方式來處理,即使變更發(fā)生在產(chǎn)品開發(fā)工作后期。 因此,我們的目標是要讓變更成本曲線盡可能長期保持平穩(wěn)——即使在后期接受變更,開銷也是經(jīng)濟合理的。圖3.11說明了這個觀點。 我們可以通過對在制品數(shù)量和工作流進行管理來實現(xiàn)這個目標,因此,與順序開發(fā)相比,在使用Scrum時,變更成本受時間的影響更小。 不管使用哪種方式來進行產(chǎn)品開發(fā),我們都希望有這樣的關(guān)系:小的需求變更所造成的實現(xiàn)方式變更也相應(yīng)較小,因而成本變更也。ú浑y想象,大型變更帶來的成本顯然更高)。我們從這種關(guān)系中希望得到的另外一個特征:不管變更請求何時出現(xiàn),都要保持這種關(guān)系。 圖3.10自我實現(xiàn)的預(yù)言 圖3.11讓變更成本曲線趨于平穩(wěn) 在使用Scrum時,很多工作產(chǎn)品(例如詳細需求、設(shè)計和測試用例)都是以剛好及時的方式產(chǎn)生的,以免創(chuàng)建非必需的工件。這樣,在發(fā)生變更時,不必丟棄或重新修改的、基于假設(shè)而產(chǎn)生的工作或被迫做出的決定要少得多,因此可以讓成本和變更請求的大小更加成比例。 使用順序開發(fā)方式時,庫存會隨著時間的推移而增加,這意味著早期所建的工件和被迫做出的不成熟決定最終造成變更成本快速上升。這導(dǎo)致圖3.11中傳統(tǒng)開發(fā)方式的曲線在早期就出現(xiàn)拐點(曲線突然上升的那個點)。在使用Scrum開發(fā)時,到達某個時間點之后,變更成本和變更請求的比例也會變得很離譜,但這個時間點會出現(xiàn)得更晚一些(如圖3.11中的Scrum曲線拐點所示)。 平衡預(yù)測性的事前工作和適應(yīng)性的剛好及時工作之間的關(guān)系 計劃驅(qū)動開發(fā)有一個基本的理念:事先得到詳細需求和計劃是至關(guān)重要的,并且做事情要有先后。在Scrum中,我們相信前期工作有幫助,但不宜過度。 在Scrum中,我們承認不可能事先精確獲得所有需求和計劃。這是否意味著不應(yīng)該事先做需求和計劃呢?當(dāng)然不是!Scrum的要義是找到平衡點,即使平衡預(yù)測性的前期工作和適應(yīng)性的剛好及時工作之間的平衡(參見圖3.12,改編自Cohn2009中的圖)。 在開發(fā)產(chǎn)品時,應(yīng)該從經(jīng)濟合理的角度來設(shè)置平衡點,滿足法規(guī)、監(jiān)管和∕或公司的目標的前提下,盡量根據(jù)快速反饋持續(xù)進行調(diào)整,少做事前預(yù)測。 究竟怎樣才算平衡?這在一定程度上由這幾個因素推動:所建產(chǎn)品的類型、待建產(chǎn)品(結(jié)果不確定性)和產(chǎn)品構(gòu)建方式(方法不確定性)的不確定程度以及開發(fā)中的限制。過度預(yù)測要求我們在普遍存在不確定性的情況下做出假設(shè)。過度調(diào)整可能會讓我們處于動蕩中,讓人覺得工作效率低下、混亂。為了能夠快速開發(fā)創(chuàng)新產(chǎn)品,在我們的工作環(huán)境中,一方面要調(diào)整,一方面也要通過剛好夠的預(yù)測來取得平衡,以免陷入混亂。Scrum框架在秩序與混亂之間取得了很好的平衡。
你還可能感興趣
我要評論
|