本文轉自：Scrum中文網

原文鏈接：http://www.scrumcn.com/agile/scrum/21759.html

引言

Spotify通過文化和價值觀來進行管理，在本篇中，我們從如下八個方面來介紹Spotify的敏捷工程文化：

一、 如何管理小隊的自主性

二、 如何管理標準化

三、 如果做到以人為本

四、 如何管理部署上線

五、 如何管理創新

六、 如何管理失敗

七、 如何處理浪費

八、 如何管理文化

一、 如何管理小隊的自主性

Spotify的小隊，類似于一個高度自治的、迷你的“創業公司”。一方面，小隊要保持自主性，同時也要兼顧公司在產品上的整體一致性。

如何看待自主性和一致性

通常認為：一致性和自主性就像是天平的兩端，自主性高則一致性少。

Spotify認為：這是兩個不同的維度：

1. 低一致性、低自主性：

管理者下指令，團隊執行。

2. 高一致性、低自主性：

管理者告訴團隊要做什么，以及怎么做。

3. 高一致性、高自主性：

管理者聚焦要解決什么問題，由團隊自己去找出解決問題的方法。

4. 低一致性、高自主性：

團隊各行其事，管理者很無助，產品是個怪胎。

理想情況：具備一致性的自主，只有具備一致性才令團隊自主具備可能性，而一致性越高，管理層越能下放自主權。

Spotify的管理原則：

獨立自主，但不能局部優化
小隊可以自主，但不能追求局部優化。就像是一個大型樂隊，每個樂隊小隊都在獨立自主的演奏，但又必須彼此傾聽其他小隊的演奏，共同聚焦整首曲子的演出，這樣才能演奏出好的音樂。
目標——建立相互松耦合，但整體高度一致的小隊。

打造獨立自主、松耦合、整體高度一致的小隊

1. 為什么小隊的獨立自主如此重要？

這是一種激勵方式，受激勵的人們能夠開發出更好的產品。
獨立自主能夠讓小隊更快地做決策和行動，而不需要經過層層審批。
獨立自主，能夠盡量避免交接和等待。

2. 獨立自主：

小型（人數少于8）、跨職能、自組織的團隊。
小隊自行決定開發什么產品，如何開發，以及如何協作。
坐在一起，共同對研發的端到端事物負責，例如：設計、交付、部署、維護、運營等。

3. 整體高度一致：

小隊有長期的使命，例如：使Spotify成為探索音樂的最佳應用程序，或內部事物，例如執行A/B測試的基礎架構。
小隊要與產品的整體策略保持一致，與公司的整體優先級和其他小隊保持一致。Spotify的整體使命的重要性和優先級，高于小隊的任務。
小隊們合作開發產品的整體策略，以及季度重新探索短期目標。

二、 如何管理標準化

一方面，小隊的要保持技術靈活性，另一方面要兼顧公司的整體規范性。

自由勝過標準化

如果有人問：應該使用哪種編程工具，或是如何做計劃？答案是：這要看是哪個小隊。
有的會用Scrum，有的會用Kanban，有的會估算故事點并統計速率，有的則不會，實際情況因小隊情況而已。

隨著時間的積累，發展出了一些設計指引、代碼規范等來減少工程上的摩擦，但唯有非常時期才會使用。在權威與自由的天平上，傾向于自由而非權威。

通過異花授粉而非標準化，來平衡靈活性和一致性

異花授粉（Cross-pollination），而非標準化（Standardization）。
當越來越多的小隊都使用某種實踐方法時，例如使用Git進行版本控制，其他小隊也會跟進和開始使用，當小隊間都使用這種工具協作時，就成為事實上的標準。
通過采用這種非正式的方式，得以在一致性和靈活性間保持平衡。

解耦系統

1. 現狀&問題：

產品中包含100多個獨立開發和部署的系統。
在技術上，每個系統由某一個小隊負責；大部分小隊會同時負責好幾個系統。
系統間存在交互，而各小隊又分別專注于自己的特性。例如播放清單的管理、搜索或監控。
如何讓小隊在專注自己的特性和系統的同時，還能與公司整體以及其他小隊保持一致？

2. 實踐方法：

以清晰的接口和規范，力求實現需求之間以及系統之間的解耦。

內部開源機制

內部開源模式：誰都可以改代碼+同舟共濟的代碼評審文化。

例如，上圖中有兩個小隊：Squad1和Squad2

小隊1需要在B系統完成某項事情時，而小隊2對B系統的程序編寫比較在行。
通常小隊1會找小隊2協助處理。
如果小隊2沒有時間或者有更重要的任務，小隊1也不會等待。組織鼓勵小隊1自行去編寫系統B的代碼，然后再請小隊2評審修改。消除等待的同時，這樣有助于提升質量和傳播知識。

三、 如何做到以人為本

唯有以人為本，工作才能得以順利進行。

以人為本的文化

1. 堅實的“互相尊重”文化：經常聽到像是“我的隊友真棒”的評論。

2. 人們常常把事情歸功于其他人的杰出表現，而非自私的為自己爭功。

3. Spotify確實有很多天才，但卻很少有人狂妄自大。

4. “不干涉+同舟共濟”的文化：

你和你的隊友會被期望自己去找答案，沒人會告訴你該做什么。
但當你需要協助的時候，你會很快獲得許多援助。
大家一致認同的真理是：我們在同一條船上，而且必須幫助其他人成功。

以激勵為公司文化的重點

Spotify每年都會進行員工滿意度調查。

四、 如何管理部署上線

對自主性最重要的一點是部署上線的難度。

追求小而頻繁的發布：

1. 程序發布應該是例行的（Routine），而非戲劇性的（Drama）。

2. 拒絕惡性循環：發布困難-》發布得少-》發布規模大-》發布困難。

3. 追求良性循環：發布容易-》頻繁發布-》發布規模小-》發布容易。

投資令發布更加容易

不是建立流程、規范來管理發布，而是通過投資測試自動化和持續交付的基礎設施，例如：改變架構，讓發布解耦。

——使用Chromium嵌入式架構，每個客戶端就是一個偽裝的網頁瀏覽器。每個區塊就像是網站的一個框架，小隊可以直接發布他們的產品。

客戶APP小隊、基礎設施小隊和“自助服務”模式

利用發布火車和特性開關解決小隊間的同步問題

五、 如何管理失敗

包容失敗的文化

自下而上驅動，自上而下支持的持續改進文化。

沒有任何學習成果的失敗就真的只是失敗。
當出問題的時候，通常要進行事后檢視。不關注“這是誰的錯”，只關注“怎么發生的？學到了什么”，以及“我們如何改變”。
事后檢視是事故管理流程的一部分，任何事故單，問題解決了還不算完，僅當有所學習和收獲時才能關閉。不僅要改進產品，還要改進過程。
所有小隊，每隔幾周就要召開一次回顧會議，討論什么地方做得好，什么地方該改進

“改進清單”和“牛逼的定義”

實例：某小隊的改進看板

1. 改進看板的內容：

左上：現狀，小隊面臨質量問題。
左下：牛逼的定義，理想中不會有質量問題。
右上：真正的目標。如果我們靠近牛逼一步是什么樣子？
右下：三個讓我們達到目標的行動項，完成后會增加新的行動項。

2. 看板的內容，在回顧會議上跟進。

控制失敗造成的損失

1. 失敗必須是非致命的，否則我們無法存活到下次失敗。

通過架構解耦（Decoupled Architecture），控制爆炸范圍(Limited Blast Radius)。
當一個小隊犯錯時，只會影響到系統的少部分，而非搞垮整個系統。
由于無需交接切換，小隊通常能夠快速修復問題。

2. 采用A/B測試

新功能發布時，先發布給少量用戶體驗并進行密切觀察。僅當確定功能已經穩定后，才會逐步發布給全世界的用戶。

因此，失敗只會影響到系統的少量用戶，并且影響時間很短暫。這種有限的損害范圍，讓小隊勇于做更多的嘗試，并加速學習的步伐，而不是把時間浪費在風險的預測和控制上。

六、 如何管理創新

通過降低可預測性，來促進創新

100%可預測性=0%創新。
如果必須做出交付時間承諾，通常會推遲承諾——直到產品特性已經被證實或者接近完成時，才給出承諾。
通過降低預測性要求，使小隊能聚焦于價值交付，而不是成為某人的武斷計劃的奴隸。
有位PO說：我把我們的小隊看做一群聚集起來從事自己狂熱事業的志愿者。

鼓勵人們玩耍和嘗試，以促進創新

驚艷的新產品，始于人的靈感，唯有允許人們玩耍與嘗試，才能產生靈感。
鼓勵人們花10%的時間，執行“黑客日”或者“黑客周”。在這個時間里，人們可以根據自己的想法，盡情的去試驗或者開發任何自己想要的產品。
在Spotify，每年會舉行兩次黑客周。

頭號標語：Make cool things real！Build everything you want, with whoever you want, in whatever you want!
好幾百人整周都在閉門當黑客，并在周五時大型會展中展示成果。

開發出來的產品真的有用嗎？

這不重要。
關鍵是只要你嘗試的點子夠多，我們就能不斷接近目標。
而且往往，做黑客時學到的知識，比黑客行為本身更有意義。
而且，也挺好玩的。

黑客創意產品——“撥打一首歌”

只需要拿起電話，撥打一首歌的號碼，就能聽歌。

“黑客周”活動

鼓勵試驗的文化（Experiment-friendly Culture）

1. 例如：

該用工具A還是工具B？不知道，讓我們兩個都試用一下然后做個比較。
或我們是否真的需要Sprint計劃會議？不知道，我們跳過一次會議，看看后面是否會懷念它。
或我們該在歌手頁放5首還是10首排行榜歌曲？不知道，讓我們兩種情況都嘗試一下，然后評估效果。

2. 對于決策問題，以其爭論半天，不如試著討論下：

有什么假設？
我們學到了什么？
接下來我們嘗試什么？

3. 這讓我們的決定多基于客觀數據，而非來自某個人的想當然或者屈從于權威。

七、 如何處理浪費

排斥浪費的文化

雖然我們樂于嘗試，并且試著用不同的方式來做事情，但我們的文化非常排斥浪費。
人們會快速停止做任何不能帶來增值的事情。如果發現有效，就繼續；反之，則拋棄。

a) 通過試驗發現有用，需要繼續的一些實例：回顧會議、每日站會、google文檔、GIT、協會的研討活動。

b) 通過試驗發現沒用，需要拋棄的一些實例：例行報告、交接、獨立的測試團隊或測試階段，任務估算，無用的會議，企業官話。

大型項目

大型項目是一種最常見的浪費。（大型項目，通常指需要多個小隊一起合作好幾個月來完成的項目。）
大型項目，意味著巨大的風險。（Big Project = Big Risk）
要盡量減少大項目，盡可能把大項目拆成一系列的小工作。
有時候，大項目有其合理性，并且潛在收益遠大于風險，這種情況下，需要采取一些措施：

用物理看板或者電子看板，通過各種組合方式，可視化項目進度。
進行每日同步會議：所有小隊共同參與討論，解決相互依賴。
每一到兩周，進行一次演示：將產品各部分進行集成，召集干系人進行整體評估。
一個小而緊密的領導團隊，來持續地掌控整個大局。通常有：一位技術主管，一位產品主管，有時候還有一位設計主管。三者通力合作。

在混亂與官僚主義之間取得平衡

當我們成長時，面臨者陷入混亂的風險。當如果增加太多的結構和流程，又會陷入官僚化的風險。
關鍵問題：什么是最小可行官僚系統？可以讓我們以最少的結構和流程來避免陷入完全混亂。
排斥浪費的文化和敏捷思維能幫助我們在混亂和官僚主義之間保持平衡。

八、 如何管理文化

為何Spotify如此重視文化？

在企業成長的過程中，會面臨各種問題，以及采取各種解決方案，包括改造產品架構、流程和組織等。

但是企業面臨的情況也是一直在變化的，今天看似聰明的解決方案，可能會在明天造成一個難纏的新問題。而健康的文化能夠修復有問題的流程。

關注文化的角色（Culture-focused Role）

人力資源運作團隊
30+位敏捷教練

新員工訓練營（Boot Camp）

時間：為期一周
人員：由新招募的人員組成臨時的小隊
內容：

解決實際問題。
同時學習技術棧和工作過程。
以及學習如何作為一個團隊協同工作。
這種緊張而有趣的訓練，能讓你真正融入到文化中。

通過講故事來傳播文化

在博客、午餐以及各種場合分享自己的成功以及失敗學到的經驗教訓。

每個人都是組織文化的一份子。

組織文化，是組織中每個人的態度和行為的總和。
每個人都是組織文化的一份子。
每個人都在塑造組織的文化。

相關閱讀：

Spotify敏捷模式詳解三部曲第一篇：研發團隊

Spotify敏捷模式詳解三部曲第二篇：研發過程

參考資料：

本文部分內容及引用的圖片主要來自于Henrik Kniberg和Anders Ivarsson的文章《Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds》。

本文作者：

Jerry Li(李潔)， Eric Liao（廖靖斌）

總結

以上是生活随笔為你收集整理的Spotify敏捷模式详解三部曲第三篇：工程文化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。