如何成為Scrum專家 - 極簡計畫書

Scrum是推進團隊進度，合作專案的敏捷方法論之一。在過去幾年來從資訊產業，金融業，甚至學校教育，都有不少人在倡導這個簡單而且踏實的方式。因為Scrum有很多優勢，例如減低壓力，具有務實的彈性，容易評估現況，易於控制品質。這些優勢，可以用在大部分的企業環境中。因此，成為Scrum專家對職業生涯很有幫助。

學習Scrum並不困難，在各企業巫醫的網路資料中，早就擁有看不完的資料。請參考這篇。

對職業生涯有幫助的不僅是「學會什麼是Scrum」，更重要是成為Scrum專家。或者，至少成為在他人眼中的Scrum專家。專家的定義，請參考註1。

或許你在職場有2-4年的工作經驗，作為一個團隊成員，在專案領導人的帶領下，參與以Scrum為基礎的專案。然而，這不會讓你變成Scrum的專家，因為你只是「照著做」而已。

在此提供一個極簡計畫，可以在很短的時間內讓自己變成Scrum專家。

如果懶得看說明的長篇大論，可直接到這個網頁下載計畫書

開始之前的條件

這份一頁極簡計畫書有使用上的條件：

(a) 必須要有還不錯的英文閱讀能力，TOEIC750以上。如果你的英文能力自認不夠，請參考這裡。

(b) 必須要有2-3年以上的實務工作經驗。而且在工作環境中，至少聽過Agile/Scrum。

(c) 必須打從心裡認為有效使用Scrum是有好處的。換言之，不能是因為「有人叫我要學Scrum」而學Scrum。因為，此極簡計畫書本身執行的方式也是Scrum！


如何成為Scrum專家極簡計畫書的使用步驟如下：

(1) 確認目標的實質意義

此極簡計畫是要在2個月內，讓執行計畫的你變成「Scrum專家」。而何謂Scrum專家的實質意義就是在此極簡計畫中三個sprint的「實質產出」。

Sprint-1 知識：讀完2本Scrum書籍，以及2份網路資料

Sprint-2 證照：取得Scrum證照

Sprint-3 研討會：舉辦公司組織內Scrum研討會或分享會

這三個實質產出的組合意義，目的就會讓你成為Scrum專家。即便不是Scrum大師，至少也是被大部分人承認的專業人士。

這三個Sprint各有已經設定好的任務(Task)，所有任務完成後，就表示該Sprint完成了。而每個任務本身的描述都是有簡單清晰的「完成條件」definition of done。

(2) 分配每個Sprint的時間

計畫書中，每個Sprint各有數個任務，每個任務都有估計的時間。時間是以小時為單位。加總起來，會有要完成Sprint所需要的總時數。

一般軟體專案Scrum估計都可能會有錯，在Sprint過程中，要能實際反映團隊實際的「速率」，因此前1-3個Sprint的燃盡圖很重要，可以讓團隊知道實際的效率。所以每個Sprint都是固定時間，大約4-6週，sprint時間到就結束了，只會看做完哪些Story，在下一個Sprint才調整要完成的story數量。

然而，個人Scrum做法會略有不同。整體概念仍然一樣，但因為Product Owner也是「你自己」，因此Sprint時間可以變動。換言之，可能第一個Sprint是4週，第二個Sprint是5週。

請在極簡計畫書中，每個Sprint任務表格上方，填寫預計的Sprint開始的日期，和結束的日期。Scrum是要反應實際狀況，因此，也許整個sprint需要5小時，但因為你有本來的工作要做，因此可能要花2個月才能有5小時的空閒。

(3) 每日工作

當有超過30分鐘空閒的時候，就可以把那張極簡計畫書拿出來，在這個Sprint選一個任務(Task)開始「執行」，或者，繼續上次未完成的任務。這些Task都是大約設計成30-40分鐘完成，但是根據Scrum的精神，每個人的績效不同，因此也有可能會花的時間多或者少，但無論如何，在還沒完成已經做一半的任務之前，不要換任務！

當然，如果該日沒空，自然就不需要拿出極簡計劃書來執行。

每個任務，都有完成條件，確定滿足完成條件後就可以塗黑空格，並且在右邊簡單的紀錄所花費時間，和大約日期。時間不用太精確，以半小時為單位即可。有些任務很簡單短暫，也許10分鐘就完成，但也以半小時紀錄就好。

如果沒辦法在0.5小時內完成一個任務，那要請自己休息一下，再決定要繼續完成該任務，也可以決定今天就先到此為止。

不能有某任務做到一半，就「先拿了」下一個任務，也不能有這個Sprint還沒完成，就先開始做下個Sprint的某個任務。當然Sprint中的任務，有些是沒有前後關聯，因此Sprint中的任務不需要按順序。只是，一旦開始做，就一定要做完為止。

某些任務需要下載檔案，請參考註2的各個下載網址，可以一次下載完成。

在計畫書中的任務描述都很簡單清楚，但如果真有問題，也歡迎來信詢問

(3) Sprint 結束自我檢討和下個Sprint的開始

完成Sprint中所有任務之後，表示這個Sprint完成。要花15分鐘時間，先自我檢討一下Sprint過程中有哪些阻礙，而自己應該怎麼改善阻礙。

接下來就要開始下一個Sprint。實際上，本來Sprint的開始是需要先討論Story和Task的選擇。然而，極簡計畫書希望你不要花時間在研究這些Task重不重要，而是先努力的花時間搞定它。畢竟這些任務所需要的時間都不多，實務上也對你有莫大的幫助。

不過，或許有些任務你早就已經完成，那就可以看一下完成的條件(DoD)，已經達到就可以自動塗黑。

(4) 計畫書完成？專案結束了嗎？

三個Sprint完成之後，這個極簡計畫書就達到它的功能。但就個人專案的角度來說，專案不見得要結束。只是這時候你已經有足夠的能力和經驗，可以決定要不要繼續以Scrum的方式來學習Scrum。

(5) 3個Sprint結束後的彩蛋！

很簡單，當你完成這個極簡計畫書，實質上你自己完成了一個Personal Scrum。

彩蛋要靠自己完成。請在計畫書背面以三個Sprint的各任務所花的時間，「手工」繪製燃盡圖。

這件事的意義在於，你有確切證據證明你能有效運用Scrum在非工作事項上。也證明你有自我學習的能力。它可以用在未來履歷表，面試，或者說服同事Scrum不如想像中困難，只需要一點點毅力去執行。


在此下載計畫書

常見問題：

Q1：這個極簡計畫書，很多地方跟我在工作上用的Scrum都不一樣啊？

Ans：當然不一樣，因為他屬於Personal Scrum。但是它的最基本精神是一樣的。請參考這裡，了解Scrum哪些最基本精神比較重要。

Q2：我不就是自己的Product Owner？為什麼我一定要用這三個產出來達到「變成Scrum專家」。

Ans：你當然可以自我決定產出和任務，也有機會變成Scrum專家。極簡計畫書，是在如果你還沒有好的定義時，可以透過過去人的經驗，減少時間浪費，讓你專注在精進自己。

Q3：為什麼要取得Scrum認證，這樣就會變成專家嗎？

Ans：有些人可能會以「取得相關證照」，作為專家的標準。這的確是個參考標準，但也只是參考而已，因為Scrum並沒有所謂官方證照，所以市面上各種證照到底哪一個比較適合？請參考這篇「Scrum認證！不要再浪費錢了」。在此採用的是Scrum-Institute的低成本證照。

---

註1：即職場上的專門行業，指具備專業化知識及技能的職業人士。通常，專業技能須符合科學原理，經過長時間的學習及訓練，並有經專業認證的考試獲得的合格證書或執照，擁有自我約束行為的職業操守（或道德）及可量化的專業標準等。...定義細節請參考這裡。


註2：各種需要下載的資料

(a) 任務 1.4 的2個pdf教材
* https://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016.pdf
* https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

(b) 任務1.7的wiki頁
* https://zh.wikipedia.org/wiki/Scrum

(c) 任務2.1的pdf
* http://www.scrum-institute.org/Scrum_Books_International_Scrum_Institute.php

(d) 任務3.1與任務3.3的材料

* http://www.eduscrum.com/

* https://www.crisp.se/gratis-material-och-guider/scrum-checklist

