The Brackets Scrum to Kanban Switch
這是 Adobe Brackets 團隊從 Scrum 轉換到 Kanban 的經驗. 當他們做這樣的決定時, 很多人問他們為什麼要做這樣的事情. 其實這些決定, 都是團隊在 retrospective 中提出來的 (所以告訴你們一定要做 retro). 那接下來就來看看他們的理由吧.
1. Sprint
在 sprint 結束時通常會有點無聊, 有些工程師會沒事做, 因為已經沒有開發工作. 有些測試人員會很忙碌, 因為他要忙著收尾.照理說, 沒有事情要忙錄的人, 可以開始去處理 backlog 中其他需求, 即使這個需求不需要在這個 sprint 內交付. 可是這在以前 scrum 中做這樣的事情似乎很奇怪.
2. 優先順序
當產品賣得越好, 或是系統越複雜時, 回報的 bug 會越多. Adobe Brackets 團隊就面臨這樣的狀況.
對於 bug 來說, 通常在團隊成員會被視為是額外的負擔, 因為在 scrum 中這是不會得到點數, 只有故事被實作完成時, 才會得到點數, 所以對團隊成員來說會覺得沒有業績.
但是, 老闆會覺得說你在 sprint 後期, 你沒有功能要實作, 這時候你就應該把所有 bug 都該處理掉, 不管是內部找到, 或者是外面回報回來的.
3. 研究性質的故事
大家一定會遇到某個功能, 你需要先研究一下, 才會知道要如何做, 或者是要做什麼. 可是在 scrum 中 sprint 的範圍是固定的, 如果你有一個研究性質的故事, 這個故事是要產出一個明確要做的功能, 可是要等到下個 sprint 才能實作這個功能, 這樣似乎很怪, 無法連起來一鼓作氣.
4. 速度
速度 (Velocity) 是要計算我們能完成多少事情. 可是這件事情不準確, 例如, 有時候遇到突發事件, 或是緊急 bug 要立即處理, 這些都會影響我們完成的故事的數量, 導致最後的速度不代表我們實際的能力.
5. 規劃
在 Scrum 中, 通常可以用兩種方式來規劃時程
(1) 範圍固定: 所有要做的功能加總的點數 / 速度 (每個 sprint 可以完成的點數) = 需要幾個 sprint
(2) 時間固定: (所有時間 / sprint 的時間長度) * (每個 sprint 可以完成的點數) = 最多可以完成多少故事點數
例如: 所有功能的點數加起來是 200 點, 目前團隊速度是一個 sprint (2 週) 可以完成 50 點. 因此需要 4 個 sprint 才能把事情做完. (也就是需要 8 週 )
在 Kanban 中, 我們會用以下方式來規劃時間
cycle time: 某一種大小工作的平均處理時間
throughput: 在某一段時間內, 能完成多少某一種大小的工作
例如: 如果小型工作(當初粗估可以在一週內完成) 平均 cycel time 是 4.5 天完成, 中型工作 (當初粗估可以在一到兩週內完成), 平均 cycel time 是 8 天完成. 那在一個月內, 我們的工作量 (throughput) , 約可完成 6 件小型工作, 或者是 3 件中型工作.
Scrum 方法的強處, 是可以讓你比較準確規劃出發佈的計畫. 因此, 有些人在這方面會有顧慮.但是目前看起來還好.
6. 會議時間
Kanban 會花比較少的開會時間, Scurm 的 planning meeting 會比較久. Kanban 一開始只需估 是小型, 中型, 大型的故事. 然後要拿來做的時間, 才將故事拆解出細項, 所以不會花太多時間. 只要經理能說出下一個要先處理的故事就可以了.
如何, 你是否也遭遇相同的問題呢? 那有沒有想要開始轉換到 Kanban 去呢?
全站熱搜
留言列表
