正相關

April 12 10:36~11:54

 

兩天前回實驗室跟ezScrum團隊討論這禮拜六Scrum課程的投影片。當討論到sprint planning meeting內容時，學妹A問了Teddy一個問題：

學妹A：story point跟工時兩者是否正相關？

Teddy內心獨白：正相關、正相關、正相關、正相關…？

Teddy：你的意思是說一個story的story point愈大，是否需要更多的工時來完成這個story？

學妹A：對。

Teddy：基本上是這樣子沒錯。

此時學妹B又追上來補了一槍。

學妹B：之前在辦Scrum教育訓練的時候，常常有學員會問類似的問題：「有兩個story point分別為5和13的stories，在sprint planning meeting時，如果story point為5的這個story經過工作細分之後發現需要21個小時才能完成，但是story point為13的這個story卻需要80個小時。從story point來看，13是5的2.6倍，但是從工時來看，80是21的3.8倍，這是不是說原本估算的story point要重新調整？」。

***

 

「基本上」story point愈大表示需要更多的時間才能做完，但是story point與工時的關係不能用這樣的數學公式去推算：

有一story 1的story point= 5，其預估工時為21小時。另有一story 2其story point=13，試求story 2的工時為何？

Teddy以前也遇過，story point比較小的story，經過估算之後所得到的工時居然大於story point比較大的其他stories。為什麼會這樣？

關於story point估算的問題，請參考「如何估算 story point？」、「Story point 為何沒有單位：相對論篇」，Teddy今天想講的是，在估算story point的時候，只考慮不同stories之間的「相對大小」，而在將story細分為task時，才會估算工時。雖然story point比較大的story理當花比較多時工時來完成，但實際施工的時候，也可能因為下列因素導致story point比較小的story其工時卻比較大。

• 實施pair programming：如果一個task採用pair programming的方式來實作，工時則要乘二。至於採用pair programming的時機太多了，例如團隊因為有新人加入，所以想要讓新人藉由pair programming的方式來瞭且系統。或是團隊中某開發人員想要透過pair programming的方式來擴展他比較不熟悉的領域。也有可能是這個task要完成一個很重要的核心功能，因此找來兩位高手以pair programming的方式來實作。
• 不預期的工作項目：假設團隊在上個sprint結束前的retrospective meeting中決議要想辦法改善團隊的功能測試自動化程度。因此在這個sprint中Product Owner同意投資10個小時來做這件事。於是團隊就挑選了一個合適的story，為這個story加上撰寫自動化功能測試案例的task。不預期情況的例子還很多，例如某個增強原本功能的story必須要先做refactoring才能夠比較順利的進行，或是在工作細分的過程中跑出新的工作出來。
• 不同的施工人員：同樣的工作，交給不同的人來做就需要不同的工時。Teddy在實施Scrum的時候，雖然基本上每個task是等到daily scrum的時候才動態由開發人員來認領，但是有時候在sprint planning meeting時有些特定的工作經過討論與大家同意之後會先被「特定人士」給認領走。在這樣的情況下，該工作所估算出來的工時，有時候會比大家原本預期的還要來的多。

所以說，story point比較大的story會有比較多的工時，這樣的趨勢基本上是對的。但是以Teddy的經驗，當發現story point與工時之前的比例差異很大的時候，也不用急著去重新估算story point。只要確定增加的工時不是因為原本錯估story之間的相對大小所引起的即可。這樣講還是很抽象，等鄉民們到了「叔叔有練過」的階段之後，就可以慢慢體會。

***

友藏內心獨白：會說出正相關是因為57金錢爆看太多了嗎？