2016/03/12 — Scrum Workshop

撰文者:Winter Wong (媽我上 Medium 了~)

傳統最常見的專案開發方法就是瀑布式,需求確認後開始設計,之後撰寫程式碼,最後進行測試和上線。但這樣的開發方式常常無法應變快速的需求改變,而導致時程混亂和開發流程無法確實執行。

相較於無法應變改變的瀑布式,敏捷式開發 (Agile) 則更能夠管理改變並擁抱改變,而透過遊戲式的體驗以及 Paper prototyping 來快速了解 Agile 中 Scrum 的專案管理方法則是今天 Workshop 的主要目的。

Scrum初體驗

Scrum 一詞源自橄欖球運動,指在兩隊前鋒對峙下互相爭球。不同於瀑布式直瀉而下,Scrum 在專案的進程中會不斷的循環以及接受回饋,也因此能夠快速的反應需求的改變。

Scrum 中的角色包含Product Owner/Scrum Master/Team Member 其中

Product Owner
主要工作為定義產品,檢視 ROI,以及確認產品需求。PO最重要的事情即是 Build the right thing.

Scrum Master
則是要維持專案開發模式,控制時間,讓成員保持專注,以及意見的收斂,但不負責預估開發時間。如何 Do it fast 是 Master 的責任。

Team Member
主要工作即負責開發,是多職能的成員。Build the thing right.

Scrum流程

介紹完 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 前輪流報告以下三件事:
‧昨天做了什麼事?
‧今天要做什麼事?
‧是否遇到任何阻礙或問題?

Story board

由於前述的問題,我們第一天的時程超級大 Delay,幸好透過與 PO 溝通確認需求,以及 Master 讓討論結果不斷收斂,成員們終能回歸正軌上,將 Task 完成,雖然每天的工作天 (在此 Workshop 中只有 3 分鐘) 都超級慌張,但最後還是奇蹟似地完成了我們的 Prototyping。

5. Sprint review
此階段即是檢視需求是否有被確實完成。

6. Sprint retrospective
寫出此次 Sprint 中做得好以及不好的地方。

Sprint retrospective

7. 重複以上步驟直到專案完成。

Burndown chart (左) 及 Story board

後續心得分享

透過此次 Workshop,能夠直接地了解到 Scrum 實際上是如何進行,但也因為時間有限,很多細節和概念無法說明白,如果要更深入的了解,還是需要去閱讀相關的書籍。

此外,所有的活動都嚴格地計時執行,對於我這個超級初心者來說,實在緊張到不行,還沒吸收完講者的資訊就要開始動作了,完全就是一個胃痛 Workshop。

在與其他不同職業和職位的人討論的過程中,能夠明確的發現自己所不足的地方,例如表達能力不夠好,需要花費很多時間才能將事情描述清楚、和對方達成共同認知;另外也發現,身為工程師,真的很難將自己抽離出來,不去想實作的事情,而要專注在產品的功能和細節的劃分上。

Workshop 最棒的地方是能夠和各個不同領域的人交流,離開自己的同溫層,第一次體驗實在有點緊張,下次要努力地 Go out of table / building!

※ 照片取自 AgileCommunity.tw