GetKanban (http://getkanban.com/) 是一套實體的看板遊戲, 可以讓大家在短時間內, 理解如何應用看板到軟體開發上面. 是很值得大家去玩一次看看.
這次連續玩了兩場之後, 個人有些感想, 如果團隊要能有效率的交付, 以下事情每個團隊需要好好考慮:
1. 持續交付 (Continuous Delivery)
如果在產品開發完畢之後, 能夠立刻部署到 staging 環境, 然後進行自動化測試, 來看看這個版本是否符合客戶需求. 這樣才能讓團隊越早知道自己的產品, 品質是否已經禁得起考驗了. 但是要能做到這步, 至少需要做到以下幾個項目:
a. 涵蓋率高的自動化測試
b. 自動化部署的過程
c. 系統測試也需自動化
2. 持續整合測試
Continuous Integration 這件事是團隊品質和效率的基石, 如果你能在早期時, 就準備好基礎建設, 然後在開發過程逐步增加自動化測試的範圍. 這樣你便可以在程式開發完後, 便能快速確認之前的功能, 是否還運作正確. 如果做到這點的話, 你就可以隨時掌握你產品的品質.
3. Swarm
有時候當緊急事件發生時, 這時候便需要有救火團隊出來, 幫部門或公司解圍. 這時候很關鍵的事情, 是否大家願意拋棄本位思考, 拿出資源來共度危機. 如果大家都只想到自己, 那這個燙手山竽就會尾大不掉. 不過, 救火這件事情也不能常常做, 偶而做是為了幫團隊度過危機, 或者是幫業務解圍. 可是老闆或是業務必須思考, 這樣事情若是常常做, 便會嚴重影響手上的工作, 反而讓更多事情變成是真的延遲.
source: http://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000
4. 多技能
有時候當危機發生, 或者是某個角色或工程師很忙碌時, 你可能會需要調度別人來幫忙. 這時候如果你的成員沒有多技能的本事, 想要幫也幫不上忙. 我們並不是要工程師精通很多技能, 但是至少會些基本的東西, 這樣或多或少可以有些進度, 而不會只能在旁邊看看而已.
5. 持續計劃
a. 對於需求要不斷地檢查哪些要先做, 哪些不要做. 唯有週期性地檢視, 才能知道我們把資源用在對的事情上面.
b. 固定交付日期要提早安排, 否則最後就變成是 P1 case, 要用 Swarm 的方式才能解決, 這樣便會影響其他正常的工作.
不過, 這個遊戲買一個要美金 450 元, 也就是說台幣要 13500 左右, 這也未免太好賺了, 學習真的是無價啊…...
留言列表
