原文翻譯：Use of Kanban in the Operations Team at Spotify
InfoQ 與 Spotify 的運維工程師 Mattias Jansson 進行了交談。Spotify 是一款針對桌機和手機的音樂串流服務，提供幾乎沒有延遲的廣泛音樂收藏。Spotify 公司裡的運維團隊使用 Kanban ，而 Mattias Jansson 將 Kanban 引入了運維團隊。Kanban 已經多次出現在 InfoQ 上，儘管大部分都是由軟體工程師的角度來看。Jansson 與 InfoQ 詳細談了 Spotify 運維團隊在實施基於 Kanban 方法來處理其工作任務時獲得的經驗。
Q: 一開始採用 Kanban 方法時，遇到了哪些問題？
我們在 Spotify 的運維團隊由七個成員組成，我們處理一系列不同類型的任務。我相信這在運維團隊中很常見。這一時刻，你可能正在設計一個將花費大量資金的網站。而下一刻，你正在為開發人員修改防火牆規則。
當我們開始試用看板時，這給我們帶來了一個問題 — — 我們有從數個月到 15 分鐘可以完成的故事卡（story card），至少我們很難估算出這些故事的大小，譬如說我們要更新伺服器上的 library，這會不會影響看起來沒有相關的服務呢？考慮到有些故事太小，寫故事要比解決問題本身花費更長的時間，如果寫這個故事本身除了標題以外還要撰寫更多的內容，那將會是一個非常痛苦的過程。
但是我要超越自己。
在開始測試 Kanban 很久以前，我們注意到，儘管我們確實擅長於所做的工作，但我們無法提前計劃太多 — — 我們是被動的，不是主動的。其他部門的一堆「緊急」的工作總是妨礙我們的內部項目，這些中斷的原因導致我們常常在人員和系統中進行 context-switch。我們意識到公司的成長速度超出了我們的預期。
聽起來很有趣，我們團隊似乎主要問題是可伸縮性（scalability） — — 實際上是我們的團隊和我們的工作方法無法適應公司的成長和需求。
Q: 所以你們怎麼處理這個問題呢？
我們決定在辦公室以外的地方開會，然後坐下來討論目前的工作方式。 這樣可以更清楚的了解我們目前的工作方式和我們預期的工作方式。這是我們問自己的一些問題：
- 我們實際上從事哪種工作？
- 各種工作花了多少時間？
- 是否有可能以有意義的方式將我們的工作歸類到各個領域？
- 工作從哪裡來？我們會發起（initiate）他們嗎？其他？如果是這樣，是誰呢？
- 我們如何彼此分享知識？
- 我們如何確保運維開發獲得所需要的時間？
- 是否有可能減少我們所做的 context switch 量？
- 和更多…
在我們的會議（計劃的和臨時的）之後，我們得出的結論是，可以引入守門員（goalie）來捕捉所有臨時的請求並將其分類為適當的東西，從而可以做更多的事情 — — 小任務立即完成，大任務將被寫成一張正確的卡片。擁有這個守門員的一些優點是：
- 對其他部門更高和更快速的服務水平
- 確保知識在我們團隊中的傳播
- 最小化我們其他人的 context switch
我們決定使它盡可能簡單，至少從一開始就如此。像是：
- 我們有三個垂直的通道：todo、doing 和 done。
- 除上述內容外，我們還有兩個水平通道：標準類型（standard type）和不明確故事（intangible story）。（我們的大部分主動性工作都屬於後者。）所以為此創建單獨的水平通道，我們可以確保這類型的工作確實完成。
- 我們只使用三種尺寸（又稱 T-shirt sizes）：Small，Medium 和 Large。 Small 工作是可能需要一天完成的任務。 Medium 工作是需要半個星期才能完成的工作。 Large 工作是可能需要一周左右才能完成的工作。我們跳過了估算（estimation），因為它就只是浪費資源而已。
- 我們在 todo 通道上設置了較低的 WIP，這個垂直通道被拆分為 standard type 和 intangible type 的水平通道。我們每週一次（或如果空著）將新故事引入 todo通道，以確保內部，不明確（intangible）的任務實際完成。
- 我們將 Doing WIP 設置為等於團隊人數減去一名（守門員）。我們正在考慮將其降低得更多，以鼓勵大家合作分擔故事（share stories），但前提是我們對 Kanban 感到更自在。
那更大的任務呢？好吧，我們決定將耗時一周以上的工作稱為「專案（project）」。根據定義，它們很大，因此我們在 Wiki 頁面上對其進行詳細說明，並將它們做切分，切成 Small、Medium 和 Large 的故事。 然後，他們進入待辦事項（backlog），通常會將這些故事放進不明確（intangible）通道。
後來，我們意識到我們需要支持緊急的問題，因此我們在待辦事項中增加了第三個水平通道。 由於不鼓勵使用緊急通道，因此為此通道 WIP 設置為1。
Q: 從軟體開發為核心的 Kanban 到以維運為中心的 Kanban，哪些地方需要調整呢？
數量不多，因為 Kanban 是一個非常簡單的系統。但是，據我所知，無論類型，每個組織都需要適應 Kanban，而且我們的適應方式可能與傳統的產品開發團隊有所不同。
在運作良好的開發團隊中，您通常會有一個故事源（story source） — — 也許是產品開發部門，由該部門開發負責人或各個開發人員共同定義每個故事。這樣做的預期結果是，故事在某種程度上是同構的（isomorphic） — — 它們具有可比較的大小，故事本身都滿足一些共同的標準，等等。
一個典型的運維團隊有許多任務來源 — — 來自個別的開發人員，產品開發人員，其他部門以及內部產生的故事。這是一個問題，因為這些外部任務一直中斷著我們內部的長期項目。這種情況在我們團隊裡的資深工程師裡更是常見。
更糟的是，我們希望盡快消除這些中斷，因此我們經常忘記記錄這些更改或將其告知我們的同事。
如果不處理這些小型外部任務下，導入 Kanban 並不能解決這個問題，因此必須進行調整。
正如我前面提到的，我們的適應是每周放一個人擔任該隊的守門員。有了守門員，我們終於可以正確使用 Kanban 了，因為日常工作中大部分細微的外部干擾都已經消除。
我認為，開發團隊和運維團隊之間的一個區別是，運維團隊產生了許多內部生成的任務（task）和專案（project）。我們的問題是，我們發現往往外部的任務優先於這些內部的任務。這可能是由於人性的關係（幫助他人至上）或者是外部任務通常比較具體。
就像我之前提到的那樣，我們根據 David Anderson 的建議，通過導入不明確（intangible）類型的故事來適應 Kanban。通過在 todo 通道上下兩個部分之間平均分配 WIP 為 8，這讓我們可以確保 50% 的工作量會落在不確定（intangible）通道。到目前為止，這對我們來說效果很好。
