Scrum開發管理方法的由來、團隊建設與實施過程

起死回生的“哨兵”

2001年9月11日，隨着世貿雙塔轟然倒塌的巨響，美國聯邦調查局遭受了前所未有的指責和質疑。美國人民很想知道，這個地球上最強大的情報機構爲什麼事先一點預警也沒有？聯調局的分析員們帶着愧疚的心情重新分析整理過往的資料，發現恐怖分子的行蹤其實都有跡可循，倒黴的事情在於聯調局的工作方式還是30年前式的。他們將情報打印在紙上然後從樓上傳到樓下由某個負責人簽字之後再傳回樓上，最後分發給相關部門。顯然，恐怖分子不會給聯調局這個時間去發現他們的陰謀。

痛定思痛，聯調局決定投入巨資建設一套信息化的分析處理系統，力爭在最短時間內發現風險併發出預警。考慮到這套系統的保密性要求，他們將其交給了傳統軍工巨頭洛克希德·馬丁公司。這項工程被命名爲“哨兵”計劃，預算4.5億美元。經過了五年的開發之後，錢花得差不多了，但進度只有一半。更可怕的是洛·馬公司宣稱完成開發工作還需要6至8年，並且再投入3.5億美元。其實大家心裏都清楚，這已經是一個爛尾工程了。

傑夫·約翰遜是聯調局“哨兵”項目的技術負責人，他很清楚項目失敗的原因，就在於洛·馬公司使用的仍然是傳統瀑布式開發方式。這種方式對於需求的變化幾乎沒有招架之力，只能是將前期工作推倒重來，所以造成如今的困局。約翰遜爲此向聯調局提出可以採用一種敏捷方法論，只需要用項目裏還剩下的2000萬美元，保留五分之一的開發人員，在12個月內就能完成這個項目。

負責經費預算的檢察長一度認爲約翰遜因爲焦慮過度而病急亂投醫。但面對現實同樣束手無策的檢察長只好死馬當活馬醫，讓約翰遜按照他自己的想法姑且一試。約翰遜使用敏捷方法論中的Scrum開發管理方式，首先確定最重要的需求，然後立即開發實現功能原型。有了最小可用的功能，就讓聯調局的工作人員使用並提出意見。之後調整功能，擴展需求進入下一輪迭代中。這樣的一個過程在Scrum稱之爲衝刺週期，在不斷的衝刺之下這套系統逐漸完善起來。

終於在兩年之後“哨兵”系統正式運行起來，儘管這比約翰遜承諾的時間要長，但還是讓聯調局大大鬆了一口氣。這個神奇的Scrum是什麼？它來自於橄欖球運動的一個術語，即球員們環抱圍成一圈，然後將球控制腳下向着目標區移動。引申在軟件開發管理上則是強調團隊合作的重要性，同時讓各個成員發揮出自己的力量，整個團隊具有強大的信心與持續的激情。

Scrum理念的創造者是傑夫·薩瑟蘭博士，這位老兄的人生經歷堪稱彪悍。早年他從軍服役，在越南戰場上乾的就是最危險的技術活：駕駛偵察機深入敵軍後方。當時美軍飛機被擊落的概率是50%，但他卻成功完成了100次敵後偵察任務。可知這位老兄是一個非常善於思考並且處事冷靜利落的人。

當然，美軍飛機的戰損率高也有自身訓練的問題，後來軍方發起了Top Gun訓練計劃，一舉扭轉了飛機戰損率。這一最初來自越南戰場的訓練經驗後來在陸軍中也得到了推廣應用，並且在第一次海灣戰爭中大獲成功，成爲了一場影響世界的軍事訓練革命。此爲後話，不再贅述。

薩瑟蘭博士在退役後又經歷了學術生涯與商業活動生涯。他正是在企業裏管理軟件開發的過程中，發現了傳統瀑布式方法的諸多缺陷，進而思考並提出了Scrum方法並進行了實踐。

Scrum的理念和方法其實很簡單：一個團隊最好在七人以下；一個產品負責人，一個項目管理員；一張包含待辦、在辦、已完成的事項清單；由衝刺構成的開發週期與每日立會。

這一理念提出後，立即引發了業界的廣泛思考和探索。傑夫·約翰遜顯然也是Scrum理論的擁躉，不過可以看出來他也並非是盲目的信徒。他非常瞭解“哨兵”項目的癥結所在，所以能夠對症下藥，應用Scrum方法創造了這一看起來似乎是不可能的奇蹟。

