Scrum是一種敏捷方法，旨在指導(dǎo)團(tuán)隊(duì)進(jìn)行產(chǎn)品的迭代和增量交付。通常被稱為“敏捷項(xiàng)目管理框架”，其重點(diǎn)是使用經(jīng)驗(yàn)過(guò)程，使團(tuán)隊(duì)能夠快速，有效，有效地做出改變。傳統(tǒng)的項(xiàng)目管理方法確定了需求，以控制時(shí)間和成本;?另一方面，Scrum修復(fù)了控制需求的時(shí)間和成本。這是使用時(shí)間框，協(xié)作儀式，優(yōu)先產(chǎn)品積壓和頻繁的反饋周期來(lái)完成的。整個(gè)項(xiàng)目中業(yè)務(wù)的參與至關(guān)重要，因?yàn)镾crum在很大程度上依賴于團(tuán)隊(duì)與客戶或客戶代表之間的協(xié)作，以精益 (Lean) 方式創(chuàng)建合適的產(chǎn)品。

什么是Scrum？

我們首先應(yīng)該清楚Scrum不是什么。有一種常見(jiàn)的誤解，認(rèn)為敏捷就是?Scrum。雖然Scrum確實(shí)很敏捷，但它并不是實(shí)現(xiàn)敏捷原則的唯一方法。Scrum只是產(chǎn)品開發(fā)的眾多敏捷方法之一。其他方法包括極限編程（XP），晶體，特征驅(qū)動(dòng)開發(fā)，DSDM Atern等。所有這些方法都遵循敏捷宣言及其相關(guān)原則。一個(gè)有用的比喻是認(rèn)為敏捷是冰淇淋 (ice Cream)，而Scrum，XP，水晶 (Crystal) 等，都是不同的口味，如巧克力，草莓，香草。它們都很敏捷，它們都很好，很多都可以組合使用。

簡(jiǎn)而言之，Scrum是一種靈活的迭代和增量產(chǎn)品交付方法，它使用頻繁的反饋和協(xié)作決策。

?

歷史

Scrum基于1986年由Hirotaka Takeuchi和Ikujiro Nonaka撰寫的題為“新產(chǎn)品開發(fā)游戲”?的哈佛商業(yè)評(píng)論的論文。在本文中，作者用橄欖球運(yùn)動(dòng)作為比喻來(lái)描述自我的好處。組織團(tuán)隊(duì)進(jìn)行創(chuàng)新產(chǎn)品開發(fā)和交付。Jeff Sutherland，Ken Schwaber和Mike Beedle從本文中提取了這些想法，包括隱喻，并將其應(yīng)用于他們的軟件開發(fā)領(lǐng)域。在橄欖球術(shù)語(yǔ)之后，他們稱他們的新方法為Scrum，這個(gè)術(shù)語(yǔ)描述了球隊(duì)如何形成一個(gè)圓圈并且讓球再次發(fā)揮作用。他們?cè)?993年首次在Easel公司應(yīng)用了這種方法.Schwaber和Beedle在Scrum的敏捷軟件開發(fā)一書中寫下了他們的經(jīng)歷。2002年，Schwaber?在2004年與Scrum一起出版了敏捷項(xiàng)目管理書，其中包括Schwaber與Primavera合作完成的工作。

Scrum框架

Schwaber將Scrum稱為框架而非方法論??。這主要是由于“方法論”這個(gè)詞的內(nèi)涵，許多人認(rèn)為這些詞匯本質(zhì)上是規(guī)定性的。相比之下，Scrum只提供了一個(gè)交付結(jié)構(gòu)，但并沒(méi)有告訴你如何做特定的實(shí)踐，而是將其留給團(tuán)隊(duì)來(lái)確定。圖1顯示了基本的Scrum框架。

圖表1. Scrum Process Canvas

該項(xiàng)目始于企業(yè)提供的清晰愿景，以及按重要性排列的一系列產(chǎn)品功能。這些功能是產(chǎn)品待辦事項(xiàng)的一部分，由客戶或客戶代表（稱為產(chǎn)品負(fù)責(zé)人）維護(hù)。通常稱為迭代或沖刺的時(shí)間框是團(tuán)隊(duì)必須完成所選功能的設(shè)定時(shí)間量。短跑的長(zhǎng)度通常為一到四周，并且在整個(gè)項(xiàng)目的整個(gè)生命周期中保持這個(gè)長(zhǎng)度以便建立節(jié)奏。團(tuán)隊(duì)從產(chǎn)品待辦事項(xiàng)中選擇它認(rèn)為可以在sprint中完成的項(xiàng)目，并在sprint規(guī)劃會(huì)議中創(chuàng)建包含功能和任務(wù)的sprint backlog。

