Du Spirit

No more calculation 症狀 (Symptom):喜歡用公式換算,像是點數換算時數,時數換算點數,換算可完成的 story 數量,點數換時程等等。 討論 (Discussion):分享兩個故事,第一個是我在水果公司的第二年,當時 Android 團隊剛開始起步,那時團隊成員剛組成,少數人對 Scrum 的認知不是很清楚 (有一半以上的人過去有 Scrum 經驗),所以那時 planning 是先把可工作日乘平均實際工作時數,減去會議時間後再乘上人數得到的總時數,作為 story 是否能排進這個 sprint 的參考,planning meeting 後排進的 task 總時數接近上限。即便如此,回頭看 burn-down chart,task 時數預估其實很少有準過,但消化的 story 數卻有逐漸穩定的趨勢。 第二個是我後來的另一家公司,當時已經跑了四個 sprint 的 Scrum team 突然加了兩個人,然後開發的東西完全換了 (使用的技術和語言都和前一個不同),團隊更動後的第一個 sprint,planning 時使用的方式是用信心指數,也就是 task 切完後,Scrum Master (不是我) 從 priority 高的 story 開始問團隊成員:這個 story 排進去有信心完成嗎?一直到團隊成員沒信心為止,當時 planning 完後總 story 數好像是 26 點,task 總時數是印象中不到 100 小時。某天管理層問 Scrum Master:團隊有六人,兩個禮拜的 sprint 為什麼只有不到 100 小時的 tasks?後來那個 sprint 實際完成的 story 數是 31 點,因為在結束前兩天,又拉了一個 5 點的 story 進來,實際的 task 總 (預估) 時數印象中也才一百出頭。在我離開前,團隊消化的 story 數也趨近一個穩定值。

Scrum Bad Smells 2
Scrum Bad Smells 2
圖片出處:https://workchronicles.com/adding-more-people-to-a-project/

No more calculation

症狀 (Symptom):喜歡用公式換算,像是點數換算時數,時數換算點數,換算可完成的 story 數量,點數換時程等等。

討論 (Discussion):分享兩個故事,第一個是我在水果公司的第二年,當時 Android 團隊剛開始起步,那時團隊成員剛組成,少數人對 Scrum 的認知不是很清楚 (有一半以上的人過去有 Scrum 經驗),所以那時 planning 是先把可工作日乘平均實際工作時數,減去會議時間後再乘上人數得到的總時數,作為 story 是否能排進這個 sprint 的參考,planning meeting 後排進的 task 總時數接近上限。即便如此,回頭看 burn-down chart,task 時數預估其實很少有準過,但消化的 story 數卻有逐漸穩定的趨勢。

第二個是我後來的另一家公司,當時已經跑了四個 sprint 的 Scrum team 突然加了兩個人,然後開發的東西完全換了 (使用的技術和語言都和前一個不同),團隊更動後的第一個 sprint,planning 時使用的方式是用信心指數,也就是 task 切完後,Scrum Master (不是我) 從 priority 高的 story 開始問團隊成員:這個 story 排進去有信心完成嗎?一直到團隊成員沒信心為止,當時 planning 完後總 story 數好像是 26 點,task 總時數是印象中不到 100 小時。某天管理層問 Scrum Master:團隊有六人,兩個禮拜的 sprint 為什麼只有不到 100 小時的 tasks?後來那個 sprint 實際完成的 story 數是 31 點,因為在結束前兩天,又拉了一個 5 點的 story 進來,實際的 task 總 (預估) 時數印象中也才一百出頭。在我離開前,團隊消化的 story 數也趨近一個穩定值。

我不確定看完兩個故事後,大家的感想是什麼?第二個故事裡的團隊很混?事實上,我在上面故事裡有一些沒提到的事情,第一個故事裡,接近 sprint review 的前幾天,團隊的下班時間通常也越晚。第二個故事裡,由於新的工作內容是延續加入的那兩位成員的工作,對使用的技術和語言熟悉的人數比是熟悉 2,對上不熟悉 4,估時的時候,時數常會被熟悉的人牽著鼻子走,但實際執行時,不可能所有的 task 都是熟悉的人施工,因此預估值和實際值的差異時常很大,這也是我當初和 Scrum Master 討論用信心指數決定數量的一個原因。

第二個故事還有後續,當時和 Scrum Master 向公司的顧問提到此事,顧問笑著說,很簡單啊!直接把時數乘上一個倍數,塞滿預估值就好啦!重點是讓管理層相信團隊,如果把預估值塞滿能讓管理層相信團隊有好好地做預估,那就把它塞滿,只要 sprint 結束時能有高品質的產出,而且產能是可被接受的,管理層就不會在意這個預估值是被乘上任意數的結果。我能理解這是權宜之計,但心中總是不那麼踏實,所以,後續的 sprint 我們並沒有真的這樣做,之後 可能因為大家慢慢熟悉技術和語言,點數也成長到四十幾左右,至於預估的總時數呢?這就是有趣的地方了,不知道是生性樂觀還是什麼原因,其實很少會超過 100。

基本上,這陷入了一個換算的盲點:就像是氣象預報,預估終究是預估。如果工作的預估和實際的執行是一致的,就不會有《人月神話》中那一句話:用人月的前提必須是人力與工時可以互換的情況下。我並不是說反正執行結果都不會跟預估的一樣,所以團隊成員在 planning meeting 裡可以亂估,而是要回頭想一下,Scrum 裡 planning meeting 的本質是什麼?是在尋找團隊對 story 及 task 的內容取得共識,以及對這個 sprint 能完成哪些項目進行預報,時數和點數只是用來做預報的參考,這也是為什麼大多數都建議 story 用相對的點數進行預估,而不是用容易被誤解的時數。

回顧:《Scrum Bad Smells 1

回頭檢視待完成草稿時,發現這篇的完成度其實已經可以發布了,想想應該是那時寫完這篇文章時,考慮到文中不少當事人都還是同事,也就沒有發布了,如今文中的當事人都各奔東西,那時的團隊也都不見了,我想應該是可以發布,算是為過去的工作經驗留點紀念吧。

--

--