昨天在 Lean Coffee 聚會時, 有人問到當 sprint 時間要到, 可是 story 還沒做完, 是否要結束. 這是一個很好的問題, 因為這是一開始執行 scrum 的團隊, 必定會遭遇的問題, 即使是很有經驗的團隊也會碰到.

 

image-4-for-merseyside-schools-athletic-championships-gallery-181149491  


首先, 我們先來看如果延長會有什麼問題:
1. 有可能不知道什麼時候會結束
因為隨時都可能發現某些部分沒做好, 或是忘了做. 或者有些地方因為技術不確定, 很可能不知道還要做多久. 如果 sprint 要展延, 很可能會不知道哪一些才可以結束. 這樣的不確定性, 讓專案很難規劃, 並且老闆也會很擔心你為什麼老是變來變去的

2. 節奏老是不固定
如果 sprint 會延長, 那表示有時候 sprint 可能是 10 天, 有時候是 13 天, 還有時候是 15 天. 員工很難知道這時候是否要進去下個 sprint, 或者該先安排什麼事情. 如果就是固定 2 周(假設從星期一開始), 那他就知道星期一早上就是要招開 sprint planning meeting, 然後第二周星期五下午就是要開 retrospective meeting.

3. 紀律會容易鬆弛
如果你跟大家約法三章說這些事情就是要這樣進行, 可是遇到困難, 或者是一些意外, 就不遵守你約定好的事情, 以後大家都會覺得規定的事情可以打折扣. 我想很多歷史故事可以都可以看出落實規定的重要性. 例如孫武練兵就是好的範例. 並不是說我要 command and control, 但是基本的紀律還是要有的.


因此比較好的方式是準時結束, 然後來檢討為什麼做不到, 是規劃的時程有問題, 還是什麼地方需要改進. 

接著還有人問說, 那 demo 的時候怎麼辦呢? 當然是只有 demo 你有做完的功能. 例如這個 sprint 要做 10 個功能, 你只做完了 7 個, 那就只 demo 7 個. 不要對沒有做完的也 demo, 否則老闆會有錯覺, 認為你都做完了 XDDD

也有人有疑慮如果 sprint 準時結束, 那會不會 engineer 認為做不完也沒有關係? 基本上, 我相信人性本善, 他們都是想實踐自己的承諾. 我想你若是 sprint planning 有說好要做這些功能, 並且要在 review meeting 中 demo 這些功能, 大多的 engineers 都是會儘自己的能力做好. 

所以比較重要的是要在 retropective 中討論可能的原因, 是否有哪些項目要改進, 例如可能是 spec 常常不確定, 或是 review 所花的時間超出預期, 或者原先架構太複雜加個小功能要很多時間. 重點要知道病因, 才能對症下藥. 而不是立馬責怪 engineer.

當然啦, 也是可能會有白目的 engineer, 就是喜歡愛摸魚, 或者真的是能力不勝任, 這時候這種人可能就不是任何 process 可以幫忙的 XDDD



arrow
arrow
    全站熱搜

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