2016-12-09

Scrum Drawing Game 1.0

[前言]
事情是這樣的 約莫11月初的時候 我的老闆找我談了一下
在年度盛會ETS Global Meeting上是否能準備一個Workshop ?

原本手頭上有兩個已經帶過的workshop 但是都太專門太技術
不太適合ETS 所有的Member

所以我想了又想 想了又想 想了又想
終於在有一天的夜裡

想到了一個很棒的Idea

Scrum Drawing Game 



[設計思維]
在設計遊戲的時候
我站在User的角度去思考
經由這個Workshop 我能學到了什麼

於是我把可能可以學到的項目都列出來:
1. 悶著頭做 可能到最後方向錯誤 不是客戶要的
2. 什麼叫做可以出門的產品
3. Business Value 的重要性
4. 基礎建設的重要性
5. 及早交付的重要性
6. 隨時調整PBI優先順序
7. 隨時整理Product Backlog
8. Retrospective 的重要性
9. 如何達成共識
10. PBI的描述越清楚 越能幫助Team完成任務

所以我設計了以下幾種規則 讓學員能夠體認到上述能學到的觀念
1. 每個Sprint都要Review 隨時檢視
2. 垂直性功能而非水平性功能, 一個角色的完成 一定要有基本的外型,姿勢, 顏色, 位置才能出貨
3. 每個圖畫中的角色都有不同的Business Value
4. 如果完成的基礎建設 可以加快開發速度
5. 越早完成部署 越早拿到好處 賺到的錢會加倍
6. 根據Business Value 調整優先順序
7. 一定要隨時調整Product Backlog 不然你會跟不上
8. 如果能停下來 做個自省 找到改善方法 會比不自省來得好
9. 面對面 隨時討論 隨時也能找PO Sync
10. 訓練PO的邏輯與描述能力

[遊戲流程]
== 產出 ==
一張圖畫


== 隊員分配 ==
每組一個 Product Owner
其他人皆為 Team

== 這個遊戲總共 4 個Sprint ==
每個Sprint 約莫30 分鐘
15 分鐘 做 Plan & Run
10 分鐘 Sprint Revew (all groups)
 5  分鐘 Sprint Retrospective

== Sprint 0 ==
在Sprint 0 , Team 要先準備一張紙版的JIRA
要分成這四個欄位 : Product Backlog, To Do, In Progress, Done

PO 這時要去理解 User想要的圖案是什麼
然後將需求轉化到 Product Backlog

PS. 此時Team可以先幫忙PO把PBI建立起來

== Sprint Start ==
== In the Sprint Planning ==
大家一起討論 要先做什麼
PO 要盡量釐清需求 也要考慮Business Value 也要考慮是否要實作基礎建設

估算出來的Sprint Backlog 要將這些Story貼到 Todo欄位


== Run Scrum ==
PO 這段期間內 要隨時refine PBI 隨時調整優先順序
Team 就按照Story 工作 (new feature or infrastructure)

基礎建設完成之後 隨時可以得到一把剪刀 跟 20%Sample的拼圖

PS. 我安排的基礎建設是 "數獨" 正常會吃掉1~2 Sprint的時間 就看團隊願不願意投資


== Sprint Review ==
1. Demo這個Sprint的產出
2. User 根據產出 不同角色有不同價值 圖案只要超過某個條件 就能拿到價值
2. 其他組可以趁機來觀察一下別組靠什麼賺錢

PS. Feedback要整合進Product Backlog


== Sprint Retrospective ==
檢討 找出改善方案

== Repeat the process ==
重複這個循環直到第四個Sprint結束







[發現]
1. 一開始有幾組先把所有的角色的草圖畫出來 但是沒能得到分數 因為這東西不能出門 (MVP)
2. 由於越早交付 價值的倍數越大 所以應該要先拼提早交付的
3. 狂做基礎建設的組別 得到很多拼圖 交付的產品馬上就趕上來了
4. 目前沒有一組有觀察到User喜好 而隨時更改Story 有點可惜
5. 果然面對面溝通是最有效率的
6. 如果有Member卡住 換人畫畫看


[自省]
1. PO到最後都是在Sprint期間 邊看sample邊描述 提醒member哪邊做錯了
    [S] 1. PO待planning結束得先暫時離開group
           2. PO只有在planning時才能說話

2. 重複計分的問題
    [S] 做分數條 打過得分數就貼在上面

3. 剪刀功用不大
    [S] 其實原本的設計是希望學員把圖給剪下來 再貼到白報紙 這樣才會造成預期的塞車

4. 資源太充足
    [S] 1. 隨機抽走一個人
           2. 一開始白紙太多 或許只需要3,4張 其他用數獨去換

5. 大家都沒在看別人畫了什麼 得了幾分
    [S] TBD

6. 大家都沒做planning或是retrospective 直接繼續埋頭做事
    [S] 強制設下 planning跟retro時間 不做的人就發呆

7. 這個題目的需求是死的 一開始PO看到的sample 是什麼就是什麼 下次可以模擬需求是會變的
    [S] TBD


[看看大家的作品吧]






0 意見: