tag:blogger.com,1999:blog-1298974142445162186.post1238224029966058026..comments2024-03-19T15:58:12.198+08:00Comments on 搞笑談軟工: Scrum 是什麼(16):Story寫得好才容易估算(上)Teddy Chenhttp://www.blogger.com/profile/02066842119056439711noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-1298974142445162186.post-86339012111661212472012-12-27T19:35:55.572+08:002012-12-27T19:35:55.572+08:00Dear Teddy,
關於這個課題,我們有遇到類似的狀況,衍伸出兩個問題,想請教一下您的意見。
...Dear Teddy,<br /><br />關於這個課題,我們有遇到類似的狀況,衍伸出兩個問題,想請教一下您的意見。<br /><br />當進行planning meeting第二階段e估計task時,發現有兩個story會有共同的部分,我們想將它提出來,如:增加一個Story是『允許顧客可以刷卡』,然後將刷卡所需的基礎建設都歸在這裡。<br /><br />而原來的『顧客可以刷Visa卡』與『顧客可以刷Master卡』還是維持,以便分別進行客製化的工作。<br /><br />問題1:<br />如果要這麼做,或是在第二階段才發現story太大應拆解,然後想回頭增加Story,這算是常見的狀況嗎?<br />這麼作會違反Story應該由PO以客戶為出發點來撰寫的原則嗎?(因為這樣的story顯然是受到技術的影響所產生的)<br />又這時應該將這個故事,連同相關的story(以上兩個刷卡)一起重估point嗎?<br /><br />問題二:<br />我知道這麼做也會造成新的story(基礎建設)一定要比客製的兩個刷卡的story先作,這樣好像違反了Story間的獨立性。<br />不過,我們也常遇到story間還是免不了有施作順序的問題。<br />再舉另一個例子:有一個Story是『財務人員要能每天與信用卡公司對帳』。如果不先做刷卡的部分,就先進行這個story,很有可能沒辦法設想到刷卡失敗的所有狀況,而在對帳時分別作不同的處理。<br /><br />因此,是否就忽略其重要性,自行改變其priority?<br />還是實務上真的有辦法寫出彼此完全獨立的Story嗎?<br /><br />問題有些多,不知是不是當初上課沒認真聽到,還望不吝撥冗回覆。<br /><br />非常感謝<br />Rock Chenhttps://www.blogger.com/profile/00048496020060010404noreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-9050600271451834332012-03-22T18:32:42.698+08:002012-03-22T18:32:42.698+08:00To Charles:
雖然估算task的時候會真正估計要花費的小時數,就可以明確的反應出實際所需...To Charles:<br /><br />雖然估算task的時候會真正估計要花費的小時數,就可以明確的反應出實際所需要的時間,但是如果團隊想要知道的是『整價專案的大小』,如果全部都估13,則專案的大小就會被高估了。Teddy Chenhttps://www.blogger.com/profile/02066842119056439711noreply@blogger.comtag:blogger.com,1999:blog-1298974142445162186.post-10610958057202477462012-03-21T10:20:39.598+08:002012-03-21T10:20:39.598+08:00學長,如果兩個都估13點,應該也沒關係吧。
因為到時候切task的時候,會真正估計要花費的小時數,就...學長,如果兩個都估13點,應該也沒關係吧。<br />因為到時候切task的時候,會真正估計要花費的小時數,就可以明確的反應出實際所需要的時間了吧?Charleshttps://www.blogger.com/profile/00337808587732861064noreply@blogger.com