Scrum 是什麼（10）：時程估算

January 28 23:03~January 29 00:20

前情題要：

• 〈Scrum 是什麼（1）：雙重回饋機制〉
• 〈Scrum 是什麼（2）：Scrum 的內涵〉
• 〈Scrum 是什麼（3）：三種補充文件〉
• 〈Scrum 是什麼（4）：Product Backlog〉
• 〈Scrum 是什麼（5）：初探 Sprint Planning Meeting〉
• 〈Scrum 是什麼（6）：Sprint Planning Meeting 眉角〉
• 〈Scrum 是什麼（7）：Daily Scrum〉
• 〈Scrum 是什麼（8）：Sprint Review Meeting〉
• 〈Scrum 是什麼（9）：Retrospective Meeting〉

 

Scrum的大小活動大致上算是都交代過一遍了，今天談一 下幾天前學妹在Facebook上問Teddy的一個問題：時程估算。

***

學妹：最近我們常常被問到關於時程估計的問題，尤其是之前沒有run過Scrum的團隊，他們會想知道假設客戶一個案子來了，要怎麼去估算時間跟報價呢。我們用自己的經驗回答了，但總覺得回答得不夠有說服力。很想請教學長在這方面有沒有相關經驗可以跟大家分享呢? 謝謝!!

Teddy：很簡單啊，請問你問題的人跟Teddy聯絡...不是啦，這個問題不容易回答，基本上agile是建議不要採用「固定費用的合約」，但是實務上目前很難能夠被客戶接受。再加上如果團隊沒有run過Scrum不知道自己的「速度（生產力）」那就更難估了。你都怎麼回答別人？

學妹：這問題其實是上次學長講座結束後，後續留資料跟我們接觸的廠商訪談時候提出來的XD。首先，我們是講說通常一個有經驗的scrum團隊開發速度會趨穩定，這時候可以根據這樣的速度做估計。如果沒有經驗的話，會請他們用Commitment Based的方式，變成邊做邊調整，並且預留buffer，可是留buffer又牽扯到報價的問題。而且對方是表示對他們接案為主的小公司來說，這樣真的滿難的。所以討論到最後，對方說可能先從自己有興趣沒時程壓力的案子先run看看。我自己覺得我們回答的不好，所以最近才在想這個問題有沒有好的做法 ~"~

Teddy：要回答這樣的問題其實也很簡單，最保險的作法就是看他們原本怎麼估，就怎麼估。然後用SCRUM想辦法在估算的時程內把案子做出來。以這種方式多做幾次就會越估越準，不用說去找什麼「沒有時程壓力的案子來試SCRUM」。

學妹：哈哈哈 這樣一說突然覺得很有道理耶XD 突然想起學長寫的「Scrum 不會幫你解決問題」這篇。我想我自己也陷入那種想用Scrum幫大家解決所有問題的迷思了XDDD 謝謝學長，我會再多想想的!!

***

Teddy覺得學妹原本的回答已經很得體了。時程估算在軟體開發中本來就是一件困難的事情，問什麼 ？很簡單，因為變數太多了啊。有什麼變數？

• 需求會變
• 開發團隊成員會變
• 技術會變

但也不能說因為變數太多所以就什麼也不估。估算的結果通常有兩種：「不準」以及「非常不準」。對於一個剛開始想要採用Scrum的團隊，如果客戶還是只願意用傳統的固定價格合約的方式來進行專案，那麼案子還是可以做。也沒甚麼好害怕或是擔心的，採用Scrum並不是進京趕考「一試定終身」，也不是做數學四則運算考題，第一次就要算出所謂的「正確答案」才算是成功。Scrum（所有的敏捷方法）都是一種逐步改善的過程，先把箭射出去了，再看看箭離標靶有多遠，然後修正後再射箭...縱然標靶本身並非是固定不動的（活動標靶），但依此精神長久下去所射出的箭總是慢慢地往標靶靶心靠近。

沒錯，「Scrum 不會幫你解決問題」，江湖上沒有什麼大還丹或是天山雪蓮之類的補品，吃一口就可以平白增長數十年功力。只有「傻的願意相信」，勇敢誇出第一步，然後邊走邊修正（果真如Kent Beck大叔所說的，軟體開發就跟開車是一樣的道理）。

Robert L. Glass在Facts and Fallacies of Software Engineering第31頁寫了一段大家都知道的事實：

Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time.

Scrum能帶來的好處，是把「計畫」這兩個字從名詞變成動詞。Scrum團隊隨時都在計畫，隨時都在調整，眼睛隨時都盯著標靶前進。Teddy前面提到的三個影響需求估算的變數，第一點「需求會變」這幾乎是無法改變的事實，所以Kent Beck大叔又告訴我們要「擁抱改變」。在Scrum的設計中，專屬的Product Owner與Scrum Master，舉辦Sprint Planning Meeting、Daily Scrum、Sprint Demo等活動，以及自動化測試、refactoring等作法，都算是用來「擁抱改變」的方法。

至於另外兩點變動因素「團隊成員會變」與「技術會變」，還是要靠「Sustainable Pace」以及「Shared Code」與「Pair Programming」等實務作法，讓提升團隊合作的能力，並且讓團隊成員有餘力可以讀書與自我成長（Sustainable Pace是很重要的）。

***

講了一堆，其實講再多鄉民們不願意去嘗試也沒用。軟體是動手做出來的，開發軟體是一種逐步改善的活動，所以，不要怕第一次估算沒做好就裹足不前。因為這就跟追女朋友一樣，不開口機會永遠是零。考慮東，考慮西的，最後又回到原本每天加班的老方法上面。團隊是否一開始就可以馬上實施「正統的Scrum」並不是重點，重點是這一狗票的敏捷方法（例如XP與Scrum）與敏捷實務作法（例如自動化測試、持續整合、Pair Programming等等）有那一些是可以拿來改善軟體開發流程，能用多少就算多少。而且要記得「開發軟體是一種逐步改善的活動」，不是說那一天心血來潮隨便挑一個敏捷實務作法來試一下乎弄過去就沒事了，而是要依據團隊與專案現況，挑選合適的實務作，對症下藥方能見效。但這藥也不能亂吃，吃錯了藥輕則花錢消災，重則可能要終生洗腎，不可不慎。

***

下一集：〈Scrum 是什麼（11）：不信邪之流程改善精神〉

***

友藏內心獨白：這整篇哪裡有提到時程要如何估算啊？