敏捷開發中故事點和估算的秘密


高質量的估算能夠幫產品負責人優化效率和沖突。因此,精准估算的重要性毋庸置疑。

估算並非易事。對軟件開發人員來說,估算堪稱是最難的工作之一。估算必須考慮所有能幫助產品負責人做出影響整個團隊和業務決策的因素。因此,從開發到高管都為它焦頭爛額也不足為奇,但這種做法是錯誤的。敏捷估算並不是什么性命攸關的大事,就只是估算而已,事實就這么簡單。
我們不用要求團隊周末加班加點來彌補一項被低估的工作。換句話說,與其事后補救,不如事前看一看有什么方法可以讓敏捷估算盡可能變得更精准。

與產品負責人(PO)合作

敏捷開發中,產品負責人 要負責確定backlog的優先級次序——即一個按優先級排好序的工作列表,其中包含關於產品所有所需完成的功能和修復的缺陷的簡短描述。產品負責人能夠從業務中提取需求,但他們不一定了解具體如何實現。因此,精准的估算能讓產品負責人對每個工作項目的工作量有新的了解,這對他們評估每個項目的相對優先級能起到一定作用。


開發團隊開始估算后,關於需求和用戶故事的問題會經常出現。這是一件好事:這些問題可以幫整個團隊更加充分的理解工作。對產品負責人來說尤為特別,將工作項拆解為粒度較小的任務,然后通過估算故事點幫助他們確定所有(和可能隱藏的)工作的優先級。而一旦他們得到開發團隊的估算后,可能會再重新排列backlog中的工作項。

敏捷估算是一項團隊工作

敏捷估算的關鍵在於全員(包括開發人員、設計人員、測試人員、部署人員……等等)參與。團隊每個成員都能就產品和需要交付的工作貢獻一個用戶故事。例如,如果產品管理者想要實現支持新瀏覽器這一看似簡單的功能,開發和QA就需要謹慎權衡,因為他們的經驗告訴他們這個看似簡單的需求背后可能隱藏巨大的困難。


同樣的,設計的變更不僅要設計團隊的投入,還需要開發和QA人員的參與。缺乏全員參與的估算會降低估算質量,也會導致團隊士氣低迷,因為關鍵的貢獻者會認為自己被排除在外。所有這些因素都會影響最終交付的軟件質量。


因此,不要讓你的團隊成為封閉估算的受害者。封閉狀態下的估算只會加速失敗。!

故事點和小時數

傳統的軟件開發團隊以時間為單位來估算工作量,例如:天、周、月等等。而敏捷團隊大多采用故事點為計量單位。故事點的相對規模(工作量)用斐波那契數列如0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100表示。這聽起來似乎有點有違常理,但這種抽象的表述實際上能夠促使團隊針對工作的難點做出更果斷的決策。下面是使用故事點的幾點原因:

  • 以日期為單位,無法計量那些無法避免的非項目相關的工作,如需要團隊成員參與的電子郵件、會議和訪談等。
  • 日期可會存在一定的感情因素,而相對估算則可以剔除感情因素。
  • 每個團隊估算工作的范圍略有不同,這意味着團隊的速度(以故事點為計量單位)自然也會有所不同。反過來,這樣就可以避免出現以速度為爭端的團隊間的勾心斗角。
  • 一旦團隊就每個故事點價值的相對工作量達成一致,團隊就可以在無爭議的情況下實現點數的快速分配。
  • 故事點能夠激勵團隊成員以工作難度而非耗費的時間為基礎來解決問題。這確保團隊成員能專注於價值交付,而不是強調花費了多少時間。

故事點和計划撲克

使用故事點進行估算的團隊會用計划撲克的形式來統一團隊的估算值。團隊從backlog中抽取一個工作項,簡單地討論之后,請每個成員在腦海里構思一個估算。然后每個人拿一張卡片,寫下自己的估算值,由scrum master收齊卡片后展示每位的估算值。如果估算一致,那么討論結束,如果存在不同的估算值,就花點時間(無需太久——幾分鍾即可)了解為什么成員給出了不同的估算。記住,估算討論應該抓大放小、提綱挈領,如果團隊過於糾纏細節,則暫停討論,提升討論的水平和高度之后再繼續。

精准估算講究效率,無需浪費時間

任何單個任務都不應花費超過16小時。(如使用故事點,則可以設置20個故事點為上限)。如果單個工作項超過這一工作量,對其進行精准估算會更難。而精准估算對於位於backlog頂部的工作項來說尤為重要。如果單個工作項的估算超過了16小時(或20個故事點)的上限,意味着我們需要將其拆分為更小的工作項並重新進行估算。


對於那些位於backlog下方的工作項,可以只進行粗略估算。因為等到團隊真正開始要做該工作項時,需求可能已經發生了變化,相應的應用程序肯定會有所變化。因此,先前的估算可能就會不那么准確。所以不要浪費太多時間去估算那些可能會發生變更的工作項。只需要提供粗略的估算,為產品負責人提供一個可以用來確定產品路線圖優先級次序的大概數據即可。

借鑒以往估算的經驗

回顧會議是團隊從已完成的迭代中總結經驗教訓的機會,當然也包括估算准確性總結。很多敏捷工具可以跟蹤故事點,這讓團隊可以更輕松地反思和調整估算。例如,我們可以嘗試提取過去故事點估算值為8 的5個用戶故事,討論每個工作項的工作量是否大致相同。如果存在差異,討論其背后的原因。然后將討論得到的經驗用於未來的估算。像敏捷的其他實踐那樣,估算也是一項熟能生巧的實踐。因此團隊肯定會越做越好。

 

Worktile官網:www.worktile.com 

內容整理:Workile

文章首發於「Worktile官方博客」,轉載請注明來源。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM