當開發人員在解 bug 時, 常常會有想換種寫法來解決問題的作法. 這個方法比較方便, 可以不用管過去的作法, 尤其是當原先程式不是你寫的.
這時候, 經驗老到工程師會說, 如果沒有找出 root cause, 只是換種作法, 事情可能沒有真正被解掉, 之後有可能會再冒出來.
同樣地, 我們在處理軟體開發, 遇到需求快速變遷, 或是開發時間很長時, 我們也會想換個全新的開發方式, 好讓我們可以很快地應付這些問題. 例如像是使用 Scrum 等敏捷開發方法.
Scrum 有它的效用, 也確實能夠幫忙減緩這些問題. 但是你自己必須想想, 你團隊真正的問題到底是甚麼, 換個作法並不一定真的可以解決你的問題. 因為 Scrum 想解的問題, 可能不是你們團隊真正面臨的問題.
例如有些團隊本來設計品質不好, 又不做測試, 整個交付時間便會拖很久. 當他們採用 Scrum 的iteration 方法開發, 以前半年交 12 個功能會 delay, 現在每一個月交 2 個功能還是會 delay. 因為他們真正的問題(設計不佳, 沒做測試)並沒有處理, 只是想利用 iteration 開發換個做法, 看看是否就不會 delay.
以 Lean 的想法來說, 它就並不是馬上完全換新的作法(Scrum 很激烈的從waterfall 跳成iteration), 它認為你必須先了解自己的開發方式哪裡出了問題, 然後藉由 PDCA 的方式, 一步步改善你的做法, 這樣才能真的解決問題. 而且大多是你組織出了問題, 才導致開發流程有問題, 進而無法即時交付產品.
Lean 是想從你原先的開發流程中, 觀察出你設計過程不過嚴謹, 導致後面重作(rework)或是 bug 情況嚴重, 想辦法一步步改善這樣的狀況, 然後才有機會達到 scrum 所想要 iteration 開發的境界: 每一個月準時交覆某些功能, 不會讓測試是 one iteration behind.
因此在採用全新作法(Scrum)時, 記得要確認你真的有找到 root cause, 否則那些問題是會再發生的
留言列表
