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

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

從猜測開始

除了標案之外，很多時候，我們其實並不知道我們的客戶／用戶是誰。我們之所以會「知道」客戶／用戶是誰，其實那是因為我們在「猜測」而已。那我們為什麼要猜測呢？因為，不猜測的話，後面的產品規劃、開發，就無法繼續進行下去！

好，既然是一種猜測，那它就是一種「假設」（Assumptions），而「假設」是需要被「驗證」的（Validated），而且「驗證」是會被期待要「快速」、「有效」、「省錢」的！

相信你我都曾經在學校裏頭做過實驗吧？做實驗，不都是先有個「假設」，然後去想辦法證明這個假設為「真」嗎？可是，實驗結果不都往往反而證明了原先的假設是錯的嗎？所以，我們才會被「失敗為成功之母」的諺語不斷地洗腦嗎？

可是，各位發現了沒？當我們進入職場之後，這句洗腦諺語早已被我們拋諸於九霄雲外去了。不論是已經當主管的自己，或是我們自己的長官，竟然總是期望團隊能一次就猜對目標客戶／用戶（Target Audience）、一次就做出啵棒的功能，讓客戶／用戶滿意到，不但會馬上掏腰包購買，還會幫你做口碑行銷？

這就是多數傳統式產品開發和專案管理的現況，期望一次就做對！

發明大王愛迪生，光是找適合做燈泡的燈絲材料，就實驗失敗超過五千次以上，然後才「賓果」，發明了可實際商轉的電燈泡！愈是突破性、革命性的產品或功能，所會遭遇到的失敗也往往愈多、愈頻繁。要做出能讓客戶／用戶真正熱愛的軟體功能或產品，也不比這個簡單，因為人心的確很難測，尤其是在客戶／用戶不明的情況之下，更是如此！

如果要我用一句話來說明Scrum是什麼的話，我會這樣來下定義：「一種可以讓團隊有重複實驗、不斷地從小失敗中學習、修正，最後達至大成功，的一種方法和架構」！

重複實驗

所謂的「實驗」，對軟體開發團隊來說，就是要釋出（release）一個成果（可能是一版軟體更新，或是一些操作流程畫面示意圖），給我們猜測的客戶／用戶去實際體驗看看。如果客戶／用戶認為這個成果並沒有辦法解決他們所面臨的問題（TA假設正確，但功能假設錯誤），或是這個成果他們根本就沒興趣要（TA假設錯誤），那麼，這個成果即驗證了實驗的失敗。

然而，團隊可以從這個失敗當中學習到一些東西，可能是TA假設錯誤（例如，男生），必須回頭重新做TA的假設，可能是另外的一個用戶族群（例如，女生），也可能是功能假設錯誤，必須從客戶／用戶的實際操作體驗之中觀察、訪談，引導挖掘客戶／用戶內心的真實感受，以作為下次實驗的修正依據。

就是這樣，讓團隊能周而復始地重複實驗，以逐漸逼近最合適的TA，逐漸完善產品或功能的問題解決方向和完整度。

同時，為了能夠讓團隊保有節奏感，每個釋出（release）的週期會被固定下來，而且在整個專案的過程當中，都不會更改，這個週期就叫做衝刺（Sprint）。衝刺的持續時間，通常會被定義為二到四週不等，視專案的複雜度、客戶／用戶的急迫性，以及產業的變化速度而定，並無一個標準答案。

小失敗

為什麼衝刺的時間要訂得這麼短呢？

因為，如果能愈快釋出成果去驗證假設，專案的成本就會愈低！如同上方我們談的，實驗是個有十賭九輸特性的玩意，因此，用儘可能低的代價（時間、金錢），去驗證假設為「否」，讓藏匿的「真」趕快浮現出來，其實才是最划算的做法！

既然衝刺的持續時間為二到四週不等，那麼，每個衝刺結束後所產生的成果，也就不可能是太大的規模。保持衝刺輸出的成果小規模有什麼好處呢？

好處就是，當我們遇到小挫折和小失敗的時候，我們通常可以平心靜氣地理智對待它，從中吸取教訓，繼續前進，而當我們遇到大挫折之時，我們往往會遭受驚嚇，不知失措，士氣一蹶不振，甚至是無法從這個大挫折中走出來，重新振作。

因此，Scrum的衝刺週期安排，就是讓團隊在很短的時間之內就能完成一個小實驗，驗證這個小實驗的假設到底正不正確，又該如何修正，以進行下個小實驗。

大成功

每個衝刺都有一個事先規劃好的「目的」，這個「目的」就是這個實驗的「假設」，例如，這個衝刺的輸出成果，是要驗證它能否真的解決客戶／用戶的某些問題。

當我們透過一個個連續的衝刺，輸出了一個個的成果，給客戶／用戶一個個驗證過之後，有些「賓果」（做對了），有些做錯了再修正，這些「賓果」的小成果，就會一直累積成為一個大成果，而這個大成果就是能為客戶／用戶真正解決問題的完整解決方案了！

如果當初團隊為每個衝刺所做的假設，是有依據重要性來排序過的，那麼最重要的假設，可能是個技術可行性風險評估，會被最早驗證完畢，整個專案的成功率也就很快地大幅提升了。

即便是放在最末端最後驗證的假設，因為專案時程限制的關係，需要被丟棄不做，整個專案之前所累積的各個小成果，其實也都可以完整出貨，為客戶／用戶解決問題，創造價值了。而組織本身，當然也就受益於這個專案所創造的價值了。

說到這裡，其實專案已經獲致大成功了！

待續...

原文轉貼自：威廉網紙（原文連結）

敏捷系列文章：

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

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