這裡有篇記錄他們團隊從 Scrum 轉換到 Kanban 的心路歷程. 讓我們來看看他們的故事吧:
之前 Scrum 的做法
1. 疊代
a. 疊代的長度是 2 周.
b. 禮拜一早上先進行 retrospective, 下午進行 iteration planning. 然後其他時間進行開發.
c. Product Owner 要求我們有兩次 demo, 第一次在第二個星期三, 是在開發環境或是 stage 的環境上進行. 第二次在疊代的最後一天, 是在 UAT 的環境.
d. 如果遇到緊急事件, 疊代會重新計劃, 有些故事會被排到下一個疊代才處理
2. 每天的生活
a. 每天會有一個鬧鐘響的時間, 如果鈴響時, 你還沒出現, 你必須要捐一元當作團隊基金, 供 retropsective 時買 coffee 喝
b. 15 分鐘後, 我們會進行每日立會. 在立會前, 我們會讀取 e-mail, 好讓我們知道接下來會議要討論什麼. (開發團隊在亞洲, 可是利害關係人在歐洲或美國)
c. 我們會紀錄 time sheet (這不是 scrum 的實務), 可以知道我們時間花到哪邊, 跟我們所預估的差多少.
3. 角色
a. 在 scrum 中, 我們有開發團隊和產品負責人 (product owner). 在我們公司 product owner 又稱為 Capability Manager. Capability manager 會分成兩類, 一類專注於技術, 一類專注於商業價值.
b. 我們沒有 scrum master. 但是有個角色叫 release manager, 其職責是傳統專案經理的角色.
c. Capability manager 專注於產品功能. release manager 則專注於故事的規劃, 客戶時程, 和小範圍的調整.
4. 工具
a. Excel:
b. Jira: 後來改用 Rally, Jira 只當 bug tracking tool
c. Rally: agile 疊代的規劃全部放在這裡
因為人力缺乏, 所以團隊同時要處理多份工作, 和多個專案. 每隔一段時間, release manager 會坐在一起討論, 未來幾個疊代, 人力資源要如何分配.
5. 心靈層面
a. Scrum 的重點於精神層面, 而非只是那些要實施的 practice.
b. 例如, 每日立會不是進步報告, 而是資訊分享和協同合作.
c. Release manager 和 capability manager 不會參加每日立會
6. 其他
Retrospective 只會找團隊成員參加, Release manager 和 capability manager 不會參加. 每個團隊成員會輪流主持會議, 所以 retrospective 不會有固定的形式, 就看主持的人決定如何進行.
為什麼我們從 Scrum 轉換到 Kanban
1. 老是估不準
在有些區域的團隊, 因為技術困難度的關係, 很難估得很準. 導致在疊代最後, 落差很大, 導致看起來生產力很差. 我們希望移除這樣估算, 讓團隊成員專注於開發.
2. 承諾帶來很大的壓力
因為估計要多久可以做完後, 團隊成員便要承諾去做到, 這會帶來很大的壓力.
像是我們有兩個 demo 時間, 我們就要確保我們能在哪天準時展示, 有時候因為時差的關係, 便要早一天做完. 或者是要能先安裝好, 可能又要再早一天. 這樣是很糟的惡性循環.
有時候我們對需求都不是很清楚, 可是卻要處罰團隊成員無法承諾所估計的東西. 導致於團隊成員出現防衛的心態, 老是以最安全的方式, 或是偷偷藏 buffer 來進行估計.
我們 Kanban 的做法
1. Kanban board
我們將 chanson board 改成以下 7 個欄位, 以反映我們真實的工作流程
None (也就是 backlog)
Tasking: Release manager 會將事情, 從 backlog 中拿到這裡.
Building: 開發團隊會從 tasking 中拿事情出來做.
Peer Review:
Deploy to UAT: 做完了就會放到這裡
Acceptance: Product owner 會拿 “deploy to UAT” 的事情來驗證
Deploy to LIVE
因為採取 pair programming 的方式, 並且要避免多工. 所以我們 WIP 設定為 4.
2. 規劃
我們沒有所謂的 planning meeting. 基本上, 每當有一件事情進來, 我們會對這個項目進行估計.
3. 展示
我們並沒有強迫哪一天要展示. 但是我們有固定的會議, 那天 release manager 會問團隊是否有東西要展示, 雖然通常答案都是沒有 XDD
4. 評估
我們不再作 story point 的評估. 但是我們還是會紀錄實際的時間和評估時間的比較. 並且從去年開始, 我們使用的 pair day 來做評估
轉換到 Kanban 後的想法
1. 至少不用操心承諾的問題. 把心力專注於交付上面.
2. 當 backlog 內有東西進來, 開發人員有空時, 便要從中拿一個來做, 不管你有沒有這個能力. 如果大家都只是各有所長, 將會影響到團隊的生產力. 因此在 Kanban 的團隊中, 重視開發人員的知識分享, 以及能力的培養.
3. 對於 release manager 來說, 他們會感到比較困惑, 因為改到 kanban 後, 沒有 iteration 導致時程的規劃會很籠統, 不清楚.
參考資料: From Scrum to Kanban
全站熱搜
留言列表
