遊戲目的
敏捷是否真能提升研發效率？敏捷對比瀑布有哪些優勢？員工通過直觀的遊戲環節，模擬迭代交付和瀑布交付，更能深刻體會兩者的區別，並理解快速交付、自組織、客戶協作、瓶頸等敏捷概念。
道具
- 紙牌一組12張（也可以是硬幣、籌碼等）；
- 白紙每組兩張；
- 水筆每組一支；
- 角色貼紙；
- 手機計時。
- 預計佔用60分鐘
角色分工
- 每組6-10人，每一組圍着一個桌子站好。
- 每一組需要確定每個人的角色：一個CEO，一個PO，剩下幾對SM-DevTeam模擬幾個團隊。
- 選好角色後，每個人手臂上用角色貼紙貼上角色
![]()
規則
- 工作：DevTeam用一隻手翻紙牌，1次只翻1張；SM/PO/CEO分別計時
- 計時：
- 團隊時間：SM記錄從本團隊的DevTeam收到第一個紙牌，一直到完成所有紙牌的總時間；
- 上市時間：PO記錄從把紙牌交給第一個團隊，一直到從最後一個團隊收到第一張紙牌的時間；
- 項目完成時間：CEO記錄從紙牌交給第一個團隊，到PO收到最後一張紙牌的時間。
- 工作規模：每一輪由組織者說明一個任務規模，每個DevTeam在完成指定的工作規模之後才能把工作移交給下一個團隊的DevTeam。
- 記錄：每個團隊都需要記錄每一輪每個組的團隊時間、上市時間以及項目完成時間
- 標準：每個團隊所有紙牌必須數字朝上，否則無效
團隊記錄
- 每輪完成後，每個團隊需要將記錄的數據填寫到表一：
|
第一輪 |
第二輪 |
第三輪 |
第四輪 |
第五輪 |
|
|
規模 |
|||||
|
團隊時間 （SM） |
|||||
|
上市時間 （PO） |
|||||
|
項目時間 （CEO） |
- 五輪完成後，每個團隊將表一記錄的數據更新到彙總表中對比。
- 備註：由於本次培訓我們每組只有7人，且大家對項目時間和團隊時間較關注，就沒有設置PO角色，只記錄了團隊時間和項目時間。
遊戲環節
練習
- 一次把12張紙牌交給第一個團隊，第一個團隊的DevTeam把所有紙牌翻完之後，交給第二個團隊。這一輪的目的是讓每個人熟悉一下工作，尤其是該怎樣記錄時間。過程中如果正反面翻錯了，需要重新翻。
- 規則：左手
- 規模=12張紙牌，一次下發
- 計劃：2分鐘
- 回顧：每輪之後有2分鐘回顧，對如何改進下一輪工作達成一致
第一輪
- 規則跟練習時一樣
- 計劃：2分鐘
- 回顧：2分鐘
第二輪
- 一次6張紙牌
- 需要注意的是，每個團隊的SM記錄的是從本團隊的DevTeam收到第一張紙牌，一直到完成所有紙牌的總時間；
- 規則：左手
- 計劃：2分鐘
- 回顧：2分鐘
第三輪
- 一次6張紙牌
- 需要注意的是，每個團隊的SM記錄的是從本團隊的DevTeam收到第一張紙牌，一直到完成所有紙牌的總時間；
- 規則：雙手
- 計劃：2分鐘
- 回顧：2分鐘
第四輪
- 一次3張紙牌
- 規則：雙手
- 計劃：2分鐘
- 回顧：2分鐘
第五輪
- 規模降到1，也就是上一個團隊每翻完一張紙牌，立刻交給下一個團隊繼續翻
- 規則：雙手
- 計劃：2分鐘
- 回顧：2分鐘
實際遊戲結果
各組實際數據
| 1組 | 2組 | 3組 | 4組 | 1組 | 2組 | 3組 | 4組 | 1組 | 2組 | 3組 | 4組 | 1組 | 2組 | 3組 | 4組 | 1組 | 2組 | 3組 | 4組 | |
| 規模 | 12，左手 | 6，左手 | 6，雙手 | 3，雙手 | 1，雙手 | |||||||||||||||
| 團隊時間 | 10 | 14 | 16 | 25 | 9 | 9 | 13 | 18 | 8 | 6 | 9 | 14 | 8 | 14 | 15 | 14 | 11 | 15 | 21 | 18 |
| 9 | 10 | 18 | 13 | 10 | 8 | 15 | 12 | 10 | 4 | 10 | 8 | 8 | 13 | 13 | 15 | 12 | 14 | 19 | 17 | |
| 15 | 6 | 18 | 10 | 12 | 5 | 17 | 15 | 10 | 4 | 11 | 8 | 13 | 11 | 14 | 13 | 12 | 14 | 21 | 16 | |
| 項目時間 | 41 | 38 | 60 | 64 | 26 | 42 | 35 | 32 | 21 | 30 | 24 | 24 | 19 | 26 | 23 | 21 | 18 | 19 | 27 | 19 |
對各組數據，從輪數的維度採用曲線圖分析：
從遊戲結果來看，隨着WIP的減少，項目時間越來越短，但是團隊時間卻是先減少後增多。
對各組數據，以小組的維度用曲線圖趨勢線分析：
結果一樣，即每組的項目時間逐漸減少，但團隊時間先減少，後增加。
可見，隨着迭代頻率的加快，確實可以有效減少項目時間，但是團隊要不斷加快步伐，感覺做的事情越來越多，越來越累。說明除了可以採用迭代開發，還要找到合適的迭代頻率，否則可能事倍功半！
結果反思
- 大家對遊戲結果感覺挺驚訝，甚至表示懷疑，爲啥團隊時間會隨着迭代頻率加快反而增加哪？每組的結果都是這樣，說明並不是巧合。
- 實際上，隨着每輪迭代規模的減小，項目完成時間大大縮短，但是項目需要完成的其他活動也顯著增加，比如12張牌一起只要傳遞一次，而如果分成6張、3張甚至1張，那麼傳遞的次數成倍增加，時間自然增加，在精益理論中，這就是一個浪費。可見，若沒有持續集成或者自動部署，那麼每完成一次發佈，都需要配置、運維完成一次發佈操作，如果這幾次發佈能合併到一起，則配置、運維可以減少操作次數，減少工作量。所以，不能僅想着提高迭代速度，經過幾次迭代後，應找出適合自己團隊的迭代頻率。
- 遊戲中，有些團隊搞不清正反面要求而慌了手腳，遲遲沒有啓動。所以產品開發時必須先明確方向（驗收準則），沒有方向時可以假設方向，然後讓客戶快速驗證。
- 團隊的績效可以通過工具（單手變雙手）、經驗（經過多輪工作）改進，但是要想有大的飛躍，更需要方法（由瀑布方式改爲敏捷方式）的創新；
- 規模小的時候，開發的波動會比較小，開發速度會比較快，形成了“流”，這也是我們一直強調要穩定迭代的原因，這樣纔能有穩定的輸出。
- 規模較大的時候，瓶頸現象十分明顯，隨着規模的減小，瓶頸現象逐漸消失。
- 自組織能力非常重要，比如第三組在培訓的時候每個人表現都很好，回答問題也很積極，但到了遊戲環節，需要小組共同配合的時候就落後了，研究了好久也沒搞清遊戲規則，且最後一輪他們的團隊時間和項目時間都是最長的。這時候如果先選擇出一個Scrummaster可能會好很多。
- 各個小組的工作時間都有所波動，但並不影響整體時間，所以優化一個流程需要從整體考慮，而不能只是一味的進行單團隊/個人的優化。
- 如果大家配合更積極，參與更投入，時間會更快，比如這次最快的是第一組（武漢團隊），他們在遠程受干擾較少，所以敏捷中專注很重要。