OKR和Scrum –用OKRs-E鏈接兩個強大的框架

在Tita上，咱們收到了不少有關如何將OKR與其餘框架一塊兒用於管理組織中的人員，流程和活動的問題。在像咱們這樣的互聯網軟件開發公司中，最受歡迎的公司之一是Scrum。

Scrum的好處以及爲什麼賽過Waterfall

與其餘傳統框架（如Waterfall）相比，Scrum的最大好處是它專一於短而增量的衝刺以及對變化的適應性。

使用Waterfall，能夠在項目開始時就定義結果並達成共識，一般會有詳細的範圍和項目規範。經過從未來的完成點開始進行工做，能夠從這些規範中得出計劃，並以線性方式制定時間，預算和依賴項。這種方法的產品是一個路線圖，概述了直到發行點爲止須要完成的全部軟件開發工做。不足之處？若是在旅途中發生任何變化，時間表，依賴關係以及常常須要從新制定預算的工做；該計劃實際上被打破了。

另外一方面，Scrum與朝向指望端點的短增量衝刺有關。詳細計劃被精簡的規範或「故事」以及按期的回顧所取代，這些回顧能夠衡量每一個衝刺的結果。這些回顧應回答如下問題：「咱們所作的工做是否使咱們更接近所需的故事了。」

這是建造橋樑和火箭飛船的區別。

火箭技術是相對較新的技術，建造一艘火箭飛船須要幾個增量步驟和迭代才能正確完成。致使SpaceX在船上發射火箭的工做就是一個很好的例子。

另外一方面，橋樑建設是一個很是容易理解的工程挑戰，已經解決了不少次。搭建橋樑的迭代次數少，時間和成本計劃高，這是常用Waterfall的地方。

OKR和Scrum如何比較？

OKR和Scrum的類似之處在於，這兩個框架都須要一個專門的人來執行，即「 Scrum Master」或「 OKR Ambassador」。

二者都有明肯定義的角色，他們的責任是確保團隊遵照框架。Scrum是一個高度規範的框架，具備特定的角色和儀式。Scrum的好處包括透明性，項目可見性和持續的溝通。團隊共同決定他們能夠在短短的兩週「衝刺」中完成哪些工做，這使Scrum成爲一個很是民主的過程。

OKR也有一套規則，儘管不如Scrum編寫。這些規則肯定目標能夠是什麼，關鍵結果是什麼，以及它們如何共同衡量目標的實現。像Scrum同樣，OKR也有時間表，可是，這些時間表（季度和年度）比兩週的衝刺要長得多。建立OKR涉及首先，公司領導層決定他們想要實現的目標，而後團隊建立本身的OKR，並使它們與公司目標保持一致。

OKRs-E 公式

如何將Scrum與OKR結合

只要每一個人都清楚每一個框架的範圍和參數，OKR和Scrum就能而且確實能夠成功地合做。咱們在Tita使用的OKR方法包括執行（Execute），團隊要努力實現其目標。衝刺很是適合於計劃，能夠在每一個季度內爲Group OKRs工做。

爲了使這兩個框架合適，在每一個季度開始時，重要的是，OKR大使和Scrum Master與開發團隊一塊兒肯定該季度須要實現的三個最重要的事項。因爲OKR處理更長的時間表和更普遍的目標，而Sprint處理的是更精細的工做組織，所以OKR應該放在首位。

爲了使OKR在此階段正常工做，必須強調須要衡量結果而不是輸出的關鍵結果。例如，若是您要解決的問題是錯誤的軟件，那麼衡量被壓破的錯誤的數量是很差的「關鍵結果」。修復錯誤能夠減小一個錯誤，可是，若是報告了更多的錯誤，那麼您實際上並無在減小軟件的錯誤，而是在計算要修復的數量。

更好的關鍵結果將是測量報告的錯誤或在一個季度內提出的支持通知。若是該指標趨於降低，您能夠肯定要解決要解決的問題。

有了「目標和關鍵結果」集，就能夠開始Sprint計劃業務。在此階段肯定Sprint的長度很重要。若是Sprint是每個月一次，則單個Sprint目標可能會直接對應於開發團隊的3個目標之一。對於2周的較短衝刺（更常見），「衝刺目標」成爲目標的「計劃執行」。

長話短說，心動不如行動

Scrum和OKR能夠在Tita這樣的軟件工具中共同發揮做用，而且能夠很好地工做，Sprint目標成爲OKR的執行部分（一般是用Tita的項目管理的看板模式）。可是，要從這兩個框架中看到真正的價值，相當重要的是，每一個參與者都應充分理解它們，並撥出時間來管理它們，並提名Scrum Master和OKR大使。

目標計劃執行部分-- 項目看板