Scrum Bad Smells: No more calculation

閱讀時間約 4 分鐘
raw-image

症狀 (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

52會員
102內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
發表第一個留言支持創作者!
Spirit的沙龍 的其他內容
Agile is Dead?
閱讀時間約 13 分鐘
Scrum Bad Smells
閱讀時間約 1 分鐘
你可能也想看
Daily Scrum 的起源在 1993 年的 Easel 公司,我定期向第一個 Scrum 團隊展示黑衫軍(All Blacks)橄欖球隊為球賽做準備的影片(指有紀錄以來的史上第一個 Scrum 團隊)。這個來自於紐西蘭的黑衫軍,是一個卓越的超乎尋常的傳奇球隊...
Thumbnail
avatar
KK
2023-07-08
Scrum Master 能從學習更多產品管理知識中獲益處在「產品」越來越盛行的世界裡的這個事實,幫助了 Scrum Master (SM) 了解更多有關產品管理的知識。 Product Owner (PO) 作為了解顧客的人, 在排定對顧客具有價值的排序工作上,負有重責大任。 一般來講,在許多國家...
Thumbnail
avatar
KK
2023-06-24
2020 Scrum Guide 的更改與更新說明 (Part 2)2020 Scrum Guide 更新:Scrum Artifact 和承諾 可能 2020 Scrum Guide 中最大的變化在於 Scrum Artifact。 Scrum 中仍然只有三個 Artifact ,即 Product Backlog...
Thumbnail
avatar
KK
2023-06-17
Product Owner 如何跟 Scrum Master 密切工作共同作者:Shalom Chin 與 KK;譯者:KK 你的 Product Owner (PO) 和 Scrum Master (SM) 能良好合作嗎?你的 SM 和開發人員是否將 PO 視為 Scrum 團隊的一份子? Scrum 是以強大團隊合作為基礎的工作方式,尤其是 PO 和 SM 之間的
Thumbnail
avatar
KK
2023-04-18
特別推薦你的Scrum 急件實務處理法「怎麼隕石又來了!急件又來了?我該怎麼處理?」 面對這件事,你的選擇只能是「加班」和「死命的加班」嗎?有沒有更好、更科學的處理方式,能幫助你不加班的順暢解決呢?我相信是有的,並且整理並條列如下的推薦給你: 有效運用 Yesterday’s Weather:Scrum 是一個大量運用數據的科學...
Thumbnail
avatar
KK
2023-04-11
scrum的態度,先做再優化(工作)面試,找工作篇-2023/01/15~20,02/05 1.對於面試,可以先在履歷中有初稿時,先公開發布,之後從「職缺/薪資/工作內容/」決定你短時間要往哪方面加強,然後準備作品集或者新增專案上去。 列技能圖(XMind)檢視自己會哪些東西,以及給資方快速了解你 104找工作職缺,「面試趣」、「比薪
Thumbnail
avatar
Lily
2023-02-06
Scrum帶你上天堂?敏捷開發的優點和缺點/敏捷黑手阿伊Scrum是近年軟體開發方法最熱門的關鍵字,說得像是可以返老還童、起死回生的仙丹妙藥。但台灣真正導入的團隊又沒多少,聲稱導入的團隊又充滿著在地文化的台灣式手法。那麼,到底應不應該導入Scrum呢?
Thumbnail
avatar
吐納商業評論
2021-10-09
Scrum 完成的定義 當一個產品待辦事項或者產品增量被描述為「完成」時,每個人都必須瞭解什麼是「完成」的 定義。 - Scrum 指南
avatar
黃世銘 (Sam Huang)
2018-08-14