鳳

Socialtext 應用 Scrum 方法的三年（下）

(這是 Three Years of Scrum at Socialtext 這篇文章的中譯，接續上集的內容。)

---

改善立會流程

彼此支援的互助方式，意味著開發人員不需要等開會，就能即時解決自己工作中的阻礙。

這樣一來，當我們每次在立會上要列出自己遇到的阻礙時，實際上……根本沒有任何阻礙。

此外，儘早消除阻礙還有另一個好處：我們通常都能完成每天的工作承諾。因此，我昨天做了什麼以及上次立會時我說過要做的事情的實際內容是相同的，因此第二個狀態的更新也顯得多餘。

最後的結果是：原本每天要討論的三件事，最終被減少到一件。

突然之間，我們的開會時間大幅縮短，通常只需要 8-12 分鐘，有時候甚至更快。

為了加速集會進行，我們會在各自的微博上提前記錄內容，再由系統自動集中到共筆頁面上。在立會裡，我們會直接將頁面進行畫面共享。當大家都習慣這樣的工作方式後，大部份人的狀態彙報通常只有一句：就是各位看到的這樣，或沒什麼新內容，搞定。

精通 Scrum 的專家看到這裡，可能會認為我們不太對勁：整個團隊似乎根本沒有溝通。但我認為實際情況正好相反：團隊的溝通非常順暢，只不過溝通都是在立會之外進行的。我們每天的工作都列在看板系統上：這塊看板實際上就是一個自動產生的共筆頁面，其中列出我們目前流程中需要執行的每項工作，例如這樣：

（Socialtext 的看板內容節錄。此處的 WIP 是指開發中的工作。同一頁裡還包括準備中、品管中，以及等待核可等未顯示的部份。）

通過看板了解狀態，並隨時消除阻礙，這些做法使得立會程序變得沒那麼重要。它像是解決早期問題的古老機制，已經不再適用於團隊的現況。

事實上，情況正是如此。當年 Schwaber 和 Sutherland 兩人在 EasleCorp 公司創建 Scrum 方法時，他們需要解決的具體問題是這樣的：各項需求之間彼此衝突和影響的程度如此之高，以至於技術人員根本無法開展工作——他們甚至無法發佈任何一項產品。

因此，您可以將 Scrum 模型裡的衝刺周期理解為改變過程中的喘息時間，或者直接想成是請給我們一個月時間做出實際工作，然後再來修改計劃。

最近一年多來，這樣的問題已經再也沒有在 Socialtext 出現過。於是我們繼續改善工作流程。

進一步改善流程

從 2007 年起，我們嚴格執行為期兩周的衝刺周期。這個模式運作了兩年多，直到 2010 年初為止。在這段時間裡，我們共進行了 52 次為期兩周的衝刺，其中 48 次準時發佈為新版的產品。（如果您想知道細節的話，有兩次失敗的衝刺是因為聖誕節和新年的延誤，一次是由於品質問題導致延期發佈，還有兩次是因為功能未臻完善，不適合發佈。）

這兩年間，我們也遇到了各種挑戰——有五六次升級造成運作上的瑕疵，需要開發人員提供支持。但產品的整體素質依然很高，同時幾乎沒有顧客抱怨功能上的問題。

在將我們的工作拆分為小塊的過程中，我們自己的技能也得以提高，同時對於功能可以正式完成的時間估計也更加精確。結果我們發現，如果將工作拆分為幾乎相同規模的小塊，通常根本不需要估算工作量，就能測量出預計的完成時間。

一旦所有工作項目都高度一致，團隊的流程就可以從只要以高品質成功完成，我們可以每兩周發佈一次，變成只要這塊工作完成，我們就可以發佈——與此同時，管理層對於專案準時完工依然可以保持充足的信心。

如此一來，我們逐漸從傳統的 Scrum 模型轉變成塊狀工作法，也就是所謂的看板流程。

在這段時間裡，我們也對每天舉行的 Scrum 集會進行改進，首先在周三添加了工程話題環節，之後則將集會改為每天進行，但並不要求必須全員參加。（工程話題包括傳統員工會議裡常見的活動：宣布人員招募訊息、公司策略討論、層出不窮的員工意見建議、測試人員發現的潛在問題等。）

幸虧有了看板，會議的焦點不再是我目前正在做什麼，因為大家都可以一目了然地看到每個人正在做什麼。現在我們討論的是接下來需要做什麼，何時以及如何調整優先順序，以滿足每天的需求。如此一來，我們不再需要討論如何完成目標和任務，以及我們被什麼卡住，而是轉為討論團隊正在面臨哪些挑戰，以及我們可以採取的措施。

