【本文翻譯自felipecastro.com】

盡管看起來似乎有相同的理念，但許多公司都在努力適應(yīng)OKR和Agile。使用敏捷的團(tuán)隊(duì)經(jīng)常抵制采用OKR，因?yàn)镺KR對(duì)他們而言似乎是多余的。

這場(chǎng)斗爭(zhēng)的根源是對(duì)OKR和敏捷本身的誤解。如果使用正確，OKR和敏捷會(huì)是強(qiáng)大的組合。他們可以創(chuàng)建價(jià)值驅(qū)動(dòng)的團(tuán)隊(duì)，并改變組織的工作方式。

我在一些世界領(lǐng)先的出版物和會(huì)議中一直在談?wù)揙KR和敏捷。本文總結(jié)了我所學(xué)到的知識(shí)。

功能工廠（The Feature Factory）

敏捷的創(chuàng)建是為了交付軟件。它是用于管理軟件項(xiàng)目的瀑布式開發(fā)的替代方法，它專注于管理可交付成果（故事或功能）[deliverables (stories or features)]而不是價(jià)值（業(yè)務(wù)成果）[value (business outcomes)]。

實(shí)際上，敏捷中沒有一個(gè)單一的儀式（ceremony）可以跟蹤結(jié)果。

敏捷宣言本身具有誤導(dǎo)性，因?yàn)樗嬖V人們度量可交付成果。第七項(xiàng)原則指出：“可工作的軟件是進(jìn)度的主要衡量標(biāo)準(zhǔn)（Working software is the primary measure of progress）。

所有可工作的軟件都是有價(jià)值的假設(shè)顯然是錯(cuò)誤的。有些項(xiàng)目會(huì)帶來價(jià)值，而另一些則不會(huì)。用戶會(huì)使用一些功能，但其他功能可能無人問津。

大多數(shù)組織都陷入“功能工廠”模式。團(tuán)隊(duì)沒有專注于創(chuàng)造價(jià)值。正如約翰·卡特勒（John Cutler）所說，開發(fā)人員“ 只是坐在工廠里，制定功能，然后將其發(fā)送出去”。

Marty Cagan強(qiáng)調(diào)了功能工廠的可怕后果：

團(tuán)隊(duì)只是在那里充實(shí)細(xì)節(jié)、代碼和測(cè)試。他們對(duì)外部的環(huán)境幾乎一無所知，甚至不相信這些實(shí)際上是正確的解決方案。

[他們]很少考慮這些功能是否真正解決了潛在的業(yè)務(wù)問題。他們根據(jù)產(chǎn)出（output）而不是成果（outcome）來衡量進(jìn)度?！?/p>

聲明發(fā)布15年后，大多數(shù)公司仍將敏捷僅用于交付。擴(kuò)展框架通常無濟(jì)于事。他們選擇了阻力最小的方法，并專注于改善軟件開發(fā)。因此，很少有組織能夠?qū)崿F(xiàn)業(yè)務(wù)敏捷性（business agility）。

敏捷交付（Delivery Agile）

我喜歡將組織視為五層架構(gòu)。它們是文化（Culture），戰(zhàn)略（Strategy），戰(zhàn)術(shù)（Tactics），運(yùn)營（Operations）和目標(biāo)（Goals）。

組織架構(gòu)

目標(biāo)滲透到所有其他層面，因?yàn)樗鼈兎从沉斯镜倪\(yùn)作方式和行為方式。

傳統(tǒng)公司的組織架構(gòu)如下：

傳統(tǒng)架構(gòu)

在傳統(tǒng)架構(gòu)中，各層的情況是：

1.文化是自上而下、命令與控制式的。
2.戰(zhàn)略使用年度靜態(tài)計(jì)劃。
3.目標(biāo)遵循瀑布式方法。
4.戰(zhàn)術(shù)需要很大的賭注和較長的反饋周期。
5.運(yùn)營使用瀑布式的開發(fā)和項(xiàng)目管理。

當(dāng)公司采用敏捷時(shí)，通常會(huì)使用敏捷交付。它們僅替換架構(gòu)的最底層：

敏捷架構(gòu)

敏捷交付僅在運(yùn)營層使用精益和敏捷。當(dāng)團(tuán)隊(duì)進(jìn)行分散的實(shí)驗(yàn)時(shí)，敏捷取代了瀑布開發(fā)。瀑布開發(fā)不存在實(shí)驗(yàn)文化，盡管多少采用了一些A/B測(cè)試，但許多高風(fēng)險(xiǎn)的假設(shè)仍然未經(jīng)測(cè)試。

