傳統最常見的專案開發方法就是瀑布式，需求確認後開始設計，之後撰寫程式碼，最後進行測試和上線。但這樣的開發方式常常無法應變快速的需求改變，而導致時程混亂和開發流程無法確實執行。
相較於無法應變改變的瀑布式，敏捷式開發 (Agile) 則更能夠管理改變並擁抱改變，而透過遊戲式的體驗以及 Paper prototyping 來快速了解 Agile 中 Scrum 的專案管理方法則是今天 Workshop 的主要目的。
Scrum 一詞源自橄欖球運動，指在兩隊前鋒對峙下互相爭球。不同於瀑布式直瀉而下，Scrum 在專案的進程中會不斷的循環以及接受回饋，也因此能夠快速的反應需求的改變。
Scrum 中的角色包含以下：
‧Product Owner：主要工作為定義產品，檢視 ROI，以及確認產品需求。PO 最重要的事情即是 Build the right thing.
‧Scrum Master：則是要維持專案開發模式，控制時間，讓成員保持專注，以及意見的收斂，但不負責預估開發時間。如何 Do it fast 是 Master 的責任。
‧Team Member：主要工作即負責開發，是多職能的成員。Build the thing right.
介紹完 Scrum 中的角色區分，主講人給定各組一個主題「關於台北」，並要求製作此主題的平板 App paper prototyping。接著便進入 Scrum 的流程。
0. 討論主題
透過 User story 的情境設置，能夠讓主題更明確，例如我們的主題是：As a 一個台北的捷客 (捷運使用者)，I need 知道距離目的地最近的捷運出口，So that 不會浪費很多時間在繞路上。
1. Product backlog
討論完主題之後，首先要指定組內的 PO，由 PO 主持討論，定義出此主題的 Feature (Product backlog) ，並由 PO 決定這些 Feature 的順序 (Priority) 。
這些 Feature 必須被定義的很明確，例如選擇捷運站，輸入目的地，顯示地圖、導航等等。
在實作過程中，由於我們在 Feature 的定義不夠明確，所以在後續出了一些問題。
2. Sprint planning meeting & Sprint backlog
在 PO 定義完功能之後，Team member 根據這些功能去切分成小的 Task，並預估可能花費的時程。這些 Task 會被區分為三個階段，分別是To do、Doing 及 Done。
誠如前面所述，由於 Feature 的定義不夠明確，導致在此階段要切 Task 時，Team member 無法確切知道應該如何切割。發生此狀況時要不斷地與 PO 再次確認需求，以確保雙方的認知是一致的。
3. Sprint (一次時程為 1~4 週，不宜超過一個月)
在此階段 Team member 開始認領工作，Scrum master 根據 Task 數量及時間規劃繪製 Burndown chart。
4. Daily scrum meeting
透過每天簡短的 Meeting 來掌握時程與進度，每個成員在 Story board 前輪流報告以下三件事：
‧昨天做了什麼事？
‧今天要做什麼事？
‧是否遇到任何阻礙或問題？
由於前述的問題，我們第一天的時程超級大 Delay，幸好透過與 PO 溝通確認需求，以及 Master 讓討論結果不斷收斂，成員們終能回歸正軌上，將 Task 完成，雖然每天的工作天 (在此 Workshop 中只有 3 分鐘) 都超級慌張，但最後還是奇蹟似地完成了我們的 Prototyping。
5. Sprint review
此階段即是檢視需求是否有被確實完成。
6. Sprint retrospective
寫出此次 Sprint 中做得好以及不好的地方。
7. 重複以上步驟直到專案完成。
透過此次 Workshop，能夠直接地了解到 Scrum 實際上是如何進行，但也因為時間有限，很多細節和概念無法說明白，如果要更深入的了解，還是需要去閱讀相關的書籍。
此外，所有的活動都嚴格地計時執行，對於我這個超級初心者來說，實在緊張到不行，還沒吸收完講者的資訊就要開始動作了，完全就是一個胃痛 Workshop。
在與其他不同職業和職位的人討論的過程中，能夠明確的發現自己所不足的地方，例如表達能力不夠好，需要花費很多時間才能將事情描述清楚、和對方達成共同認知；另外也發現，身為工程師，真的很難將自己抽離出來，不去想實作的事情，而要專注在產品的功能和細節的劃分上。
Workshop 最棒的地方是能夠和各個不同領域的人交流，離開自己的同溫層，第一次體驗實在有點緊張，下次要努力地 Go out of table / building！
※ 照片取自 AgileCommunity.tw