Scrum 這個專案管理的原則，近年來相當火紅，怎麼運作就不再多作介紹了，去 google 就有一大堆相當專業的評論。
如果你要繼續讀下去，希望你對 Scrum 是有基本了解的。但假使你有點懶得，也可以參考下面這張圖，希望能讓你 30 秒了解 Scrum 想要達到什麼。
基本上 Scrum 想讓團隊能夠把重心放在開發出第一版非常破爛的原型，業界稱作 POC (Proof of Concept)。對老闆或投資人來說，他們希望能看到一個「好像能賺錢的東西」，所以破爛沒關係，達到目的就好。
過了第一關之後，應該就能關關難過關關過，再不斷針對細節作 refactor。
接下來，就是管理的事了。
所以簡單說 Scrum，有三個重點：
- 團隊的重心
- 潦草但有力的願景
- 管理
你為何要讀這篇？
大部分坊間的說明都是從營運者的角度切入，再不然是在說服管理階層：這樣的方式有什麼好處。從底層團隊成員作為出發點的介紹比較少。
另一方面，Scrum 的哲學非常強調團隊成員間的同步（sync up），如果 PO（Project Owner）和成員間沒有達成一定共識，造成某一方遷就一方，就容易造成運作上發生問題。
所以如果你是管理方面的人員，了解從工程師角度在運作 Scrum 會產生的問題，在協調團隊內部的協同時就比較容易找出共識。
如果你是軟體工程師，避免掉下面提到的這些小問題，或是試著採用一些原則，你會讓團隊運作的更順暢。
我不是 scrum 專家，只是想聊聊在這樣的遊戲規則下，擔任一顆齒輪之後，一些小小的心得。
好，我們開始吧：
了解你的專案前提
上面舉的開發全新產品的例子，只是團隊的某一種模式而已。事實上，軟體專案有各種不同的性質，除了上面提的開發之外，一個 scrum 團隊也有可能主要是在作維護的工作，這個時候，Scrum 的策略就會比較偏向求穩，而不是求突破。
當然，這件事就交給 PO 來擔心就好，但即使身為工程師，了解專案的性質是必要的。
除此之外，專案主軸也是要考慮的前提之一，有的專案是要作出一個給 end user 的產品，例如：一個線上糾共乘的服務；有些則是著重在開發技術面的東西，例如：人聲辨識功能，有資料庫並提供 sdk 或 api 供串接。
這兩種類型的專案，在運作時所圍繞的重心會有所不同。所以當在 planning 時要發表意見時，或是在決定 story 的主題之前，記得先問問自己：「現在 Scrum 團隊在處理的專案，是怎麼樣的一個性質」。
不要把 backlog 當作你自己的記事本
有需要處理的事情，立馬開張票記下來。一來方便自己追蹤，二來團隊成員也可以知道自己接下來會做的事。
乍看之下很合理，事實上大錯特錯！！
backlog 是以專案的角度出發，來看還有多少事情要作，並不是用來看這個團隊裡的哪個人要作多少事。所以 backlog 只會是跟產品面向有關，或者實作及驗證是不同兩方的票。
這樣子有人會問，這樣怎麼追蹤團隊中個人的進度呢？？靠的是 Daily standup。
Daily standup 時，每個人主要講述三件事：
昨天做了什麼？今天打算作什麼？有什麼需要跟其他成員協調或告知的事情？
很神奇的，如果每天花一分鐘從嘴巴講出上述三件事，自然而然會對工作進度更加的嚴謹。這也難怪，如果你是個守信用的人，假設晚上發現明天 daily standup 時無法做到今天所說要做的事，那在明天報告前是拚死也要趕出來的。
也因為這是每天進行的，所以每個成員的工作情況是可以共同掌握的。既然這樣，還需要用 backlog 來追蹤工作進度嗎？
完成階段性目標，而不是做了多少事
有開過車嗎？當你坐上駕駛座，準備用導航的時候，你會輸入的是「要去的目的地」，而不是我「準備要開幾公里」吧？
所以重點是對這個專案做到了什麼，而不是我花了多少努力在上面。
另一個要強調的部分是「階段性」。
Scrum 就是希望每個 sprint 都有明確的階段性目標，這個目標也是所有團隊成員需要共同了解的。
那為了達成這個目標，一個 sprint 之間，團隊成員做了多少事？說真的，如果我是 PO，我一點都不在乎。
正確的 Demo
除了 daily standup，整個團隊間可以共同溝通的另一個時機是在 sprint review / demo 的時候。
在團隊目標為新創產品的情況下，成員的屬性會相當多元。以前端工程師來說，就可能會跟包括 UX、後端及行銷的部分界接。甚至，前端自己本身譬如 web 及 mobile 間也會有要串接的情況。
所以在 demo 的時候，必須要很清楚是知道：「這個 demo 是要給誰看的！」
舉個例子：這個 sprint，前端工程師根據 UX 人員的設計，定義了埋 log 的機制，在 demo 時，就一定要針對 UX 人員作 demo，確定對方有了解實作的結果。
這說明了在定義 story 時，有個推薦的模版：
"As a XXX, I want A to do YYY"
你如果是 "A" 的話，上面的 "XXX"，就是你 demo 時該傳達的對象。把上面的例子套進去就會是這樣：
"As a UX designer, I want Client to record user event"
所以 client 做了 record user event 之後，要向 UX designer 報告。
埋 log 這件事，跟後端也有關係，因為前端的資料會往後送；行銷人員更是在意，因為是他們是這個功能的終極使用者。所以爾後會有兩個 story：
"As a Client, I want Backend to record user event"
"As a Marketing Guy, I want to see user event records"
所以當 backend 實作完後，就要向 client 這邊作 demo。而行銷人員這邊，是 end to end 的情況，算是一個全盤驗收。
試著釐清你該 demo 的對象吧！如果你抱持著這種想法：「我 demo 的東西，就是全團隊都需要知道的」。相信我，這只會讓你的 demo 毫無重點。
善用你 Repo 的 Readme 及 issue 系統
身為工程師，在實作 PO 開出來的需求之前，常常需要先作一些 survey 或者額外花時間開發會用到的 library。類似這樣相當技術性的東西需要被紀錄時，該怎麼作呢？
先想想什麼情況這些技術性的東西會被用到？
就是在其他人需要用到這項技術的時候啊！（這句好像廢話 lol）
相較於 Scrum 的 issue 是以專案為主軸，技術方面的主軸就是以技術本身為主，這種情況，issue 不開在 repo 上面怎麼說得過去？
當需要這項技術的人要來 clone repository 的時候，可以看 readme 或者透過歷史 issue 來了解這項技術的演進過程。這個時候你叫他回去翻 JIRA（註一） issue？
當然你想要在 JIRA 上紀錄你作過這件事也是可以，但請先確定你 repository 上的 readme 其他人也看得懂！
在管理別人之前，先學會服從
越好的團隊，就會搭配更好的工程師。所謂「能力越強，自尊越高」，優秀的工程師，通常都是自負到你會有點想一拳灌下去這樣。
所以如果你是如同頂級球員或當紅藝人的工程師，那 PO 就會是領隊的教練或是經紀人。
當然有領導魅力的 PO 會讓事情進行的更順利，但換個角度，好配合的成員也是讓事情事半功倍的要素之一。
一般的工程師，是沒有上面形容的那麼誇張，但多少還是對自己有一定的自信，不然怎麼能寫出洋洋灑灑一大堆程式碼呢？
但想像一下你是交響樂團裡的一名樂手，而且你技藝高超，樂團指定你作 solo，但無論如何，當你在演奏的時候，脫拍或即興是絕對不被允許的。（所以我還是比較喜愛爵士多些）
為什麼？
因為樂團要做的就是照指揮的意思來詮釋曲目，如果你有自己的想法的話，當你是指揮時愛怎麼表現都行。
雖然說當個好樂手和成為指揮不是正相關，但是明確知道你在團隊中扮演的角色，絕對是讓你成為好團員的關鍵，而日後有機會成為管理層級的人的話，也比較懂得過來人的辛苦。
我們是 Scrum TEAM
最後用這段 Netflix 在員工教育訓練中的一頁來作結：
We are not a family, we are more like a pro sport team.
（不好意思是簡體的）