l

2012年3月21日 星期三

Scrum 是什麼(16):Story寫得好才容易估算(上)

March 20 16:52~18:08

image

前情題要:

 

某位鄉民問Teddy一個關於story point如何估算的問題,鄉民們如果曾經有將需求寫成user story的經驗,也很可能會遇到類似的問題。Teddy舉一個比較容易理解的例子來說明這個問題。假設鄉民們要開發一個電子商務網站,其中有一個「信用卡付款」的功能。客戶要求至少要支援Visa與Master這兩種不同的信用卡類型。

這樣的需求要如何寫成story?有兩種常見的寫法:

  • 第一種寫法:身為使用者,我可以使用Visa與Master信用卡付款。
  • 第二種寫法:把兩種不同的信用卡付款方式分開寫成兩個不同的stories。
    • 身為使用者,我可以使用Visa信用卡付款。
    • 身為使用者,我可以使用Master信用卡付款。

假設Product Owner在專案開始之前已經先把大部分的user story給寫好了,這些user story可能只有20%是比較詳細且討論估算過的,其他的user story尚未被Product Owner細分過。此時Product Owner想找開發人員來初估一下每一個user story的story point,以便大致上了解整個計畫的總story point(初估專案大小)。假設Product Owner將上面這個信用卡付款的需求寫成第一種寫法的樣子(在同一個user story中同時實做完成Visa與Master信用卡付款),而開發人員估算這個story的story point為20。到目前為止都沒有問題,但是,如果Product Owner將這個需求採用第二種寫法寫成兩個stories,那麼這兩個stories的story point要怎麼估算?

在這個問題上面,開發人員的意見分成兩派,以下以全真派和古墓派作為區隔。全真派的開發人員認為這兩個user story的大小是一樣的,所以認為應該賦予它們一樣的story point,例如13。但是古墓派的人認為,信用卡付款的需求雖然被細分為兩個不同的user story,但是這個兩個user story有一些共同的功能,如果先做完Visa信用卡付款這個story,那麼Master信用卡user story所需要做的事情就比較少,所以在估算story point時,後者的story point應該比前者要小。古墓派的這種講法聽起來很合理,對不對?

對,但是這又衍生了另外一個問題,假設最後估算的結果如下(括號內的數字表示story point):

  • 身為使用者,我可以使用Visa信用卡付款(13)。
  • 身為使用者,我可以使用Master信用卡付款(8)。

那麼估算完story point的結果已經隱含了上面這兩個user story的施工先後順序,也就是說Visa信用卡付款這個user story要先完成(story point為13),之後才可以實作story point為8的Master信用卡付款這個user story。但是,這樣的相依性如果日後大家都忘記了,當專案正在執行的時候,Product Owner先選了Master信用卡付款這個story來施工(story point為8)。等到下一個sprint,Product Owner要選Visa信用卡付款這個story時,突然鬼遮眼問了開發人員這樣一個問題:「上個sprint不是已經做過Master信用卡付款這個story,該story的story point只有8,那為什麼接下來要做的Visa信用卡付款這個類似功能的story,它的story point反而是13呢?是不是應該要重估一次,改成比8小的值?」

***

把一個比較大的user story切割成若干個相依的小user story,就容易出現上述這種很討厭的問題。將user story以下面的方式重寫是一個可能的解法:

  • 身為使用者,我可以使用「第一種」信用卡付款(13)。
  • 身為使用者,我可以使用「第二種」信用卡付款(8)。

用類似「變數宣告」的方式來表示這個系統會提供兩種不同的信用卡付款方式,至於是那兩種這兩個user story並沒有明確的寫出來。但是因為在user story中有註明「我可以使用第一種信用卡付款」與「我可以使用第二種信用卡付款」,所以在挑選user story的時候,很明顯的一定會做story point為13的「第一種信用卡付款」這個user story。至於等到真正實作的時候,這個「第一種信用卡付款」是Visa或是Master,就由Product Owner依據實際的狀況來決定。

上面提到的這種user story撰寫方法是不是最好的方式,說真的Teddy並不知道,但至少是一個看起來還可以接受的方式。

***

下一集:〈Scrum 是什麼(17):Story寫得好才容易估算(下)

***

友藏內心獨白:Product Owner真的很重要。

3 則留言:

  1. 學長,如果兩個都估13點,應該也沒關係吧。
    因為到時候切task的時候,會真正估計要花費的小時數,就可以明確的反應出實際所需要的時間了吧?

    回覆刪除
  2. To Charles:

    雖然估算task的時候會真正估計要花費的小時數,就可以明確的反應出實際所需要的時間,但是如果團隊想要知道的是『整價專案的大小』,如果全部都估13,則專案的大小就會被高估了。

    回覆刪除
  3. Dear Teddy,

    關於這個課題,我們有遇到類似的狀況,衍伸出兩個問題,想請教一下您的意見。

    當進行planning meeting第二階段e估計task時,發現有兩個story會有共同的部分,我們想將它提出來,如:增加一個Story是『允許顧客可以刷卡』,然後將刷卡所需的基礎建設都歸在這裡。

    而原來的『顧客可以刷Visa卡』與『顧客可以刷Master卡』還是維持,以便分別進行客製化的工作。

    問題1:
    如果要這麼做,或是在第二階段才發現story太大應拆解,然後想回頭增加Story,這算是常見的狀況嗎?
    這麼作會違反Story應該由PO以客戶為出發點來撰寫的原則嗎?(因為這樣的story顯然是受到技術的影響所產生的)
    又這時應該將這個故事,連同相關的story(以上兩個刷卡)一起重估point嗎?

    問題二:
    我知道這麼做也會造成新的story(基礎建設)一定要比客製的兩個刷卡的story先作,這樣好像違反了Story間的獨立性。
    不過,我們也常遇到story間還是免不了有施作順序的問題。
    再舉另一個例子:有一個Story是『財務人員要能每天與信用卡公司對帳』。如果不先做刷卡的部分,就先進行這個story,很有可能沒辦法設想到刷卡失敗的所有狀況,而在對帳時分別作不同的處理。

    因此,是否就忽略其重要性,自行改變其priority?
    還是實務上真的有辦法寫出彼此完全獨立的Story嗎?

    問題有些多,不知是不是當初上課沒認真聽到,還望不吝撥冗回覆。

    非常感謝

    回覆刪除