Scrum與OKR融合實(shí)踐經(jīng)驗(yàn)分享

很多軟件公司的研發(fā)團(tuán)隊(duì)都喜歡用Scrum管理研發(fā)流程，Scrum是一個(gè)誕生于20世紀(jì)90年代的敏捷方法論，CORNERSTONE內(nèi)部也一直在使用這一方法。

相較于瀑布式開發(fā)的其他傳統(tǒng)方法，Scrum最大的優(yōu)點(diǎn)是 關(guān)注持續(xù)快速迭代以及 對(duì)變化的適應(yīng)性。如果使用瀑布式開發(fā)，在項(xiàng)目一開始就要確定項(xiàng)目結(jié)果，并且要對(duì)此達(dá)成一致，通常還要有詳細(xì)的計(jì)劃和項(xiàng)目規(guī)范。項(xiàng)目計(jì)劃是從這些規(guī)范中產(chǎn)生的，通過以項(xiàng)目在未來的完成情況為出發(fā)點(diǎn)，向后推進(jìn)，以線形的方式規(guī)劃出 時(shí)間、 預(yù)算和 各階段的聯(lián)系性。

瀑布式開發(fā)的成品是一份路線圖，能推算出一款軟件到推出之日為止，需要完成的所有開發(fā)工作，而不足之處就是如果在軟件開發(fā)過程中出現(xiàn)了變動(dòng)，包括時(shí)間線或各階段連接時(shí)出現(xiàn)問題，甚至在很多時(shí)候連預(yù)算都需要完全重做，實(shí)際上這就破壞了計(jì)劃。

Scrum關(guān)注的是為了達(dá)到一個(gè)理想終點(diǎn)的持續(xù)快速迭代 。取代詳細(xì)計(jì)劃的是 精益管理 或者是 需求和回顧會(huì)議 ，這些會(huì)衡量每一次迭代成果?；仡檿?huì)議的目的應(yīng)該圍繞一個(gè)問題： “我們所做的工作有沒有讓我們離目標(biāo)需求更近？”

Scrum 的力量來自于它能夠管理工作，實(shí)現(xiàn)一個(gè)未知的、獨(dú)特的、或者前所未有的結(jié)果。這一方法能系統(tǒng)地、漸進(jìn)式地解決在研發(fā)過程中產(chǎn)生的問題。瀑布式開發(fā)只有在其涉及的過程和工作都是可預(yù)測的、并且此前已經(jīng)有人嘗試過的情況下，才能發(fā)揮最大功效。

這其中的差別猶如建一座橋和建一艘火箭搭載船的差別。 火箭技術(shù)相對(duì)較新，建造一艘火箭搭載船要有很多增量步驟，重復(fù)多次才能獲得成功。美國太空探索技術(shù)公司（SpaceX）為了能讓火箭在船上著陸所做的工作就是一個(gè)很好的例子。

反之，人們對(duì)建橋的流程已經(jīng)駕輕就熟且無數(shù)次成功地實(shí)踐過了。建橋不需要重復(fù)很多次，對(duì)時(shí)間和成本規(guī)劃的要求高，這就是瀑布式開發(fā)經(jīng)常應(yīng)用的領(lǐng)域。

OKR和Scrum的相似之處在于兩種方法都需要有一人專門管理實(shí)施情況，我們稱之為“ Scrum Master”或“ OKR負(fù)責(zé)人”，他們的責(zé)任就是保證團(tuán)隊(duì)依照規(guī)則行事。

Scrum是一種高度規(guī)范的方法論，有明確的職責(zé)和流程。Scrum的益處包括 透明性、項(xiàng)目可見性以及 頻繁溝通。團(tuán)隊(duì)集體決定他們?cè)跒槠趦芍艿囊粋€(gè)sprint內(nèi)能夠完成什么樣的工作，這也使Scrum變得很有民主性。

其實(shí)OKR也有一套規(guī)則，這些規(guī)則決定什么是目標(biāo)O，什么是關(guān)鍵結(jié)果KR，以及如何把二者結(jié)合起來衡量目標(biāo)的實(shí)現(xiàn)。

和Scrum一樣，OKR有時(shí)間表—— 季度和年度，這比為期兩周的sprint要長得多。設(shè)定OKR首先要做的是公司領(lǐng)導(dǎo)決定需要實(shí)現(xiàn)何種目標(biāo)，接著，團(tuán)隊(duì)設(shè)定自己的OKR，并確保團(tuán)隊(duì)的OKR與公司的目標(biāo)保持一致。

