之前和朋友談天, 他說在執行 Scrum 時遇到一些困難, 讓他覺得 Scrum 似乎並不是那麼美好. 讓我們來看看他遇到了什麼困境:
1. 基本消費額太高
在每個 sprint 中, Scrum 要進行 planning meeting, daily standup meeting, review meeting 和 retrospective, 很多人在抱怨都一直在開會, 2 周的 iteration 其實不是兩周, 可能只剩下 7-8 天而已. 如果再加上要參加別人的 review, 或是公司的會議, 那其實沒有多少時間在工作上面.
2. 老是估不準
在 planning 時, 我們都會評估可以完成多少工作. 可是在決大多數的狀況下, 我們都是估不準的, 每次都低估了事情的複雜度. 但是我們卻花了不少時間在估算, 在討論 50 % or 90% 的信心程度, 或者在爭吵是否估的太寬鬆. 不是說不要估計, 但是如果多留些時間來做事, 或許能讓事情做得比較快. 這個平衡似乎該多考量一下.
3. 臨時重要的交付工作怎麼辦
人算不如天算, 總是會有臨時緊急事件. 可是 scrum 天生就規定 sprint 中不能改 scope.
如果強迫要加進去, 沒天良一點的, 就是請工程師自己默默吃下去, 但是原先該做的還是要做完.
如果有良心的, 會要再重新估算, 可是這又花了不少時間在討論估計的準確度, 並且要調整原先計劃, 所以又浪費不少時間, 在做一些沒營養的事情.
4. 受不了無止境的衝刺
Scrum 每 2 周的 sprint, 都要交付一些東西出來. 雖然這件事情立意良好, 但是畢竟不是機器人, 心情總會有高有低, 每次都要努力完成目標, 使命必達, 這真的是很煎熬. 如果再加上臨時被塞貨, 又要準時交卷, 團隊成員很難不累倒的.
5. 技術債沒有處理
Scrum 是從管理面來變成 agile, 可是通常執行久了, 會發現程式品質越來越不好, 如果你沒有加上任何好的 engineering practice. 這部分不一定要是 XP 的招式, 可以是傳統的 review, unit testing. 但是沒有的話, 你的系統會很危險, 因為在不斷變動的狀況下, 你沒有安全網來保護你的系統, 早晚會摔死的.
各位朋友們, 不知你們是否也遭遇相同的狀況嗎?