由于其他層在敏捷交付中保持不變，因此其收益較小。瀑布式的遺留問題與組織敏捷性直接沖突。

瀑布目標(biāo)（Waterfall Goals）

在設(shè)定目標(biāo)時(shí)，瀑布式思維仍然是常態(tài)。組織使用年度自上而下的過程來創(chuàng)建一組靜態(tài)目標(biāo)。這與敏捷直接沖突。

瀑布式目標(biāo)遵循靜態(tài)規(guī)劃模型。通常，這是從管理人員制定年度公司目標(biāo)的務(wù)虛會(huì)開始的。然后目標(biāo)在整個(gè)組織中級(jí)聯(lián)，從而制定了年度固定計(jì)劃。

您能想到比層疊瀑布（top-down waterfall）更自上而下的瀑布類比嗎？

靜態(tài)模型有幾個(gè)假設(shè)：

1.我們可以預(yù)先詳細(xì)定義計(jì)劃的所有步驟；
2.該計(jì)劃的絕大多數(shù)將是正確的；
3.市場(chǎng)狀況將基本保持不變；
4.變化將很小。我們將在今年年中進(jìn)行審核。然后，我們將創(chuàng)建更新的詳細(xì)靜態(tài)計(jì)劃。

瀑布式目標(biāo)是基于項(xiàng)目的（WATERFALL GOALS ARE PROJECT-BASED）

更糟的是，瀑布式目標(biāo)并不注重價(jià)值（value）。他們圍繞著管理層批準(zhǔn)的一系列項(xiàng)目（projects）展開工作。

弗雷德里克·泰勒（Frederick Taylor）高興地看到他的教義至今仍在使用。他寫道：“每個(gè)工人的工作都至少提前一天由管理層全面計(jì)劃，”。

在泰勒主義的敏捷方法中，團(tuán)隊(duì)存在的目的是為了交付項(xiàng)目。高管以真正的功能工廠的方式計(jì)劃工作。這種模式拖慢了公司的發(fā)展速度，讓他們更難適應(yīng)，并增加了風(fēng)險(xiǎn)和浪費(fèi)。

大多數(shù)(如果不是全部的話)擴(kuò)展框架都在敏捷交付中工作。它們是精心設(shè)計(jì)的方法，專注于使用敏捷來交付瀑布式計(jì)劃。

從靜態(tài)到動(dòng)態(tài)計(jì)劃（FROM STATIC TO DYNAMIC PLANNING）

靜態(tài)模型的追隨者就像克里姆林宮的中央計(jì)劃者，他們創(chuàng)建了自上而下的5年計(jì)劃，相信自己可以預(yù)測(cè)未來。

相反，動(dòng)態(tài)計(jì)劃包含變化。它在迭代模型中以較小的計(jì)劃周期工作。動(dòng)態(tài)計(jì)劃假設(shè)市場(chǎng)條件和計(jì)劃本身將發(fā)生變化。不僅如此，我們對(duì)問題的理解將隨著我們的學(xué)習(xí)而發(fā)展，我們的計(jì)劃必須反映這一點(diǎn)。

正如肯特·貝克（Kent Beck）所說：“如果你什么都沒學(xué)到，那就只能按計(jì)劃進(jìn)行了?！?/p>

您希望團(tuán)隊(duì)在短迭代中工作并檢驗(yàn)假設(shè)。那么，你怎么能使用克里姆林宮設(shè)計(jì)的瀑布式流程中定義的一組靜態(tài)目標(biāo)呢?

你不能。因此，盡管我們?cè)诮桓稌r(shí)使用敏捷，但在其他任何事情上我們都使用瀑布。這種情況需要改變。

全棧敏捷（Full-Stack Agile）

為了實(shí)現(xiàn)業(yè)務(wù)敏捷性（business agility），公司必須采用全棧敏捷（Full-Stack Agile）。他們必須替換傳統(tǒng)組織架構(gòu)的所有層：

全棧敏捷

在全棧敏捷中，各層變化為：

• 文化的基礎(chǔ)是創(chuàng)建與團(tuán)隊(duì)一致的自治。它不控制詳細(xì)的計(jì)劃，而是遵循使命的原則。領(lǐng)導(dǎo)者“指定最終狀態(tài)、目的和盡可能少的約束?！?/li>
• 戰(zhàn)略是數(shù)據(jù)驅(qū)動(dòng)的，迭代的，并專注于驗(yàn)證假設(shè)。
• 目標(biāo)使用OKR（目標(biāo)和關(guān)鍵結(jié)果）遵循敏捷模型。
• 戰(zhàn)術(shù)是在短反饋周期內(nèi)進(jìn)行安全失敗的實(shí)驗(yàn)。
• 運(yùn)營使用敏捷開發(fā)。

重構(gòu)組織債務(wù)（REFACTORING THE ORGANIZATIONAL DEBT）

技術(shù)債務(wù)是大多數(shù)工程師都能理解的問題。團(tuán)隊(duì)通過走捷徑獲得技術(shù)債務(wù)，這使得代碼更難修改，并且無法擴(kuò)展。技術(shù)債務(wù)將在以后支付，并附帶利息。

要解決技術(shù)債務(wù)，您必須重構(gòu)代碼。這在不添加新功能的情況下改進(jìn)了內(nèi)部結(jié)構(gòu)。

滲透到敏捷交付中的瀑布式遺留產(chǎn)生了組織債務(wù)。而且就像它的同胞一樣，它讓公司更難改變，而且還要支付利息。

要成為全棧敏捷，公司必須解決組織債務(wù)。他們必須重構(gòu)架構(gòu)的所有層。但這說起來容易做起來難，因?yàn)樵S多人都嘗試過，但都失敗了。最好的方法是什么？

從“思維模式”到“管道”（FROM “MINDSET” TO “PLUMBING”）

敏捷社區(qū)中的許多人都認(rèn)為，唯一的解決方案是專注于思維方式的轉(zhuǎn)變。似乎我們可以改變組織的思維方式，所有的問題都會(huì)消失。事實(shí)上，一些名人在一次會(huì)議上穿著一件T恤，上面寫著“敏捷就是思維模式（Agile is Mindset）”。

僅關(guān)注思維模式的改變可能是有害的，因?yàn)檫@是不可行的。戴夫·斯諾登（Dave Snowden）寫道：“思維模式似乎正在取代'價(jià)值觀'和'使命'，成為避免陳詞濫調(diào)的最新行動(dòng)”。

另一種選擇是專注于改變公司行為的實(shí)際行動(dòng)。

正如斯坦福大學(xué)的James March提醒我們的那樣：“領(lǐng)導(dǎo)力不僅包含優(yōu)雅的氣質(zhì)（poetry），還包括管道（plumbing）。” 盡管“優(yōu)雅的氣質(zhì)”很重要，但大多數(shù)組織卻忘記了管道：它們的系統(tǒng)和過程。更換水管通常很麻煩并且需要時(shí)間，但這是值得的。

有一種用于業(yè)務(wù)敏捷的工具可以更改“組織管道（organizational plumbing）”。該工具叫做OKR（目標(biāo)和關(guān)鍵結(jié)果），是Google和Spotify等公司使用的目標(biāo)框架。

與傳統(tǒng)的規(guī)劃方法的最大區(qū)別是什么？OKR 經(jīng)常被設(shè)置和評(píng)估——通常每季度一次。此外，OKR是雙向的，而不是將組織級(jí)聯(lián)下來。團(tuán)隊(duì)根據(jù)公司目標(biāo)創(chuàng)建自己的OKR，然后與經(jīng)理一起評(píng)估他們。

這種方法為團(tuán)隊(duì)提供了一個(gè)更吸引人的環(huán)境。他們覺得應(yīng)該要對(duì)自己給自己設(shè)定的目標(biāo)負(fù)責(zé)，并每周快速跟蹤一次。

如果使用正確，OKR可以使組織成為全棧敏捷。

建立價(jià)值驅(qū)動(dòng)的團(tuán)隊(duì)（CREATING VALUE-DRIVEN TEAMS）

成為全棧敏捷的關(guān)鍵是專注于價(jià)值。挑戰(zhàn)在于，該系統(tǒng)已經(jīng)被優(yōu)化過，能夠交付高管計(jì)劃的任務(wù)。不幸的是，敏捷還針對(duì)交付進(jìn)行了優(yōu)化，創(chuàng)建了功能工廠模型。

