我們收到很多問題詢問如何把OKR和其他框架結合起來使用，以便管理組織的人員、流程和活動。
軟體開發公司最喜歡用的框架之一就是Scrum，Scrum是一個誕生於20世紀90年代的軟體開發框架，我們公司內部一直在使用這一框架。
Scrum的優點以及為什麼它能優於瀑布流開發
相較於瀑布流開發的其他傳統框架，Scrum最大的優點是關注持續快速迭代以及對變化的適應性。
如果使用瀑布流開發，在專案一開始就要確定專案結果，並且要對此達成一致，通常還要有詳細的範圍和專案規範。
專案計劃是從這些規範中產生的，方法是通過以專案在未來的完成情況為出發點，向後推進，以線形的方式規劃出時間、預算和依賴性。
靠這種方法做出的成品是一份路線圖，概述出到軟體推出之日為止，需要完成的軟體開發工作。那麼不足之處是什麼呢？如果在軟體開發過程中出現了變動，時間線，依賴性，以及在大多數情況下連預算都需要完全重做，實際上就破壞了計劃。
與此不同，Scrum關注的是為了達到一個理想終點的持續快速迭代。取代詳細計劃的是精益規範或者是需求和回顧會議，這些會衡量每一次迭代成果。這些回顧應該圍繞一個問題： “我們所做的工作有沒有讓我們離目標需求更近？”
Scrum 的力量來自於它能夠管理工作，實現一個未知的、獨特的、或者前所未有的結果。 這一框架系統地、漸進式地問題解決過程。瀑布流開發與此不同，只有在其所涉及的過程和工作都是可預測的，並且此前已經有人嘗試過的情況下，瀑布流開發開發才能發揮最大功效。
這其中的差別猶如建一座橋和建一艘火箭搭載船的差別。
火箭技術相對較新，建造一艘火箭搭載船要有很多增量步驟，重複多次才能獲得成功。美國太空探索技術公司（SpaceX）為了能讓火箭在船上著陸所做的工作就是一個很好的例子。
反之，人們對建橋這一工程難題的理解十分透徹，也已經無數次解決過這一難題。建橋不需要重複很多次，對時間和成本規劃的要求高，而這是瀑布流開發經常應用的領域。
OKR和Scrum的異同
OKR和Scrum的相似之處在於 兩個框架都需要有一人專門管理框架的實施情況， 稱為“Scrum負責人”或“OKR負責人”。兩個職位職責明確，他們的責任是保證團隊依照框架行事。
Scrum是一個高度規範的框架，有明確的職責和儀式。Scrum的益處包括透明性、專案可見性以及頻繁溝通。團隊集體決定他們在為期2周的一個短期“sprint”內能夠完成什麼樣的工作，這也使得Scrum是一個很民主的過程。
OKR也有一套規則，雖然這套規則不如Scrum的規則條理清楚。這些規則決定什麼是目標O，什麼是關鍵結果KR，以及如何把二者結合起來衡量目標的實現。
和Scrum一樣，OKR有時間表，但是比為期兩週的sprint要長得多（季度和年度）。設定OKR首先需要做的是，公司領導決定需要實現何種目標，接著，團隊設定自己的OKR，需要確保團隊的OKR與公司的目標保持一致。
如何把Scrum和OKR結合起來
只要每個人都清楚兩個框架的範圍和引數，OKR和Scrum可以成功地結合在一起使用，效果也確實不錯。我們在確立公司OKR後，會進一步落實實現OKR的行動方案。Sprints和行動方案能在行動週期內有機結合，促進團隊OKRs的達成。
為了能讓這兩個框架合拍，重要的一點是在每個季度開始的時候，一位OKR負責人和一位Scrum負責人與他們的研發團隊坐在一起，決定需要在這個季度完成的最重要的事情（通常為3項）。
由於OKR週期更長，目標更巨集觀，而Sprint涉及的更具體的執行層面工作， 因此需要首先考慮OKR。
要讓OKR在這一階段就能有效開展， 相對於強調對結果實現的追求，更應關注對結果的衡量。比如，如果你想要解決的問題是有缺陷的軟體，那麼，統計消滅了多少個軟體缺陷就不是一個有效的關鍵結果。修復了一個缺陷，缺陷的數量就少了一個，但是如果有更多的軟體缺陷被報出來，你就沒有讓軟體變得更完善，你僅僅是在數自己修復了多少個缺陷。
一個更好的關鍵結果應該是統計出現了多少缺陷，或者統計一個季度內出現了多少客戶需求。如果這個評估指標的趨勢有所下降，那麼你就可以自信地認為你正在解決你最初想要解決的問題。
設定了OKR的目標和關鍵結果後，就可以開始規劃Sprint。在這一個階段，重要的是要決定Sprint的週期。如果一個Sprint為期一個月，一個單一的Sprint目標很可能會直接對應開發團隊3個OKR目標的其中一個。至於更常見的為期2周的較短Sprint，Sprint目標則變成OKR目標的行動方案。
我們更推薦第二種方法，因為這種方法在連線兩個框架的同時還保持了二者最初的目標，即Sprint管理生產和程式碼傳輸， 而OKR設定目標，衡量評估工作結果。
但是，這也意味著每一個OKR都需要有自己的Sprint時間線。如果你有一個大型的開發團隊在一個產品的不同領域開展工作，比如前期工作、後期工作和系統管理，這一方法就能發揮很好的效果。使用這種方法的話，每一個領域引導1個OKR和1條Sprint時間線，而整個小組內部有3個OKRs。
對於規模較小，沒有能力運轉3條Sprint時間線的開發團隊，我們也推薦這種方法，但是隻需要專注一個單一的OKR即可。
原文作者：Rob Davies
翻譯：周雁潔