建立軟體開發團隊 (1) 計畫 組成

... of the 20,000 notable players for us to consider, I believe that there is a championship team of twenty-five people that we can afford, because everyone else in baseball undervalues them...(Moneyball 魔球)


軟體開發團隊的建立和運作，不可能有完美的狀況。但是，妥善的計劃，能大幅降低軟體團隊的運作風險，並且讓團隊成員專注於發揮專長和創意，減少不必要的浪費時間。

特別是浪費時間在於解決非技術性問題。


問題有可能來自各方面，例如：

(1) 目標極端困難。例如：要在3個月內完成類似AWS EC2的雲端運算平台。

(2) 目標不確定性極端的高。例如：團隊目的是要完成一個不知道誰簽訂的模糊合約。

(3) 團隊還沒組成，目標也還沒確認，就已經有時間壓力。例如：一個2-3個人合作的新創公司，剛剛獲取資金成立。

(4) 團隊的組成有時間壓力。例如：在大企業中，因為高層要求，一定要在某月某日找齊7個人組成團隊

(5) 團隊已經有部份是問題成員，在此同時還要因組織任務擴張而增加人力。

(6) 因為組織變動(例如企業改變目標，併購等等)，讓某個團隊大幅流失人才，而需要重整補齊人力。

(7) 因為文化與跨國合作困難，導致前期人力大幅流失而需要重整團隊。


負責組織團隊的人，最最基本的認知就是：

軟體團隊組成這件事情：本身一定會有困難與挑戰。不具備困難與挑戰的軟體團隊，其實沒有存在的必要。(註1)


以下三個步驟可以供組織團隊負責人參考：

(1) 了解探索事實，盡可能將事實攤在陽光下

許多新團隊一開始就建立在「各種假設」上。例如新創團隊「假設大家對Scrum都有相關經驗」，或者「假設在3個月後可以找到2個優秀的iOS開發人員」，或者「假設大部分的使用者都有fb的帳號」，或者「假設3個月內某個模組可以先行開發完成」。

在許多情況之下，很多事情的確有假設，才能進行下去。

但是，在建立團隊的時候，除了瞭解背景假設之外，先確認事實才重要。

以下事情必須要儘早確立。

(a) 團隊目標願景：

可參考下節「確切定義短期中期目標」。如果是非營利組織，團隊願景就非常重要。因為這可能是召集成立團隊的最大動力。一般企業，營利組織，除了獲利之外，也可能會伴隨其他更遠大的目的。例如：「讓人類可以移民火星」之類的(註2)。

一個有崇高理想的非營利團體，也就不應該將盈餘拿來作為績效獎金。而是以團隊能達到的願景作為激勵人心的最大方式。(例如Kiva)

相對的，如果只是單單純純想賺大錢的公司，例如某東南亞賭場在台灣的軟體部門。也就不需要唬爛一個崇高的偉大目的，就只要讓團隊了解「大家來歡喜寫程式賺錢吧」即可。因為有正確的認知，才能集合正確的團隊。一個誠實的宣稱「大家來寫程式賺錢吧」的團隊，自然不會將社會責任活動當作是團隊成員想要做的事(例如：到沙灘撿垃圾，協助獨居老人)，當然「培育企業人才」也不太需要，甚至Scrum裡面的「自己選取task來做」也根本不用，採用由上而下的軍隊式管理，讓工作以最有效率的方式完成，才是這種團隊的最好方式。


(b) 資源現況：

目前的現況是不可否認的事實，但許多人一開始的時候，會將現況和未來的希望混為一談。在此時此刻擁有的資源就是現況。

例如：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人。...這就是資源現況。

但也有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。...這也是資源現況。

更有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。而團隊目前總薪資預算為1千萬台幣，其中還得包含筆記型電腦採用費用。扣掉已經到職的兩個人，年預算只剩下600萬台幣，所以可以找10個人，但是平均年薪只能為60萬，或者找6個人，平均年薪為100萬。...這也是資源現況。

作為一個建立並組織團隊的人，資源現況的瞭解和掌握，必須要越清楚越細節越好。實際上，絕大部分的情況下，只要稍微多花個幾個小時，就可以掌握到很多現況細節。


(c) 組成專長：

即使已經是軟體開發的專家，這仍然是一件需要擔心的事情。

如果團隊的短中期目標確定，組合的專長可能大致確認。然而，某些專長不見得是「團隊成員需要有的」，這些專長可能可以用「短期購買」取得。

團隊領導者在取得事實的階段，需要清晰可見的專長分佈圖。

以上圖為例：簡單地列出做一個購物網站可能需要的專長，並且也把目前團隊已經擁有的人才能力列在其上。未來在組合團隊時候就比較容易考慮周詳。

要注意的是，這樣的圖並不是要完全技術上正確，而是要做為未來計畫的參考。因此有可能一再修改，也不見得需要用了不起的繪圖軟體製作。


(d) 關鍵成功因素：

哪件事情做好了，會讓這個團隊成功。成功關鍵因素應該只有1-3個，不應該太多。 這個關鍵成功因素必須要很「實際」，能夠被「衡量」，當然也必須要是能「達成」。至於困難不困難就不一定。以xspace的火箭設計為例，他的關鍵成功因素不只是火箭能發射，還要能「掉回地球後，能自己站立，以便低成本回收」。

軟體開發團隊的「建立組成」的通常是願景能否達成的關鍵成功因素。然而，建立組成的本身也有關鍵成功因素。例如，在2個月內吸引3個具有5年工作經驗，並且容易合作的工程師到職。



....其他需要搜集以及展現的事實還有不少。完整清單請參考(註3)。當然，不可能花幾百天的時間，只是為了收集事實，只要在合理的時間內，盡量收集了解重要的事實。

(2) 確切定義短期中期目標

前段所述的事實如果了解的夠完整。定義短期中期目標就很簡單。

短期目標是1週到4週內「必須」完成的事情。中期目標則必須要能夠「完成一項的關鍵成功因素」。

以建構軟體團隊而言，八九個短期目標完成後，差不多就等於一個中期目標完成。

任何軟體開發計畫，必定會有目標，而讓團隊朝向「同一個方向」前進。所謂團隊，當然是一群人往同一個方向前進，才能叫做團隊。一群在同一個組織架構的人，或者在同一個老闆底下工作的人，不見得是一個團隊，很有可能每個人在軟體開發

(3) 根據目標擬定計劃和備用計畫- Plan B

兵法有云「夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況無算乎！吾以此觀之，勝負見矣。」

計劃本身並不重要，但是做計畫這件事情很重要。

計劃要達到的目的要非常清楚。而且必須「至少」包含兩件事情！

*** 達到短中期目標的做法 
*** 實質建立工作環境與實際做法

建立軟體開發團隊的初始計畫至少需要涵蓋以下內容：

(a) 團隊目的，短中期目標

....請參考前兩段...

(b) 團隊組成

需要哪些專長的人在這個團隊。更重要的是，哪些技術背景的人的組成最適合這個團隊。最好的方式是將所需要的「實質技術能力」清楚地列個圖示，根據分佈圖，來劃分團隊組成。

切勿用想像的方式。

以上圖為例：這是一個打算建立電商網站的技術分布圖，和目前團隊成員(四個人)所擁有的技術連結。可以很清楚的看到哪些領域還沒有適當專長的人。也可以清楚地展示，團隊目前組成和未來最需要的地方。

這個草圖並非正確的描繪出細節，而且也把技術不相干的東西納入（例如裡面有個API doc，其實是還沒有去做的事情）。但整件事情的精神在於「視覺化」。透過視覺化，對團隊的變化才有整體性的考量和規劃，而不會落於枝節上。


(c) 團隊運作原則

近年來流行Agile的Scrum方式。可以參考這裡。


(d) 初始化工作項目

當團隊的成員是逐漸到職，最初的工作項目是能夠讓團隊快速形成共勢。這看似枝微末節，但是是隱含的關鍵成功因素。

初始化工作項目，在新成員到職的前幾天，最好是鉅細彌遺。規劃了新成員第一天到第五天，「每天」要做的事情和達成的結果。並規劃前4週，要達到的大項目，以及前3個月的必須要的貢獻程度。

團隊是由一個個單一個人組合起來。將個別成員的適應期縮得越短，對團隊的組成越有利。

規劃前五天的細目，絕對不會讓這個新成員變得沒有創意，也絕對不會扼殺他的潛能。反而是讓他可以在極短的時間之內，先擺脫掉和「智慧創意」無關的邊緣事項。因為這些邊緣事項，如果在前一段時間沒有擺脫，之後會一直出來煩大家。

以下是某個電商開發團隊的前三天初始化工作項目，同時也是檢閱清單：

Day-1  
    - Mentor介紹工作環境，取得電腦和其他硬體設備
    - Mentor協助取得email和其他必要的帳號
    - 取得目前程式碼版本控制系統權限，確定可以clone
    - 確定clone目前的程式庫

Day-2
    - 取得目前的UI/UX設計文件，Mentor協助了解文件內容
    - 參加Scrum會議，理解Scrum雞與豬的原則 
    - 在Mentor協助下，建立自己開發環境

Day-3
    - 在Mentor的協助下，在自己的開發環境確定能修改程式/簽入(commit)/建立branch，最後產生自己的build。
    - 了解基本的測試項目

以上僅是3天的範例，這些看似細節，但要在三天之內完成也不並容易。


(e) 定期檢討方式

檢討方式可以參考這裡和這裡。

簡而言之，建立團隊的過程也需要被檢討。

例如：

新加入的成員，在當初面試的時候所呈現的能力，和實際上工作的產出，是否吻合。

新的成員對於非技術類型的雜事，是不是很快能找到資訊。例如git的位置，目前各個branch的狀況，自動化建構的方式，建立開發環境的方式等等。

---

註1：如果這個挑戰對負責組織團隊的人來說太過困難，最好不要接受這樣的任務。一個失職的程式設計師頂多讓專案推遲幾天，或者品質降低一些；但是一個失職的領導者，會讓整件專案崩壞。


註2：例如xspace

註3：建立軟體開發團隊的事實搜集清單

(a) 團隊目標願景
(b) 資源現況
(c) 組成專長
(d) 關鍵成功因素
(e) 關鍵風險 - 一旦發生就可能會失敗
(f) 關鍵技術 - 是否有必須具備的關鍵技術，需不需要招募這樣的人才
(g) 利害關係人 - 哪些人跟這個團隊有實質的相關
(h) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等

Scrum - 團隊中永遠的反對黨

最近被問到的幾個問題：

   - 怎麼聚焦討論，譬如說有人很愛插話，或者有人很愛在會議室角落另開討論群，或者有人非常堅持己見，很愛先否決對方 ...

   - 有遇過非常固執的人，總是以否定句開頭去否定對方嗎 ？

   - 有人固執的反對什麼事情都反對

....


以Scrum/agile方法為核心的團隊有先天上的「平等」和「自發」的假設。Scrum假設人人都有某種能力，並且也假設，團隊成員對於「溝通」都有某種程度的共識和經驗。

然而，實際情況通常不太美好。

** 技術人員常常會因為麻煩，而反對業務上的決定
** 業務人員因為對技術不了解而作出自相矛盾的決定
** 開會時候常常岔開話題
** 因為不專心，很多人在開會時候搞不清楚情況
** 某些人常常提很多意見，而且實在太多意見！

任何由人組成的團隊，多少都有溝通問題。如果你是團隊領導者，或者Scrum Master，溝通問題一定是你必須要負責的問題！

Scrum溝通問題，就像處理bug一樣，最好的解決方式是「事先解決」。有三個基本共識必須要事先建立。

建立這三個基本共識，可以讓未來的溝通變得簡單清晰，減少不必要的誤會。

(1) 建立雞與豬的基本共識

專案管理中的「負責角色」有各種說法。RACI可能是近年最常見的。

** 負責人（R = Responsible），負責執行 
** 誰批准（A = Accountable），對任務負全責的角色，通常是負責人的老闆 
** 顧問（C = Consulted），提供意見或建議的人 
** 通知誰（I = Informed），被通知結果的人，例如其他部門的相關人等 

在Scrum專案中，可以被簡化成兩種人：雞和豬。(雞與豬的故事可以在網路上找到很多版本，例如這裡)


豬：負責做的人也是負全責的人

雞：所有其他人（當然必須是和這個專案有關的人）

在溝通時，所有雞都可以出意見，但是豬一定擁有真正決定權。畢竟是豬被切肉出來做火腿，雞只要下蛋而已。

就平等的軟體開發Scrum而言，任務是有自己選取。但是就實務上，專案管理者不但身兼Scrum Master可能還會身兼分配任務的角色。這時候，等於是分配「誰是豬」！

任何會議上，對「豬」的正面或負面意見都可以討論，但是最終決定必須要是「豬」。

例如，PM決定哪個功能要先做，而工程師都反對，原因是嫌未來會有其他麻煩的事情產生。然而，就決定功能的先後次序來說，「PM就是那隻豬」而其他所有人「都是雞」。

團隊必須要有清楚的認知，才不會有無謂的抱怨和繁瑣的溝通。而清楚的認知，是團隊領導者的任務。

 (2) 建立事實優先的基本共識

Scrum溝通，必須，而且只能，建立在事實上。

這也是為什麼每日例行會議只說明三件事情：哪些工作完成，接下來做哪些，遇到什麼問題。

假設有人在某討論會議中說「現在UI速度很慢，登入要等很久」。某種程度來說，可能是事實。但是，「慢」以及「等很久」，都只是形容詞，必須要請他提出何謂慢，什麼叫做等很久才能繼續有意義的討論。

或者，有人提出「如果先做A會讓之後變得很麻煩，應該要先做B」。這其實也是模糊的說法，A和B這兩個功能，如果先做A是會讓以後時程延後8小時？還是8天？還是8個月？這才是根據事實的討論。

然而，這種建立於事實的共識，Scrum Master必須要不厭其煩的提醒和導正，才能建立這種共識。

(3) 建立產出優先的基本共識

大部分的專案，都是需要產出某些東西。無論這個東西是軟體，或者硬體，或者某些解決方案。

在團隊討論中，要讓「為反對而反對」的人閉嘴的最佳方式，就是以「產出優先」而不是以「嘴巴講」優先。

例如，某工程師強烈反對A做法，希望改用B做法。最好的方式就是請這個工程師，作出他自己希望的A做法，用以和B做法比較。如果他說「沒空」或者是有「更重要的事情在做」，那表示他的強烈反對，也不是那麼強烈。

至於對於「只反對而不提出取代方案」的人，其意見大概也只是僅供參考。如果經過負責的豬判斷，其意見很好，當然可以欣然接受，加以改進（例如在code review的時候）。





如果尚未建立這三個共識。就已經發生溝通問題。團隊領導者或者Scrum Master仍然有彌補的方式。

不過，越早了解，並試圖解決溝通問題，通常成本越低。

那麼可能的解決方法有：

(1) 自己的問題？

如果你是一個領導5人以上的團隊領袖，無論你的名稱是Scrum Master還是專案經理，如果你認為團隊裡「大部分的人」都有溝通上的問題。

那麼真正有問題的人是你！！

但是也不要太緊張。這並不代表你是個無能的領導者。只是你的實際行為，讓團隊容易產生溝通問題。

問題的產生點可能是：

(a) 試圖面面俱到，顧及每個人的感受，而非先考慮事實。每個人都喜歡受人愛戴，但是在軟體開發團隊中，鄉愿和受人愛戴只有一線之隔。唯有根據事實，腳踏實地領導事情的進展，才是長久之道。為了顧全少數人的面子，或者僅為了顧及某一兩個老是抱怨東抱怨西的人的心情，對團隊從來都不會有好處，反而只會讓多數沉默工作者更難獲得信任


(b) 未掌握Scrum精神，只是掌握Scrum的作法。請參考這裡。

(c) 其他，請參考：作為技術領導者的方式。

(2) 解決老鼠屎

如果團隊之中，溝通問題老是產生於某個人。

除非此人是像高斯，愛因斯坦之類的天才中的天才，否則不應該容許有嚴重溝通問題的人存在於團隊。

這類型人有幾種表徵：

(a) 無論什麼事情都悲觀 
(b) 事情不分大小時常抱怨 
(c) 問題都是別人的錯  
(d) 常認為自己懷才不遇
(e) 不願意做某些無聊的雜物

