當手上有榔頭，看到任何東西都像釘子 -- Abraham Maslow 1966
------
過去數年來Scrum明顯成為Agile軟體開發裡最常被討論跟使用的方法。
當然也有不少文章討論scrum的缺點(請參考這裡)。然而，Scrum是個在agile development範疇內的方法論，它是個很好的參考軟體開發流程的工具，而這工具有其「特性」，無所謂好與壞，當然就無所謂優點與缺點。
然而，這些特性不可否認，需要對該工具有一定的認知，特別是一些「預設要知道的事情」，以免誤用。舉例來說，當你使用榔頭的時候，大概會知道它是用來釘釘子，而不是拿來釘螺絲。此外，你也會大概猜到，右手拿榔頭左手扶著釘子時，要記得不要敲到自己的手指。
以下Scrum缺點（特性），也是常見的陷阱僅供參考。
(1) 團隊成員對Scrum的了解必須一致，工作能力最好也要差不多。
Scrum的運作中，高度依賴成員的自主性。Scrum Master雖然很重要，但僅在於Scrum本身的運作。對於任務完成的定義以及任務的品質，還是靠所有成員的能力。
換言之，如果有人技術能力特別糟糕，或者技術能力雖好，但對於Scrum的運用與瞭解和大家都不一樣，那麼有可能會有意想不到的長時間磨合期。
(2) Scrum並不會真正加快速度，只是讓速度透明，讓大家專注重要的事情。
許多企業導入scrum的目的是為了加速產出。事實上，Scrum並不會加快「某件事情的速度」。Scrum會讓事情變得透明，同時也讓團隊進行的速度變透明，讓大家更容易專注於正確的事情上。
整體來說，Scrum會減少各種不必要的浪費，讓整個專案效率提升，但就個別事情的速度而言，Scrum並不會提升。換言之，軟體工程師仍然需要有自己的方式來提升個人效率。
(3) Scrum並不會解決工作內容的相依性
傳統的專案管理方法論，常常會提供類似甘特圖的工具。然而，Scrum方法論專注於某件任務(story)的完成，而隱含著希望每個任務的相依性，會在團隊成員的「成熟考慮」下被處理完成。
換言之，有相依性的工作就是有相依性的工作，軟體開發團隊還是必須要有自己的方式解決相依性。使用scrum並不表示相依性消失，也並不表示當有個寫得很獨立的story產出時，就一定會跟其他工作無關。這些都還是得靠團隊來處理。無論是使用Jira還是agilefant還是任何工具，都應該有自己的處理相依性的方式。
Don't hire a software developer until you read this book是一本有趣的書，它的副標題是：學習如何管理應用程式的開發流程，確保你的手機程式，網站，網路應用的產品會成功做出來。
這本書和一般的企業巫醫做法略有不同，它只專注在一個單純面向，就是「非軟體人員如何建構軟體開發團隊，並且做出自己要的產品」。實務上，它是一本工具書。裡面的Pro Tips直接而且不廢話的指出應該要的做法。
這本書花了好幾個章節，大致闡述了近年來軟體開發的相關技術與運用，並把重點放在非技術背景的創業者，如何組織建立軟體開發團隊，並且讓團隊往期待的方向前進。
做得到書上的內容的人，大概就是程式設計師心中的好老闆，或者是好ＰＭ。
然而，這本書其實也非常適合給「程式設計師」閱讀
它展示非技術人員領導軟體產品開發「真正關心」的地方：也就是實際產出。至於開發人員使用的程式語言，使用的軟體工具，甚至想要把產品做的完美...這些都是不是考慮的要務。
例如，在書中說明新創產品開發常犯錯誤的幾條
(1) 為求完美把錢燒光了：
MVP需要的是最小規模的產品以及最好的品質。但太追求完美因而增加太多附屬功能，在作者來說是一種無法控制的浪費
(2) 輕忽看似很小的需求規格改變
例如某些開發人員會說「這不會花太長時間，只是把按鈕從這邊移到那邊」。開發人員當然會負責搞定，但是要求預估時間是創業家一定要做的事情
(3) 忽略測試
測試的重要性應該不用多提。然而非技術人員很容易忽略測試的重要。
(4) 即將上線前做需求改變
對作者來說，這等同於自殺任務。其實資深的軟體工程師在內心深處都很清楚這點，但是創業者或PM想要自我毀滅的時候，又有多少人可以阻止？
(5) 開發中後期增加人力以加速開發
在人月神話這本書中有很長的篇幅描述，很多時候增加程式設計師只會讓專案速度更慢。
此外，一般開發人員也可以透過這本書獲得Lean-Startup的精神概念與實務上Agile開發的整合。
舉例來說：它說明了Agile原則，以創業者的角度，來看agile的各種方法論對軟體開發的好處。並且也拿實際工具(Trello)，展示一個創業者實際對開發團隊該做的動作，連同移動Task Card都說明很清楚。MVP，如何做出最小可行規模的產品。從創業者的角度，來看這些工具，其實更可以讓軟體工程師知道專注於最小變動需求的好處。
Scrum是敏捷開發原則下，目前在軟體產業裡常見的方法論。而由於Scrum只是個方法論，並沒有所謂的標準，各個組織的應用方式皆有不同。常見的應用(practice)，例如：spint-kick-off-meeting, daily standup, burn down chart, planning poker, retrospective。
零零總總的practice中，哪些最為重要當然眾說紛紜。考慮到Scrum的真正精神，以下三件事情是「最基本要有的」。也就說，如果這三件事情做不到，那麼其他事情做到也沒有用。
(1) 每個Sprint有交付具體產出
Scrum的Sprint都要有具體「可交付」的產出。sprint的開始，就應該以「結果」為計畫的導向，而此結果必須要是可交付的產出。
有些團隊會以Sprint長度不夠為理由，設定一個「並不能交付」的milestone作為該sprint的產出。如此一來會有幾個問題：(1) sprint結束的檢討，並不基於產出的事實 (2) kick-off下一個sprint的意義不大，因為前一個sprint並沒有真正可在市場衡量的產出 (3) PO會有充足的理由不參加demo以及下一個sprint的kick-off，畢竟這個sprint沒有有意義的產出，而如此一來PO就很容易不真正加入團隊。
Sprint不見得要固定長度，請參考這裡。
(2) PO有確實加入Scrum團隊
Scrum團隊成員有三個角色，team member, scrum master, product owner。其中最容易不在的人，就是product owner。許多軟體開發團隊，product owner就是PM。但無論如何，Product owner必須要真實參與團隊。
所謂真實，指的是所有standup應該參加，在團隊運作過程，能夠回答該sprint的需求問題，並確實知道sprint中間「不應該做的事情」以及sprint開頭結尾「應該做的事情」
更重要的是PO加入團隊之後，DOD(definition of done)的標準才會具有「市場一致性」。舉例來說，不成熟的軟體研發人員常會對事情做完有不同的定義：
「程式寫完只是還沒review，所以還沒merge」
「程式寫完測試也沒問題，只是QA還沒通過」
「功能搞定了，QA也沒問題，只是還沒...」
PO確實加入後，可以讓事情做完的定義，統一在於「可準備交付到市場」。換言之，所有和程式設計相關的工作：測試，相關文件，環境設定，certificate等等都會以「可準備交付到市場」為原則。沒有這個原則，跑Scrum很難達到預計效果，要達到這個原則，最基本的就是PO需要確實投入團隊。
(3) 每個Sprint結束之後有確實地檢討(Retrospective meeting)
這世界上沒有完美的團隊，也沒有不用修正的軟體開發方法論。每個sprint的確實檢討，是修正團隊，讓團隊趨於一致的唯一方式，而非強加訴諸任何規矩。請參考這裡
確實的檢討並不容易，要做到兩件事情：
(a) 基於事實檢討
(b) 不檢討不在場的人事物
基於事實的檢討
檢討的內容必須基於事實，不是基於感覺與想像。感覺和想像的情況如下：
「我感覺好像有點慢」
「不知道怎麼講耶 但這個事情不應該這樣做」
事實的情況舉例如下：
「這個sprint我們沒有按照當時說好的DOD的定義，所以有XX與XX項目，本來說完成了，後來隔幾天又說沒完成」
不檢討不在場的人事物
檢討確實是對事不對人，然而，事情都是人做的，不可能不檢討「人的做法」。不檢討「人的做法」只是鄉愿。
不過，要避免檢討不在場的人。
例如「因為UI/UX之前給的東西不正確，導致我們要重做某些事情」如果UI/UX是同一個scrum團隊，那麼檢討此項目當然可以。但要是不是同團隊就沒有意義。
因為，Scrum的檢討會議目的是產生「團隊要改善的項目」，而不是去讓非團隊的人改善。
Scrum的學習必然是從實際的經驗獲得，但經驗的獲得又必須從知識學習的取得為基礎，要成為看似不錯的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
