Scrum

敏捷方法的成功密技(十二之二):Scrum 如何精準估算用戶故事的點數?

在上一篇文章敏捷方法的成功密技(十二之一):Scrum 如何精準估算用戶故事的點數?中,我們談到了精準估算用戶故事點數的兩種現象,這一篇文章,我們就要來繼續談談「低估難度」的狀況以及 Scrum 對這些問題的解決之道,藥方為何。

敏捷方法的成功密技(十二之一):Scrum 如何精準估算用戶故事的點數?

在上篇文章當中,我們假設一個工作天的 8 個小時,全部都可以被運用在產品開發的相關工作上,也就是所謂的「理想日」,但是,事實上這是不可能發生的完美狀態!之所以會這樣假設,那是因為要簡化「最佳化衝刺負載容量」這個議題的討論!現在,我們得回歸現實,務實地來看看,一個「理想日」,實際上被運用在產品開發相關工作上的比例,到底是有多少?

敏捷方法的成功密技(十一):Scrum 如何最佳化利用衝刺的容量?

在上一篇文章《敏捷方法的成功密技(十):Scrum 的衝刺目標誰決定?》當中,我們談到了衝刺(Sprint)目標,但實務上 PO 仍應與 Scrum Master 和開發團隊「一起」討論,來制定各個衝刺的目標,這樣才像一個符合 Scrum 精神的「團隊」!

敏捷方法的成功密技(十):Scrum 的衝刺目標誰決定?

在上一篇文章《敏捷方法的成功密技(九):Scrum 的衝刺目標怎麼訂?》當中,我們談完了衝刺(Sprint)目標的制定技巧,但是,這些衝刺目標,到底該由誰來制定呢?我們先來看一下這樣的一個場景…...

敏捷方法的成功密技(九):Scrum 的衝刺目標怎麼訂?

綜合本系列之前的文章,Scrum 其實就是一個小團隊(約5-9人),利用一個個固定短週期的衝刺(Sprint),跟客戶一同逐步漸進地,完成一個產品,而這個產品的功能,就是由一個個,由客戶主導、撰寫的用戶故事(User Story)來呈現需求的(關於用戶故事的簡要陳述,有興趣的朋友可以先參考一下《能讓需求簡化,還能更省時、更省錢,提供更多價值》這篇短文,容日後有空再專文細述之)。

敏捷方法的成功密技(八):Scrum 的衝刺時間長短怎麼訂?

一個衝刺(Sprint)的時間長短到底應該是多少才是最好的呢?如果衝刺的時間設定得太長,那麼,應變的彈性就會變得比較小,而如果衝刺的時間設定得太短,那麼,又容易讓開發團隊能產出的成果出問題。怎麼說呢?