Jan. 23 22:05~22:59
這禮拜四（1月21日）是C. C. Agile第29次聚會，邀請在遊戲公司工作的Spirit分享Scrum遊戲開發專案的「User Story Refinement（用戶故事梳理）經驗」。主講者的團隊從10人成長到目前24人，致力於開發遊戲特性與社群平台整合的手機App。
講者的投影片可在此觀看並下載，有興趣的鄉民們請自行餵食。Sprint的團隊充分掌握了敏捷開發精神，隨著專案的演進，人員與需求的改變，他們實踐Scrum的方式也演進了至少4個版本。
第N個版本的用戶故事梳理方法，節錄自講者投影片。
***
當天活動開始之前Teddy剛講完另一場演講，趕回公司有點精神不濟。當Spirit在介紹他們用戶故事梳理會議的演進過程時，因為改了太多版本，聽到後來Teddy頭都暈了，已經搞不清楚不同的做法分屬於哪一個版本。演講即將結束前在討論的過程中，Spirit又「預告」他們即將要嘗試第5種做法。
Teddy突然有一種感受，這些不同的做法，似乎並沒有解決整個專案的核心問題。從Scrum的角度來看，Teddy覺得這個專案有兩個非常顯而易見的困難需要突破：
- 專案形式上有3個Product Owner。
- 真正背後的Product Owner因為……（自我消音）。
打個比方，就是總統不用到立法院報告，行政院長或是其他部會首長對於政策沒有最後的決定權。這個情況，好熟悉啊，似乎Teddy曾經在夢中也遇到這樣的狀況：「管你官再大，還是大老闆說了算。」
***
Teddy覺得Spirit的情況可以用「限制理論」的「五步驟聚焦法」（請參考〈[還少一本書] 目標：簡單有效的常識管理〉）來解釋。
- 第一步驟：發現專案價值鏈中的瓶頸（有參加這次 C C Agile 的朋友請露出會心一笑）。
- 第二步驟：嘗試最大化使用瓶頸效能，可惜成效有限，因為「牛仔很忙」。
- 第三步驟：其他非瓶頸的工作階段，也就是Scrum團隊中的所有人，都配合瓶頸的步調調整工作方式。Spirit當晚分享的多次演進過程都屬於這個步驟。
- 第四步驟：接下來要做的事情應該是「把系統的瓶頸鬆綁」，但這一點似乎很難突破。
- 第五步驟：要尋找下一個瓶頸，但是因為第四步驟「革命尚未成功」，所以同志仍須努力。
***
友藏內心獨白：看現場就不會被消音了。
沒有留言:
張貼留言