估算需求複雜度(3)如何評估專案時程
估算需求複雜度(2)Dog Point Game << 前情 在上一篇文章中提到,該如何讓敏捷開發團隊透過 Dog Point Game 來熟悉相對估算的精神,並以團隊一同進行估算的方式,針對需求複雜度取得相對客觀的共識。 然而,一個傳統團隊要成功轉型成 Scrum 開發團隊將面臨許多困難,其中有很大一部分是來自於產品擁有者(Product Owner, 後續簡稱 PO )的思維,是否能接受敏捷開發的概念。想讓 PO 接受敏捷開發,就必須先瞭解 PO 的需求以及他可能會碰到的問題。只有協助滿足他的需求,解決他的問題,才能建立 PO 與 Team 之間的信任。 而 PO 最重要的問題之一就是「如何評估專案時程」,這篇文章將提出一種能在 Scrum 中運用的相對評估方式,以實際推估的數據,來隨時回答 PO 這個棘手的問題。
迷思在 PO 詢問團隊:「能否讓我知道,這個專案你們預計多久可以完成?」 團隊請千萬不要回答:「因為我們 run 敏捷開發,所以要到實際估算時才會知道每一個 story 要花多久。而且我們只估算接下來的 1~2 個 sprint ,因為之後的一切都會變化,估了也估不準,告訴你也沒用。」這樣的答覆只是在逼你的 PO 走回頭路。 PO 心想:為什麼在傳統的開發方式中,開發團隊至少可以透過工作分解結構(Work Breakdown Structure,簡稱 WBS)來評估一個時程目標,反而到了敏捷開發變成「做多少,算多少」這種不負責任的態度?那還不如用傳統的方式來進行開發,至少讓我可以對我的老闆跟客戶交差,至於品質與時程,當然還是開發團隊要負的責任,跟我 PO 無關。而且敏捷開發不是說要擁抱變化、儘早交付、鼓勵需求異動?到時候我看你們怎麼死的。 當 PO 開始用這樣的態度來要求團隊時,團隊成員就會覺得這個 PO 沒有敏捷心態(Agile Mentality),是個不知上進、改變、跟不上趨勢潮流的落伍角色,而又開始製造出角色之間的對立。
Step 1:按順序整理好 Product Backlog Items首先請 PO 整理好整個專案的專案待辦項目(Product Backlog Items,後續簡稱 PBI),別被詞彙嚇到了,其實就只是在專案範圍內,有哪一些 features/stories/function list 需要完成。 請記得,在敏捷開發中的優先順序(Priority )相當重要,因此當所有 PBI 都被整理出來後,務必請 PO 按照優先順序排好。 若以開發一個購物車系統的部分需求來當例子,如下表所示:
Step 2:以 T-Shirt Size 來定義 PBI 的相對大小這個步驟相當簡單,先以 t-shirt size (Small, Medium, Large) 三種等級來定義 PBI 的相對大小。 PO 只需要問自己:「如果只有大、中、小三種 size 的話,這個 PBI 應該屬於哪一種等級?」
假設 PBI 在 PO 評估完 size 後,結果如下表所示: 把整個 PBI 的大小等級都分類完後,應該每個 size 都有被使用到,否則可能需要協助 PO 回顧一下,這樣的相對分類是否需進行調整。
Step 3:使用 Sprint 0 進行穿刺實驗接著有兩種方式可以方便估算出,整個 product backlog 需要團隊花多少時間才能交付。假設目前團隊正式的 sprint 時間為 2 週。
不論採用何種方式,期望得到的資訊如下:
以 sprint 0 的 spike solution 為範例,假設估算如下所示: 假設這三個 PBI 團隊總共花了 1 週的時間完成 (4/20~4/26)。因此可以得到以下的推估:
目前 product backlog 上分別有 2 個 L , 2 個 M , 2 個 S 共 6 個 PBI 。以上述兩個資訊為基礎,可以推算出完整的 product backlog 總大小為 2*20 + 2*13 + 2*5 = 76,剩下的 product backlog 大小為 38 。 團隊每個 sprint 可完成 76 個 story point ,因此要消化剩下的 PBI 只需要 38/76 = 0.5 個 sprint ,也就是一週的時間,也就是若 4/27 開始進行,可以在 5/3 完成整個專案。 考考你如果經過 Spike 試驗後, L 為 40 , M 為 20 , S 為 10 ,每個 sprint 為 2 週,團隊的 velocity 為 50 ,sprint 1 從 2015/5/4 開始進行,那麼下面的 product backlog 何時可以完成? 推估如下:
結論透過上述簡單的三個步驟,Scrum 團隊以實際的估算來相對推估出整個 product backlog 的大小,並以實際的產出來推估出團隊的 velocity。 其重要的精神在於:
這樣的方式帶有幾點好處:
最後,我個人比較喜歡使用「推估」而非「預估」,雖然相對估算並放大很可能會帶有誤差,但總比過去 WBS 那種以個人過去經驗來「猜測」整個專案的時程來得可靠得多。 請不要再把 PO 推向懸崖了,請把 PO 當成團隊最重要的一員,只有成為「一個團隊」,衝刺(Sprint)才會是同個方向,才會有力道。
|
joeychen
04/29
針對這個議題,在 Scrum Community in Taiwan 的 Facebook Group 裡面有幾位好朋友的討論,David 幫忙整理成文章了,個人覺得對這議題在實務面會碰到的問題,很有幫助。
提供給大家當參考:http://kojenchieh.pixnet.net/blog/post/420903523