Scrum方法不僅適用於軟件開發過程，在其他行業甚至是我們的家庭生活中都可以應用它。當然，一個理念再簡單再好，也需要先得到認同然後再去進行實踐。很難想象團隊中的成員連基本的認知都無法達成一致，卻要去基於這個方法做事情，肯定是無功而返了。

標題目標與團隊建設

目標

scrum正如其名稱來由所揭示的，橄欖球運動員們緊緊圍成一圈，把球控制在圈內，然後向着目標前進。最終能否得分取決於所有隊員之間的全力配合。在使用scrum方法進行開發活動管理也是一樣，開發團隊成立的第一天，所有成員首要的事務就是要知道團隊的目標所在。

如果目標不清晰，那就像在賽場上隊員們思路不統一一樣。這個認爲要穩守反擊，那個覺得要大舉壓上，造成的結果是兵力分散，空門大開，輕易被對手抓住機會得分。誠然，球隊中會有實力超羣的球星，他的能力可以一個頂倆或者頂仨，但不可能一個打十個。球星如果把目標定爲自己多得分，想憑一己之力終結比賽，這多半難以成功。但球星的目標如果是和隊友們一起贏得最後的勝利，球隊的戰鬥力就爆發出來了。

軟件開發團隊也是如此，每個人的實力不見得都在一個水平線上。但開發者們如果只把目標定爲完成好自己的任務，那麼這個團隊中的成員仍然處於一種各自爲戰的狀態，最終結果的質量必然是在團隊成員的平均水準之下。所以，每個人都應該把最終交付的產品質量作爲目標，力求產品做到穩定、高效、可用。

團隊建設

關於團隊的構成，它首先應該是多功能的。也就是說開發一個軟件產品所需的專業技術人員都應該包括在內。自從人類進入機器大生產時代以來，工業流水線式的生產方式就是主流，因爲它快速並且易於管理。這一思維應用在軟件開發上則收效甚微，因爲開發工作是知識密集型，並且軟件產品的特點是需求變化快速。很難做到前期目標不調整，後面可以持續各個環節的工作，一旦返工則成本巨大。

因此以流水線模式將開發人員分成“服務端組”、“客戶端組”、“美工組”、“測試組”並非是最好的辦法。這種組織方式會造成的另一個嚴重問題是各個組只對本組的工作負責，最常見的一種情況是產品在線上運行出了問題，每個組都試圖證明“在我的環境裏運行是正常的”，然後建議“你們要不再查查別的原因”。這顯然不是在解決問題，而是利用組織之間的鴻溝來擺脫問題。

其實出現上述情況之後，最後總是要由CTO或技術總監這樣更自更高層的領導者下令，抽調各組人員臨時組成一個團隊來分析問題並解決掉。各位可以回想一下，在職業生涯中是不是面對過上面所說的場景。所以，一個多功能的團隊內所有信息都是均等流通的，出現問題能夠快速排查並處理。

多功能團隊的另一層含義是每名成員除了自己擅長的技術之外，還應該學習其他成員所擅長的技能。這一點對於應對人員風險來說至關重要。團隊中的成員總會遇到各種問題而有可能暫時缺席或者離開，那麼在短時間內爲了不影響工作進展，最好的頂替者當然是團隊內部的成員。因爲就算臨時去找來高手，其要熟悉業務就需要一個過程，不可能快速上手並融入團隊中。

對於團隊成員數量，最好是在八人以下。這個依據來源於一個人際交往的理論，就是說一個人在日常活動中可以保持聯絡而不影響工作效率的人數是七人。聯繫人超出了七人，那意味着個人生產力會大幅下降。其實也不難理解，因爲大部分時間都用在頻繁的溝通交流上了，而且還要記住這些交流會產生的待辦事項，顯然本職工作就難以做好了。

可能會有疑問說，一個大公司裏好幾百號人，要應用scrum那應該怎麼辦？辦法就是把大團隊拆分，然後按照scrum的結構進行組織。對於有任務關連的團隊，可以由各個團隊的管理員們再出來單獨組成一個scrum團隊，這樣可以根據任務需要靈活構建上層管理團隊。而每一個基層團隊又都可以保持自主性與凝聚力。

scrum團隊中的管理員角色從功能上更像是爲項目服務的管家，他負責召集人員制定目標、召開每日立會，協調資源，在衝刺活動結束後召開總結會議。一個迭代週期完成之後，管理員要聯繫客戶並向其展示工作成果，根據客戶的反饋對功能進行修正，並確立下一個週期的工作內容。