這種對(duì)交付的癡迷由來已久。它從使用工作軟件來衡量進(jìn)度開始，并一直持續(xù)到今天。畢竟，正如Jeff Sutherland（Scrum創(chuàng)始人）的書名所說，Scrum是“在一半時(shí)間內(nèi)完成兩倍工作的藝術(shù)”。

看板中缺少一列：“行得通嗎？”，如John Cutler的插圖所示：

敏捷被遺忘的列

“完成”只有在增加價(jià)值時(shí)才重要。

實(shí)際上，不能改進(jìn)指標(biāo)的功能可能會(huì)產(chǎn)生負(fù)回報(bào)。新代碼可能會(huì)有bug，需要維護(hù)，產(chǎn)品也會(huì)更加復(fù)雜。

盡管《宣言》具有誤導(dǎo)性，但其中一位作者寫道：

“ [擊敗]瀑布的關(guān)鍵是要認(rèn)識(shí)到敏捷專家重視成果（Outomes）勝于功能（Features）。功能列表（feature list）是一個(gè)有價(jià)值的工具，但這不是目的。真正重要的是整體結(jié)果（overall outcome），我認(rèn)為這是對(duì)客戶的價(jià)值?！?br> ——Martin Fowler（重構(gòu)一書作者）

你為什么要做這個(gè)？（WHY ARE YOU WORKING ON THAT?）

Henrik Kniberg關(guān)于推動(dòng)每個(gè)團(tuán)隊(duì)的因素有很好的幻燈片：

您在做什么，為什么？

第一個(gè)選項(xiàng)表示功能工廠。假設(shè)團(tuán)隊(duì)沒有能力決定要構(gòu)建什么。他們做某件事是因?yàn)橛腥烁嬖V他們這樣做。它遵循泰勒主義的計(jì)劃與行動(dòng)分離的原則。它既讓人失去動(dòng)力，又無法推動(dòng)創(chuàng)新。

第二種方法是另一種極端，在這種情況下，團(tuán)隊(duì)只為了“他們喜歡”而工作。

第三種選擇是價(jià)值驅(qū)動(dòng)團(tuán)隊(duì)。一個(gè)專注于交付價(jià)值并了解如何產(chǎn)生影響的團(tuán)隊(duì)，他們有一個(gè)明確的目標(biāo)，并且在工作與公司戰(zhàn)略之間有著清晰的視野。

正確使用OKR的方法（THE PROPER WAY TO USE OKR）

像其他工具一樣，OKR可能會(huì)被濫用，變成一個(gè)待辦事項(xiàng)列表。但是，如果你想要關(guān)注于價(jià)值，你的目標(biāo)必須反映這一點(diǎn)。你必須使用基于價(jià)值的關(guān)鍵結(jié)果：

價(jià)值就像開玩笑：你不需要告訴對(duì)方它是好是壞。

基于價(jià)值的OKR并非只是衡量結(jié)果。您必須了解什么對(duì)您的客戶和組織是有價(jià)值的。

以下示例顯示了兩種關(guān)鍵結(jié)果（Key Results）之間的區(qū)別：

關(guān)鍵結(jié)果示例

當(dāng)您將敏捷與基于活動(dòng)的關(guān)鍵結(jié)果（Activity-based Key Results）一起使用時(shí)，會(huì)產(chǎn)生摩擦。敏捷團(tuán)隊(duì)已經(jīng)有了路線圖，那為什么他們需要OKR？每次我遇到努力將OKR和敏捷聯(lián)系起來的團(tuán)隊(duì)時(shí)，他們都專注于活動(dòng)。

使用基于價(jià)值的OKR（Value-based OKRs）可以帶來變革。它可能是敏捷與精益之間缺少的環(huán)節(jié)?？梢詮浐?code>產(chǎn)品（product）與工程（engineering）之間的差距。

改變語言（CHANGING THE LANGUAGE）

甚至敏捷使用的術(shù)語也關(guān)注交付。我們需要放棄一些概念，比如“完成定義（definition of done）”、“燒盡圖（burn-down charts）”和“速率（velocity）”。相反，我們需要關(guān)注于價(jià)值。我們需要的不是驗(yàn)收標(biāo)準(zhǔn)（acceptance criteria），而是成功標(biāo)準(zhǔn)（success criteria）——OKR。

從意見到數(shù)據(jù)（From Opinions to Data）

驅(qū)動(dòng)獨(dú)立敏捷的不是數(shù)據(jù)。這是HiPPO：最高薪人士的意見（Highest Paid Person’s Opinion）?！禜ow Google Works》一書中很好地說明了這一概念：

