對於需求的處理, 瀑布式和 Scrum 兩者有著截然不同作法, 讓我們看看他們各自如何進行
瀑布式
1. 早期就已經訂定好所有細節.
假設早期就能知道所有細節
假設所有需求項目之後都有人要
假設寫完文件後, 內容就很完整
2. 專案開始做之後, scope 就是確定了, 不能討價還價
3. 如果範圍需要變動時, 需要透過正式的變更控制流程來管理
在多數狀況下, 不但原先的需求要做, 新的需求也是要處理
4. 認為使用者一開始就要把需求寫完整, 知道自己要什麼
5. 會在一開始時, 花費大量的時間, 對所有需求進行分析以及評估
6. 需求項目可能會是一個很大, 需要耗時很長一段時間才能做完的東西
Scrum
1. 細節是在開發期間, 藉由團隊對話的方式, 持續不斷的更新
2. 開發範圍是在開發中是可以調整的
3. 需求能夠依狀況變更, 是 business 成功的關鍵
有時候當時間不夠, 或是沒有資金時, 應該要放棄低價值的需求
如果發現某個需求的價值不高時, 可以從 backlog 中移除
如果發現某個需求價值很高時, 可以考慮將某些低價值的需求移除, 而擺進這個新的需求.
4. 認為使用者無法在一開始就知道自己要什麼
5. 不會在一開始時, 花費大量的時間, 對所有需求進行分析以及評估
在經過一段時間後, 需求細節的部分可能會變, 因此一開始的大量投入可能會是浪費
6. 需求項目要足夠小, 足夠詳細, 可以在一個 sprint 內完成. 但是有可能在處理過程中, 會有更多細節會產生出來.
哪個比較好呢? 如果你的專案真的範圍很小, 或者需求都不會改變, 瀑布式是不錯的選擇.
但是如果你的需求很不確定, 一開始無法了解很清楚, 或者老闆改需求的狀況很嚴重, 我想傳統的瀑布式應該是不行.
不過有趣的是, 即使傳統做法有問題, 但是大家還是不敢嘗試使用 scrum 的方式. 我想其中一個原因是大家習慣瀑布式的做法. ”習慣”確實會讓人安逸於現狀, 即使它再有問題, 大家也有不少應對招式, 所以一時之間還死不了, 因此下次新專案開始, 我們還是繼續使用舊的做法.
所以推行新的東西, 不是只有好的做法就可以, 還需要人心的轉變 …...
全站熱搜
留言列表
