不文謅謅，做到這些你的專案就在跑敏捷
看完一堆敏捷文章，講了一口好敏捷，但真的實際去實作或推動總是力不從心嗎？Daily Stand meeting, Planning meeting, Demo meeting, Retrospective meeting… 這些會議是什麼、會議要持續多久、要注意什麼、成員在會議中扮演什麼角色？如果你對這些不太清楚，讀完這篇你會對敏捷實作更有一些想法
本篇跳過敏捷由來/方針/歷史淵源/價值等，想了解的可以參考這篇 (黃冠融 — 敏捷(Agile)是什麼？)
主要講的是：
1. 跑 Scrum 的幾個重要會議，包含會議內容以及哪些人應該要參加，還有很重要的是「替代方案」
2. 整個團隊以及組織過於龐大，該怎麼踏出第一步名詞解釋：
🧙『Scrum Master』 (沒有簡稱，叫起來怪怪的..)：又稱敏捷教練，宣傳以及教育敏捷方法給自己的隊員、主持敏捷相關會議、持續改善流程及幫助團隊解決困難 (或找到對的人幫忙解決)。由於沒有實際掌權的能力，卻又要領導團隊往對的方式進行工作，需要「Strong communication skill」激勵士氣並讓人信服
🙋♂️『Product Owner 』(簡稱 PO)：基本上是產品經理的角色，負責規劃團隊的 roadmap，了解使用者以及 Stakeholder 需求，規劃一個推出後會讓市場發出 wow 的產品。寫 User story (Feature) 到 Backlog ( Feature pool) 中，並能判斷哪些 Story 是優先要做進而放到每次的 Sprint 中
👨💻『Scrum Team』：參與這個 Scrum 的成員，包含 Scum Master、PO、工程師、設計師、測試，最多 5–9 人，建議這些人的座位就坐在一起，方便討論，敏捷推崇有什麼問題「即時且面對面的討論」。
⭐ 強烈建議討論文需要文件紀錄，以免之後很難回溯，要交接也會有口述上的落差，程式碼真的很難三言兩語就說的水落石出啊(???成語能力很爛)👨👨👧👧『Stakeholder』：通常是業務方、客戶、股東或是老闆本人，只要是「有權利」可以否決產品的並且非上述以及 QA 團隊的，你就可以當作是 Stakeholder
『Sprint』：指 Scrum 團隊完成一定數量工作所需的短暂、固定的周期。基本上 Sprint 的週期為 2–4 週
固定時間很重要，多一天少一天都不行，這樣可以讓團隊的工作有一個固定的節奏，如果時間不斷更動，會讓團隊成員覺得「在這個時間內完成不了也是沒關係的心態」。如果真的做不完，我的建議是帶著 RD leader 去 review 為什麼不行？如果在立會 (文章下一段會提到) 上都沒有提出遇到的問題，照理來說是必須要在時間內完成的，所以立會很重要，Review 機制也很重要
全員參加的重要會議
⏰『每日立會 (Daily Stand meeting)』：Scrum master 主持會議，目的為同步所有人的情況；一個人的時間不超過 3 分鐘，總會議不超過 15 分鐘
找一個空間(小桌子圍繞)，有白板最好但非必要，大家依序同步專案的內容給所有成員，內容快速帶過昨天做什麼/今天做什麼/目前面臨的問題是什麼？如果需要花時間討論的會後再去討論，(Scrum master 請嚴格把空時間，超過三分鐘不能解決就會後討論)。⭐ 注意請以維持整個團隊資訊透明同步是這個會議的宗旨！
看過很多失敗的立會，例如一站就是半小時，腳酸不能坐下只因為這是「立」會、參加的人太多，一次十幾二十個，即使一人講一分鐘就過了二十分鐘、或是開發團隊不好意思說遇到什麼問題，一整個禮拜都在講修 Bug 仍然沒有進展，這些是立會被誤用的例子
建議：⭐我會用電腦紀錄大家今天準備做什麼以及遇到什麼問題，隔天的 Daily meeting 可以檢視是否做到，或是一件事情是否做太久以及問題解決了沒。這個好處是有個 Log 把大家做的事情都記錄起來。常常會遇到今天說要做什麼，隔天會議在講昨日工作時完全沒相關，請不要太相信 RD 的專注力 (sorry 各位 RD 朋友..)⏰『計畫會議 (Planning meeting)』: Product Owner 主持會議，每一個 Sprint 開始前計劃本次 Sprint 要做什麼，把所有產品要闡述的說得一清二楚，並且跟著工程師一起拆分任務 (大需求拆成小任務的概念)，以及大家估計每個任務大概需要做多久。通常這個會議是最耗時的會議，可能有人到 4 個小時或一整天；我覺得不錯的做法是請 PO 闡述完要做的工作後，請較資深的 RD 分派任務，或是 Scrum master 跟著團隊一段時間會大概知道哪些人可以做哪個，但是我還是傾向沒有人是專精什麼的，大家都可以輪著做，以免有人離職會對團隊傷害很大
估時真的是一個智慧，在 Scrum 的估時有一套方法，我個人覺得很複雜，但我看過最清楚的是這部影片。我尚未實行這個方式，一來我覺得太過複雜，二來太過費時跟大家解釋 (人性就是只要一複雜大家就懶)，目前的做法我還是請 RD 用一天 5 的小時去估計工作量，讓時間以及經驗讓辜時更準確。
⭐ 如果真的估不出來請討論是否任務分得不夠細或是可以拿之前做完的 task 與之相比，是更容易還是更難呢？只要有標準一定可以比對的 ( 或是把任務比擬做衣服的尺寸，s/m/l 大概哪個任務對應哪個尺寸去評估時間)
建議：RD 或 QA 的工作做的熟悉後就輪著做，並且可以指派熟悉的成員幫忙，這樣整個團隊都不斷地在 upgarde，這也是 Scrum master 很重要的工作之一。在這個會議中，⭐很重要卻容易忽略的是「定義可以交付的標準」在一開始實行敏捷或是新成員很容易 RD 的任務跟 PO 的任務完成是有落差的，我吃過很多次虧，RD 說得完成可能還需要一天去上線，那這樣時間以及對下一個任務的安排就會有所影響我的 case 將 Plaining meeting 稍作變形，將 PO 闡述拆分任務以及估時分成兩個會議，一個在星期一一個在星期五，中間的時間 PO 與 RD 可以討論後需要修改有些彈性，想了解的可以看我的上一篇：不紙上談兵，所以 Scrum Schedule 怎麼規劃？#新創公司實驗心得 (上)
⏰『Demo meeting』：性質就是 UAT (User Acceptance Testing)，這個會議是讓開發團隊展示他的成果，可以是已經測試完的或是開發玩只差測試 (可以在 Sprint 一開始訂定可以 Demo 的標準)，如果有需要甚至是可以請相關的業務團隊一起參加此會議
⏰『回顧會議 (Retrospective meeting)』: Scrum matser 主持會議，約一小時。在每次 Sprint 結束會有個檢討會議，檢視「怎麼讓團隊更好」、「怎麼讓工作更有效率」，把團隊視為石頭去打磨，如同幽助從靈彈、靈光拳到最後的妖靈彈 (超宅)。
請注意這絕對不是一個好棒棒互相吹捧的會議，Scrum 畢竟是國外傳來的，亞洲人的性格就是不敢面對面得罪，Scrum master 的職責就是鼓勵大家發言，並且成為大家的榜樣，說出哪裡需要改進，或是所有人都講至少一個需要改進的地方，並在會議結束時跟大家說：「大家真的好棒！我相信之後會越來越好的」
建議：以我的 case 來說團隊成員約 20 人，將他們分成三組去工作，所以如果每兩週開個回顧會議，會議會太多太雜；我的做法是在團隊週會是順便檢視整個團隊遇到哪些問題以及需要優化的部分，我這個會議中我會讓所有團隊知道整個 Team 做了哪些事，鼓勵做得好的 (技巧性的所有人都會輪流被鼓勵到) 需要改進的地方一定要記起來，不然這個會議會淪為形式開身體健康的，在下次下一次會議中檢視要改進的改了嗎？去抽絲剝繭混亂的來源，並一步步的使之清楚明瞭，並像傳教士般感染全部的成員，是 Scrum Master 的職責
大家都沒聽過敏捷，我該如何下手
這是大家敏捷看得拍案叫絕，還沒做就放棄懶得叫的原因之一。
我覺得方法有幾個：
- 像提 Proposal 一樣跟主管提案，大刀闊斧 (不建議，通常想得太美好之後做起來被主管黑掉，除非你就是主管本人，但也得考慮實施的結果不好讓底下團隊很無力，方向變來變去)
- 找一些簡單時間線拉比較短的的專案小組實行，如同以前生物課的實驗主以及對照組。這個 case 對於你要看專案以外也要看小組成員，然後把敏捷的正向以及方法不段的在這個專案中植入他們的工作以及思考；不要忘記把 QA 以及設計師一起加入本次實驗組裡，事先規劃好每個 Sprint 的週期，以及每週大家主要任務要做什麼
- 整個 Team 或是你可以掌握的人員，開始部分實行敏捷流程，比如說從每日立會 (同步) 以及檢討會議 (優化) 開始，這個即使你的團隊目前的專案是 waterfall 也是可以的，這個不管有沒有導入敏捷都是對團隊有益的；做些紀錄比如說開始了這兩個會議讓專案的進展 (把專案拆分成 task, 每週完成的任務是否有變多或是完成複雜的任務時間是否縮短了) 以及團隊合作的效率提升，想辦法值化出來以及邀請主管參加回顧會議，循序漸進的把更多的敏捷方法導入
不是追求快而是追求質量以及高效
敏捷不是照本宣科，而是了解敏捷精神後為你的團隊去客製化敏捷流程，哪裡需要多一個會議，哪個會議其實不需要…等等。像是以每日立會來說，在快要發布一些重要功能的緊急時刻時，我會一天兩個立會，一是一早，二是下班前再次確認問題解決沒，一個晚上你可以有更多的思考，為明天一早做打算或是申請加班；如果你有在看番茄工作法你會會覺得方法跟番茄工作法的精神類似 (早晨 AM review 以及 晚間 PM review)。之後會分享最近看得子彈筆記/番茄工作法的心得，將發現這些增強效率的方法跟敏捷的大架構是大同小異的
|同系列 Scrum 相關文章：