HiPPO How Google Works

敏捷背后存在一個(gè)錯(cuò)誤的假設(shè)。該模型基于利益相關(guān)者告訴團(tuán)隊(duì)需要完成的工作，然后審查工作。

Ron Jeffries描述了與利益相關(guān)者（重點(diǎn)是我的）的假設(shè)對(duì)話：

“每周您都會(huì)告訴我們[……]對(duì)你來說什么是最重要的，我們會(huì)告訴你我們覺得可以完成什么?！币恢芎螅憔陀辛薣……]，如果你想[……]，你可以把它交付出去。”

利益相關(guān)者按照泰勒主義的模型來決定做什么以及是否可以交付。假定他們知道什么是有價(jià)值的，他們的意見是對(duì)實(shí)際價(jià)值的衡量。

但數(shù)據(jù)顯示并非如此。例如，Ron Kohavi發(fā)表的一篇論文分析了微軟一系列想法的結(jié)果。只有1/3的人在期望的指標(biāo)上產(chǎn)生了統(tǒng)計(jì)上顯著的積極變化。

敏捷不是收集數(shù)據(jù)并衡量什么是有效的，而是詢問HiPPO構(gòu)建什么。他們有66%或更多的誤差。

許多公司仍在使用“客戶的聲音（voice of the customer）”模型。在此模型中，有人代表最終客戶。在過去很難收集數(shù)據(jù)的情況下，這是有道理的。但現(xiàn)在，它只是瀑布的又一個(gè)殘留物。

用實(shí)驗(yàn)代替HIPPO（REPLACING HIPPOS WITH EXPERIMENTS）

事實(shí)上，團(tuán)隊(duì)并不需要有人來代表客戶。他們可以采訪客戶，衡量他們的行為。OKR可以通過允許團(tuán)隊(duì)以學(xué)習(xí)和迭代的實(shí)驗(yàn)來代替HIPPO。

如Barry O'Reilly所述，它使團(tuán)隊(duì)能夠采用假設(shè)驅(qū)動(dòng)開發(fā)（Hypothesis-Driven Development）：

1. 我們認(rèn)為 < 這項(xiàng)能力 >，
2. 將導(dǎo)致 < 這個(gè)結(jié)果 >，
3. 當(dāng) <我們看到一個(gè)可度量的信號(hào)> 時(shí)，我們將有信心繼續(xù)前進(jìn)。

在這個(gè)模型中，評(píng)審不再是關(guān)于顯示可交付成果的。團(tuán)隊(duì)使用評(píng)審來討論度量標(biāo)準(zhǔn)和主要假設(shè)，以改進(jìn)它們。

啟用自治（Enabling Autonomy）

命令與控制仍在這里。

指揮和控制的思想仍然滲透在敏捷交付中。利益相關(guān)者決定要構(gòu)建什么。結(jié)果，“因?yàn)镾am說……”團(tuán)隊(duì)就開始做某件事，“當(dāng)Sam覺得可以的時(shí)候”就會(huì)停止。

你需要整個(gè)團(tuán)隊(duì)的貢獻(xiàn)。因此，他們需要了解業(yè)務(wù)問題，并對(duì)構(gòu)建什么有發(fā)言權(quán)。正如Marty Cagan所寫，“如果你只是用你的工程師來編碼，你只能得到他們一半的價(jià)值?！?/p>

為了使團(tuán)隊(duì)能夠自治，您需要給他們自由來決定如何實(shí)現(xiàn)期望的結(jié)果。團(tuán)隊(duì)的宗旨必須改變:

正如Mary Poppendieck寫道：

也許敏捷開發(fā)實(shí)踐的最大缺點(diǎn)是團(tuán)隊(duì)決定做什么的方式。很長一段時(shí)間以來，回答這些問題都不被認(rèn)為是團(tuán)隊(duì)的責(zé)任。

團(tuán)隊(duì)不必執(zhí)行由利益相關(guān)者構(gòu)想的瀑布計(jì)劃。他們可以使用雙軌敏捷（dual track Agile）和設(shè)計(jì)沖刺（design sprints）發(fā)現(xiàn)有價(jià)值的產(chǎn)品。

OKR的其他材料

• 使用OKR（目標(biāo)和關(guān)鍵結(jié)果）制定敏捷的目標(biāo)
• 使用現(xiàn)代敏捷和OKR超越“功能工廠”的思維定勢(shì)