突然很想做專案（1）

December 30 08:54~10:09


昨天下午 Teddy 又厚臉皮的跑去找一位好友吃飯兼聊天，由於這位好友目前正在客戶端帶領若干個外派的程式設計師做專案走不開，於是就和 Teddy 直接約在客戶端的餐廳見面。好友已經卡在該專案一年半以上的時間，專案預計結案時間也延了 6 個月，現在已經接近收尾的階段（至少好友內心希望是這樣的...XD）。


好友提到最近客戶對系統執行一系列的壓力測試，看看系統的效率（performance）與同時上線人數（concurrent users）的極限在那裡。在測試的過程中，客戶也發現了系統對於『例外處理』有許多沒有考慮周詳的地方。由於當初的系統分析，設計幾乎都只有寫出『正常流程（normal scenarios）』的處理方法，對於例外鮮少描述。但是，分析文件客戶也看了啊，也簽名了，所以最後雙方就開始想辦法說服對方『這是你們的疏失』。當然廠商通常還是被ㄠ的那一方，但是至少要讓客戶覺的『你欠我們一個人情』，而不是因為『廠商當初沒有考慮到』。

***

聊到這邊 Teddy 感觸很深，因為 Teddy  的博速論文就是研究『例外處理設計』，這在軟體開發中基本上都是被忽略的一環，但是，如果你的軟體系統是要能夠『長時間執行不關機』的那一種，例外處理設計就變得很重要。不過例外處理設計不是今天 Teddy 想談的主題... 。


後來繼續聊著聊著突然聊到測試這件事，由於之前 Teddy 的另一位在做專案的好友告訴 Teddy，他們公司的高層告訴他：

做專案是不需要做自動化測試的，做產品才要（請參考 600 多個 bugs 要怎麼修？）

於是 Teddy 也問了好友同樣的問題，你們的專案是否有做自動化測試？


很遺憾的，好友的專案並沒有做自動化測試，而且好友以前所參與過的所有專案，也都沒有做過自動化測試。根據好友的經驗，在台灣寶島做專案好像真的沒有人有在做自動化測試。

***

Teddy：為什麼不做自動化測試呢？


好友：因為一般人的直覺反應都是，如果寫了自動化測試，會拖慢寫程式的時間。換句話說，寫程式的時間都不夠了，那有時間去寫自動化測試。


Teddy：那專案有因為沒寫自動化測試而準時上線的嗎？


好友：沒有，幾乎所有的專案都是 delay 居多。


Teddy：那大家都習慣了專案延遲，這樣做專案不是會虧本？


好友：在估算專案成本的時候，已經先 灌水 預留延遲 3 個月的成本，所以只要不延遲太久，還是有的賺。

***

聊到這邊 Teddy 心中突然想到一個名詞，


能量不滅定律（能量守恆定律）：
Energy can neither be created nor be destroyed: it can only be transformed from one state to another. 


Teddy 認為，把一個專案做到一定的品質並結案，其『最少工作量』是不變的。省略了自動化測試，看起來好像少做了一件事，可以把時間省下來寫程式，但是太多實務經驗已經告訴我們，這是錯誤的想法。『 it can only be transformed from one state to another 』，跳過『自動化測試這個階段』，那麼原本應該花在自動化測試的時間不會消失，而是跑到『長時間 debug』與昂貴的『人工測試』上。後者（長時間 debug 與人工測試）的成本其實是遠大於投資在自動化測試的成本。


『人工測試』最大的問題就是無法做 regression test，也就是說不能像自動化測試案例一樣可以不停的重複執行。為什麼要不停的重複執行？還記得 Teddy 在『亂談軟體設計（2）』裡面提過一句至理名言：


開發軟體最怕的不是『寫程式』或是『不會寫程式（寫不出程式）』，最怕的是『改程式（改那些原本已經寫好測試過可以動的程式）


為什麼最怕改程式，因為相信大家都有這樣的經驗，改完程式之後原本可以動的其他程式卻不能動了，更慘的是，你可能不知道到底那些地方被改壞了，所以後續還要花費很多時間來『debug』。其實軟體開發（不管是做產品或是做專案）真正花在所謂『寫第一遍程式』的時間應該不到 1/3（搞不好不到  20%），那麼其他時間都在幹嗎？改程式（因為需求不清或是需求改變而改程式），debug，以及 testing 的時間加起來絕對是遠遠超過所謂的 coding（寫第一遍程式） 的時間。


所以，要如何加速專案的進行，讓專案『有可能』可以準時上線，或是至少不要延遲太久？答案很簡單，減少改程式，debug 與 testing 的時間。

***

Teddy 也同意人工測試是必須的，但是光是依靠人工測試要達到一定的軟體品質，那麼花在人工測試的成本絕對是遠遠.............遠大於花在撰寫與維護自動化測試案例的成本。而且從另一個角度來看，如果你是客戶，當廠商把 source code 交接給你的時候，同時還附上一堆自動化測試，請問你對這個廠商所開發出來的系統是不是會比較有信心？下次如果還有案子，你會想找一個有提供自動化測試案例的產商，還是一個用人工方式做測試的廠商？

***

有一次 Teddy 在做 Scrum 經驗分享的時候，曾經有鄉民問 Teddy：


鄉民：Scrum 雖然聽起來很好，agile practices（例如持續整合，自動化測試，pair programming）也很好，但是我要如何說服公司採用呢？


Teddy：請問您公司的專案有曾經準時結案過的嗎？


鄉民：沒有耶。


Teddy：那有什麼好怕的，現在都已經這麼爛了，就以『死馬當活馬醫』的心態，採用 Scrum 與 agile practices  不會更差了。

***

這個故事還沒講完，因為好友的專案成員幾乎都是人力派遣過來的，所以 Teddy 下一集再來稍微談一下這個問題。

***

友藏內心獨白：Teddy 10 幾年前作專案也是沒寫自動化測試，也是都延遲（因為當初沒有人教 Teddy 啊）。怎麼過了 10 幾年做專案的方式都沒改善啊。