[Scrum對話1]橄欖球和軟體開發有什麼關係？

真正的大師，給我們講述一個高深的理論的時候，往往讓你感覺不到他是在給你講一個理論，更像是在講故事，深入淺出。
大學的時候，曾經遇到一位講《政治經濟學》的教授，當時大家聽他的課，著迷到一定要佔座，這樣好坐到前面幾排。
工作後，讀了《期限》，再次產生這種共鳴。幾年前，讀了《TOC》系列後，就再沒發現這樣的大師。

今天，偶然遇到了這個Scrum對話系列的網文，該文作者通過對話的方式介紹了在微軟軟體開發中一種流行的專案管理方式。萬幸！終於又讓我碰到了一位大師！

---敏捷精靈

馬特裡：爭球？你是說要我們的開發團隊成員拿只橄欖球在走廊上相互衝撞嗎？

美芬；"爭球（scrum）" 是一種符合敏捷開發模式的敏捷的專案管理方式。她的基本流程就是先建立一個產品"訂單"(backlog)，做一個“衝刺”(sprint)計劃，執行它，每天開會討論它，定期示範工作成果，對上一階段工作做反省，接著再重複以上流程。

馬特裡一直以來在思考如何將敏捷開發原則應用到整個專案計劃中去。

馬特裡：我們上次談了敏捷開發，這次我試著想如何將她運用到管理一個項目中去。我們曾經聊過用測試驅動開發方式(test-driven development)來作為開發模式，但是整個項目的計劃該怎麼辦？有什麼針對專案計劃的敏捷方式嗎？

美芬：是的，實際上，有一個非常著名的敏捷專案管理方式，她的名字就叫“爭球（scrum）”

馬特裡：“爭球（scrum）”這不就成了一個橄欖球隊了嗎？橄欖球和軟體開發有什麼關係阿？

美芬：恩，沒有護墊，很多人會受傷。

馬特裡：哈，美芬也有幽默感了。我一直以為你唯一好玩的地方就是你的髮型了。

美芬：我的髮型怎麼啦？！沒關係。不管怎樣，Scrum是一種敏捷的專案管理方式，她遵循我們上次談到的敏捷原則。簡而言之，短時間的迭代，不斷的改善和反饋，並且相互合作。她是一種簡單，輕量級的流程，能帶來很多好處。

馬特裡：那大家都要帶只橄欖球在走廊上跑來跑去嗎？

美芬：不是必需的哦，但是你要是感覺這樣做能提高工作效率的話，那就這麼做好了。慢著，我想了想還是不要做的好。或許這樣做不利於大家的健康。我有很多Scrum的經驗，感覺用它來管理各種類型的項目都超好。

馬特裡：這種敏捷開發確實聽上去挺酷的，有點好處。好吧，那麼我會問，我很好奇我們是怎麼使用它的。什麼是“Scrum”。

美芬：Scrum其實就是用敏捷的方式來管理項目。她不是關於如何開發程式。首先，我們來看看Scrum是如何符合我們先前提到的敏捷開發原則的：

• 保持簡單：Scrum本身就是很簡單輕量級的流程，她能使我們的開發流程簡單化。
• 接受變化：Scrum鼓勵將工作細分成小塊。我們關注的是一小段一小段時間，但是在這些時間段的中間我們可以重新安排我們工作的優先順序。
• 不斷迭代：我們需要在小於30天的一次次迭代中構建應用程式。
• 不斷的反饋和改善：在每一次迭代的末尾，我們總是回顧我們以前是怎麼做的，並且思考我們下次可以做哪些不同的事來改善流程。
• 協作：Scrum強烈鼓勵團隊成員的協作和溝通。如果沒有這些，Scrum就一點用都沒有。
• 減少浪費：Scrum協助我們識別做那些只對客戶或者團隊有價值的事情。

馬特裡：好，我已經記住了這些原則。你還是沒有談得很詳細。我應該怎麼實施Scrum?

美芬：Scrum可以分為好幾個關鍵步驟。在此之前，我需要講一下幾個關鍵的定義。

• 產品"訂單" (product backlog)：你 可以把產品訂單想象成為你想構建產品所需做的所有事情一個高層次的，按優先順序排列的列表。列表中的內容可以是類似在極限編程中使用的使用者故事，或者就是一 行行簡單的功能說明。這裡面重要的部分是工作的優先順序。當你從這張列表中抽出一項項的工作任務時，你總是挑到的是最重要的任務。
• "衝刺"（sprint）：一個sprint就是一小段迭代的單元時間，最長是30天。每一個sprint都有一個目標和他對應。
• "衝刺"訂單（sprint backlog)：就是一張sprint的工作工作清單。一個"衝刺"訂單開始於產品訂單的一些任務以及在此之上細分的一些更具體的任務，每一個任務都應該有一個明確的“完成”的定義。
• 產品負責人：這個人是負責維護產品訂單和定義功能優先順序的。產品負責人通常在一個sprint實施過程中處於配角的地位。

