SCRUM之比喻

老子《道德經》云：“治大國，若烹小鮮。”用簡單的貼近生活的例子做比喻，來論述複雜的事情和高深的道理，在古文中很常見。再如荀子《勸學》中滿篇的比喻（估計讀過中學語文的都能背上幾句）：“青，取之於藍，而勝於藍；冰，水為之，而寒於水”，用來比喻人通過學習改造，可是勝過以前。SCRUM作為一種敏捷架構，也有很多比喻，這些比喻可以使我們更形象地理解其內涵與外延。

 

前一陣子正在拜讀SCRUM聯盟主席Mike Cohn的《SCRUM敏捷式軟體開發 (Agile Software Development)》（英文名：Succeeding with Agile: Software Development Using Scrum）一書。作者運用了很多形象的比喻，來解釋SCRUM中的一些問題和概念。比如：

 

一. 火箭、重力

 

“我把Scrum比作火箭。火箭向前推進依靠的是它的發動機功率。但將其拉回來的是重力。如果火箭被推的足夠遠，它可以進入軌道。但如果它不能進入軌道，必定會被拉回到地面，回到起點。Scrum的影響必須推得足夠遠，使整個轉型不會因為“企業重力”而被拉回起點。”

 

作者在論述企業進行敏捷轉型和推廣傳遞Scrum時用了以上比喻。Team Dev只靠自己是不能夠永久保持敏捷的。Scrum必須傳遞到其它部門，否則這些部門的“組織慣性”最終會使轉型所作的努力化為灰燼。作者還專門辟了一章，講述推進Scrum不能忽略Team Dev之外的群體（包括人力資源、後勤和專案管理辦公室PMO）的影響以及如何讓其它部門能配合敏捷實踐。筆者在前次參加Scrum中文網的敏捷沙龍活動中，演講人李連華在演講《Scrum實踐中的困難、挑戰與三級助力》中，也提到了這個比喻，他提到克服這個“企業重力”需要“三級助力”（就像火箭發射的三級助推），即敏捷意識、工程實踐和實踐社區。

 

二. 疼痛

 

對於任何變革，抵觸都是不可避免的，Scrum轉型也是如此。但對於“抵觸”，企業的領導者應該採取什麼樣反應？是讓“我們”戰勝“他們”？還是分析原因，然後創造一種氛圍，讓大家感覺到轉型勢在必行？作者引用了一個比喻：

 

“社會組織中的抵觸訊號就像疼痛對身體的訊號作用一樣有用，疼痛表明某些身體機能失調。像疼痛一樣，抵觸並沒有告訴我們什麼出問題了，而僅僅只是覺得有一些不對勁。試圖去克服這些抵觸是沒有意義的，這比不診斷病因而只吃止痛片更嚴重。”

 

所以，對策不應該是用絕對的權威完全忽略員工的情感和反應而把Scrum強勢推給企業，也不能把抵觸的員工視為要解決掉的問題。就像不能只用止痛藥，而是應該對原因認真探究，對症下藥。

 

三. 樂隊指揮

 

Scrum創立者之一Ken Schwaber在1997年發明了單詞ScrumMaster。為什麼要發明這個新頭銜？原因是提醒每個人，ScrumMaster不只是專案經理角色增加或減少某些附加的責任。那麼ScrumMaster到底是個什麼角色？Mike Cohn用了這樣一個比喻：

 

“請把ScrumMaster想象成樂隊指揮家。兩者都必須即時引導一個團體，團體中的個人是為了某一創造性的目標走到一起，而這個目標是沒有人能夠單槍匹馬實現的。波士頓流行音樂指揮家Keith Lockhart對其角色的評價：‘當你成為一名指揮家，人們就猜測你會是拿破崙式的人物——站在大箱子上行使權力。我不是權力迷，我是責任迷。’優秀的ScrumMaster以一種獨一無二的方式成功地履行其責任——沒有權力的、特殊的責任。”

 

樂隊指揮，不像小提琴手、小號手等演奏員真正地去演奏樂曲，但他通過對樂曲的理解協助樂團協調一致地完成演奏；ScrumMaster，不像團隊成員真正地去產出軟體，但他保護團隊，迅速清除擋路石，保證團隊一起順利工作，使團隊有效地朝著目標前進。類似的角色可能還有足球教練和電影導演。ScrumMaster懂得他的工作並不能給他帶來公司配車或車庫入口的好車位，他既不能對團隊成員說：“你被解僱了”，也不能在遇到問題時說“讓我來”。所以做好ScrumMaster本身就是一門藝術。

 

四. 體育團隊

 

高效能Scrum團隊，首要目標是接受團隊責任制。只有PO對產品Backlog負責嗎？只有程式員才為整潔、優雅代碼負責嗎？只有測試員才為品質負責嗎？不是。應該是整個團隊要為產品的所有方面負責。這有點像體育團隊。

 

“新賽季開始。我們會說團隊中哪些成員要對奪取冠軍負責？教練嗎？老闆嗎？明星選手？……整個團隊都在為通過某種方式贏得比賽而負責。如果團隊輸了，可能很容易責怪這個人或那個人，但團隊知道他們中的每個人都要為失敗負責。這個從來不是一個人的錯。實際上，沒有單獨承擔失敗責任的人。”

 

Scrum軟體研發團隊，可能有Architect、UE Designer、Developer、Tester、DBA，還有Scrum Master和PO，這就像是足球隊中的不同位置的人，他們的職責有所不同，但他們都在為比賽的輸贏負責。進攻中，後衛可以進球，防守時，前鋒可以是第一道防守線。

 

五. 三明治商店

 