一旦團(tuán)隊(duì)致力于sprint積壓，任務(wù)工作就開始了。在sprint的這段時(shí)間內(nèi)，團(tuán)隊(duì)可以免受中斷，并且可以專注于滿足sprint目標(biāo)。不允許更改sprint backlog;?但是，可以更改產(chǎn)品積壓以準(zhǔn)備下一個(gè)sprint。

在沖刺 (Sprint) 期間，團(tuán)隊(duì)每天以15分鐘的會(huì)議（稱為scrum Standup）的形式互相討論和溝通。團(tuán)隊(duì)圍成一圈，每個(gè)成員都說(shuō)明了他們昨天做了什么，他們打算今天做什么，以及他們的方式是什么。

在sprint結(jié)束時(shí)，團(tuán)隊(duì)將他們完成的工作演示給利益相關(guān)者，并收集反饋，這將影響他們?cè)谙乱粋€(gè)sprint中的工作。他們還舉辦了一次回顧展，以了解如何改進(jìn)。這次會(huì)議至關(guān)重要，因?yàn)樗闹攸c(diǎn)是Scrum的三大支柱：透明度，檢查和適應(yīng)性。

角色和責(zé)任

Scrum中只有三個(gè)角色：ScrumMaster，產(chǎn)品負(fù)責(zé)人 (Prodcut Owner) 和開發(fā)團(tuán)隊(duì) (Development Team)。

ScrumMaster是流程的守護(hù)者，團(tuán)隊(duì)的倡導(dǎo)者和團(tuán)隊(duì)的保護(hù)者。他們消除障礙，促進(jìn)團(tuán)隊(duì)溝通，調(diào)解團(tuán)隊(duì)內(nèi)部的討論，并與團(tuán)隊(duì)外部人員進(jìn)行協(xié)商。最重要的是，它們存在于團(tuán)隊(duì)服務(wù)中。

產(chǎn)品負(fù)責(zé)人 (Prodcut Owner) 代表客戶的聲音，并有權(quán)決定產(chǎn)品。此人擁有產(chǎn)品待辦事項(xiàng)，負(fù)責(zé)將愿景傳達(dá)給團(tuán)隊(duì)，并定義積壓項(xiàng)目并確定其優(yōu)先級(jí)。產(chǎn)品負(fù)責(zé)人每天與團(tuán)隊(duì)合作，回答問(wèn)題并提供產(chǎn)品指導(dǎo)。

該開發(fā)團(tuán) (Development Team)隊(duì)由七個(gè)正負(fù)兩個(gè)人組成，他們共同負(fù)責(zé)產(chǎn)品的交付。他們擁有估算，做出任務(wù)承諾，并在每日Scrum中相互報(bào)告每日狀態(tài)。它們是自組織的，意味著結(jié)構(gòu)在沒(méi)有外界明確干預(yù)的情況下出現(xiàn)。換句話說(shuō)，團(tuán)隊(duì)擁有如何選擇構(gòu)建產(chǎn)??品功能 - 團(tuán)隊(duì)擁有“如何”，而產(chǎn)品所有者擁有“什么”。

Scrum的應(yīng)用

Scrum通過(guò)一系列儀式 (Scrum Ceremonies) 或會(huì)議 (Meetings) 來(lái)應(yīng)用。必要的Scrum儀式包括sprint計(jì)劃會(huì)議 (Sprint Planning)，每日scrum (Daily Standup)，sprint審查 (Sprint Review) 和sprint回顧 (Sprint Retrospective)。還需要使用稱為沖刺的時(shí)間框。發(fā)布計(jì)劃會(huì)議是可選的，允許規(guī)劃和預(yù)測(cè)沖刺組。

Sprint計(jì)劃會(huì)議

沖刺計(jì)劃會(huì)議在每個(gè)沖刺的第一天舉行。ScrumMaster，產(chǎn)品負(fù)責(zé)人和團(tuán)隊(duì)都出席了會(huì)議。產(chǎn)品負(fù)責(zé)人提供他或她希望在sprint中完成的功能集（“什么”），然后團(tuán)隊(duì)確定實(shí)現(xiàn)這些功能所需的任務(wù)（“如何”）。將審核工作估算，以確定團(tuán)隊(duì)是否有時(shí)間完成sprint中請(qǐng)求的所有功能。如果是這樣，團(tuán)隊(duì)承諾沖刺。如果沒(méi)有，優(yōu)先級(jí)較低的功能將返回到產(chǎn)品待辦事項(xiàng)中，直到sprint的工作負(fù)載小到足以獲得團(tuán)隊(duì)的承諾。

