許多軟體工程師，他們經常有滿腔熱血，希望能將他們對於在軟體開發上所學的技術與心得發揮應用在工作的專案上。

也有許多開發團隊，僅接受幾天的 UML 與 OO 的教育訓練，就想 “應用” 在專案開發上。

有很好的抱負及理想當然是很好。不過，將新技術、新的開發流程應用在傳統的專案上，其風險很大。還不是普通的大，是真的很大的風險！

幾個關鍵的問題思考：

• 團隊成員們的接受度如何？
• 團隊其他成員的技術及技能夠不夠？
• 該專案的開發時程及預算等資源，夠你 “實驗” 一些新的技術與製程嗎？
• 最危險的是，導入新技術及製程的當事人或團隊，真的足夠具備該有的觀念與知識嗎？

例如，專案導入 “Use Case” 及 所謂 “物件導向” 技術。若對 “封裝(Encapsulation)” 沒有足夠的認知，根本不瞭解 “廣度” 與 “深度” 的表達，是很難寫好 “Use Case” 的；對 “Control”、”Entity”、”Boundary” Object 的責任(Responsibility)及本質都不清楚的話，該如何設計物件結構及表達物件之間的互動合作？；對於 “Stateless” 與 “Stateful” 物件都不知如何設計與搭配，又該如何開發 N-Tier 的應用系統呢？

單一個問題，是容易在專案開發的過程中，逐漸的克服及解決。但，一旦許多的問題一併發生時，那麼，難以發現的複雜度就呈現出來了。而且，無論如何，就是無法解決這些問題，而且，專案又面臨時程的壓力，結果，為了趕工，粗製濫造，一開始所懷抱的理想，早就拋諸腦後了。

個人一向不主張 “現學現賣”，風險實在太高了。
若真要應用在 “專案開發” 上，那麼，最好是不要好高騖遠，往前走一小步，做一個不太成功的專案。

什麼意思呢？
只將一項新的技術或觀念應用在一個小型的專案上。

例如，我常主張，要讓一個專案 “看來很成功”，最重要的一件事，就是要能與客戶達成相互之間的 “平衡(或者稱之為妥協)”。
要如何平衡？ 測試先行(Test First)是最佳的利器！

開發團隊撰寫功能測試的測試程式碼；客戶負責提供寫測試的 “劇本(Scenario)”。越簡單越好，可不要搞什麼 “Test Case” 之類的，也就是測試不要以文件、測試列表等這些 “Paper” 來表達，太容易發生糾紛了。
自動化，就是自動化！！所有的功能均能以測試程式碼來執行自動化的測試，若其中之一的功能沒有通過，自然就反應在測試的結果。而功能一改，自然，測試碼也必須跟著更改。功能為什麼更改？也就相對反應客戶需要對其更改的功能 “負責任”，因為，測試劇本是由客戶所提供的。

“測試先行” 簡不簡單？ 技術上是蠻簡單的，但，實際執行起來可不簡單，因為，牽涉到開發人員心理層面及與客戶溝通(必須說服其撰寫測試劇本)等諸多問題。

若能成功導入單一一個新的技術與觀念，提升團隊的經驗、技能與信心。那麼，再漸增地加上一些 “新技術”，如 “Use Case” 表達需求、”Class Model” 表達領域物件的結構．．．等。

人們往往希望做事能面面俱到，但最後卻往往都面面不俱到。
做一個不是太成功的專案，往前一小步；勝過什麼都想做，到最後卻反而一團遭而無法收拾的專案。