其實，每個人或多或少都會抱怨，也會有悲觀的時候。此乃人之常情。但是如果非常嚴重，那麼這個人就會變成鍋子裡的老鼠屎。只要鍋裡面有一顆屎，即使被稀釋了幾萬倍，也不會有人想吃那鍋飯。團隊也是如此，一個負面老鼠屎，其影響範圍遠超過5個好隊友。

老鼠屎不見得就是錯的，他或許自己創業會變成一個好創業家。因此，及早讓不適合目前至個團隊生活的人離開對大家都有好處。

(3) 縮小範圍

當溝通問題發生，可以將重要的溝通，盡可能縮小範圍，讓溝通清楚簡單。

這聽起來是淺白無聊。但是，實際上在團隊之中，太多無聊的溝通錯誤發生，以致於這麼簡單的事情，仍然值得注意。

以Scrum而言：「DOD」什麼是完成，乃是基本的問題。即便團隊已經彼此合作過一段時間，仍然三不五時要確定一下什麼叫完成。

以溝通進度而言，必然將最近在做的事情，縮小其範圍到「最近的一個完成點」。 無法縮小表示根本不知道自己在做什麼。舉例來說，軟體開發中，如果有一個人的某A任務，需要20個工作天，那麼在3天的進度報告，絕對不能聽到「還有17天就完成」，而是要縮小範圍到：「下一個milestone會是明天，而預期也會如期完成」。因為，最近的一個檢查點(milestone) 如果不能如期完成，就代表未來的17天，很有可能也不會如期完成。反過來說，最近的一個milestone會完成，那麼未來就比較有可能如期完成。

縮小範圍也可以讓「雞和豬」的責任範圍展示的更清楚。

有個真實的案例：有個團隊舉辦慶功宴，由甲和乙兩位負責。甲很熱心的定好了餐廳，並且就「自認為剩下的事情乙會處理」，然而乙心理認為，既然甲定了餐廳，表示後續的小事情甲也會處理，畢竟許多事情和餐廳有關係。那麼到了慶功宴當天，當然除了餐廳定好之外，其他的雜物(例如當天如何報帳之類)一件都沒完成。

另一個真實的案例：有個軟體開發專案，大家都認為某甲的程式需要重構(refactorying)。但是，某甲認為他需要4周才能完成，因此遲遲不肯進行，大家也難以和某甲溝通。專案經理於是縮小範圍，先找某甲也認為很小規模的一個功能-原本預計一天-加以重構，透過pair-programming，確定某甲專注於這個任務上，最後只花了1小時。因為有這樣的證明，專案經理於是要求某甲先完成全部程式碼翻修，最後整體只花了2天就完成，雖然仍是麻煩事，但遠比某甲估計的4周來的快太多。其原因也很簡單，重構是繁瑣麻煩的事情，當然會被估計成很長的時間。

Scrum - 檢討完了...然後呢？

定時檢視目前的進度與問題，是所有專案管理都會做的事情。Scrum方法會在每個Sprint之後，舉行檢討會議(驗屍會議)，找到在過去一段時間最需要改善的事項。

請參考前篇：Scrum - 回顧。檢討？驗屍！

假設團隊依照正確的Scrum的事實認定原則，踏實的列出問題。接下來就應該「解決」它。誠如前篇，所有的問題必須要有歸屬「某人」。某些事情是「很多人」或者「不知道什麼人」，這種情況的歸屬就屬於Scrum Master。

稍微強調一下，只要Scrum Master稍微不注意，就會讓歸屬人這件事情變成互相指責，試圖鞭屍，對人不對事的謾罵。但是，如果不試圖歸屬某人，就常會讓問題懸空，無法真正解決。

只要確切的定義真正的問題，就等於是產生了一半的解決方法。

不過有些常見老問題，還是值得探索一下。

例如：

(1) PM/PO 常常在Sprint中間要求修改規格，甚至新增額外的項目...

(2) 某個人的產出和績效，明顯的比其他人差很多...

(3) 某個功能的實際時程遠超過預估，以至於某些團隊成員需要很大幅度的加班...

而常見問題都有其共通性，常見的試圖解決方法也有共通性。然而，以Scrum而言，Scrum Master在此扮演非常重要的角色，因為所有的問題，其有效解決方式，應該都和Scrum Master本身有關。

Scrum Master必須要掌握以下原則：

原則一：試圖做到完美是不可能

    完美的team不可能存在，每次sprint應該試圖解決最重要的幾個問題就好。

原則二：持續做同樣的事情，不可能產生一樣的結果

    參考愛因斯坦的名言：Insanity: doing the same thing over and over again and expecting different results.

原則三：任何創意方式都應該嘗試：包括「無作為」

    
    當定義好問題之後，下一個sprint應該要試圖改善問題。但是，改善問題的本身有時候需要「時間」，而由於Scrum每個sprint都只有4週，Scrum Master應該要將「無作為」當作某些問題的處理選項。畢竟，有時候過度反應某個未來可能不存在的問題，也沒太大意義。

但是也請謹慎區分「無作為」和「逃避」，這兩者只有一線之隔(註1)。
    

針對身為Scrum Master的人，在此提供一些解決問題的範例：

(1) 時間相關的問題

由於時間是軟體專案衡量進度的唯一單位。時間是最初，也是最後要考慮的事情。因此許多檢討事項都和「時間」有莫大關係。

--- 在Sprint中某些時間估計錯誤，導致加班 ---

這在專案前幾的sprint特別常發生。建議解決方式有：

(a) 探詢真正的需求點和重要的事情，移除根本不重要的工作事項

(b) 減低時間浪費，特別是大型專案中開會的時間

(c) 無作為：因為團隊已經了解問題，而且下個sprint估算也應該會比較正確，加班問題很可能自然消失。

(d) 厲行「最大時間」單位，假設是1天。換言之，工作項目超過1天，就需要分拆成不同的項目，或者不同的完成階段。這樣可以在比較短的時間內，很快發覺時間錯估的規模。


絕對不建議解決的方式是：讓某些人繼續加班；犧牲品質；謊報進度...

--- 某個人的事情老是做不完 ---

這個也很常發生。如果是該員能力無法趕上團隊。似乎是個很大的問題。然而，絕大部分的團隊都應該利用分工導致的比較利益法則（參考這篇），根據相對優勢來分工。

細節請參見下一節：(2)人才和人力的問題


建議解決方式有：

(a) 先確定他不是不想做。假設有個不想在這個團隊努力的人，無論再怎麼調整，也都沒有意義。應該用最快的方式讓他好好離開。

(b) 讓他做可以用時間苦勞換取績效的工作，而非需要能力才拿達成的工作 ，例如將其人力保留用於意外任務或者PM臨時修改需求 

(c) 找到他的相對優勢，換言之，Scrum Master要略為調整scrum的精神，改以指派的方式指定工作。但這點需要觀察並且徹底了解他的優勢才有辦法執行。

--- 團隊有意外任務 ---

這個問題也很常見，可能的解決方式有

(a) 無作為：經過一番思考，發現這只是意外，下個sprint應該不會發生

(b) 根據前sprint所耗在意外任務的時間，重新估計下個Sprint意外任務要花的時間

(c)  設定意外任務防火牆：可以找一個專門的人，處理所有意外任務。不得已的時候也可以找工讀生，委外人員等等。

(2) 人才與人力的問題

許多軟體開發的相關研究，都一再顯示，一個好的設計師和普通的程式設計師的績效相差很大。某些1980-1990之間的研究認為可能差距10倍，當然這個10倍厲害的程式設計師的爭論很多(註2)。但就一般的情況來說，超過5個人的團隊，就自然而言有人能力以及產出比較好，而有可能有某人能力和產出都比較差。

一個團隊裡，人力和人才必須要平衡，並且由Scrum Master在前幾個sprint的結果瞭解哪些是人力，哪些是人才。人力和人才的衡量標準在於「產出」而不在於「個人能力」。換言之，即便大家都認為他能力很好，但是某些原因，他的產出只有一般般，那麼他就不是人才，而是人力。

但是，無論是人才還是人力，團隊的組合的先決條件就是1+1>2，團隊合作可以讓整個團隊獲利。Scrum Master在發現團隊有某些人的績效和產出問題時，應該優先考慮分配工作上的比較利益法則。（台灣經濟學的入門書通常會用蓋木屋與磚屋的例子：參見這裡）