跟蹤進(jìn)度

一旦沖刺計(jì)劃 (Sprint Planning) 會(huì)議完成并且團(tuán)隊(duì)做出了承諾，團(tuán)隊(duì)就會(huì)開始使用高度可見(jiàn)的信息輻射器跟蹤其進(jìn)度。這些散熱器包括燃盡圖和任務(wù)板。

團(tuán)隊(duì)使用任務(wù)板跟蹤每個(gè)功能的任務(wù)進(jìn)度。使用的最小列是“待辦事宜”，“執(zhí)行”和“完成”。團(tuán)隊(duì)將在任務(wù)委員會(huì)舉行每日Scrum會(huì)議，并在陳述他們昨天做了什么，他們打算今天做什么以及他們正在努力解決的障礙時(shí)，全面移動(dòng)項(xiàng)目。有關(guān)軟件開發(fā)項(xiàng)目的示例任務(wù)板，請(qǐng)參見(jiàn)圖2。

圖表2. Scrum任務(wù)板示例

燃盡圖顯示了沖刺中剩余工作量的趨勢(shì)線。x軸是sprint中的天數(shù)，y軸是sprint規(guī)劃會(huì)議中定義的所有任務(wù)的小時(shí)數(shù)。在沖刺期間，指示剩余工作量的線應(yīng)該在沖刺的最后一天趨勢(shì)下降到零。有關(guān)sprint burndown圖表示例，請(qǐng)參閱圖表3。

圖表3. Sprint Burndown圖表示例

使用燃盡圖表，任務(wù)板和每日Scrum跟蹤Sprint進(jìn)度。結(jié)合起來(lái)，這三件事可以清楚地描述正在進(jìn)行的工作，已完成的工作，仍有待完成的工作，是否能夠及時(shí)完成，以及可能阻止團(tuán)隊(duì)滿足其沖刺和/或發(fā)布目標(biāo)。

Sprint評(píng)論 (Sprint Review)

在sprint結(jié)束時(shí)，團(tuán)隊(duì)邀請(qǐng)利益相關(guān)者參加sprint評(píng)審會(huì)議，在會(huì)議中演示sprint中完成的功能并請(qǐng)求反饋。產(chǎn)品負(fù)責(zé)人會(huì)跟蹤反饋并根據(jù)需要將其合并到產(chǎn)品待辦事項(xiàng)中。

一旦審查完成，團(tuán)隊(duì)（沒(méi)有利益相關(guān)者）進(jìn)行回顧，以確定他們希望繼續(xù)做什么，他們掙扎的是什么，以及他們對(duì)未來(lái)的改變有什么建議。創(chuàng)建一個(gè)行動(dòng)計(jì)劃，這些項(xiàng)目將在下一個(gè)sprint的過(guò)程中實(shí)施，并在下一個(gè)sprint回顧中進(jìn)行審查。

發(fā)布計(jì)劃 (Release Plan)

發(fā)布計(jì)劃也是Scrum的一部分，是一種對(duì)包含多個(gè)sprint的時(shí)間框進(jìn)行長(zhǎng)期規(guī)劃的方法。這通常是按季度完成的，本季度的結(jié)果不一定是向客戶發(fā)布的，但可能只是內(nèi)部版本以確認(rèn)系統(tǒng)集成和驗(yàn)證。圖表4顯示了發(fā)布計(jì)劃如何適應(yīng)Scrum框架的其余部分。

整個(gè)團(tuán)隊(duì)參加發(fā)布計(jì)劃會(huì)議，產(chǎn)品負(fù)責(zé)人在會(huì)議中展示他/她希望在本季度完成的功能。然而，該團(tuán)隊(duì)并未對(duì)這些功能進(jìn)行任務(wù)，而是提供總體水平估算，以確定在什么樣的沖刺中可以完成哪些功能，以及在本季度末可以完成多少這些功能。發(fā)布計(jì)劃可以是功能驅(qū)動(dòng)的（完成這組功能需要多少?zèng)_刺？），時(shí)間驅(qū)動(dòng)（我們期望在截止日期前完成多少功能？）或成本驅(qū)動(dòng)（考慮到這個(gè)預(yù)算，我們的日程安排是什么樣的，我們?cè)跊](méi)錢之前會(huì)做些什么？）

?

圖表4. Scrum中的發(fā)布計(jì)劃

?

總結(jié)

以上是生活随笔為你收集整理的使用Scrum进行敏捷项目管理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。