馬特裡：你現在講的，對我來說，太技術了。這麼多的新名詞有什麼用？為什麼不來點簡單的像“功能列表”之類的詞？這樣不就更加符合敏捷的原則嗎？

美芬: 恩。。不知道該說什麼。我猜“產品”強調的是列表的長期性，“訂單”就是我們還沒有得到的東西。有道理吧。有了"sprint"，我們就可以跑一個馬拉松，但是在休息點和休息點之間，可以來幾次衝刺（就是迭代）。

馬特裡：好吧，好吧。我會習慣的。那流程是怎樣的呢？

美芬：非常簡單。就是這樣的。

1.構建一個產品的訂單（product backlog)。

2.計劃一個短期衝刺。

3.執行它，每天開會。

4.示範完成的工作。

5.做反省工作。

6.休息一下，然後重複。

馬特裡：就是這樣嗎？聽上去好簡單。顯然我需要這些步驟的更細節的一些東西。

美芬：你要我做什麼我就做什麼。

馬特裡：那給我一個漢堡吧。

美芬：不是你要我做的一切我都會做的！讓我們回到Scrum。我先給你很快的介紹一下這個流程中的每一步。然後在以後的交流中，我們可以詳細討論一下每一步的一些最佳做法。覺得怎麼樣？

馬特裡：聽起來比灌腸好點。繼續吧。

美芬：當你構建產品訂單時，你的團隊和你的產品負責人決定哪些功能是對客戶重要的，同時要建立一個按優先順序排列的所有功能的列表。最重要的功能出現在列表的最前面。

馬特裡：這需要一些遠見性的思考，這樣不就和敏捷的原則相悖嗎？

美芬：這時候的計劃是非常非常高層次的。他只是我們對戶從今天開始想要的那些功能的粗略的認識。明天認識就有可能變化。下一步就是要計劃“衝刺”。我們從產品訂單中抽出優先順序最高的項目，然後計劃將這些項目完成。那麼我該抽多少呢？你認為在這次迭代中你可以做多少你就抽多少。我們接著將產品訂單細分成衝刺訂單的一些具體任務並且開始執行它們。

馬特裡：酷。聽上去挺簡單的。但是我怎麼知道我下一步要做什嗎？

美芬：每個人都會在計劃階段被委派一項任務，所以他們都應該清楚自己該做什麼。在這個之後，當你完成了一項任務，你就可以去抽下一個還沒有被委派，且是最高優先順序的任務。我們有了這樣一個計劃後，我們就執行它，每天開會。我們會過一遍sprint的任務單，每天我們都會估計在某一任務上還要做多長時間。我們應該客觀實際的估計每項任務到底需要多長時間完成，如果他們比計劃的花的時間長，我們就從最低優先順序的任務開始取消任務。我們每天都會開一次碰頭會。

馬特裡：好吧。現在你是真瘋了。你每天都想開一次碰頭會。一周開一次已經夠痛苦的。I think you have been into the glue again.

美芬：我承認。聽上去很瘋狂。但會議很短，對5個人的小組來說只要花10來分鐘。如果你喜歡的話，我會談怎麼讓會議盡量短。在sprint完成之後，我們會展示一下完成的工作。這時候的短會會讓每個成員慶祝自己完成的工作，並且讓負責人知道完成的工作。

馬特裡：我猜想客戶，或則客戶的代表如產品負責人會出現在那裡，對吧？他們會對完成的工作很好奇。

美芬：當然啊。每個和項目有重要關係的人，包括客戶，都應該參加到示範過程中。一個sprint是以反省作為結束的。對於小組而言，這是一個來審視我們什麼做的好（應該繼續做），和決定下一次應該做些什麼不同來改善的好機會。

馬特裡：哈，不斷的提高。真是一個很直接的流程。我喜歡。

美芬：在這一個sprint做完之後，你需要重新設定一次訂單，然後開始留一段計劃的時間，然後就是從新再來，為客戶創造更多價值。

馬特裡：好吧。讓我回去和我的小組成員試試，做一個兩周的sprint。或許你和我可以過幾周來做一次反省，到時候你可以給我一些建議。

美芬：哇，看太陽從西邊出來了。你真的需要我的協助嗎？！？

馬特裡：。。。。。。

美芬觀點：正如步驟中第六點所言，在“衝刺”和“衝刺”之間，留幾天緩衝時間很重要。團隊需要一段時間做一下調整，趕一些非sprint計劃中的事情。這段時間是一個很好的用來解決一些技術或者工具問題的機會。你會發現你慢一下後，會變得更有效率。這就是為什麼叫“sprint”的一個理由，你不可能無休止的衝刺。