敏捷方法的成功密技（十三）：開車旅行跟敏捷式專案管理有什麼關係？

如果你正開車到一個陌生的新景點去旅行，總距離大約是 200 公里左右，而你現在已經開了 160 公里，花掉了你兩個鐘頭，那麼，你知道，過去這段時間，你的平均車速是大約每小時  80 公里左右。現在我們來考慮以下的三種情境。

敏捷方法的成功密技（十二之二）：Scrum 如何精準估算用戶故事的點數？

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

敏捷方法的成功密技（十二之一）：Scrum 如何精準估算用戶故事的點數？

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

敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？

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

敏捷方法的成功密技（十）：Scrum 的衝刺目標誰決定？

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

敏捷方法的成功密技（九）：Scrum 的衝刺目標怎麼訂？

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

敏捷方法的成功密技（八）：Scrum 的衝刺時間長短怎麼訂？

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