Scrum是推進團隊進度，合作專案的敏捷方法論之一。有很多優勢，例如
- 減低壓力
- 具有務實的彈性
- 容易評估現況
- 易於控制品質。
每個Sprint各有數個任務，每個任務都有估計的時間。
- 時間是以小時為單位。
加總起來，會有要完成Sprint所需要的總時數。在Sprint過程中，要能實際反映團隊實際的「速率」，因此
- 前1-3個Sprint的燃盡圖很重要，可以讓團隊知道實際的效率。
所以每個Sprint都是固定時間，大約4-6週，
- sprint時間到就結束了，只會看做完哪些Story
- 在下一個Sprint才調整要完成的story數量。
- 團隊成員對Scrum的了解必須一致，工作能力最好也要差不多。
- Scrum的運作中，高度依賴成員的自主性
- 對於任務完成的定義以及任務的品質，還是靠所有成員的能力。
上面任一點，都容易 run 不好，那麼有可能需要長時間磨合期。
- Scrum並不會真正加快速度，只是讓速度and資訓透明，讓 team member 專注重要的事情
整體來說，Scrum會減少各種不必要的浪費，讓整個專案效率提升，但就個別事情的速度而言，Scrum並不會提升。換言之，軟體工程師仍然需要有自己的方式來提升個人效率。
- Scrum並不會解決工作內容的相依性
Scrum方法論專注於某件任務(story)的完成，而隱含著希望每個任務的相依性，會在團隊成員的「成熟考慮」下被處理完成。
Scrum只是個方法論，並沒有所謂的標準，各個組織的應用方式皆有不同。常見的應用(practice)，例如：
- spint-kick-off-meeting
- daily standup
- burn down chart
- planning poker
- retrospective。
考慮到Scrum的真正精神，以下三件事情是「最基本要有的」
sprint的開始，就應該以「結果」為計畫的導向，而此結果必須要是可交付的產出。
// bad
以Sprint長度不夠為理由，設定「並不能交付」的milestone作為該sprint的產出。
如此一來會有幾個問題：
- sprint 結束的檢討，就不是基於產出的事實
- kick-off下一個sprint的意義不大，因為前一個sprint並沒有真正可在市場衡量的產出
- PO會有充足的理由不參加demo以及下一個sprint的kick-off，畢竟這個sprint沒有有意義的產出
而如此一來PO就很容易不真正加入團隊。
Scrum團隊成員三個角色中，最容易不在的人，就是product owner。但無論如何，Product owner必須要真實參與團隊。
- 指的是所有 standup 應該參加
- 在團隊運作過程，能夠回答該sprint的需求問題
- 確實知道 sprint 開頭結尾「應該做的事情」
- 確實知道 sprint 中間「不應該做的事情」
有 PO 之後，
- DOD(definition of done)的標準才統一在於「可準備交付到市場」。
換言之，所有和程式設計相關的工作：測試，相關文件，環境設定，certificate等等都會以*「可準備交付到市場」*為原則。沒有這個原則，跑Scrum很難達到預計效果，要達到這個原則，最基本的就是PO需要確實投入團隊。
每個sprint的確實檢討，是修正團隊，讓團隊趨於一致的唯一方式
// bad
- 「我感覺好像有點慢」
- 「不知道怎麼講耶 但這個事情不應該這樣做」
檢討確實是對事不對人，然而，不檢討「人的做法」只是鄉愿。不過，要避免檢討不在場的人。
// bad
- 「因為UI/UX之前給的東西不正確，導致我們要重做某些事情」
如果UI/UX是同一個scrum團隊，那麼檢討此項目當然可以。不是同團隊就沒有意義。
因為，Scrum的檢討會議目的是「團隊要改善的項目」，而不是去讓非團隊的人改善
- 為Scrum teamd 排除困難，緩衝障礙
- 確保整個 team 的工作流程能夠符合Scrum精神。
- 幫助Scrum Team盡量只專注於開發活動
比較像一支職業球隊裡的教練兼管理。
-
他訓練球員戰術配合，
-
比賽時緊盯球員戰術執行狀況，並適時暫停上場叮嚀。
-
平常沒事就幫忙球場清掃與草皮保養
-
球員肚子餓沒力氣練球他就去幫忙買便當跟麵包。
-
他同時是球隊老闆與球員間的溝通橋樑
-
老闆有命令要傳達或是球員有問題要回報，都要透過球隊教練。
而重要並且特別的是，這位教練跟球員沒有從屬關係。他們都同樣是這支球隊裡的一份子，只是負責工作不同而已。
SM必須要成為PO的好朋友，因為
- SM必須就團隊狀況，經常與PO討論
- 幫助PO建立backlog清單，一同討論與安排重要性與先後順序。
PO通常不和Scrum Team一起工作，所以能協助PO了解人與工作狀況最重要的人就是SM
SM與PO之間要培養好的默契：
- 如果雜務可以變成User Story，就可以安排時間排Sprint處理掉
- 如果不適合，那就是SM來幫忙處理掉
在羊兒放出柵欄，四處吃草，到回欄休息這段時間內：
- 牧羊犬始終保持高度專注
- 牧羊犬確保過程中沒有羊兒跑錯方向或是脫對保去別人的地盤
- 但是從來沒看過牧羊犬拖著小羊走的。
SM也是一樣：
- 通常是團隊中對scrum流程最熟悉的人
- 他隨時提高專注，不讓團隊中任何人違背scrum精神。
只要是跟程式無關的，SM幫你做。
- survey CI/CD工具
- 尋找適合的新語言學習平台
- git flow使用上困難的排除等
team只要專心開發，或是根據SM調查後的結果開會決定未來要使用的工具就好。
網路世界有句名言：對的時間做對的事，並且一定要被看到。 SM一個很神聖又很難的任務，就是教育偉大的主管與老闆，什麼是Scrum。
不懂Scrum的人來看scrum team會覺得他們跟傻逼一樣：
- 哪有人交代一個任務給你要我等10天才能有結果，
- 哪有人每兩個禮拜就要花一整天開會玩撲克牌的
在適當時機，用潛移默化的方式，讓你的長官或老闆更了解你們在做什麼，以及，最重要的，這樣做對公司有什麼好處，於公於私都是非常非常有益的。
最主要的工作如下:
- 產生出 product backlog 內的項目 (Product Backlog Item, PBI) 不一定要 PO 自己寫, 可能是他和客戶一起完成, 不管怎樣就是要生出一版.
- 對 PBI 排出順序
- 定義出驗收標準 (acceptance criteria)
主要的是扮演
- 教練的角色, 來幫忙大家熟習 Scrum 的流程
- 確保團隊的行為是正確的. 大家用正確的心態, 合適的手法來做事情