實施方法與工作過程

衝刺

一個遵循Scrum理念的團隊建立起來之後，就要進入工作狀態中了。但這不是一上來先打了雞血一樣，過一陣子又疲軟無力。要想保持高效的產出，節奏很重要。在scrum中，一個衝刺的過程一般來說不超過一週時間。持續四到五個週期的衝刺之後，就可以得到基本可用的產品了，這也是流傳甚廣的30天開發可用軟件說法的由來。

對於衝刺的目標來說，並不是說在每個週期完成一個功能模塊，所有模塊開發完後組裝在一起完事。每一次衝刺的目標都應該是交付一個可用的軟件產品。當然，最初的產品僅是一個粗糙的原型，但也足夠給客戶提供直觀的體驗。在此時客戶發現問題並提出新的需求，在下一個衝刺中就可以全力解決問題並開發客戶所需的功能了。

在衝刺開始之前，要舉行一場計劃會議。這個會議的議題是討論要進行的工作，並將討論內容歸納成用戶故事。需要注意的是計劃會議只討論當前一個衝刺之內能完成的任務，目標過於宏大沒有意義。作爲一種敏捷方法論，Scrum強調的是快速接近用戶真實意圖，打造符合預期的可用軟件。

當一個衝刺結束之後，則要召開一場總結會。這個會議則是討論當前已經完成的工作，同時要回顧出現了哪些問題以及解決的辦法。這是爲了避免在後面的工作中再犯相同的錯誤，這往往是提高效率的關鍵。最後則是向所有成員展示已經取得的成果，鼓舞團隊士氣，爲下一個衝刺做好準備。

經過數輪的衝刺實現產品的迭代，這必然是趨近於客戶的目標的。這遠比團隊關起門來開發幾個月，拿出來的產品跟客戶的預期差距甚大要好得多。同時，固定時間的衝刺活動也有利於團隊成員保持工作節奏，能夠合理地安排自己的任務。

要點：

• 舉行衝刺計劃會議；

• 全力以赴投入工作；

• 召開衝刺總結會；

• 多輪迭代。

事項清單

Scrum團隊的任務管理是有別於傳統的軟件開發管理的。在傳統管理方式中，是由項目經理與架構師或者資深程序員討論出一個任務列表。然後項目經理在甘特圖中標明各個任務的起止時間，再把開發人員填充進去，萬事大吉。這種圖表是完美的，如果不出意外，結果也應該是完美的。

可是問題就在於軟件開發活動就是個意外頻出的過程，一張繪製完美的圖表到後期總是被各種變更扭曲、打亂，結果變得醜陋不堪。在Scrum的實施過程中，採用的是事項清單來管理任務。

在說明任務管理方法前，還是要提一下Scrum理念所強調的儀式感。Scrum方法認爲一個團隊中的所有成員最好是將自己的電腦從格子間的工位搬出來，有條件的話大家在一個單獨的房間裏共同辦公。例如找一間空閒的會議室，大家把電腦都放在會議桌上，彼此圍成一圈。然後拿出可粘貼式便籤紙，準備下一步工作。

管理員這時會站起來，在會議室的白板上用碳素筆畫出三個分隔的區域，並且從左至右在各自區域寫上：待辦事項、在辦事項、完成事項。接下來討論第一個衝刺要完成哪些任務，在Scrum中，這被稱之爲用戶故事（下節詳細討論用戶故事）。大家達到一致之後，管理員把用戶故事分別寫在便籤條上並貼在“待辦事項”區。再接着就是進行任務分配了。

重點之處在於，任務並不是由管理員自上而下地分配給某人，而是由團隊成員自告奮勇領取任務。領取者會莊嚴地將便籤條從“待辦事項”區移至“在辦事項”區。這樣團隊所有成員也就明確承諾了自己的任務，並且在一個衝刺週期完成之後，再由領取任務者將自己的便籤條從“在辦事項”區移至“完成事項”區。相信當衆主動承諾所帶來的驅動力是遠勝於被人在後面給推着走的了。

當然，如果一個團隊在組建伊始，可能會出現對工作承諾過於悲觀或過於樂觀的問題。但經過一到兩個衝刺之後，團隊成員彼此熟悉並且配合默契了，就會更加合理地領取任務並完成好。當衝刺的次數越多，團隊的效率就會越高，這是Scrum方法所帶來的一個巨大的益處。