在“依賴專家但需謹慎”一節，說到Scrum團隊成員應該是“通才”還是“專才”時，Mike用了三明治商店的例子。Scrum專家們也經常會引用這個例子，來給Scrum新手講解Scrum團隊中通才和專才的關係。

 

“一個普遍的誤解是Scrum團隊的每個成員都必須是通才而不是專才。這是不對的。我對此感到吃驚的是世界上每個三明治商店都已知道如何對待專家，而在軟體行業的我們還在為這個問題苦苦掙紮。……他們（指三明治商店）有三種類型的僱員：訂餐員（order taker）、三明治廚師（sandwich maker）和流動工（floater）。訂餐員在櫃檯上工作，寫好每個三明治訂單然後傳遞給背景廚師。廚師在訂餐員後面工作，接到訂單後就準備三明治。訂餐員和廚師是專家。流動工則是多面手——能幹兩種工作，不過可能沒有專家那麼好。……這對Scrum團隊的啟示是我們總要嘗試擁有一些多面手。正是多面手讓專家們顯得更專業。”

 

常有人說，公司裡有些代碼只由一個人（專家）來寫，只有他明白，一旦他離職，沒人能接手。所以，嘗試培養“流動工”，也許可以避免這種問題的發生。

 

六. 持續胎壓偵測

 

“……我特別滿意的一個改進是用來自動偵測輪胎胎壓是否過低的感應器。有時候很難分辨清楚輪胎壓力是否變低了，人工檢測胎壓這活兒顯然很髒，所以我很少做。我認為持續檢測輪胎壓力是一個偉大的發明。在同一時期，汽車製造商發明了持續測試輪胎壓力的新方法，而軟體Team Dev則認識到不斷測試產品也是一個好主意。”

 

傳統開發方法中，測試要等到開發完成並交付到測試環節才開始。即使是有些聲稱使用了Scrum的企業也在每個Sprint中使用微瀑布的開發方法（包括我原來的公司，也曾走入這樣的誤區），即：等一個功能完全開發完成後，再開始測試。其實，Scrum把測試作為一個主要的實踐，並把測試作為開發過程的一部分，而不是作為開發工作“完成”後才發生的某些事情。不是等產品構建好了之後才儘力測試產品的品質，而是在流程中、產品製造過程中持續地構建品質。

 

書中還有許多比喻，比如：

“我把敏捷過程比喻為一個漩渦，隨時間的推移，漩渦逐漸形成，吸引新的人和團體進來，作為它的基礎。”

“所有人都知道你在做敏捷，所以你更容易堅持下去。……不管你是開始減肥、戒煙或啟動一個鍛煉計劃，把這個計劃告訴你的朋友總是一個不錯的想法。你也許會感到有一種心照不宣的壓力去獲得成功，因為你已經宣布你的打算。”

“我不提倡這樣做（輪流擔任ScrumMaster）。……在家裡，我們輪流擦桌子和洗碗，我們誰都可以做這份工作。但是，我們不輪流做飯。我妻子烹飪的本事遠遠強過家裡其他人，我們希望吃到的飯菜時能做出來的最好的飯菜。”

“一個集體所有權的團隊會寫出更乾淨的代碼，而且可能因此減少缺陷。沒有人願意在同事面前丟臉。……再考慮一下你給客人用的浴室。哪一個會保持得更乾淨？只有你自己會用的，還是客人可能看到的那個？”

“觀看網球比賽時，你可能注意到選手接發球時注意力很集中，而不是毫無準備的站著。企業Scrum轉型的領導者和變革推動者希望企業可以時刻準備好向左、向右或者任何方向行進。”

“產品Backlog呈現出冰山形狀。在該產品Backlog冰山的頂部是團隊在最近一個Sprint中能完整實現的那些小功能需求；當我們從該冰山進一步往下看（也就是更遠的將來）時，Backlog條目會變得越來越大，一直到水平面為止。團隊還不知道有什麼藏在它下面，那些實際上是還沒有進入討論流程的需求。”

“美國作家E. L. Doctorow曾寫過‘寫小說就像在夜晚的迷霧中開車，你只能看到前燈燈光所及的地方，但是你能以這樣方式完成你的旅途。’軟體開發也是一樣。我的前燈不能照亮在我和燈光不能到達地方之間的所有東西。前燈照亮的那些地方，足夠讓我在車安全行使時看到東西並做出反應。”

“詳細說明書的一個不足是它們很少保持更新。在寫一份文檔前，問問自己是否願意一直更新該文檔。如果不是，要麼謹慎考慮編寫文檔的必要性，要麼給這個文檔規定一個失效日期，類似牛奶盒子上‘最好在……之前飲用’的提示。”

 

除了這本書之外，我還看到聽到過很多關於Scrum的比喻。

 

前幾天看薑志輝的視頻《軟體博弈》，他也用到不少比喻，比如：他從“殺人遊戲”講述迭代的必要性，他把往Sprint裡放待辦項比作往籃子裡放雞蛋，他把Scrum軟體開發比作像“魔獸世界”這樣的合作溝通的團隊遊戲。把Scrum比作遊戲的還有李國彪（Bill Li），他把Scrum比作圍棋（入門容易，成為高手談何容易），把實施Scrum比作下一盤圍棋（一開始布局留白，到中盤會碰到很多疑惑、挑戰和困境）。Scrum培訓師Jens Ostergaard用日本劍道中的“守-破-離”來比喻學習Scrum的3個階段（或境界）。等等等等……

 

我們通過這些比喻，能更深刻的理解和領悟Scrum。反過來，我們在技術實踐中的不斷學習和探索，也豐富著我們對生活的感悟。