自從上回老杜把TDD,DDD在中國的處境看成是‘水土不服’之後，雨辰就一直想找個機會再跟老杜‘理論’一下。後來在整理以前資料的時候找到了Ivar Jackbson(UML三友，用例的發明人)在2008中國之行時做的一次演講時用的PPT，其中提出了一種稱之爲‘明智軟件開發’的軟件開發思路。雨辰當時看這個大約4M的ppt時的第一印象就是Ivar破天荒的提出將UP與敏捷有機結合到一起，並最終用於軟件開發的過程中。讓這兩個陣營中的優秀思想相互補充，各自發揮所長，聽起來倒是一種不錯的想法。
當然IVAR也對AGILE陣營中對“架構”的偏激思想進行了反擊，正如後來孟巖所總結的那樣：
Agile認爲，應儘快產生可執行代碼，架構可以隨後重構出來，而他（Ivar）認爲，skinny system就是架構(軟件一開始的核心架構)，開發skinny system的過程也就是確定架構的過程。而架構是一個系統中最重要的部分，對質量要求不折不扣的部分，因此必須精心設計，絲毫馬虎不得，也別指望事後能夠通過重構產生好的架構（這時雨辰所一直信奉的）。另外一方面，也不要執迷於那些通用的龐大的企業級架構。正如skinny system暗示的，好的架構都是小而簡單的。Ivar認爲，軟件各部分對於質量的要求是不一樣的，與架構無關的部分，適當降低質量要求以求得開發效率的提升可以的，事後也完全可以通過重構等手段改善之。然而架構卻是必須從一開始就認真對待的，Ivar甚至說，“唯一重要的質量就是架構的質量”。
看了上面孟巖BLOG中一段文字，雨辰又聯想起2006年9月《程序員》雜誌中，IVAR發表過一篇名爲《讓統一過程也敏捷》的文章。在該文中作者提出了一個叫EssUP ”核心統一”過程的方法，其可以看成是UP,XP,CMMI的‘三合一’，如下圖：
而現在看來，該文章所闡述的內容其實就是在爲IVAR後來提出的“SMART”開發做‘鋪墊’。當然“SMART”本身絕不是對Agile進行‘招安’，而是對RUP&UP的一種有益補充，必定RUP太重了。從這一點看，IVAR要比AGILE陣營的態度要溫和，更有‘大家’之氣，也更老辣。
EssUP方法認爲傳統的軟件過程，比如統一過程（UP），是通過對她所定義的不同角色所進行的活動和生產的製件進行描述的。這些活動和製件可能服務於不同目的，例如基於用例的需求，測試驅動的設計、架構的構建、基於組件的開發（這些都是過程）。換句話說，他們在處理不同的實踐。這些實踐不是外在的、也不是可見的，甚至沒有一個名字。這樣的過程中所包含的許多實踐可以被形象地比喻爲“一鍋湯”。即過程是您選擇的一組實踐的組合。”
上面的原文意思（按雨辰自己的理解）就是將要開發的軟件根據功能分割成N個‘過程’中，每個過程比如用例需求分析或基礎架構等都是由一些實踐組合而成，而那些實踐包括敏捷實踐，架構實踐等，但必需是經過驗證且簡單有效的，並且這些實踐可以被組合成爲所‘需要’的實踐。
除了將過程細化，Ivar同時該方法還引入了卡片機制來使用‘過程’變得敏捷，而卡片與agile中的story card基本無異，當然引入卡片本身也沒什麼可奇怪的，必定‘卡片’與‘用例’差不多，而IVAR又是用例的發明人，所以理所當然了。
EssUP將每一個實踐通過一系列的過程卡片進行呈現，這些卡片包含了定義你自己的過程所需要的各項元素， 包括關鍵能力， 活動和製件。這些卡片可以用來爲您的項目建立一副牌，通過卡片組合來爲項目成員規定項目任務，或者定義新的過程元素。 在項目中， 還可以通過卡片實例來表現實際交付物和任務。卡片使得過程本身變得敏捷，易於使用。無論是電子卡片還是打印的版本，都能有效地推動過程採用， 項目計劃， 併爲實踐者提供方便的參考指導。這些卡片使過程“活“起來，比靜態的網頁和書更方便閱讀、理解。
一口氣讀下來，感覺該方法是將UP做爲了開發流程的主幹，而敏捷這類的實踐變成了流程中的相應環節和一磚一瓦。再說的簡單一些，就是當你要設計開發一個非常複雜的系統時，你可以在其中使用UML,，XP，AGILE，RUP，只要場景適合允許，那就可以將其做爲一個組件加以使用，最後再將這些過程銜接起來，構成軟件開發的整個流程。
當然在IVAR之前，就有一些案例使用了類型IVAR所強調的這種‘大雜燴’的開發方法。比如：TRW公司於1987-1994年間爲美國空軍開發的導彈預警和地面指揮控制系統CCPDS-R是歷史上非常著名的、融合統一過程（該項目所採用的過程方法後來形成了RUP的一個主要來源）和敏捷思想的成功範例。該獲獎項目的規模爲75人、6年、100多萬行Ada代碼，採用了類似RUP 4個階段的迭代遞增、架構優先過程。它不僅按進度和預算交付了大型關鍵任務系統，而且還使用戶獲得了超出預想的功能，在生產率和質量方面取得了2倍的增長。
在整個項目過程中， CCPDS-R承受了大量需求的變化，甚至包括開發後期的一個合同範圍變更。同等程度的需求變化扼殺了大部分採用傳統管理方法的項目，而CCPDS-R卻由於採用了風險管理、設計階段架構的不斷集成以及基於演示的評審方法，有效控制和穩定了變更成本，取得了超乎尋常的成功。CCPDS-R在注重個人互動、可用的軟件、客戶協作和響應變化等方面都做得非常出色，可以說完全實現了敏捷價值觀和目標。
不過因爲IVAR還未公佈SMART方法的具體實現細節以及相關流程，所以對於外界看來光憑那個PPT還是有些‘盲人摸象’，但必定其指定了一個方向就是‘分久必合’，當下軟件方法論中RUP,AGILE等各自佔據一片江山，而存在即合理，所以與其排斥不如包容。針對合適的場合，合適的團隊，使用“全適的開發方法“。當然無論是UP還是AGILE，都對開發者提出了較高的要求，就是對OO設計方法和技能的掌握。即：
XP要求開發團隊具備熟練的OO編碼、測試和重構等技能，RUP也對OO需求分析、架構設計提出了較高要求。沒有真正理解OO範式與傳統結構化方法的本質區別，缺乏OO技能，那就玩不轉了。
而國內的開發者的水平又擺在這，所以最後還是應了老杜之前說的那句話：
所謂‘根據公司團隊實際情況採用相應的方法’只是一種奢談。在國內來看，這類方式論的普及和理解層次遠沒到國外的水平，對於諮詢公司而言相應的培訓市場也並沒理解中那樣有利可圖。我更認爲TDD,這類敏捷實踐在國內‘水土不服’。