前一陣子, 討論到員工不應該同時處理太多事情, 因為多工代表 interrupt 太多, context switch 會導致太多浪費, 會讓工作效率降低.
我想這件事情大家基本上是同意的. 老闆不能同時叫員工處理很多事情, 然後又希望他又快又好.
所以推到 Scrum 來說, iteration 中不應該加入新的功能或事情, 應該要堅守原先既定的範圍. 這件事情應該絕對是對的, 不遵守就是假的 Scrum, 假的 agile.
我想很多人會這樣想, 這樣指責長官們.
讓我們來想想, 當初 agile 為什麼會產生?
當初開發的流程流行的是 CMMI, RUP 或者是 ISO, 假設需求一開始就很明確, 或者不應該變動, 因此接下來就可以專心好好把它做好.
可是在那時候的環境, dot com 的發生, 很多事情不斷在變化, 新的事物不斷在產生. 因此, 傳統的做法, 已經無法因應這樣的狀況. 所以我們要有新的思維, 不同的做法, 來讓我們可以對付這樣的情況.
因此, agile 是為了讓我們有應變 change 的能力.
Scrum 的疊代架構, 便是要讓我們可以對付不斷變的世界, 可以每隔一段時間, 根據外面的回饋, 調整我們的腳步.
這只是一種做法, 一種處理 change 的方式, 但是不是代表你加了新功能, 新的 bug 來處理, 你就不 agile.
這就像 system thinking 中提到的, 任何一種解法都會帶來 side effect. 他可以解決目前的問題, 但是也會帶來新的問題.
Scrum 的 sprint 就是這樣, 限制一段時間內範圍不變, 一方面可以專心, 一方面也可以因應新的需求做調整. 看起來是很棒的. 但是, 如果你的環境是不斷在變, 或者是剛好遇到一個超緊急的 bug, 你變還是不變呢?
Sprint 在某些環境下只是症狀解, 基本解應該是讓團隊成員有因應 change 的 mindset. 症狀解總是會有副作用, 所以不少人會在緊急事件這種狀況挑 scrum 的毛病. 基本解應該是平時是 sprint 的做法, 但是遇到緊急事件時, 可能要考慮是否要調整 scope 來度過難關, mindset 是要根據環境的狀況做出適合的 change.
所以遵守 sprint 的原則是 doing agile, 你應該讓自己慢慢調整到 being agile, 根據 change 來作出合適的調整. 並且記住任何解法都有副作用, 沒有所謂的銀製子彈.
全站熱搜
留言列表