要注意的是，過於追求表面上的公平，但是反而會團隊績效的降低。公平雖然重要，但是團隊合作產生的獲利更為重要。Scrum Master要能讓團隊追求團隊目標，而非追求個人公平。其方法有：

(a) 讓團隊成員看這篇文章

(b) 不要設定表面的績效衡量標準(例如：bug數量) 而是設定每個人不同的標準

(c) 所有不同的標準，朝向同一個目標。例如，在籃球比賽中，得分籃板助攻失誤阻攻...等等都是指標，而所有指標必須都要朝向球隊勝利才有意義。而不應該對每個球員設定同樣的目標。

(3) 目標的問題

目標指的是現在要做什麼，現在什麼事最重要，要達到什麼效果...簡單的說，每個專案都有其最終目標，但是在專案開發過程中，都有中間目標，PM/PO理論上應該會透過各類型中間的目標，達到（也有可能會修正）最後的目標。

然而，Scrum為了讓開發人員專注於工作，在一段短時間的Sprint是不允許修改目標。因此，如果遇到PM中間亂入，常常會造成團隊困擾。

但其實更為重要的是，如果團隊方向具有很大的不確定性，Scrum Master應該視其為「機會」，而非「威脅」。因為Scrum的天生優勢就是在於處理不確定性。

--- PM客戶或其他長官常常突然要求修改做的一半的規格---

(a) 無作為：因為這可能是專案開始的意外插曲，Scrum Master很確定下個sprint不會發生

(b) Scrum Master作為擋箭牌。在Sprint中間過程，用盡一切手腕，擋住所有需求修改，直到sprint結束為止。但是，允許PM重新開始一個sprint。

(c) 找個專門窗口作為擋箭牌。指定一個專門「被聯繫」的擋箭牌，將擋下需求，或者臨時修改需求這件事情是為他的工作項目。但是他所完成的程式碼，放在另一個branch(分支中)，每個sprint結束之後，才檢討他的branch是否要合併。這個做法的依據在於，通常會修改的規格，都會被一改再改，與其影響團隊作業，不如將影響範圍降到最低。

--- Sprint產出PM不喜歡或不要了 那我們不是白做 ---

這樣的抱怨也很常見，它不是問題，而是Scrum天生所展示的優勢。Scrum Master只要解釋幾點Scrum基本概念即可：

(a) 我們頂多白做4個禮拜，如果是project結束才發現這件事情？那浪費的成本是高得嚇人。

(b) 如果是PM不喜歡，那麼起碼我們會了解什麼地方他不喜歡。如果他「不要了」表示這是PM在產品需求判斷上的錯誤，在檢討會議應該要求PM改善此項目。



如果有其他常見問題在這裡沒有獲得解答？也請用email與我們聯繫 support@talent-service.com。我們會持續修改這篇文章。

---

註1：許多事情好與壞都只有一抹微妙的界線。除了「無作為」和「逃避」之外，還有「足夠自信」vs 「自我感覺良好」；「自卑」vs「謙虛」...

註2：請參見這裡

註3：如果有其他常見問題在這裡沒有獲得解答？也請用email與我們聯繫 support@talent-service.com

Scrum - 回顧。檢討？驗屍！

在Scrum方法中，每個Sprint結束要做事情是(1)實際交付產出 (2) 回顧檢討這個Sprint (3) 決定下個Sprint的開始。

其中，回顧檢討這個Sprint的做法，通常是一個2-4小時的Retrospective Meeting(回顧會議)，再加上改善動作。


實務上，回顧檢討是sprint最難做得好的項目。


困難因素在於，人類有天生的認知謬誤。回顧檢討會議既然是人來召開，人來組成，當然很難確切找到此Sprint的需要改善的問題，並對症下藥。偏偏，絕大多數專案Sprint問題和人有關。

說得更直白的：

    - 所有專案團隊的主要關鍵問題，都跟人有絕對的關係。每個sprint檢討會議不去檢討「人」，就等於是兇殺案發生而不去驗屍一樣。

    - 所有未來改善項目，其改善效果和速度，也都和人有絕對關係。

Scrum基本作法

在大部分的Scrum教學材料中(註1)，都很輕而易舉地說，團隊要在回顧檢討會議說，瞭解並討論三個項目：

(a) 這個sprint哪些地方團隊做得很好

(b) 這個sprint哪些地方團隊做得不好

(c) 下個sprint 團隊要做哪些事情使其變得更好



許多Scrum教學中，回顧會議都用一些簡單的方式：例如每個人提出3個意見，然後由Scrum Master逐一唸出，並且分類意見，接下來針對分過類型的意見投票，投完票之後再指定人選負責在下一個Sprint中改善。這個方式當然可以消除不少偏見和謬誤，但是容易忽略了「改善是需要針對人的行為而非針對事情」。


舉個某回顧會議中，團隊認為最需要改善的問題：

* 需求在sprint開始時還沒確定

這是個極為常見的sprint回顧問題，也通常是軟體團隊的困難。Scrum方法雖然試圖避免這個困難，但是還是非常容易在回顧會議中被提出來。筆者常看到會議記錄中，天真且單純的紀錄這一條問題....然後？也只是記錄而已。


這個紀錄有什麼問題？  ....有很大的問題！


大部分團隊，剛組成的時候，其Sprint檢討會議中，會不自由主的「避免」提出直接針對「某些人」的能力，做法，產出的問題。團隊會因為想要「努力團結」而避免針對人的討論。然而，除了超短期專案外，所有軟體專案，幾乎不可能「沒有人的問題」。反過來說，解決重要的人的問題，專案就會執行得更好。

回顧檢討要注重「人的問題」，並非單指某個人的能力不夠，也非某些人難以溝通。而是要透過實際的事物，探究人的行為造成的問題，而非問題的本身。「需求在sprint開始時還沒確定」是個血淋淋的事實。

但是，回顧檢討的重點在於，過去4周內，到底團隊成員知道是「誰做了什麼，或者沒做了什麼造成這個事實」，這才是重點。

正確的回顧檢討事實，可以是：


* 需求在sprint開始時還沒確定，因為Scrum Master沒有邀請Product Owner參加kick-off會議。

也可以是：

*  需求在sprint開始時還沒確定，因為Product Owner在kick-off會議沒講清楚，而團隊當時卻認為自己清楚需求，直到開始做了才發現不清楚，偏偏Product Owner之後就不參加每日例行會議。

也可以是：

*  需求在sprint開始時還沒確定，因為Product Owner在專案中間需求有改變，但是Scrum Master並未注意到大幅變更。

無論哪種回顧，都需要有「人」，「當時做的事情或這沒做的事情」，「產生的結果或沒產生的結果」。這樣的回顧檢討才會有意義。

但是，Scrum的方法論，看起來都是對事不對人。要如何在不交互指責的憤怒會議中，做到針對人的檢討，並能在下個Sprint還能持續團結合作？

如果你是專案經理或者Scrum Master，有三個基本的關鍵作法可供參考。(1) 先個人，再團隊。只內部，無外部。(2)  沒有問題，是最可怕的問題 。(3)實際事實，實際行為優先。

(1) 先個人，再團隊。只內部，無外部。

在會議開始之前幾天，先通知大家，回顧檢討會議的重點：先檢討自己，再檢討團隊，只檢討團隊內，不檢討團隊外。

(a) 先檢討自己的「行為」，再檢討團隊的「行為」。

並非要檢討個人的價值觀。例如，是不是很認真，很願意和其他人溝通...等等。而是自己先看自己過去做的「行為事實」，有什麼可以改善的地方。

例如：完成某功能程式碼之後，沒有先執行整合測試，就在某天每日會議報告已經完成，隔天發現，該功能有很多問題，還得修正進度，並且讓測試人員額外進行rollback。

另一個例子：這次sprint開始的時候，Scrum Master沒有堅持要Product Owner確定所有要完成的項目的需求，就讓Sprint展開。使得Sprint需要額外需求確認時間。

檢討團隊的行為，也和個人一樣。稍微不一樣的是，團隊行為通常是「個人行為」的組合。換言之，以「沒有人」為開頭的陳述就是團隊行為。Scrum Master或者專案經理，或者實際決定事情的主管，要特別注意，絕大部分的「沒有人」開頭的陳述，就要當作「自己」！

