之前和朋友談天, 他說在執行 Scrum 時遇到一些困難, 讓他覺得 Scrum 似乎並不是那麼美好. 讓我們來看看他遇到了什麼困境:

 

US_Navy_110813-N-XS652-351_Runners_navigate_an_obstacle_during_the_11th_annual_Armed_Services_YMCA_Mud_Run_at_Joint_Expeditionary_Base_Little_Creek  

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. 但是沒有的話, 你的系統會很危險, 因為在不斷變動的狀況下, 你沒有安全網來保護你的系統, 早晚會摔死的.

各位朋友們, 不知你們是否也遭遇相同的狀況嗎?

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(3) 人氣()