Agile Summit 2019 – 咕唧咕唧,估計估計

以通訊軟體為核心,LINE 持續發展圍繞用戶生活的各種服務,同時也抱持著開放的態度,積極與不同的平台或開發工具串聯。因此,我們鼓勵、更贊助 LINE 的工程師參與各式各樣的外部研討會,激發更多創意或合作的可能性,並於會後撰寫見聞,分享給 LINE Engineering Blog 的讀者們。

《LINE 強力徵才中!》與我們一起 Close the Distance 串聯智慧新世界 >> 詳細職缺訊息

「敏捷開發」是一種連 Google、Facebook、Apple、Yahoo、LINE 都使用的方式,是一種讓組織可以更聚焦產品與客戶需求,靈活面對需求變化,快速獲得客戶回饋,調整團隊運作流程的一種開發方式。在 Agile Summit 研討會中,邀請國內外知名講師做敏捷分享,還有許多在公司裡擔任 Scrum Master 的講師分享如何導入敏捷開發。無論你是想要了解敏捷開發,還是正在導入敏捷開發,都可以在這場研討會中獲得靈感與答案。

筆者目前在 Line Taiwan 擔任專職的 Scrum Master,因此一聽聞 Agile Summit 研討會訊息,就很想參加這場台灣敏捷圈的盛會,希望透過聽分享和問問題的方式,將一些好的作法帶回自己的團隊中,幫助團隊不斷改進與成長。公司一直很鼓勵員工可以主動的參加各類型的研討會或是社群活動,從活動中帶回一些好的東西,甚至擔任講師分享團隊的經驗。即使活動在平常的上班日,公司也會提供公假鼓勵大家多參加。 

先講結論

我們到底需不需要對 Story 做估計,有的 Scrum Team 覺得有必要,有的 Scrum Team 覺得浪費時間,似乎大家的想法都有點不一樣。我們看看講者是怎麼說的。

要估就估,不估就不估

我自己的想法跟講者很接近,對於一個剛導入 Scrum 的團隊,應該先試試看估點帶來的好處,當團隊變得成熟了,每個 Story 都拆解成適當大小以後,有沒有估點其實已經沒那麼重要了。所以根據團隊的成熟度,可以由團隊自己決定到底要不要估點。

持續完成價值最高的事情

無論團隊選擇要不要估點,永遠都是從 Product Backlog 裡面從最高優先序的項目開始做起。

在各層級調整要做的事情的多寡/大小

估點的目的是幫助我們討論,幫助我們達成目標。當我們發現項目的點數過高,無法在 Sprint 裡完成,我們可以從各個層級中 (Epic, Story, Task) 找尋其他的替代方案來完成相同的目的。 

為什麼要估計?

講者透過破題的方式先把結論帶了出來,接著回到演講的主軸,為什麼我們需要估計?

因為 ROI (Return on Investment),所以公司需要做出決定,到底這個項目值不值得投資。因為 ROI ,公司要知道什麼時候可以得到什麼成果。因為公司不是專家,不知道要做多久,所以請教專家,請教團隊。

如果以公司的角度來看,估點這件事情真得是非常的重要。但是估點本身就帶了點不確定性,造成很多人對他的誤解。我們來看一下不確定錐 (Cone of Uncertainty)。 

出處

不確定錐的 X 軸是開發一個項目的時間序列,依序是 Feasibility、Concept of Operation、Requirement Spec、Product Design Spec、Detail Design Spec、Accepted Software。Y 軸是 Relative Cost Range,大致上可以想像成變異性。所以在一開始資訊不充分的情況下,對於一個項目做估點,往往是不夠精確的,隨著我們投入資源到這個項目以後,當我們累積知識和技能以後,我們就會估得越來越準。

也就是說越晚估計得越準。但是我們估計只是要為了準嗎? 顯然應該有更多背後的意義才對。 

什麼是估計?

講者舉了一個很生動的例子,我們一起來估計。

等一下議程結束以後,你從會場到家裡,估計需要多久?你可能會在一張白紙上寫下 40 分鐘。然後把這張紙拿給你旁邊的人看一下,旁邊的人可能會跟你說,你是用猜的吧。那你覺得你可以猜得更準嗎?

大家可以想想看,我們真得需要猜得很精確,一秒不差嗎?大部分的時候,應該是沒有必要的,我們在白紙上寫下的 40 分鐘,只是為了讓我們傳遞我們回到家需要一段時間,這個時間會大於 30 分鐘這種等級,大概不會超過 50 分鐘這個等級。

從這個例子可以發現兩個事實,估計的點數其實是一個區間的意思,40 分鐘的意思,實際意義上比較像是 30~50 分鐘,是一個區間的概念。另一個事實是,估計其實不需要非常準,估計只是為了幫助討論和傳遞訊息。

所以,估計其實是一種猜測,但是大家很容易把猜測當作是承諾。

但是如果我們真得把猜測當作承諾,其實是超級危險的。我們需要很認真地正視這個問題。 