例如：沒有人發現在第二週自動測試的伺服器當機，連續好幾天的測試報告都沒有自動email出來，以至於團隊錯失及早修復bug的時間。

另一個例：沒有人提醒Product Owner開會的時間。

(b) 只檢討團隊內，不檢討團隊外

Scrum對於團隊有很嚴格的定義：做事情的人+Scrum Master = 團隊成員。

回顧檢討會議，必須要檢討內部，而不是檢討外部。許多檢討會議看似檢討內部，但其實是在檢討外部。

例如：加強和UX/UI部門溝通

這通常隱含對方不好溝通，我們只好努力跟他溝通。

又例如：公司有臨時交辦事項，團隊得分心處理

這隱含是更高階主管來的非專案任務，需要打斷專案時間。

這兩個例子並非不要改善。而是檢討回顧方式，會大幅「限制」或影響改善方式。與其他部門溝通問題，應該是具體列出過去4週，那些確切事情「被誤解」或者「理解錯誤」。根據實際的錯誤，來改變團隊對應的方法。

以UX/UI而言，釐清理解錯誤，可以用「雙方討論事情的時候，一定要至少要有mock-up」。

而以公司有臨時交辦事項為例。應該是「每個sprint預設的工作時間原本是160小時，下個sprint改為145小時，因為上個sprint臨時交辦非專案任務大約15小時」。這樣是以具體的事實，解決公司有臨時交辦事情的問題。

重點是：解決問題必須在「團隊內部能做的行為」，而非「希望團隊外去做的事情」。

會不會有回顧檢討的問題是「團隊內部解決不了」的事情？的確有可能，但是機率很低。團隊解決不了的事情，早就在sprint kick-off (開始會議)被隱含排除，所有團隊「認知到」的專案問題，幾乎都是團隊內部有方式解決或減少影響的。

(2) 沒有問題，是最可怕的問題。

有為數不少的專案團隊，在回顧檢討會議時，因為很多因素，無話可說。只好拿一些雞毛蒜皮的小事，或者看似重要但是不太重要的事情敷衍一下。

例如：

* 每週固定的下午茶太不健康，看能不能換健康一點的。
* 我們的螢幕太小，寫code很不方便。
* 每天站著會議好累，可不可以坐著
* 能不能有免費可樂
* 昨天code view有說code style要統一但是還沒有
* 我們可以固定一段時間來分享一下大家coding的心得

如果檢討會議的重要事項，全都是這類型的，那有三種可能(註3)：

(A) 團隊有如NBA夢幻一隊素質極高，工作合作超級愉快，成果驚人。

(B) 團隊失去對專案的信心和動力，或根本不相信Scrum Master。

(C) 團隊絕大部分的成員經歷太淺，不知如何開始檢討。



--- (A) ---

如果你認為你現在的團隊是A，大概有49.99%的機會你是在欺騙別人。另外有49.99%的機會是你自己騙自己，或被別人騙。


--- (B) ---

如果你認為你所處的團隊是B，而你恰好是Scrum Master，或者是專案經理，或者任何領導階層。那你最最需要做的事情是「檢討改善自己」，而非「檢討改善別人」。一個團隊，大部分的人不願意說真話，最有可能有問題的一定是管理階層。

如果你認為你所處的團隊是B，而你非管理階層，也非Scrum Master。你可以先審視自己專案對社會的重要性。如果你是在核電廠，或者急診室，那你應該盡自己一切的可能，不計代價，不眠不休地改善現況。

然而，如果只是一般的軟體專案，建議你先就自己可以改善的地方檢討自己。確定當你看到不正確的事情時，會先審視自己的能力與做法。但也不需要強出頭，把自己當作革命烈士。畢竟，大部分的軟體專案並不是那麼重要。


--- (C) ---

這種情況似乎也常發生，但是解決方法很簡單。

首先Scrum Master應該在第一時間對於「雞毛蒜皮小事」，做立刻回應。對於每個小事的回應都是：下次不用等到sprint結束，中間任何時候都可以馬上找我講。這樣才會讓團隊成員養成自動自發，並容易判斷哪些事情很不重要。

例如：

* 每週固定的下午茶太不健康，看能不能換健康一點的

...可以，馬上就換。以後一遇到這種問題，不用等到sprint結束，任何時候馬上跟我說或者寫信給我。

* 每天站著會議好累，可不可以坐著

...不行，因為站立會議的目的就是要讓你累。以後想到這類型問題，不用等到sprint結束，任何時候馬上跟我反應。

* 能不能有免費可樂

...可以，你馬上去買，發票給我。以後一遇到這種問題，不用等到sprint結束，任何時候馬上跟我說或者寫信給我。

* 我們可以固定一段時間來分享一下大家coding的心得

...可以，你馬上去發固定會議通知時間。以後一遇到技術分享的事情，只要不影響sprint時間，任何時候就直接去做，不用等到sprint結束。

(3) 實際事實，實際行為優先

Scrum的精神在實況與事實，而檢討的實況和事實在於「行為」而不在於「想法」或者「內心深處的感覺」或者「價值觀」。

這個概念非常重要。缺乏了這個概念，就容易讓檢討回顧會議，變成「互相責怪」會議。

然而，執行也很重要，執行不當，也會讓回顧檢討會議變成「互相責怪」會議。

首先會議一開始Scrum Master一定要強調，接下來的會議以事實優先，而事實當然是根據某人做的事情。在團隊成員互相不熟悉的情況下，要「反覆」的重述事實優先。並且在討論時，嚴守只看事實的承諾。

會議的形式此時就不太重要，不過：點名發表意見是個簡單的好方法。當然Scrum Master應該要自我拋磚引玉一下。

以下舉幾個常見例子：

成員J說：PM常常來叫我們改東改西，為什麼之前不確定好需求。

這時候Scrum Master應該列出這個sprint完成的task。追尋到底哪些task的需求被改變，大約影響了多少工作小時。
當然成員可能會說他不記得，就請他大致猜測一下。然後再跟sprint的時間做比對。如果改動所花時間很少，那其實不是問題。如果改動時間比率很高，才是值得關注的問題。值不值得處理，要看比率原則。-- (註4)

成員A說：我覺得我的task太多，都做不完。

這時候Scrum Master應該立刻請成員A把過去一個sprint做完的Task列出，看看是不是有做完，並且完成這些task是否有加班，或者，其實他的task是由別人完成，但是每日站立會議中並沒有說明？總之，現場應該了解事實，而事實也一定能被了解，不能等到「之後」。因為每個Sprint只檢討這個sprint，也就是過去4周左右，不可能需要很長的時間了解事實，也不可能有「我現在忘了要回去找一下」

成員K說：負責前端的人的bug太多，有時候負責後端的人都得幫忙修復bug。

這時候，Scrum Master應該立即根據bug清單，看看前端的bug數量，和負責解決bug的人。假設前端bug數量在過去sprint中有100個，而99個bug是由前端的人解決，有1個是後端的人幫忙解決，而且也只花了1小時。那麼這個問題根本不成立。只是因為後端開發伺服器的人，會特別記得「例外事件」就會有別人bug多太多害我多花時間的印象。這事情比例上多寡，是不是值得處理就要看「實際情況」列出判斷。一旦列出來給團隊成員看，就很容易大家一起判斷。

成員F：我coding速度是沒很快，但是有些速度更慢的人，就完成比較少的task，好像不太公平。

這時候Scrum Master應該根據git或其他版本控制系統，列出團隊成員程式碼數量。配合完成的task數量，bug產生數量(表示code品質不好) 以及bug解決數量(表示解決的問題)大約比對一下，看看團隊的產出是否「差不多」。當然，不同的作業系統，不同的平台，不同的程式語言是不能這樣比較。

不過大部分的情況下，這個問題並不會被提出來。但是，這個問題會存在在壓力比較大的團隊成員中，並且有礙於團隊成長。因此，Scrum Master自己必須要有客觀的衡量產出的方式！即便沒有人提出這個問題。

成員L：我們對所使用的open source工具不太了解，導致於需要學習的時間。

由於這個問題很具體，Scrum Master只需要確定這件事情是否還存在。下個sprint還會不會有不熟悉的工具需要使用。

