嗨～我是信安。我這邊指的不是物理上的，而是指流程思維上的敏捷啦！
工作也可以敏捷起來！
回到正題，最近我被公司指派，需要帶員工開發軟體的專案，對我來說是全新的挑戰。
在我屬的傳統產業中，幾乎所有的專案會依據明確的需求，從設計規劃到最後結案驗收，每個階段都有清楚的分工和依序要完成的任務。
任務就好像瀑布一樣，水由上而下整齊劃一向下流，所以也可稱為瀑布式的工作流程。
而這次開發軟體的專案，特性是使用者需求常常變動，所以如果用以往的瀑布式流程，有可能花很多時間作出來的功能，隨著需求變化早已不敷使用了。當我被指派這項任務的時候，就覺得這是必須克服的課題。
幸運的是，在我參加運動賽事的時候，常用覆盤來應付不斷變化的需求。像是針對鐵人三項賽事目標，我會切分成每週運動訓練的目標，並且週末覆盤這些目標是否要調整，來因應訓練上對於體能、工作、生活的變化，維持三方的平衡。
我覺得『個人的覆盤』和『團隊的敏捷(Agile)』有相同的核心精神。
身為覆盤愛好者的我，早有耳聞有個Scrum這類的敏捷工具，一直很想要找機會試試，再加上最近看了《Agile一本通！》這本書，更加確信這次專案非常適合應用Scrum。
接下來，想和你分享在書中看到覺得很棒的觀點，也當作敏捷初學者的學習紀錄。
Scrum的好處
要推動新的工作流程，如果沒有提出對厲害關係人有利的好處，特別是團隊可能就產生的反彈。所以對於在書中列出以下Scrum的優勢，未來和團隊說明使用：
⭐️工作不會無限增生
以往的觀點，認為如果利用敏捷提升工作效率，就是要讓團隊在短時間內盡可能再作更多的工作，其實正好相反。
敏捷的觀點，只要最初大家有共識，哪些是這次優先執行的代辦事項(固定工作量)，那團隊這次就只集中火力在這些任務上，並且在限制的時間內(固定時間)完成。
所以，可以有效提升工作效率(避免團隊有人被問題卡住不動)，也不會造成代辦事項無限增生，演變成需要常態加班。
⭐️工作進度可視化
以往的方法，管理者需要一個個問每個人的工作進度，這會讓團隊產生無形的壓力。
敏捷的方法，常運用可視化的看板，可能是實體白板、Excel還是專案管理軟體，和團隊共同維護更新看板，讓工作事項、進度和負責人都能被全局檢視。
不但管理者不用在顧人怨一直問進度，而且還能跟團隊對抗共同敵人(白板)，減少上下對立關係，根據白板的情況給予適當的協助，更推進專案進度。
⭐️團隊可自我組織
以往的工作，大部分都來自主管的的派工，甚至會不知道做這些工作到底要幹麻的。更嚴重一點的，會覺得：「反正主管說的算，管他的做就對了！」。
很多工作即使主管交代同樣的話，也會因為背後不同的原因，交出完全不同的東西，所以讓團隊從「做就對了」到「為什麼做」很重要！
其他類似例子有很多：
即使準備同樣的題目、專案的簡報，也會因為簡報不同的對象，調整報告。
即使應徵同樣的產業、工作的職位，也會因為應徵不同的公司，調整履歷。
敏捷的團隊工作，讓每個人決定自己的工作項目，過程逐漸透明且自主，鼓勵更多更新的點子提出和採用，進而從「服從」到「參與」，提高團隊向心力。
這樣即使沒有主管監督，團隊也能運行很好，達到自我組織的效果。
在公司專案，我預計先運用Excel可視化來派工，搭配明確的每週團隊目標進行。等團隊上軌道後，新的工作會再依照每個人的意願/能力自行領取，開始自我組織。
Scrum主要成員
接下來，你可以先了解Scrum的成員相對應的負責工作，主要可以分成以下三種成員。(建議後面內容可以邊對著流程圖來看會更清楚)
⭐️Team
負責執行專案的團隊，在每次的短衝產出可用的功能(Potential Shippable Products)，數量約在3~9人。示意圖用五人小朋友來表示。
以我的專案例子：Team = 工程師、日班專員，還有我，共9人
⭐️PO(Product Onwer)
有產品的決定權，像是維護更新產品代辦事項(Prodoct Backlog)、執行優先順序、設計的使用者回饋等等，示意圖用幹練眼鏡姐來表示。
以我的專案例子：PO = 部級以上的主管。
⭐️SM(Scrum Master)
協助引導整個Scrum流程的進行，包含主持各個會議、引導Team將產品代辦事項拆解成短衝代辦事項(Sprint Backlog)、團隊和PO之間的溝通等等，示意圖用瞇瞇眼老師來表示。
以我的專案例子：SM = 我。
Scrum工作流程
最後，我會以下這張可愛的經典Scrum流程圖，讓你可以快速了解Scrum的工作流程中，包含不同時間點的產出和會議。
從流程圖中你可以發現到，流程從左邊執行到右邊就是完成一次的短衝(Sprint)，也代表需求和產品完成一次的覆盤，之後再回到左邊就會開始新的短衝循環。而這邊要先律定一次短衝覆盤的時間週期(也可以稱為時間盒timebox)。
在公司專案，我預計將一次短衝時間訂為一週，希望可以加快覆盤的速度，來適應專案起步的需求變化，也是希望每個會議時間能盡量縮短。
所以，決定之後未來的一週的工作天，工作流程會變這樣子：
⭐️星期一
收到來自PO的全新或是上週回饋之後，產生的產品代辦事項，開啟產品規劃會議(Sprint Planning)
產品規劃會議Part1：
- 目的：依據產品代辦事項，PO說明這週短衝要完成的目標，以及執行的優先順序
- 人員：PO+SM+Team
- 時間：<1hr
產品規劃會議Part2：
- 目的：SM引導Team將產品代辦事項，拆分成可執行的短衝代辦事項
- 人員：SM+Team (PO自由參加)
- 時間：<1hr
短衝會議：
- 目的：Team每個人快速說明專案進行情況，自行同步大家的工作內容。像是「昨天完成哪些東西？」、「今天要作哪些東西？」、「哪些問題需要協助？」
- 人員：SM +Team
- 時間：<15 min
- PS：要留意不要停留在卡住的問題，應統一在會議後再留下討論具體解決方案。
在公司專案上，我預計將三個會議減化成一個早晨會議，並且引導議程在1hr內完成，否則實務上很容易和其它會議衝突。
⭐️星期二～四
接下來的工作天都是在早上進行例行的短衝會議，快速了解專案進行進度&問題。
短衝會議：
- 目的：Team每個人快速說明專案進行情況，自行同步大家的工作內容。像是「昨天完成哪些東西？」、「今天要作哪些東西？」、「哪些問題需要協助？」。
- 人員：SM +Team
- 時間：<1hr
- PS：要留意不要停留在卡住的問題，應統一在會議後再留下討論具體解決方案。
在公司專案短衝期間，如果發現產品代辦事項可以再精練，我(SM)預計統一在星期五的功能檢視提出，讓PO悉知。
⭐️星期五
在一週的尾聲，除了例行的短衝會議之外，會進行軟體功能和短衝的覆盤。
短衝會議：
- 目的：Team每個人快速說明專案進行情況，自行同步大家的工作內容。像是「昨天完成哪些東西？」、「今天要作哪些東西？」、「哪些問題需要協助？」。
- 人員：SM+Team
- 時間：<15 min
- PS：要留意不要停留在卡住的問題，應統一在會議後再留下討論具體解決方案。
檢視會議：
- 目的：這次短衝產出的功能，給PO/使用者實際使用看看，回饋後請PO更新產品代辦事項
- 人員：全部利害關係人(PO/使用者+SM+Team)
- 時間：<1hr
自省會議：
- 目的：這次短衝流程優化，讓開發更有效率。像是「哪些流程可以做得更好？」、「哪些功能已經製作模板下次短衝可以直接用？」
- 人員：SM+Team (PO不建議參加，否則會變成檢討大會)
- 時間：<1hr
在公司專案，我預計簡化檢視會議，改以TEAMS團隊來通知PO&確認功能需求。等到短衝工作流程上軌道，我(SM)已律定出產品代辦事項的格式，再改由PO維護。
以敏捷的心態，實踐Scrum
耐心從前面看到這裡的你，或許有發現我一直試著刪減Scrum的會議或是元素。
或許有熟練敏捷的高手，認為我還有很多敏捷的工具沒有用到，像是要用故事點(Story Ponit)來估算並量化一個任務的工作量，再更進一步用燃盡圖(Burndown Chart)去衡量團隊在限定時間內所要完成工作量的速度...等等。
我的考量是，對於現況的團隊已經要花很大的心力來思考怎麼執行專案本身，甚至有人根本還在狀況外，在這種情況下還要讓團隊花時間去學太多陌生的工具，反而工具的效果還沒出來，團隊就先強烈反彈，那也就不用玩了。
所以，與其一口氣將全部的工具用上，為什麼不用也敏捷的心態來執行呢？
我認為，首要目標必須先掌握敏捷的核心：
- 透明度：所有事情的如實呈現，不管是好消息或壞消息 ➡️ 彼此信任
- 檢視：目標、產出物、流程，團隊都能檢視 ➡️ 調整依據
- 調整：因應改變做出調整 ➡️ 持續改進
接著，確保每次短衝都有最小可行性商品(Minimum Viable Product, MVP)的產出，可以符合主管們的需求，讓專案繼續往好的方向走，我(Scrum Master)再依情況導入必要工具，持續優化流程。
只要可以做到以上這幾點，就已經符合我最初想使用Scrum的期待了，滿分100分！
已經看到這裡的你，不如現在幫我按個小小的喜歡❤️吧！希望大家會喜歡這次的分享，我們下次再見：）
最近我的個人網站終於架好囉😎！未來新運動文章會改放在新網站喔，歡迎大家前往～