雖然沒有任何一種流程是完美的，但我必須說，我喜歡這種方式的發展方向。

請不要誤會本文的意圖。我並不是說傳統的每日 Scrum 方法不好，我也並不是要推廣說我們的方法更好。準確來說，我只是想提供某種類型的最佳實踐紀錄。

筆者認為，要形成良好的流程，需要不斷地反省、調整，再做出改變。成長過程中可能會承受痛苦，但決不要放棄追求改善：沒有最好，只有更好。您肯定也明白這一點。

變得更好，並不意味著原來的方法就是錯誤的。 Scrum 方法並非一成不變，而是一種不斷持續改進的流程。就像煮一碗湯，您可以品嘗它、改進它，讓它每次的味道都變得更好。

一旦走上這條道路，您就不僅是在開發軟體，更是在創造文化。

創造文化的過程或許艱難，也許會充滿挑戰與辛酸。

不過，最終還是值得的。

Socialtext 應用 Scrum 方法的三年（上）

Scrum 方法乍看簡單，但長期採用它會產生怎樣的影響呢？Matt Heusser 花了一些時間反思，並寫下三年來每天在 Scrum 團隊裡工作，所經歷的實際情況。

(這是 Three Years of Scrum at Socialtext 這篇文章的中譯。)

---

這年頭，從樓上扔下一塊磚，都能砸到幾個向您推薦如何使用 Scrum 方法過渡到敏捷開發的專家們。這項工作非常重要，我也很高興看到有人這樣做，但本文的重點不在這裡。

相反的，我想講一講我們公司 Socialtext 採用 Scrum 方法的真實故事。

我在 2007 年秋天加入 Socialtext 時，我們才剛開始使用敏捷流程。在接下來的三年多裡，我們不斷針對開發流程進行改進。

本文的重點，並不在介紹敏捷開發的具體轉換過程，而是介紹 Scrum 方法，特別是每天的立會，以及多年來的改善過程。

關於 Socialtext

Socialtext 的總部位於矽谷的核心地帶，主要負責營銷方面的運作。

雖然產品管理、工程總監，以及少數開發人員在總部上班，但絕大部分的技術人員，都是在遍布全球的分部，或是在自己家裡進行工作。

我們開發的產品，是給企業用的社會軟體。應用這個平台，可以在任何能上網的地方工作。這種靈活的工作方式讓團隊獲益匪淺：我們可以不受地理位置的限制，招募到最能勝任工作的人。

如果您由於地理位置或時區差異等原因，不確定 Scrum 方法是否適用，請別擔心；我們以前也有過這些疑慮，但後來都找到了合適的解決之道。

促進溝通協作

許多 Scrum 團隊認為開會是高成本、又容易浪費時間的事，因此嚴格限制團隊的溝通時間。我們嘗試了一種不同的策略：盡量降低溝通成本。

為了讓溝通更方便，我們團隊採用了 Astertisk 這項開源工具作為網路音訊服務，並提供會議室功能。美西時間的早上十點到下午兩點是我們的共同工作時段，也就是可供開會溝通的時間。

一開始，我們採用定期兩周的開發周期，並且每周三次在下午一點舉行立會。

在 Scrum 模式裡，每個人在立會裡輪流報告三部分的訊息：我昨天做了些什麼，我今天打算做什麼，以及目前遇到的阻礙。

阻礙會大幅降低生產力，因為每位成員每天通常只專注於單一項目，所以如果項目卡住了，會讓開發人員變成非常昂貴的花瓶。

不過，即使是被卡住一天，也令人相當頭疼。要等一整天，在下次會議上再告訴別人，這個方法並不怎麼高明。因此，我們決定使用微博和聊天室作為彼此求助的管道。

此時團隊面臨一個決策：如果我們允許遇到阻礙的團隊成員打擾其他同事，那麼可能直接對他人的工作產生影響。好比說在聊天室裡提到某人的名字時，會讓他的電腦發出提示音，打斷他目前正在進行的工作。

最後我們決定允許這種打擾，因為被卡住會造成更大的浪費。

同時，我們也運用各種協作工具，例如用 GNU Screen 共享畫面、用 VNC 進行圖形界面測試，來進行結對開發。在 2011 年初，我們大約有 80% 的開發工作是用結對方式合作進行的。

---

(請繼續閱讀下集。)