後續？

 Retrospective檢討回顧會議中，如果找到重要的事項應該要改善。當然就是Scrum Master或者管理階層需要去「執行改善」的時候。前述內容都只有「找到問題」而關於如何有創意的解決問題，還請參閱後續文章。

---

註1：網路上參考資料非常多，例如：這裡，這裡 或者 這裡

註2：專案驗屍(postmortem)在許多人心中另有其定義，可以參考這裡，或這裡

註3：就只有這三種而已啊？確實有可能有別種，但是不太需要討論。例如：在某些軟體專案團隊的前幾個sprint，因為「蜜月期效應」的確真沒有大問題。也有很多軟體專案，本身的目標比較特殊：例如學校的畢業專案，或者政府國科會案，雖然要交付結果，但結果的本身根本不重要，當然也不有大問題。也有某些專案，並不適合採用單純的Scrum，所以無法使用檢討會議針對人進行檢討。

註4：Sprint的中途按照Scrum的精神本來就不能由PM/Owner隨意修改需求規格。但是，在這裡是Sprint的結束。如果Sprint中途真的發生臨時修改的事情，Sprint的結束當然要作為「事實」加以檢討。要注意的是，目的是檢討事實，而不是簡簡單單的說PM/Owner沒遵守「Scrum的規定」。Agile的精神中，團隊的溝通跟改善，遠比「規定」來的重要。由於軟體專案太常出現這類問題，所以後續文章也會有針對這種問題的建議解決方式。

Scrum - 專案壓力來自於無法掌握的命運

一個壓力實驗：

有兩個籠子(A,B)，都連結同一個電極器，各有一隻老鼠。A籠子中，有一個燈號和按鈕，當燈號亮起時，如果在數秒內，A老鼠沒有按下按鈕，則就會產生高壓電極，讓A,B兩籠的老鼠都被電的很不舒服。不過，如果燈光亮了，在時間內A老鼠按下按鈕，則A,B兩籠就都沒事。B籠的老鼠則是全然被動的，只要A老鼠能做好他的工作，B老鼠就沒事。當然，經過幾次電極之後，A老鼠很快就學會了一旦看到燈亮，就應該儘速去按按鈕。

過一段時間之後，哪一隻老鼠的壓力大？

經過健康檢查，A老鼠幾乎看不到壓力大的特徵。而B老鼠，則出現各種癥狀：高血壓，胃潰瘍，成長障礙等等不一而足。

(以上內容取自:數位痴呆症：作者Manfred Spitzer)


軟體專案的壓力和該實驗有異曲同工之妙。真正的壓力來源不在於事情有多難，而是在於自己「全然」隨著命運擺佈，無法控制。以A老鼠的情況來說，他仍然是被關著，而還得三不五時瞄一下燈是不是有亮，一旦亮了就得趕快反應。

然而，「至少有一件事情」A老鼠可以控制：他可以決定自己要不要被電極。B老鼠則是沒有一件事情是自己可以決定。因而壓力無從擺脫。

Scrum(實況)是根據事實，固定的時間，以及有效團隊分工來達到敏捷開發的精神。而在此基本精神內，每一個角色都有「至少可以全然控制」的事情，不但可以正確減低無法掌握命運的壓力，更能組合出正確的團隊合作方式。

Product Owner（產品擁有者或產品經理）

在傳統的「瀑布開發模式」，或者，系統整合商SI的「隨意無止盡需求模式」中，產品經理會就所有應該要做的事情列一個驚人的功能清單，交由專案經理負責領導開發。接下來的18個月，產品經理就在B老鼠的壓力下度過，即便有檢查，也不知道產品真正的進度。而18個月後發現意外的機率...已經不是機率而是必然。

而過於認真擔憂的產品經理，更有可能在每一段時間，修改需求，讓開發團隊變成B老鼠，不確定哪個需求改變的命運降臨。

在Scrum中的產品擁有者(Product Owner)擁有非常簡單而清晰的責任，這個責任用非常簡單而清晰的方式減低他的壓力：「撰寫並排序需要完成的使用者情境」。

專案開始時，產品經理會撰寫數個使用者情境(user story)並且排定優先順序，而每個sprint開始時，團隊會告知這個sprint(4周)會完成到第幾個story。產品經理等候4周之後，檢查這些當初答應的story是否有如預期完成，並且在下個sprint開始時，或確定，或重新排列，或增加，或減少接下來要完成story的優先順序。

產品經理仍然不會去「做東西」。然而他確實全然掌握階段性完成，並且確定每sprint開頭都能選他最想要的事情先做完。因此，產品經理確實能掌握這個產品每一段時間的「樣貌」，而不是在最後關頭才求神拜佛，或者要求加班。甚至，在sprint的中間階段，若有必要，產品經理可以要求sprint停止，重新開始新sprint，用來調整後來才發現不正確的優先順序(priority)

Scrum Master (開發領導者)

過去一個團隊的技術領導者，帶領團隊解決技術困難並協調各類工作。他常常會是夾在產品經理（或客戶）以及開發成員中的角色。

在傳統模式下，他若非變成一個技術獨裁者，用以壓迫成員前進並反抗大幅需求改變，就是變成試圖面面俱到的好好先生，用以彌平不同角色的紛爭。「能良好溝通」這個字眼會常出現這個角色的工作描述(job description)，但事實上，困難的專案，不會因為一個很能講話的專案經理，就變得簡單。最後最常出現的結果是：專案經理總是能有效呈現「自己的貢獻和功能」，但無法反應在專案成功。換言之，常常看到自己從來不失敗的專案經理，曾經領導了很多壓根不成功的專案。

Scrum Master並非傳統的專案經理，其責任和角色也有很大的不同。而他能有效掌握的事情，也能讓他減少原本專案經理的壓力。

Scrum Master 掌握「會議」。他可以確保每日會議只「說明三件事」：完成了哪些事情，接下來要做什麼，有遇到什麼困難。確保每個sprint開始的會議，領導團隊能完成哪些使用者情境(user story)，並且確定這幾個要完成的事情，產品經理都有完整而合理的描述。他雖然沒有掌握全部18個月會完成的事情，但是透過掌握每一個sprint，腳踏實地的一個一個完成優先要完成的事項。

Scrum Master 掌握「真實進度」。透過領導決議「和未完成」以及以事實展現的燃盡圖，Scrum Master掌握過去真實進度。因而可以有效推測未來進度，並有足夠的證據顯示給產品擁有者。因此，才能有足夠的「動作權力」成為A老鼠：仍然在籠中，但掌握部分真實權力，以減少壓力。

Member (團隊成員)

傳統模式下，團隊成員經常是壓力末端。所有的壓力最後承受的出口。所有過勞死最可能發生的地方。傳統上最常出現的是：「某功能我們在要X月X日之前出來！」「現在馬上改做XX不然沒辦法驗收」。

而傳統的產品經理和專案經理 - 無論是軟性還是強硬 - 通常不得已的把壓力直接轉嫁給團隊成員。

但是，在Scrum中團隊成員，決定使用者情境：「真正完成的所需要的時間」。而這個權力，僅代表一個事實：由做事情的人傳達做事情的時間與結果。成員不再在決定什麼事情先做後做，只要決定現在在做的事情，什麼時候可以完成，以及「真的去做他」。換言之，Scrum團隊真正的A老鼠，其實只有團隊成員，只有他才會真正的按下按鈕。然而，如果Scrum團隊不能掌握分工負責的精神，團隊成員很快就變成B老鼠：不是被無謂的壓力掌握自己的命運，就是試圖跳脫牢籠。

Scrum 認證!? 不要再浪費你的錢了!

管理類型的證照無用論，早在軟體工程界提倡Agile Movement的時候就逐漸存在。

以目前看起來取得成本最高的PMP在資訊科技的評價為例：比較客氣的說法像是這篇：雇用有PMP的專案經理需要更進一步了解其能力。而比較不客氣的說法會像是幾篇：PMP毀了專案管理，或者PMP證照無用。(註1)

而這幾年Scrum的方法論，因確切執行之後確實對軟體產品開發有顯著效益。隨之就有各類型推廣，教育，甚至認證產生。

然而，花大錢考Scrum真的有意義嗎？

(1) 認證市場