敏捷團隊做估計的原則?

估計到底要由誰來做呢?Product Owner 還是 Development Team? 最好是由團隊裡的每一個人一起做估計,因為每一個人會由於角色的不同,從不一樣的觀點做估計。所以估出來的點數會有大有小,這時候就是一個很適合討論的時候,讓大家輪流講講看為什麼會估出這麼大或是這麼小的點數。

Story 如果可以正確的切割成適當的大小,估計會比較簡單點,也就是小的比大的好估計。小的 Story 隱藏的風險比較低,比較容易掌握。大的 Story 要做的東西太多,估算自然就難以準確。所以,我們喜歡對小的 Story 做估計。

估計的目的不是為了精準,只是表達出在現在這個時間點,我們對於這個 Story 的一個看法。為了避免團隊落入估算精準的陷阱,在估計的時候,盡可能採用相對比較的方式,會簡單些。

估計的單位可以由團隊決定,原則是不要使用人天 (Man Day) 為單位。因為很容易把人力資源關聯在一起。

估計用人天當作單位,就好像是告訴大家九個孕婦可以一個月生出孩子。

那我們是否還有其他的選擇呢?

最常見的就是團隊會透過 Planning Poker 的方式做估計。每個人手上會有一組牌,牌面分別寫著點數,0, 1, 2, 3, 5, 8, 13, 20, 40, 100, 無限大,藉由出牌的方式,增加溝通與互相之間的理解。有些人或許會很好奇為什麼是這些數字,這些數字其實是費氏數列,因為人類對於這些數值很容易分辨得出相對大小,所以很適合來做 Story Point。

有寫團隊或許會採用 T-Shirt Size 做估計,分別是 XS,S,M,L,XL。

另外還有一些更稀奇的方式,譬如說

  • 水果 (Fruit Point):葡萄,棗子,蘋果,木瓜,西瓜
  • 狗點 (Dog Point):吉娃娃,臘腸狗,西施狗,牧羊犬,黃金獵犬,大丹
  • 三元估計法:Small,Uncertain,Large

不管你準備使用哪種單位,都是有機會可以得到 Velocity。但是我們想一下一個場景,我們這個 Sprint 準備做一個葡萄、兩個木瓜、三個蘋果。搞得我心裡好亂啊,我們的 Story 大小到底是什麼啊? 所以大部分的團隊還是會採用 Story Point,因為做加總的時候比較簡單點。 

想辦法是精華

當我們把全部的 Story 都估計完成以後,結果團隊發現一個 Sprint 做不完,但是 Product Owner 懇切的希望團隊可以在一個 Sprint 做完。那怎麼辦?那我們就得好好的想想辦法了。其實我們還有一個手法,就是在各個層次調整我們要做的事情。

我們可以在 Epic 層級,問問團隊。這個客戶一定要接嗎?這個 Feature 一定要做嗎?

或者在 Story 層級,問問團隊。這個 Story 是為了完成什麼目標?少做點是否可以完成一樣的目標?在先把功能完成的前提下,畫面可以醜一點嗎?

或者在 Task 層級,問問團隊。先把某些值寫死,以後再開回來讓大家輸入可以嗎?一定要開影片嗎?圖片可不可以?

因此,在各層級做 Scope Management 才是重點。估計不是為了準,是為了提出對策的解決方案。 

可是我們就是不想做估計

講了這麼多估計帶來的好處,但是有些團隊就是很不想做,那怎麼辦?其實還是有方法的。

一個成熟的團隊,Product Backlog Item 都是已經根據優先順序做排序。Product Backlog 前面的項目已經在 Refinement Meeting 裡被梳理,反正你下個 Sprint 大概都一定要做了,幹嘛估計? 在 Product Backlog 中間的項目,大概還會有變數,會被修改,既然以後都會變,我們幹嘛花時間去估計? Product Backlog 後面的項目就像是許願池,既然是許願池,估計他要做什麼?

聽起來,還真得滿有道理的。

若團隊決定不進行估計,是否有任何替代方案呢?有幾個步驟還是需要做的,只是把估計這個活動換成另一種形式。我們要把 Story 拆解成 Task,我們不估計 Story 也不估計 Task,而是把一個 Story 在控制在數天內可以完成。接著,我們也需要持續追蹤記錄每個 Story 所花的時間,透過平均的 Cycle Time 做預測。

當我們這樣的進行一段時間以後,大家對於一個 Story 要花的時間就有一個標準了,也就可以拿這個當作未來的時間預測。 

總結

那團隊到底要不要做估計? 筆者的建議是這樣的。如果團隊是剛開始導入 Scrum,根據 “守破離” 的原則,一開始在守的階段,盡可能參考 Scrum Guild 給予我們的建議,盡可能遵守原則,也就是盡可能嘗試估點帶來的好處。當團隊漸漸成熟以後,如果可以把 Story 切成適當的大小,每一個都小小的,可以在數天內完成,透過追蹤 Cycle Time 的方式來代替估計,這樣也是可以的。

Related Post