四歲台灣鄉下小孩能寫英文信

看標題可不要以為這是兒童美語班的廣告，這可是真實發生在三四歲的時候的我身上。當時家住在新莊，父親去美國出差。

我的母親看到我趴在地板上，拿一支筆，很認真地在一大張信紙上塗呀畫的，一大堆線條與圈圈，問我在做甚麼。

我答道："寫英文信給爸爸。"

母親忍住笑，看著滿紙線條與圓圈，問我："你寫了一些甚麼?"

我一本正經地答："爸爸才懂英文，他才看得懂，我不懂英文怎麼會知道。"

一個三四歲的小孩，當時還不了解"寫信"的意思，是把自己想說的話用文字寫下來給收信者閱讀，也不了解"英文"是甚麼。平常看到父親飛快地橫向書寫那些線條，聽母親說爸爸在寫英文。小孩不了解含意而只模仿動作。

我母親把這封"英文信"寄給在國外出差的父親了。當然他看不懂，不過他很高興收到這封信，而且將它仔細保存到三十幾年後的今天。

至今家人聊天時還常聊到這件事，一個帶來無數歡笑的回憶。

我原先以為這只是純真幼兒的特權，但是進入社會這些年，領悟到成年人在職場也會做類似的事情。

話說軟體工程（哇！忽然嚴肅起來了耶！）。這幾年台灣軟體界興盛CMMI評鑑，大家把評鑑制度當作證照制度看待。政府似乎相信CMMI會將台灣軟體產業全面升級，用很多經費與人力推行。軟體顧問的行業也興盛了起來。顧問熟讀各種軟體工程的方法與理論，至少SEI的那套方法以及Rational的RUP是基本功。尤其是如果這位顧問打算為客戶導入全套IBM Rational產品，應該更是會鼓吹RUP。

軟體業界都知道，除了Waterfall傳統的開發方法（需求->SA->SD->PR->Test...）之外，RUP（Rational Unified Process）主張另一種Iterative方法。簡單說呢，就是把整個開發流程切成數個小階段（稱為Iteration），每個階段獨立進行自己的需求->SA->SD->PR->Test週期。看來很簡單不是嗎？

但是要小心，要引進RUP前請先想這兩個問題（或是拿這兩個問題考考顧問），會幫你的團隊避免一場大災難︰

問題一 每個Iteration中做的"設計"，應該只針對這個Iteration的需求，還是考慮整個專案的全部需求，一次把底層設計好？
如果是前者，怎麼因應未來需求可能造成的底層架構不相容，程式需要大翻修的可能？
如果是後者，那應該不算Iterative了。因為Iterative方法的基本假設，需求不是一開始就知道的（不然不會每個Iteration都要做一次需求分析）

問題二 每個Iteration中做的"測試"，應該只針對這個Iteration完成的功能，還是要測整個系統的完整功能？
如果是前者，舊功能因為增加新功能的而失常的話怎麼測得出來？（在軟體專案中這幾乎一定發生的）
如果是後者，顯然測試的成本會隨著時間、系統的演進一直增加，是不是到最後每個Iteration只開發兩週，然後整整三個月都只做測試呢？對較多Iteration的大型專案而言，這顯然沒效率又不符成本，但是一般不是最鼓勵大專案採用Iterative Lifecycle嗎？

以上兩個問題的共同癥結在於，每個Iteration不是要建立獨立的系統。Iteration之間有相依性，有累積性。所以RUP不像表面上那麼好懂。不是沒有專案實務經驗，靠看過書受過訓，就可以去當顧問的。

如果為一家公司導入RUP，卻不能回答上述兩個問題，這就像一位四歲兒寫英文信一樣，自己不知道意思是什麼，卻認為開發人員應該會懂。我在第一家軟體公司時就曾經這麼自以為是，幸好當時公司沒有把大專案交給我負責。

我不知道如果是當年提出RUP的三巨頭會如何回答這兩個問題。身為Agile運動以及Extreme Programming謙卑的擁護者，自己版本的答案是︰

1. 只針對眼前需求做設計，靠重構(Refactoring)技術應付未來的變動。
2. 要測過全部的功能，靠自動測試降低成本與縮短時程。

這兩者都需要開發團隊有相當的根基與技術能力。沒有自動測試與重構技能的團隊，貿然使用RUP非常危險。