技術專業認證，絕對有其必要性，例如：醫生執照，律師執照，CCNA，SCJP，TOEIC，甚至，職業大貨車駕照，乙級中廚檢定...等等。擁有此技術執照，表示你至少「會」做某些事。

然而，非技術執照，只證實「考過」某些考試，一旦考試內容和實際會到的問題有差距，該執照就沒有太大意義。只能代表你對某些考試的努力成果。專案管理，企業經營方面的執照就屬於這類。這類型執照如果成本不是太高，倒也無妨。高收費的認證？等於是浪費錢。

一旦有高收費的認證，自然就會有認證教育訓練市場。教育訓練本身是好事情，可以讓人學習成長，但是，教育訓練本身如果是應付考試，意義就降的很低。

(2) Scrum高收費認證為何沒用？

迄今，Scrum認證有很多種類，單就Scrum Master而言，網路上隨便找，都可以找到以下七種，請參見下表。

證照名稱	考取成本 (以台幣計算)	組織
Certified Scrum Master	$30,000 (含16小時訓練課程)	Scrum Alliance
Professional Scrum Master I   Professional Scrum Master II	$4,500 $7,500	Scrum.Org
Expert Scrum Master	$3,000	EuropeanScrum
Certified Scrum Master	$3,800 (不含訓練課程) $4,500 (含8小時訓練課程)	GAQM
Scrum Master Certification	$13,500	ScrumStudy
Agile Scrum Master	$5,880	EXIN
Scrum Master Accredited Certification	$900	Scrum-Institute

筆者考過並取得最貴的認證以及最便宜的認證。其價格差距很大(三萬台幣 vs 九百台幣)。單就「考試內容」而言，最便宜的考試內容甚至還稍微難一點點。而最貴的CSM (ScrumAlliance)其實也就是台灣各教育機構最努力推廣的認證。

就考取認證作為職場價值這點來說：

1. 如果是沒有任何軟體專案經驗者，透過高收費教育訓練考取最貴的收費認證，基本上，和只自學而通過最便宜的認證，在Scrum基礎知識上根本沒差別。而在Scrum實務運作上，也沒差別：都屬於完全沒經驗。

2. 如果是有數年軟體專案經驗者，「有無證照」對於專案管理來說，只是履歷表上的一撇，一旦遇到真正的艱難問題：在Scrum上採取正確作法的經驗和收獲，遠比考證照的收穫大得多。因此，昂貴證照和便宜證照也無任何差異。

3. 沒有駕照，就不能合法開車。但沒有Scrum證照，在務實的企業中，只要你有足夠實務經驗，足夠證明支持你的能力，根本沒有問題。反之，如果有Scrum證照，但無法足以匹配的經驗，能力，而再加上創意不足，那麼甚至是有害無用。

(3) 建議作法

如果有想考Scrum相關證照，有三個強烈的建議：1.「自我學習Scrum」2.「確切運用Scrum」3.「考最便宜的」

1. 自我學習Scrum：

學無止盡，無論是Scrum還是其他未來可以出現的方法論，都值得一學。但更重要的是，如何自己學習。任何教育訓練都很有用，但也不可能完全取代自我學習。

自我學習的方式可參考這裡：如何學習Scrum 。以及這裡：如何成為Scrum專家，或者：scrum的缺點，或者 ：Scrum三件必要的事。

2. 確切運用Scrum觀念與作法在軟體專案中：

任何專案管理上的知識技能，如果不能有效運用在專案管理上，當然就沒有意義。以Scrum的每日會議(無論是不是站著開會)來說，其基本觀念在於：

「限時」 - 15分鐘
「事實」 - 只描述做完的項目，和下次打算做完的項目。(註2)
「困難」 - 只說明困難，不是要在每日會議上解決困難。

也許現實會讓Scrum Master或專案經理有所調整，但如果調整的方式不能切中Scrum觀念，則取得昂貴Scrum證照也沒有任何意義。(例如每日會議花超過40分鐘，肯定不符合任何一種Agile專案方式)

3. 以實力考最便宜的證照：

不可否認，還是有不少人認為一旦履歷表上有幾個証照，似乎會多一點點面試機會。另外，也有些有專案管理經驗者，自我學習Scrum想要有個目標來證實自己。

以這樣的立場，其實考取最便宜的證照即可。而最好是在沒有任何準備的情況下，抱著隨便考的心態。如果這樣考過了，表示Scrum的基本知識已經深入腦海中，考不過其投入成本也不高。

剛出社會的新鮮人，如果覺得萬一在面試時，有人對便宜的證照有疑慮？你可以客氣的敦請他去考考看，了解一下其考試的品質。

---

註1: 我們不是反對PMP。事實上，在其他工程領域PMP有其必要性。例如：cern的LHC是一個橫跨數十個國家，涵蓋土木，電機，資訊的龐大工程，PMP條列的九大項目，五十多種可能的文件在此就有點必要性。本文反對的是，以PMP(或其他管理證照)來判斷一個專案經理有沒有能力執行資訊軟體相關專案。

註2: 何謂做完？(definition of done)也是Scrum team需要在專案開始前定義好的。

註3: coursera.org 提供各種課程修業完成認證，目前沒有ScrumMaster，但是有類似Agile Management的課程，上課是免費，不過，取得認證約為3000~5000台幣之間。

如何學習Scrum

如何學習Scrum?

端看學習Scrum的真正目的，有三種方式可供參考：(1) 網路資源 (2) 收費課程 (3) 實際經驗

(1) 網路資源

很簡單，費用幾乎為零。

下載這兩個pdf，接下來，先不要上網查專有名詞，也暫先不要查字典，好好的先花時間看完。

* Scrum-institute 的 training pdf。
* m-plaza 的 Scrum Guide pdf。

然後，隨意上網找一些相關資料閱讀佐證即可。也可以自己做個類似這樣的簡單學習計畫。

不確定自己有沒有學會？可以考慮花29美金考一下證照看看，請參考Scrum證照這篇。

假如是剛畢業的大學碩士學生，英文閱讀沒有太大障礙的話，大概8-16小時應該可以完成。

(2) 收費課程 <- 不推薦

也很簡單，但是要花錢，大概7,000~20,000不等。

在google搜尋[scrum 認證課程]，出現起碼5個不同的教育機構，其價格從7,000到20,000台幣不等，時間通常大約是2整天左右。衡量自己的時間和財務狀況，挑選離家近的參加即可。

這類型的收費課程通常會協助考取證照。在此並不推薦這個方式考取非技術專業之證照。

(3) 實際經驗

非常難！要花的成本看起來很高，不過他通常伴隨工作經驗的成長。

(a)基本作法：

首先必須要先參與開發團隊一陣子，在此期間必須要先用方法(1) 網路資源。用以了解Scrum的基本精神。

然後，只要運氣不要太差，加上自己的努力，有朝一日會變成專案經理，或者是團隊領導者的角色。接下來，由於自己已經擔任領導者角色，就在自己領導的團隊中，以務實的方式執行Scrum。其中一定會遇到阻礙，每當你碾平一個障礙，就更多一層對務實的認識。

基本作法其實也是最佳作法，如果是一個已經有足夠技術背景的人，而有意識的朝這個方向前進，在台灣大概3-5年就可以有很好的成果。

(b) 突破性作法：

和所有專案管理技能一樣，當不能付諸現實的時候，技能的本身就沒有意義。就像籃球教練沒有籃球隊可以教，沒有籃球比賽可以參與的時候，籃球教練等於沒有付諸實踐的意義。

要有突破性作法的原因在於：

* 企業組織長久以來沒有真正agile的精神
* 在創新小公司任職，架構混亂，以完成事情為優先
* 自己並不是團隊領導，但希望能改變團隊
* 剛畢業，沒有領導管理經驗
* ...


然而，在這些外在因素不利的情況下，如何有Scrum實際經驗？（突破性方式的概念可參考這篇。）

簡要的說，自己起頭一個專案，無論是跨界虛擬專案，還是開源(open source)專案，還是到便宜的外包市場找南亞工程師加入的專案。當自己開啟專案時，自然就可以確定，如果要採行Scrum，不可能會有其他外界因素，所有成功與否的因素都在於自己。當然也是靠自己來碾平困難。

一旦個人的能力提昇，自然就越能貢獻現在的團隊，現在的組織，更容易體會團隊合作的可貴。