事項清單也有助於團隊成員對項目整體進展的把握，因爲只要有一個任務還留在“在辦事項”區內，那麼這一次衝刺也是失敗的。勢必大家都會爲了共同的目標而羣策羣力，而不是說別人的任務跟我沒關係，等他自己解決就行了。

要點：

• 在封閉空間內集體辦公；

• 準備好寫有待辦、在辦、完成事項的白板和便籤紙；

• 將用戶故事寫在便籤紙上，並張貼出來；

• 團隊成員主動領取任務；

• 移動便籤紙，直到任務全部完成。

用戶故事

在Scrum中，軟件功能的需求被稱之爲用戶故事。之所以要用這樣的名稱，是爲了藉助於“故事”一詞所傳達出的隱喻。我們知道一個故事的基本要素裏包括人物、情節發展與結局。對應於軟件需求來說，一個需求應該從用戶角度出發，然後他會如何操作以達成目標，以及這個需求是否可測試。

在討論用戶故事的時候應該要和最終使用者進行充分地溝通，因爲只有使用者才明白他們想要的是什麼。但遺憾的是使用者本人在沒有直觀的感受前，他只能以模糊的話語來描述他想象中的事物。

所以在確定一個用戶故事時，它的規模不能太大，最好是一個可在短期內實現的功能。一般在Scrum實踐中，一個用戶故事的開發週期就是在一個衝刺之內。

同時，一個用戶故事必須是獨立可測試的，不能說對它進行測試還要依賴於另外一個用戶故事。強調它的獨立性一是爲了減少系統功能的耦合，二則是可以根據用戶對功能的要求緊急程度進行組合。

在初期討論用戶故事時，可能會羅列出很多事項來，但不可能都同時進行。因此要按照功能的重要程度給其標記上權重值，這樣就可以將最核心的功能挑選出來優先開發。在一個衝刺完成後，用戶立即就能對已經完成的功能有直觀體驗，進一步明確下一步的工作。

除了功能重要程度，每個用戶故事還應該標記實現複雜度。這個數值是爲了估算團隊的完成能力，有了這個數值就可以合理分配一個衝刺之內的工作量。不至於說上週任務難度低，工作特別輕鬆，這周任務都很複雜，結果搞得大家都壓力重重。

要點：

• 一個用戶故事必須是獨立可測試的；

• 一個用戶故事最好在一個衝刺內完成；

• 標記重要程度值；

• 標記複雜度值。

立會

立會的意思就和字面上一樣，站着開會。這也是一個Scrum所要求的儀式，站着開會顯然會促使人長話短說，同時還有益健康。當然，Scrum理念的發起者是希望這樣一個形式能讓人時刻記住立會的目標：快速總結工作成果，並提出問題。

在一個衝刺週期內，立會是要求每天都要召開的，通常由管理員發起。開會時間也最好是一天中的固定時刻，例如早晨十點，不用特別通知，每個人到了點就自動聚在一起開會。

管理員會提出三個拷問靈魂的問題：

“昨天完成了什麼工作？”

“今天要做什麼工作？”

“遇到了什麼問題？”

每個人都要回答，而且每個問題的回答時間不能超過30秒，意味着兩三分鐘內就要把三個問題全部答完。這不是在搞某種行爲藝術，而是效率的需要。如果在短時間內不能說清這些事項，那就意味着任務的分解是不合理的，有隱含的複雜情況沒有被發現，而這對項目來說就是風險。

一個需要注意的情況，就是立會不要開成工作彙報會，大家只是例行公事般說完自己的事就各自安好了。立會的主要功能有兩點：一是讓大家的信息保持對等；二是儘早解決問題。

有研究發現，一個團隊的默契合作程度和一個叫做信息飽和度的指標相關。這個指標的含義就是團隊成員之間分享信息的比例，信息飽和度越高則團隊的產出效率越高。而每日立會則是一個極好的大家共同交換信息的機會，通過這種方式將信息飽和度保持在一個高水準。

我們翻開任何一本講述軟件工程的書籍，都會告訴我們一個軟件bug如果在前期被忽略，到後期來修復時會產生更加巨大的代價。立會上的第三個提問就解決了延遲解決問題所帶來的損失。

當然，在立會上僅需要提出問題就好，散會後再召集相關人員詳細討論解決辦法。切忌在立會上就熱烈討論半天，而耽誤了整個項目的進展。這時管理員就要保持清醒的頭腦，控制會議的進程。

要點：

• 三個問題；

• 三分鐘之內說完；

• 聚焦於出現的問題。