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

在上一篇文章《敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？》當中，我們談到了怎麼將點數／心力（Point、Effort）大小不一的各個用戶故事，依照用戶故事的優先級先後，排進衝刺（Sprint）內去實做。也談到了如何拆解肥大的用戶故事為數個小故事，以便能繼續將該衝刺的剩餘空檔也能盡量地塞滿，以最佳化該衝刺的負載規劃。

可是，這些作法都必須奠基於「夠精準的用戶故事點數估算」這個前提之下才有意義！那麼，實務上，我們到底應該怎麼來估算用戶故事的點數，才能稱上「夠精準」呢？

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

在上一篇文章《敏捷方法的成功密技（十）：Scrum 的衝刺目標誰決定？》當中，我們談到了衝刺（Sprint）目標，雖然名義上應該由 Product Owner（產品負責人）來制定，但為免團隊根本就不 buy-in，或是團隊實在是無力可達成，故，實務上 PO 仍應與 Scrum Master 和開發團隊「一起」討論，來制定各個衝刺的目標，這樣才像一個符合 Scrum 精神的「團隊」！

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

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

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

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

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

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

敏捷方法的成功密技（七之二）：Scrum 的夢幻開發團隊該怎麼來建置？

[承上一篇]

接續上一篇文章《敏捷方法的成功密技（七之一）》，除了新領域、新團隊，最有機會嚐試新作法之外，我們也談到了，只要開發團隊夠紮實，產品的開發就能夠打帶跑，因為品質才能夠被掌控得好。怎麼說呢？

敏捷方法的成功密技（七之一）：Scrum 的夢幻開發團隊該怎麼來建置？

在上一篇文章《敏捷方法的成功密技（六）：Scrum Master  並非你想像的那般卑賤！》中，我們談到了 Scrum Master 這個角色，其實最好是由一位開發和管理經驗豐富的人來擔任，工作經歷不足的菜鳥，是很難勝任得好，更很難以服眾的。

敏捷方法的成功密技（六）：Scrum Master 並非你想像的那般卑賤！

在上一篇文章《敏捷方法的成功密技（五）：Scrum的三種角色》中，我們談到了Scrum定義的三種角色，而其中Scrum Master這個角色應該是最令人感到困惑的一個。

敏捷方法的成功密技（五）：Scrum 的三種角色

在上一篇文章《敏捷方法的成功密技（四）：Scrum的理想與現實的障礙》中，我們談到了Scrum明確定義的三種角色，Product Owner產品負責人、Scrum Master 大師，以及Development Team開發團隊，接下來我們就一一來看看。

敏捷方法的成功密技（四）：Scrum 的理想與現實的障礙

在上一篇文章《敏捷方法的成功密技（三）：Scrum如何擺脫「產品客戶不愛，團隊熱情不再」的窘境？》中，我們談到了Scrum架構可以協助「部份」解決溝通斷層的問題。若是想徹底一點改善溝通斷層的問題，則還需要把在更前端「產品定義階段的相關活動」也都納入Scrum的架構內來運作才行。

敏捷方法的成功密技（三）：Scrum 如何擺脫「產品客戶不愛，團隊熱情不再」的窘境？

在上一篇文章《敏捷方法的成功密技（二）：專案管理的「溝通斷層」》中，我們談到了為什麼客戶／用戶的需求總是這麼難捉摸，為何我們要先談這個問題呢？

理由其實很簡單，在這個溝通的鴻溝沒有被妥善處理、弭平之前，所有後續的努力與投入都會事倍功半，形成「產品客戶不愛，團隊熱情不再」這個賠了夫人又折兵的窘境。那該怎麼做才能「盡可能」地弭平這個溝通鴻溝呢？（注意，我沒說能完全弭平！）

敏捷方法的成功密技（二）：專案管理的「溝通斷層」

在上一篇文章《敏捷方法的成功密技：Scrum 為何對你很重要？》中，我們談到了Scrum這個在敏捷開發方法中頗受歡迎的一派，也談到了敏捷式與瀑布式，在產品開發和專案執行成功率上的巨大差異。可是，既然這個東西這麼讚，又簡單易懂，那為什麼還是有很多公司和組織在導入這個方法的時候，不盡人意，東卡西卡的，無法體驗到敏捷法的巨大好處呢？

敏捷方法的成功密技（一）：Scrum 為何對你很重要？

最近一位認識多年的朋友，讀完了Jeff Sutherland大師所撰寫的《SCRUM，用一半的時間做兩倍的事》之後，找我問了些有關敏捷方法的問題，我發現，大多數的人可能都把敏捷方法想得太過於簡單了，以至於在組織內施行的時候，到處碰壁。

這本書，我在它剛出版的時候就讀完了，讀後我並沒有太多的驚奇，原因是，自己過去二十年的軟體產品開發經驗中，其實早就隱含了許多敏捷（Agile）的思維、技術和實作了。

不過，Jeff在這本書當中，雖然沒有談論到太多的Scrum細節，他卻想藉由此書，來把原本軟體產業所獨享的好處，推廣到各種非軟體的產業領域去應用，企圖讓大家用對的方法做事，讓工作更有效率，讓生活更快樂，讓世界更美好，這個理念倒是讓我著實地佩服！

接下來，我想來跟大家談談，我的敏捷實務經驗和思維，以及，敏捷實務和傳統實務之間的關係和差異，應用敏捷方法到底有哪些大多數人所不知道的密技，敏捷方法又該如何應用在生活之中。

「用戶故事 User Story」能讓需求簡化，還能更省時、更省錢，提供更多價值，這…可能嗎？

回歸原點的設計就是好設計，需求的蒐集也是一樣的道理（圖片來源：www.ptbus.com）

日前在EMBA的課程當中，老師談到了一個設計上的個案。這個設計個案是，一個只能往前推開的門，門上有個把手，把手旁有個「推」的字樣。這樣的設計到底有什麼問題呢？這和專案管理又能扯上什麼關係呢？