這兩天與 Ringle 一同至高雄某家規模蠻大的專案開發公司，從年前兩日的 UML 課程教育，然後年後第三日係以座談的方式，面對面聽取學員們在實際專案開發時，利用 UML 設計時，所遇到的問題，同時並檢驗他們的設計產出是否正確與適當。其實呢，算起來也有半顧問的意味，當場就拿出他們利用 EA 所開發的設計圖，檢驗、評論、說明，然後協助直接修改，甚至轉出程式碼。

我覺得學員們真的很認真，讓我有些訝異，在年前只上過短短的兩天 UML 基本課程後，竟然在一個月的時間，就已經將某一系統的需求訪談記錄建構為使用案例圖，並且還產出系統分析的類別圖與循序圖，就只差程式碼還沒出來而已。

一整天的座談，就針對這些設計產出來 “指指點點”，說明他們在 SA/SD 設計的一些茫點與比較顯明的謬誤。但大致上，我們到蠻給予高度肯定的評價，重點是有沒有 “心” 要做，其它的都還是次要而已。他們專案經理，也非常認真，提問了很多的問題。我發現到，都比較偏向是專案管理面的範疇，諸如設計產出是如何承接、由擔任什麼角色的開發人員負責、該如何 “檢驗” 他們設計的品質 …等等。專案經理重視 “制度”、”製程” 等，那也是當然的，不過，到讓我發現到，一個很明顯的問題：想太多了。 這會導致在分析/設計階段因瞻前顧後，花太多不必要的時間在小細節上，而陷入了「癱瘓(paralysis)」。

如同寫文章，越想求完美的人，越不容易動筆。分析/設計 也是如此，就是因為想要 “分析” 更精確、”設計” 得更完美，讓系統開發規格更明確 …這些心理因素的作祟，而導致在某個開發的局部就 “僵住”，好像是動彈不得、陷入瓶頸的感覺。

何以見得？ 答案太明顯了：程式碼沒有出來！

傳統 SA/SD/PM 最大最大的一個茫點是，如果沒有開立明確的系統分析與設計的規格，包括 Database Schema，那如何能讓程式人員寫碼呢？ 這不就是傳統 “Waterfall(瀑布式)” 開發流程的詬病？ 許多軟體公司以為，採用如 RUP 先進、國際標準典範的開發流程，就會從 “瀑布式” 的開發魔咒解套，問題是，當你把 SA/SD 拉長數星期以上的開發，才開始展開 “Implement” 的實做階段。這種方式，如同 “藍皮綠骨”，根本還是 “瀑布”，因為，RUP，甚至是現今必然要嚴謹遵循的開發原則，最重要的一個精髓之一： I&I (Incremental and Iteration)，根本沒有確實實踐。

從需求分析、設計、至實做，甚至包含測試，要花多久時間？ 我與該公司 PM、系統開發人員說，完成一個使用案例的實現，第一個 Iteration 不能超過三天。 他們聽了覺得挺不可思議的。怎麼可能？

唉，為了證明，所以，又要請出我們的 “呂布” 級戰將 Ringle，將他們系統的一個使用案例，從頭作一個分析，補充上使用案例敘述、設計類別圖，描述循序圖，然後利用 EA 的 “Code generator” 功能產出程式碼框架到 Visual Stuio .Net 的 C# 專案，再補上一些虛擬碼的註解，同時又加上功能測試程式碼。第一個 Iteratin，整個過程，還不到兩小時。

第一個 Iteratin 當然不可能包括完整的屬性與行為細節，那並不是第一個循環要關注的事情。即使資訊不足、流程不明確，一旦確定使用案例的目標(Goal)，就應該快速跑過一次 RA/SA/SD/Implement 等開發階段，用最短的時間，完成可以執行的程式碼。如此，最重要的幾個目的就能達成：：增進團隊整理信心、建立系統雛形結構、快速取得回饋(Feedback)。：

這麼說好了，確定目標(使用案例)、找出達成目標的手段(分析/設計)、馬上執行與測試(Implement and Test)、問題收集與回饋，這才是 “Iteration” 的真諦。

況且，程式碼是最現實的產物，客戶、老闆眼中一定要看到程式碼，才算 “眼見為憑”。我一直傾向是要在最快的時間內，一確立實作的目標，先經過簡單的設計(Simple Design)，就要快速產出可執行的應用程式碼以及功能測試碼，這才能確保軟體分析/設計的信心主要來源。

請記得，世間沒有一開始就是完美的事，分析/設計更是如此。我從來都假設需求不明確、企業流程有問題，但只要經由需求分析確立目標，就可以馬上著手系統分析與設計，當然也就可以立即產出程式碼了。當有個 “框” 之後，再來才是逐步修正細節，包括企業規則與邏輯等。 (當然，也不可能無限上綱，永無止盡的 Iteration。過與不及，均不妥。)

分析/設計，甚至包括程式碼，都只是手段，既然是手段，當然不需要太重視，因為手段會時時視需要調整與修正的。我最重視的是原則，什麼原則呢？ “把握當下，泰然面對無常”！