賈儒（高級開發工程師）
移動互聯網當道的今天，變化已經是大家習以爲常的事情了。也許昨天還在街邊苦等久久不來的出租車，今天已經可以在手機上點點預約車輛準時到達門口。優秀的產品帶來了生活習慣、甚至生活方式的變化，這是從前無法想象的。在這背後則是互聯網產品服務的變化，在這個大潮中，“進化”的週期變得越來越短，大家也許還記得當年各大殺毒軟件廠商，每年纔會發佈一個新的功能版本，而如今幾乎每一天大家的手機上都會收到各種各樣的軟件更新。而在這種快速更新的軟件背後，需要一種能夠很好適應並響應變化的團隊組織方式——已經爲大家所熟知的敏捷開發方法Scrum。
Scrum是一個基於經驗、實踐的項目組織框架，由預定義的角色參與，按照既定的基本過程來管理項目的進行。既然是以經驗和實踐爲指導的框架，那麼單純形式化的介紹很難讓人理解Scrum中各種規則的來由和好處，我將在本文中介紹Scrum的基本特性，也結合自己5年來的Scrum實踐，提供一些經驗供大家參考，也推薦大家，不論是團隊成員、Scrum Master還是Project Owner，在Scrum的實施過程中不斷回頭看一看Scrum的各個規則，並且多和其他人交流，這樣可以更好地理解和實施Scrum。
雖然Scrum定義了角色，也給出了基本的組織流程，但是Scrum並不是一套方法論，它並不提供具體的解決問題的方法，更不會直接告訴我們怎樣能夠更好，更快地開發出符合需求的軟件系統。Scrum核心的內涵是：檢驗（inspection）和適應（adaptation），主張在週期性地迭代和交付中，不斷提升團隊，不斷改進產品。
Scrum中的三個角色
Scrum中定義了三個角色，分別是PO（Project Owner），SM（Scrum Master）和TEAM。
Project Owner（WHAT）
PO，即產品負責人，在團隊中最主要的職能是“What”，他將從產品的視角出發，定義產品特性及其優先級，決定發佈的時間與內容，對產品收益負責（ROI），並參與評審開發的結果。
TEAM（HOW）
TEAM，即團隊，在這裏專指開發團隊，通常每個團隊由5-9人組成。開發團隊的任務就是在每個迭代週期中將計劃好的產品特性實現出來。Scrum的團隊是自組織的，同時也是平等的，沒有頭銜區分的。在每一個迭代週期正常進行的過程中，團隊應當交付的產品特性是鎖定不改變的，在這個過程中，有團隊自行決定怎樣去達到預定的目標，因此，團隊在Scrum中意味着“How”。
Scrum Master（SUPPORT）
SM，即Scrum教練，負責整個Scrum過程的實踐，並在過程中確保每一位成員在遊戲規則內能夠無障礙地活動，專注在團隊開發中。對於Scrum Master，不論從其名稱“Master”一詞，還是在衆多實踐中看到的其與團隊之間的關係，都很容易把Scrum Master理解成爲開發團隊的管理者，其實不然，這個Master更像一個教練，重在指導和支持團隊，因此，Scrum Master更接近於一個輔導者的定位，他應該幫助團隊更好地理解Scrum的核心價值觀，組織、協調好項目進行過程中的各種會議，爲團隊清除障礙，替團隊抵禦外部的干擾因素等。Scrum Master並不是傳統意義上那種管理層，而是一個支持者，如同潤滑劑一般讓整個團隊更高效，順利地運作，以一言蔽之，那就是“Support”。
Scrum所包含的以上三種角色中，並沒有“領導”，這也是Scrum的核心價值所決定的。領導不屬於Scrum團隊，但是實際情況下必然會在團隊之外有領導，有投資方，這些都是一定程度上不平等的關係，也會在Scrum的執行過程中對團隊產生各種影響，這些將在之後的Scrum實踐中介紹。
Scrum的基本流程
Scrum是一個不斷迭代的過程，整個軟件的開發過程由連續的迭代週期組成，每一個迭代週期叫做一個Sprint，時常建議爲1-4周。Sprint的長度可以根據團隊的需要來調整，但是僅僅在必要的時候才這樣做，在長期的軟件開發過程中，應該儘量保持Sprint的長度穩定不變，這樣才能保證整個團隊從計劃、執行到評估等各方面的工作保持一個固定的節奏，如同在長跑中運動員會將自己每一步的節奏保持在一個相對衡定的水平。相對穩定的週期，一方面可以讓團隊的工作狀態維持在比較穩定的狀態；另一方面，按照固定週期迭代一段時間後，可以讓團隊對自己每個週期內的產出能力有比較準確地把握，並且時間越長，瞭解就越準確，這樣就能夠對產品未來的計劃做出指導。下圖是一個典型的Sprint中的主要流程。
Scrum中兩個產品功能列表
Product Backlog (PBL)
PBL是帶有優先級的產品特性列表，所有已經確認計劃實現到產品中的特性都會記錄在這個列表中。PBL是對產品的總體計劃，由PO來維護，其他的所有人都可以對PBL提出建議，但是隻有PO一個人能夠最終決定PBL的修改。PBL是PO所謂產品視野的最好體現，維護一個合適的PBL是PO在整個開發過程中調整產品目標的主要途徑。
Sprint Backlog (SBL)
SBL是每個Sprint中TEAM所承諾實現的所有產品特性的列表，這個列表的基礎內容從PBL頂端（優先級高的一端）取出，一旦SBL制定完成，在整個Sprint過程中將保持鎖定不改變，實現SBL中的所有特性是TEAM在每個Sprint中唯一的目標。
根據TEAM每個Sprint所能完成的工作量估計，從PBL中取出適量的任務之後，還需要經過TEAM全體討論來細分任務，通常每個SBL中每個任務的時間應該保持在1人天以內可完成，因爲我們要在每天的Daily Scrum會議上回答經典的三個問題，而這些問題都是面向1天時間的，所以如果任務的時間超過這個限制，那麼我們對風險的控制和項目進度的瞭解，就會受到這個長時間任務的影響。
如果從一個比較粗的時間粒度來看待Scrum的過程就是：每個Sprint開始的時候，TEAM從PBL頂端取適量的任務，然後負責將其全部完成；PO隨時增減PBL中的特性，並加以描述，調整優先級，把最重要的放在頂端，需要注意的一點是——在一個Sprint已經開始之後，即使在PBL最頂端的任務也只能在下個Sprint交給TEAM去實現。
Scrum實踐
既然Scrum最核心的價值在於檢驗和適應，因此實踐Scrum的過程也是繼續學習Scrum的過程。我從2009年下半年開始接觸Scrum，到現在已用Scrum來管理項目約5年了，這個過程中每過一段時間我都會去看一些有關Scrum的資料，反思自己遇到的問題，並且看一看他人實施Scrum的經驗，以及關於Scrum實踐過程中的各種疑問的討論，每一次都會對Scrum的某些有爭議的細節有更新的認識。
緊急任務
當出現優先級非常高的緊急任務突然需要加入時，問題就來了，這個任務應該以怎麼樣的形式加入到Scrum流程中，團隊什麼時候來做？
我們知道PO在整個產品開發過程中可以決定每一個特性做與不做，也能夠決定要做的所有特性的優先級。從一個較長的時間段來看，PO決定了產品的一切，因爲他將決定每一個產品在什麼時間發佈，並且每個版本包含怎麼樣的特性。但是需要注意的是PO完成這一切的方式主要是依靠維護PBL來完成的，PBL中依次排列的項目決定了產品未來將要實現的特性，而PBL的優先級決定了TEAM下個Sprint將選擇哪些任務來實現，同時PO還可以決定哪些版本對外發布（雖然每個Sprint結束之後TEAM都會交付一個潛在的可發佈版本，但是並不一定每次都需要發佈，這將由PO來決定）。
我們還提到過一旦SBL制定完成，在Sprint進行中就不能再更改，因爲這是TEAM在Sprint中最主要的目標，我們需要保證團隊將精力完全集中在目標上，因此目標應該是確定不變的。面對緊急任務，我見到的有一部分團隊的做法是簡單地將緊急任務插入到SBL中，然後容許這個Sprint完成度受影響或者簡單地從SBL中置換出一些未開始的任務，這些都是不可取的，作爲Scrum Master，一定不能允許這樣的事情發生。因爲每一個Sprint是需要預估，需要全體團隊成員討論達成一致之後確定目標然後開始實施的，中途加入的任務將會破壞這種預估，更沒有經過完整的討論，這將極大增加未知，也就意味着風險。因此，當Sprint進行過程中遇到緊急任務需要加入時，有兩個選擇：
- 將這些緊急的任務添加到PBL的最頂端，保證下個Sprint它們一定會被實現；
- 中斷當前的Sprint，將緊急任務添加到PBL最頂端，重新開始新的Sprint；
可以看到，不論以那種方式，緊急任務都只能被添加到PBL中，而非SBL。Scrum適應變化的能力很大程度體現在Sprint這個時間長度上，因爲相較傳統的軟件開發模式，Scrum可以在每個Sprint開始的時候添加新的需求，在每個Sprint結束時都會有一個可用的版本。而當團隊處在Sprint的執行過程中時，Scrum則要求更強的穩定性。SBL中的每一項都應該在Spring Planning會議上經過全部團隊成員的討論，在這個會議每個人都可以自由提問，以保證每一個人對Sprint的目標有足夠清晰的理解，這是團隊每一個人作爲一個負責任的成員對Sprint目標做出承諾的前提，也是Sprint進行過程中團隊集中精力完成目標的基礎。
Daily Scrum
Daily Scrum會議在Sprint中的每一天都要開，而且強烈建議在每一天的同一個時間，同一地點開，最理想的時間是每天早上，因爲這個會將影響每一位團隊成員今天工作的上下文。
Daily Scrum每日站會可能是大家瞭解到Scrum時很容易留下深刻印象的一個特點，不同於我們平時多人圍坐，一開則幾個小時的大會議，這個會議是站着開的，而且時間非常短。大家都很痛恨開會，參會人數越多，會議時間越長，效率就越低，Daily Scrum既然是每天都要開的會議，那麼這個問題是一定要避免的。Daily Scrum所有的TEAM成員都要發言，但是每個人的發言僅限於回答三個問題：
- 你昨天做了什麼？
- 你今天打算做什麼？
- 你遇到了什麼阻礙？（需要什麼幫助？）
當每一位成員回答完這三個問題，TEAM就可以很好的掌握項目當前的狀態，什麼已經完成了，什麼還沒有做。需要注意的是，這個會議最主要的目的是讓團隊成員之間有足夠的交流，而不是用來讓領導瞭解項目進度的，所以在Daily Scrum上每個人回答這三個問題的時候，應該面向團隊的每一位成員，而不是領導。Daily Scrum的參會成員包括整個Scrum團隊，包含PO、SM，在這之外的人也可以參加，但是它們只能聽而不能發言，保證了這一點，能夠很好的提高Daily Scrum會議的交流效率。
Daily Scrum很簡短，任何細節問題都不應該拿到這裏來討論。所以如果開會過程中遇到了細節的問題需要進一步討論，那麼應該在Daily Scrum結束之後，另外組織會議討論這個問題，因此在Daily Scrum進行過程中Scrum Master一定要注意控制會議的主題，防止進入過度的細節中而使會議效率降低，在適當的時候要阻止這個趨勢。
在實踐中，我發現要嚴格地做到控制Daily Scrum時長並不是容易的事情，大家一起討論很容易就不自覺地開始描述細節。這裏有一個小技巧，我見過某些Scrum團隊會在Daily Scrum的時候以傳遞物品的方式來輪流發言，比如傳遞一個小公仔之類的物品，這個方式的本意是防止發言的人被其他人打斷，而如果把這個小公仔更換成一個重物（要足夠重哦，啞鈴、板磚什麼的都可以），當發言的人搬着重物說的時候，就會發現越來越吃力，於是就能夠不斷提醒自己簡短地說，儘快結束髮言了。
關於檢驗（inspection）和適應（adaptation）的遊戲
在參與Scrum Master的培訓過程中，老師讓參與該課程的約30人玩了一個遊戲，規則如下：每個人持有一張個寫有一個正整數（每個人的數字不相同，並且所有這些數字的取值區間很大）的紙條，自己可以把數字說出來，但不允許把紙條給其他人看。參與遊戲的人圍站成一個圈，老師把一個球交給所有人中數字最小的人，然後開始計時，參與遊戲的人需要按照每人所持數字的遞增順序來傳遞這個球，直到每個人都經手這個球，最終傳遞到持有最大數字的人手裏，遊戲結束。遊戲過程中大家可以自由交流，唯一的限制就是不允許把紙條給其他人看。這是一個很簡單的遊戲，同時也因爲規則很簡單，也沒有很多細節說明，於是就可以有很多的變化。
在集體討論了幾分鐘後，大家很快想到一個辦法，由一個人作爲主持來組織大家的行爲，大家以類似的二分法來尋找當前還沒有接觸過球的最小值的人，然後把球傳遞過去，但是實施過程中並不如想象中那麼理想，因爲老師給的數字取值區間太大，並且分佈不均勻，因此每次找下一個傳球人花費的時間很多。於是還沒等球傳完，這種做法已經被否定了，大家重新開始想辦法。
新的辦法是每當一個人接到球，就把自己的數字報出來，大家認爲自己和他接近就報出自己的數字，然後只要自己的數字比已經報出的最小值還要小就搶答，這樣我們提高了每一次尋找最小值的代價。這個辦法很奏效，使得球在每個人手裏停留時間都不長，保持了比較好的傳遞狀態，當傳遞完成時，我們花費了約5分鐘。
接下來，老師讓我們不斷優化這個傳遞的過程，規則不變。於是大家開始詢問和嘗試各種改變，比如重排大家站立的順序，經老師許可後，我們在開始傳遞之前將站立的順序提前調整爲按照數字增序排列，這樣傳遞過程中就很大程度上縮小了尋找下一個人的代價。很快我們就完成了傳遞，這次是1分10秒，這看起來是一個很大的進步。
但是，這還沒有結束，我們還在繼續想辦法，希望進一步優化。大家發現上一輪傳遞球的過程中，傳遞球這個動作需要從上一個人那裏接過球，轉身，再給下一個人，這個是該方法耗時的關鍵，於是再次和老師確認：我們需要的是每個人按照數字順序接觸到球（不一定要握在手中）。於是就有了新的辦法，這一次讓球靜止放在桌子上，球不動而人動，大家排成長隊，還是按照數字的增序，依次跑過桌邊，在球上摸一下。這看起來很理想，因爲我們將傳遞的時間縮短爲輕觸一下的瞬間，時間一定會再次被刷新。當計時結束時，老師很遺憾地告訴我們，這一次時間反而變長了。大家停下來分析原因，是前後兩個人跟着跑的間隙，以及球被觸的力量稍大後還會滾動，這給我們的傳遞帶來了不穩定的影響。
在大家繼續思考的時候，老師終止了整個過程，並且提供了一個他目前見到的最快紀錄的傳遞方式——大家站成弧形，然後伸出手放在同樣高的位置，由第一名持球人帶着球從弧形內側跑過，用球碰每個人的手一下。這是一個開放性的遊戲，沒有標準答案，也許某天有更好的方式，還可以在此刷新最快紀錄。在整個遊戲過程中，作爲一個團隊，我們經歷了初期的團隊組織；實施過程中對規則（即潛在優化的機會）的不斷探索；並得到了一些好的優化，也伴隨着失敗的嘗試。這就是一個典型的檢驗和適應過程，團隊需要不斷總結之前的經驗，爲之後的行爲做出指導，每次改變一小點以保持風險可控的同時積累經驗，不論好的還是壞的改變，都可以爲以後的選擇做出經驗性指導。
Scrum是一個經驗性框架，Scrum是一種組織方式，但所有的實施過程怎樣進行，還要靠我們自己，在整個過程中不斷檢驗和適應，找出最適合我們的方法。
參考
- Scrum Rule: No Additional Requirements Can Be Added to a Sprint!, http://www.civicactions.com/blog/2011/sep/07/scrum_rule_no_additional_requirements_can_be_added_to_a_sprint
- Wikipedia——Scrum, http://zh.wikipedia.org/wiki/Scrum
- The Daily Scrum Meeting, http://www.mountaingoatsoftware.com/agile/scrum/daily-scrum