close
91 寫了一篇文章: "估算需求複雜度（3）如何評估專案時程”, 是談有關如何估算專案多久能完成. 這是一個很好的問題, 也是 PM 們在接觸到 agile 時面臨最大的問題.
因此我把握這個機會, 在 Facebook 的 Scrum community in Taiwan 的社群中, 問了下面幾個常見的問題, 期待能夠得到各方的經驗談
"這個項目不是做的人去估, 這樣會準嗎?" 或者問說: "我又不懂這項, 那估出來的東西有意義嗎?"
"如果時程一直變, 那我很難跟老闆交代. 改一次還好講, 如果改多次, 或是改的幅度很大, 那我還真的很難開口"
"我做的是 contract 的project, 時間和範圍是固定的，那一直變是不行的。或者問說：那 scrum 是不是不合適 contract base 的 project"
“如果 Scrum 的 schedule 會一直變, 那是不是 Scrum 可能不適合很多地方?"
很高興在這次的討論中, 很多人出來分享他們的經驗談, 我把大家的想法整理了一下:
1. Scrum schedule 會一直變, 是在反映團隊現況, product backlog 的現況, 以及每段時間後離目標還有多遠, 是否需要調整目標的順序跟範圍. (91)
2. 利用 agile 的方法去做估算, 這些時程的變動都是有數據作輔助, 而非某個人憑感覺猜想的 (91)
3. 這樣的變動是在告訴老闆真實的狀況. 也就是給他一個有意義的 schedule, 而不是一個達不到的 schedule. (91)
4. 這樣變動的 schedule, 其實是 product owner 讓發現問題的工具. (91)
5. Scrum 的 schedule 不是估的準不準的問題, 而是文化與溝通的問題. Product Owner 是 team 與 stakeholders 之間的橋樑, 用 stakeholders 聽得懂的話跟他們說明時程, 把壓力阻擋在團隊之外, 是PO/SM重要的職責. 壓力必須到PO/SM為止... (董大偉)
6. Run Scrum真的不是流程方法框架問題, 是文化問題. 一個本來就有既定文化和制度的公司, 真的有一定的難度, 是事實, 但也不是全部沒有改變或改善的空間. 做法有很多, 但經驗告訴我, 核心問題最後都在"溝通”上~ (董大偉)
7. contract 如果不是敏捷式合約, 要完整的 run Scrum 也幾乎是不可能的. 只是沒必要 run 完整的Scrum.
8. 即使你無法 run pure Scrum, 把 waterfall 改成 milestones base delivery (例如: 每一個月交付部分功能), 裡面用不用 agile practices 可以再議, 或者你 milestone 內用 mini waterfall 也可以. 但是因為你有定期交付, 就會讓老闆覺得還蠻安心的, 因為你都有進度. 順便也可以定期從客戶得到一些回饋.我比較是從可以得到的好處來說服 boss or PM. (David)
9. iteration 開發的一個重點, 是在讓團隊養成持續改進的文化. 然後在他們遇到困難時, 才慢慢推一些 agile practice 給他們. 也就是利用 gateway drugs 的原理, 來誘拐他們朝 agile 前進 (David)
10. 把 焦點放在大家想解決的痛點上, 可能比較不容易失焦. 比如說針對” 這個項目不是做的人去估, 這樣會準嗎?” 這個問題, 背後的痛點到底是什麼? 是本來常常估不準嗎? 原本個估算方式有盲點嗎? 還是說原本的評估方式曠日費時, 無法套用到快速的 release計畫中? 痛點清楚後, 討論起方法來才會更具體 (Aska)
11. 估算從來都不會準, 做了出來之後才算準. 問題是, 為什麼估算? 誰需要這估算的數據? 而且是用來做什麼的? (Steven)
12. Time and Material 合約會比較能跟 agile 配合 (Steven, 董大偉)
13. 需求的來源如果具有一個比較長一點的沉澱、發展時間, refinement workshop 應該是可以達到一個讓 PO 和 stakeholder 稍稍比較容易掌握目前狀況的一個狀況. (Richard Hsiao)
其實用 waterfall 就可以給個準確的 schedule 嗎? 如果是的話, 為什麼還有這麼多專案 delay? 如果每個人估他自己做的部分, 然後加起來就可以有個比較準確的答案, 那為什麼還有這麼多專案 delay?
Scrum 只是在嘗試另一種方式處理專案時程評估的問題. 它不認為大家在早期估算可以很準, 因此她利用了 whole team approach 來集思廣益. 然後再藉由 iteration planning, 得到回饋, 不斷地修正專案時程.
跟大家分享一下艾森豪的名言: Planning is everything. Plans are nothing! 這就是 agile planning 的精神.
這些理由可以說服你使用 agile 嗎? 即使在估不準的狀況下 XDDD
全站熱搜
留言列表
