Categories
程式開發

速度(Velocity)不背這個鍋


本文首發於【林子的空間“】

01. 那些對速度的誤解

誤解1 – 點數跟天數對應?

用戶故事的估點跟天數對應,1個點的故事對應2天的工作量;統計每個用戶故事所耗費的天數,如果點數對應的天數到了,先標記為“開發完成”,第二天Desk check就不用增加天數了;為了趕進度,由結對改為不結對,原來結對的兩人並行做不同的task,天數還是按照結對的情況來統計…

問題:

雖然按照故事點來估算,但是每個點都跟天數對應起來,而且不是理想人天,是實際耗費人天;把這種估算當做一種承諾,要求故事需要在點數對應的天數內完成;用戶故事的只是關注開發完成。

到底該如何估算?點數又該如何使用呢?

誤解2 – 做不完了給用戶故事漲點?

如果用戶故事沒有在預定的天數內完成,需要漲點,那麼得先說服客戶;列出漲點原因並且跟客戶解釋不是一件容易的事情,團隊有時候寧願加班加點按照原來的估點完成也不要去跟客戶解釋… 或者,為了避免以後漲點的各種麻煩,在估算的時候多估一些點,導致估點不准確…

問題:

開發團隊的估算不應該受到外部因素的影響;虛估點導致的估算不准確失去了估算原本的價值和意義。

估算的意義是什麼?什麼時候需要調整點數進行重估?

誤解3 – 速度驅動一切?

週報裡的速度保持穩定,每週每對pair在2個點上下;性能調優,客戶覺得目前看不到價值不給點,所以團隊就不做了;技術改進,同樣的,客戶看不到價值不給點,就不做了;或者團隊實在無法忍受想要改進,那就從別的功能用戶故事裡多估算一些點來留時間給做技術改進;目前組內開發速度不夠,用戶故事都做不完了,生產環境的support能給別的組就給別的組做吧,那個太耽誤開發進度了!

問題:

一切圍繞速度,如果比較順利,滿足了速度要求,團隊可能就放鬆了,不一定會做更多的特性開發;如果不順利,速度趕不上,那就可能面臨著加班或者愁著怎麼能給故事漲點以增加速度;不再是業務價值驅動,不會正常的從價值的角度去考慮工作的優先級,速度被嚴重的誤用。

速度有什麼用?又該如何利用呢?

帶著這些誤解中引發的疑問,我們一起來探討一下。

02. 兩種估算方法

1. 基於故事點的估算

故事點是純粹對用戶故事大小的相對度量,不應該跟任何的天數或者工作量等關聯。

用戶故事本身的大小屬性不會發生變化,基於故事點的估算不會過期,不會受到團隊技術能力和業務領域熟悉度的影響而發生變化。比如,一個點數為3的用戶故事,它的複雜度相對於那個點數為1的基準故事來說不會發生變化,不管誰、也不管用什麼技術來開發這個用戶故事。

故事點的大小是指團隊所有角色工作加一起的統一估算數值,需要多個角色一起合作討論才能得出這個估算,因此,故事點的估算方法有利於幫助團隊實現跨功能合作的行為。特別注意,不應該按照開發的點數、測試的點數去估算用戶故事的大小,需要結合一起給出一個唯一的數值。

2. 基於理想人天的估算

理想人天的估算需要基於這樣的假設:

所估算的故事是唯一要做的工作所有需要的東西在故事開始前都會準備好故事開發過程中不會被打斷。

在不考慮其他因素的情況下,這種理想人天的估算是類似於故事點的估算方法,同樣是一種相對大小的估算。

理想時間跟耗用時間是不同的。比如一場NBA比賽的理想時間為12分鐘一小節,但是實際比賽耗用時間需要比這個時間長很多,因為中間有暫停、死球等時間。理想人天的估算是基於理想時間的,在軟件開發過程中會有多個因素導致實際耗用時間跟理想時間會有很大的不同,比如開會、討論等。

理想人天的估算方法很容易讓人根據一個故事所需完成的任務多少去估算,而不是從這個故事跟其他故事的相對大小角度去考慮;不同人估算的理想人天也會有不同,導致估算可能會不太準確。這在估算的時候是需要特別注意的。

在團隊不熟悉故事點估算方法的初期,理想人天的估算方法更容易開始;理想人天的估算對於團隊外部人員更容易解釋清楚,也更方便預測速度。

哪種方法更好

從前面的介紹可以看到,兩種估算方法各有利弊,都是對於用戶故事大小的相對度量,不能跟實際完成天數關聯起來。通常,更推薦使用故事點的估算方法,根據團隊自身情況也可以選擇採用理想人天。

##03. 什麼情況需要重估

前面提到的誤解裡對於用戶故事沒有在預定的天數內完成考慮給故事漲點,也就是重估,這種以進度來驅動重估的做法是不對的。沒有在估算天數內做完可能有兩個方面的原因:1. 估算不准確,低估了;2. 被其他工作所打斷,或者團隊技術原因導致進度較慢…

發現估算不准確的情況可能需要調整,但不能是因為做不完趕不上進度而調整。當所有用戶故事的相對大小是準確的時候,不需要重估;只有當其中一個或多個用戶故事的相對大小不准確的時候,需要調整該部分用戶故事的點數大小。

我們來舉例解釋這個問題:

1. 不需要重估的情況

假設一個團隊有4個複雜度相當的用戶故事,原本估算均為3,預計能夠在一個迭代完成的。在第一個迭代結束後,只完成了其中的兩個用戶故事,也就是完成了6個點,團隊感覺這兩個用戶故事比預估的要大,想調整為原來點數的兩倍,由6變成12;由於四個用戶故事的大小相當,剩下的兩個用戶故事也需要調整為原來的兩倍,剩下的工作量也變成了12,同樣的可能還需要一個迭代才能完成。這樣的重估就沒有意義。

因此,如果只是發現用戶故事實際耗費時間比原來預測的要多,但是故事的相對大小並沒有問題的時候,不需要重估,而是要去回顧和分析耗費時間長的原因,並採取相應的措施去改進。

2. 需要重估的情況

假設團隊由A、B、C、D四個用戶故事,剛開始給每個故事的估點均為3。在開發故事A的過程中發現A比原來估算的值要大,需要調整為5才合適,另一個類似的故事B也是一樣,需要調整為5;但是C和D跟它們不一樣,估算值應該是準確的,還可以保持為3。這種情況下對A和B的重估是有價值的,因為相對大小發生了變化。

04. 速度的作用

速度是對團隊的進度生產率的度量,可以通過計算團隊在一次迭代中完成的用戶故事所分配的故事點數的總和來得到。比如,完成5個3個點的用戶故事,速度是15;如果完成了2個5個點的用戶故事,速度是10。關於“完成”的定義不能只是到“開發完成”,而應該是“交付完成”,開發完成不能說明什麼,可能後續測試還不能過關、有很多缺陷需要修復等情況。

速度可以修正計劃的誤差。估算把對工作量的估算和對工作時長的估算完全隔離開來,將必須完成的所有用戶故事的點數總和除以迭代的速度,可以推算出迭代的次數,也就是項目持續時間。我們通過一個例子來看速度如何修正誤差:

>假設團隊估算出項目中包含了200個故事點的工作,一開始認為可以在每次迭代中完成25點,也就是將用8次迭代來完成工作。但是,在項目開始以後,團隊發現速度只能達到20點。這樣,不用對任何工作進行重估,就可以正確的認識到項目需要10次迭代,而不是8次。

速度不會是穩定不變的。根據團隊對技術和業務領域知識的熟悉程度,速度可能會增加;而隨著團隊人員調整,有新人加入以後,速度可能會下降。在故事點估算準確的情況下,速度正好是反映團隊狀態的一個參數。不應該為了保持速度的不變去調整估算的結果,而應該根據速度的變化來觀察和分析團隊的健康程度。

05. 估算與計劃

估算是為了更好的做計劃,通過估算推算出的持續時間是一種可能性,而不是對交付時限的一種承諾。估算的是用戶故事固有的屬性,其大小不應該受到交付時長的干擾。老馬在文章《瀑布過程“》裡講到敏捷開發里的計劃應該是適應性的,而預測性的、承諾性的計劃不屬於真正的敏捷。我們需要認真做好估算,盡量的準確,利用速度並根據團隊狀態和其他項目因素來適時地調整、修正計劃。

速度(Velocity)不背這個鍋 1

客戶都會希望更短的時間交付更多的功能,但是不要讓客戶只把目光關注到進度上,要引導客戶更多的關注交付的業務價值。因此,在考慮任務的優先級的時候,需要以價值為導向,而不是進度為導向。比如,重構等技術改進、性能調優、生產環境的支持,這些可能比新的特性開髮帶來的價值更大、有著更高的優先級。

06. 小結

不管是故事點還是理想人天的估算方法,估算的都是用戶故事的相對大小,跟實際完成時間沒有直接關係。不能因為用戶故事沒有在預期的時間內完成而進行重估,只有相對大小發生變化的時候需要重估。估算是為了更好的計劃,不能把估算當做一種承諾;速度是可變化的,可以用來修正計劃的誤差。始終要以價值為導向,更多的關注質量而不僅僅是進度,計劃應該是可適應性的。

07. 參考文獻

《敏捷軟件開發實踐:估算與計劃》,作者:Mike Cohn,譯者:金明《點之殤“》,作者:冉冉,https://insights.thoughtworks.cn/story-point/《瀑布過程“》,作者:馬丁·福勒,https://martinfowler.com/bliki/WaterfallProcess.html