記得在兩年前新入職一個草創階段的團隊，合作的技術夥伴希望可以使用敏捷式開發作為產品開發的節奏。就這樣跌跌撞撞地過了兩年，我們在開發團隊上也打造了屬於自己的敏捷開發節奏，這一路的推動與取捨也在這裡整理成筆記與大家分享。
在文章開始之前，以下先整理了一些Scrum的基本知識，來源皆來自參考資料（文章尾端附上參考連結）
什麼是Scrum?
Scrum是敏捷式開發，是一種以人為本的開發方法，強調團隊合作和客戶參與。軟體團隊通常會透過短期的迭代開發，持續交付價值高的軟體，以及根據客戶的反饋進行調整和改進。
敏捷式軟體開發門派更注重在人的層面，講求的是「快速從經驗中學習反應」和「團隊的自我管理」。
Scrum跟其他Agile方法最大差異是在把人（Team，Product Owner, Scrum Master），事（Sprint Planning，Sprint Retro等），物（Product backlog），很明確的定義處理
Scrum需要有哪些元素
Scrum角色：
- 產品擁有者(Product Owner)：負責決定軟體開發的功能
- Scrum Master：負責提倡以及確保 Scrum 在團隊中順利進行
- 開發團隊：負責需求的軟體建置開發、部署
- 利害關係人：除了Scrum團隊以外的都是利害關係人，凡舉主管、業務主管、老闆、客戶、行銷同事等。
Scrum工件
- Item：明確的羅列出待開發的項目
- Task：羅列出開發人員該做甚麼事情以符合 Item 的需求（在Sprint的進行過程中，Task需要可視化管理，）
- Product Backlog：放置未來待開發的 Item 清單
- Sprint Backlog：放置本次 Sprint 要開發的 Item
- Potentially Shippable Product Increment：Sprint 結束後上線的功能
- Burndown Chart：紀錄 Tasks 剩下的數量
Scrum Ceremonies
- Product Backlog Refinement
- Sprint Planning
- Sprint
- Daily Scrum
- Sprint Review
- Sprint Retrospective
好的，我們要進入正題了！在導入敏捷開發的過程中，這裡整理了我們的做法與實踐的步驟：
我想要導入，我需要準備什麼?
1.願意一起改變的夥伴：
最好是在組織有影響力的，願意相信Scrum精神，且有毅力願意面對挫折與持續調整，理解Scrum是一個開發流程，不一定完全適合團隊，可以取其精神及優點，客製化到目前的團隊上
2.具備Scrum的基本概念：
領航者或是一起改變的夥伴對Scrum的知識或是理解需要一致，想法相近的話推動起來會比較有力道。且在推動的過程中會遇到團隊的各種疑問，雖然沒有辦法給出完美的答案，但希望可以就本身的知識理解，和團隊現況找到適合團隊的解法。
3.輔助使用的工具：
我要在哪裡整理Backlog? 開發團隊可以在哪裡預估時間? 我要用什麼工具追蹤每日進度?目前我們團隊使用的是Jira，同時擁有以上的功能。一般來說最簡單的可以使用Excel+白板，可以解決以上問題，也是一個工具，或是小型開發團隊可以使用 Notion 或 Jira免費版本
4.找到開始的時間點：
什麼樣的時間點是適合開始的?可以從獨立的、規模不大的專案開始試著進行。先取得小小的勝利。後面會更有信心。
一步步教學(目前我們執行的版本)
Step 1：找到排Backlog順序的人，決定本次Sprint要開發的項目：PO是誰?
Backlog 是確定要作的功能需求列表，給PO定義需求開發順序時使用，PO會從Backlog內安排優先順序，如果沒有優先順序，將很難Backlog項目往下推進。 Backlog分兩塊，Sprint Backlog & Product Backlog，Sprint Backlog是從Product Backlog拉出本次要開發的項目的清單。
Step 2：Sprint計劃會議 這個Sprint要開發什麼的決定會議，
決定這樣的短跑衝刺要達成什麼樣的目標。這時候依靠的是PO排定的順序、技術的評估、Scrum Master的引導收斂，得到結論。 依照目前我們的習慣，在Planing Meeting已會有PM與需求單位確認好的規格，讓技術可以充分理解與對各個Story的初步評估。 我要怎麼知道這個Sprint是否可以完成這些需求?須請技術了解完需求後，針對需求拆解成任務、針對每個項目估時。
*在實務經驗上，Planing Meeting到Sprint開始前我們有針對各個Story的估時會議，會議目的是：確認此次Sprint Backlog的項目已預估時間，與實際人力資源與Sprint天數是否符合。預先知道是否能達成此次目標。
Step 3：每日站立會議：Scrum Master是誰?
站立會議由Scrum Master帶領，每次會議都在大約15分鐘內完成，每人花約2分鐘報告昨天所做的事情，並承諾今天要完成的任務，且可以提出與無法解決的障礙或相關的問題 注意：因為是每日例行，非常容易流於形式 每位團隊成員報告內容都需要對應到任務卡片上，遇到的困難需”最晚”於站立會議上會提出。
Scrum Master 須在站立會議中引導的方式
- 當報告內容開始往細節討論或發散，須及時打住另拉會議討論。
- 若報告內容無法了解進度，也須請團隊成員明確指出對應任務卡片上，知道自己在說哪個項目。
- 若進度不如預期，一張估時1天的卡片報告3天之久，代表估時有問題或開發上遇到問題無法排解，若團隊成員未主動說明，則Scrum Master 須提出討論，引導團隊一起解決。
Step 4：Sprint Review&Sprint Retrospective回顧會議：
在每次Sprint結束後，會與開發團隊一起檢視此次Sprint的成果。並且討論以下問題：
- 確認本次Sprint是否有確實進行(檢核點定義、燃盡圖狀態)
- 確認工作流程是否有可以優化之處
- 定調Sprint規範與更新
這個會議也是Sprint的精神所在，一個部分是可以與團隊一同檢視成果，建立共同的成就感以外，也可以針對每次Sprint討論並且提出小小的調整、小小的優化，長時間堆疊後會成長出最適合開發團隊的開發流程（複利效應啊！）建議此會議可以不要省就不要省。
Scrum適合我的開發團隊嗎?
1.先檢視現況：梳理出目前開發流程的步調，以及目前遇到的困難。我要解決目前開發流程什麼樣的問題？是開發速度太慢、永遠都在delay、還是需求變來變去，沒有做完的一天?
2.團隊本身的狀態：Scrum推崇的團隊大小大約10人以內，較大型的開發團隊會更不適合，尤其是在最一開始推動的時候。以及團隊本身的成員都是較資深的狀態嗎？Scrum追求的是每位成員都是可以保持開放與持續改進的狀態，團隊成員可以接受這種模式嗎？推動Scrum就會把所有開發流程透明化，團隊每天完成什麼、規格敘述什麼、一切都是共享的資訊，團隊的狀態會很同步一致，但相同的不會有保護自己的心態出現，願意與團隊一起調整一起成長是很重要的。
3.我準備好了嗎：檢視自己在團隊內的角色，推動新的流程絕對會遇到很多困難，和付出很多成本，困難與成本都是可以負荷的嗎?或是本身是一個傳教士的狀態，不怕困難的帶領大家（拖著大家）往理想的世界前進，不畏困難且有信仰！
在網路上的Scrum流程中，我們實務上保留的&我們捨棄的
我們保留的：
- Sprint Planning
- Daily Scrum
- Sprint Retrospective
我們捨棄的：
- Product Backlog Refinement
- Sprint Review
為什麼?
對我們來說，推動Scrum是要讓產品快速迭代以符合產品發展。我們執行的是0到1的產品，以及我們是從5人的開發團隊一路推廣到進15-20人的開發團隊上。在團隊擴張迅速且產品快速從無到有的情況下，對目標有共識、有共同畫面是很重要的環節，所以我們保留Planning 會議，與技術一同訂定目標與預期時間。
且每日的會議追蹤有助益將問題的影響降到最小，我們會說：「開發上有問題時，最晚提出討論的時間是每天站會。」而在這種快速節奏上的開發模式，有可能是常常一轉眼忘記自己做過了什麼，或是同時團隊也在快速擴張，這個時候Retrospective就會很重要。但這也是相對困難的一場會議，網路上有些參考做法可以看看。
至於我們捨棄的
- Product Backlog Refinement
中文名為產品待辦清單精煉會議，是在確定每個Sprint Backlog之前，針對待辦清單內的項目進行討論與優先序與釐清內容的會議。有助於後續的Sprint Planning會議更能明確的安排。現在回頭來看覺得如果有時間可以試著執行看看。
推動心得小結：
在軟體產品開發這條路上，最重要的是找到適合團隊的開發節奏。在這段推動的過程中我們也調整了好幾次開發流程，取消我們覺得不需要的會議、加回曾經被取消的步驟，重新拉回節奏等等。甚至在產品剛上線的時候的節奏也與日常維運、迭代開發時的會不同，對於我來說，Scrum是輔助我們建立一套屬於我們團隊的節奏工具，並不是照本宣科。不是網路上有，我們就一定要做。
在這個推動的過程中我們也受到很多的質疑、不肯定，團隊內的夥伴與團隊外的都有，但使我們堅定運行下去的除了長官的支持以外，穩定地交出符合期待的成果和維持站台品質、快速配合等，漸漸讓大家可以理解這樣的做法是可行且可長期運行的。這段經驗很難能可貴，也整理出來與大家分享，希望有幫助對Scrum有興趣的開發團隊。
其他工作系列文章：
我手上有很多事情要怎麼整理? 第一次聽到甘特圖可以這樣開始
工作系列 – 如何量化自己的工作？掌握工作時間的方法
參考資料
- https://tuna.to/agile-2-73856205bc9e
- https://kaichenlab.medium.com/深入淺出-敏捷軟體開發-scrum-4a9d357ac0a4 https://blog.yveslin.com/2015/05/27/scrum-beginner-introduce-guide-dao-ru-zhi-nan/
- 我如何使用Jira開始跑Scrum? JIRA軟體官方寫得很清楚，可以參考 https://www.atlassian.com/agile/tutorials/how-to-do-scrum-with-jira-software
- https://medium.com/文思不藏私/文思不藏私-產品代辦清單精煉會議-product-backlog-refinement-6e595390f293
- https://www.projectup.net/article/view/id/16678