只要每個(gè)人都清楚兩種方法的范圍和參數(shù)，OKR和Scrum可以成功地結(jié)合在一起使用，效果也確實(shí)不錯(cuò)。我們?cè)诖_立公司OKR后，會(huì)進(jìn)一步落實(shí)實(shí)現(xiàn)OKR的行動(dòng)方案。Sprint和行動(dòng)方案能在行動(dòng)周期內(nèi)有機(jī)結(jié)合，促進(jìn)團(tuán)隊(duì)OKR的達(dá)成。

為了能讓這兩種方法合拍，很重要的一點(diǎn)是在每個(gè)季度開始的時(shí)候，一位OKR負(fù)責(zé)人和一位Scrum負(fù)責(zé)人與他們的研發(fā)團(tuán)隊(duì)坐在一起，決定需要在這個(gè)季度完成的最重要的事情（通常為3項(xiàng)）。

由于OKR周期更長，目標(biāo)更宏觀，而Sprint涉及的更具體的執(zhí)行層面工作，因此需要首先考慮OKR。要讓OKR在這一階段就能有效開展， 相對(duì)于強(qiáng)調(diào)對(duì)結(jié)果實(shí)現(xiàn)的追求，更應(yīng)關(guān)注對(duì)結(jié)果的衡量。

比如，如果你的目標(biāo)是解決軟件的bug ，讓產(chǎn)品更完善，那么，統(tǒng)計(jì)消滅了多少個(gè)軟件bug并不是一個(gè)有效的關(guān)鍵結(jié)果。每修復(fù)一個(gè)bug，bug的數(shù)量就少了一個(gè)，但是如果有更多的軟件bug被報(bào)出來，你就沒有讓軟件變得更完善，你僅僅是在數(shù)自己修復(fù)了多少個(gè)bug。

設(shè)定了OKR的目標(biāo)和關(guān)鍵結(jié)果后，就可以開始規(guī)劃Sprint。在這個(gè)階段，最重要的是 決定Sprint的周期。如果一個(gè)Sprint為期一個(gè)月，那一個(gè)單一的Sprint目標(biāo)很可能會(huì)直接對(duì)應(yīng)開發(fā)團(tuán)隊(duì)3個(gè)OKR目標(biāo)的其中一個(gè)。至于更常見的為期兩周的Sprint，那它的Sprint目標(biāo)則可能會(huì)變成OKR目標(biāo)的行動(dòng)方案。

關(guān)鍵結(jié)果項(xiàng)目化之后，還需要將工作進(jìn)一步細(xì)化，將項(xiàng)目細(xì)化為一個(gè)個(gè)具體的任務(wù)，并確保每個(gè)任務(wù)都有負(fù)責(zé)人及截止時(shí)間，這樣才能確保每項(xiàng)工作都落到實(shí)處還可以最大限度的避免工作延期。

(圖為 CORNERSTONE 可視化任務(wù)看板)

我們更推薦第二種方法，因?yàn)檫@種方法在連接兩個(gè)框架的同時(shí)還保持了二者最初的目標(biāo)，即Sprint管理生產(chǎn)和代碼傳輸，而OKR設(shè)定目標(biāo)，衡量評(píng)估工作結(jié)果。

但是，這也意味著每一個(gè)OKR都需要有自己的Sprint時(shí)間線。如果你有一個(gè)大型的開發(fā)團(tuán)隊(duì)在一個(gè)產(chǎn)品的不同領(lǐng)域開展工作，比如前期工作、后期工作和系統(tǒng)管理，這一方法就能發(fā)揮很好的效果。使用這種方法的話，每一個(gè)領(lǐng)域引導(dǎo)1個(gè)OKR和1條Sprint時(shí)間線，而整個(gè)小組內(nèi)部有3個(gè)OKRs。

對(duì)于規(guī)模較小，沒有能力運(yùn)轉(zhuǎn)3條Sprint時(shí)間線的開發(fā)團(tuán)隊(duì)，我們也推薦這種方法，但是只需要專注一個(gè)單一的OKR即可。 CORNERSTONE 提供了包括任務(wù)/需求/測試管理、迭代規(guī)劃、缺陷追蹤、報(bào)表統(tǒng)計(jì)、團(tuán)隊(duì)協(xié)作 、WIKI、共享文件和日歷等功能模塊 ,20人以下團(tuán)隊(duì)可免費(fèi)使用,點(diǎn)擊即可免費(fèi)注冊(cè) CORNERSTONE 。