New Methodology
在這篇文獻里，我讀到了Fowler對于XP發展的總結，同時也對XP的核心進行了介紹：
XP begins with four values: Communication, Feedback, Simplicity, and Courage. It then builds up to a dozen practices which XP projects should follow. Many of these practices are old, tried and tested techniques, yet often forgotten by many, including most planned processes. As well as resurrecting these techniques, XP weaves them into a synergistic whole where each one is reinforced by the others.
One of the most striking, as well as initially appealing to me, is its strong emphasis on testing.
On this platform XP builds an evolutionary design process that relies on refactoring a simple base system with every iteration.
Fowler與Ambler不同，他認為可以分步嘗試XP的實踐帶來的好處，而不必一下子就全部使用XP：
With a dozen developers or less that are inclined to try it, I'd certainly push for XP. It may be that the team won't go all out in the XP process, at least initially, but you still get a lot of benefit by a partial XP approach. For me the key test of using this process well is automated unit testing. If the team are prepared to do that, then the technical foundations will be in place. If they can't do that, then I don't suspect they'll handle the rest.
RUP是輕型方法嗎？
作為獨立顧問和世界頂級的專家，Fowler的話讓人聽后有一種俯視的感覺，其對于RUP的評價讓人驚訝：RUP什么都不是！（Indeed this is my main criticism of RUP - since it can be anything it ends up being nothing.）
隨后Fowler基于自己對于RUP的主要觀點（RUP什么都不是），闡述了RUP既可以用于瀑布模型那樣的重型方法，也可以用于敏捷的輕型方法。
As a result of this process framework mentality, RUP can be used in a very traditional waterfall style or in an adaptive lightweight manner. So as a result you can use RUP as a lightweight process, or as a heavyweight process - it all depends on how you tailor it in your environment.
之前我也評價過EssUP和Larman的敏捷UP，在這里Fowler也站在一個高度發表了自己的看法：
Craig Larman is a strong proponent of using the RUP in a lightweight manner. His excellent introductory book on OO development contains a process that's very much based on his light RUP thinking. His view is that much of the recent push to lightweight methods is nothing more than accepting mainstream OO development that's been captured as RUP.
另外與閱讀Code Complete、[Evans03]等一樣，作者都向我們指出建筑工程和軟件工程根本就不是一回事，甚至于Eric認為，軟件開發完全就是設計！
因此Fowler在這里引用Jack的話說，編寫源代碼屬于設計階段！
These kinds of questions led Jack Reeves to suggest that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker.
This thinking leads to some important conclusions:
這一想法可以得出一些重要結論。
- In software: construction is so cheap as to be free
在軟件方面：施工如此廉價以致都是免費的。
- In software all the effort is design, and thus requires creative and talented people
在軟件方面所有的成就來自設計，因此需要有創造性的、有才能的人。
- Creative processes are not easily planned, and so predictability may well be an impossible target.
創造性過程是不易于規劃的，因此可預言性無疑是不可能的。
- We should be very wary of the traditional engineering metaphor for building software. It's a different kind of activity and requires a different process
在構建軟件時，應該對傳統工程所隱含的東西非常警惕。構建軟件不同于其他活動，它需要采用不同的過程。
Fowler所講的新方法指的就是敏捷方法論，而這些是對傳統的軟件工程論的反駁——軟件工程不是土木工程！所以，來自于建筑行業的某些隱語就是錯誤的，雖然我們從這個行業中得到不少有益的知識——比如說模式。
曾經在Ambler的著作中看到關于迭代和增量的討論，在[Larman04]中也有，迭代和增量到底是什么關系呢，我比較推崇Larman的認識：迭代的過程使得軟件、文檔、需求、設計都是增量的。而Ambler則認為迭代未必會導致增量。Fowler在本文中則認為這些其實都是一個東西，而且我們所說的螺旋、演化等都是迭代的不同名字（關于迭代的歷史在Ambler、McConnell、Larman等大量著作中都有詳細的介紹）。
The key to this feedback is iterative development. This is not a new idea. Iterative development has been around for a while under many names: incremental, evolutionary, staged, spiral... lots of names. The key to iterative development is to frequently produce working versions of the final system that have a subset of the required features. These working systems are short on functionality, but should otherwise be faithful to the demands of the final system. They should be fully integrated and as carefully tested as a final delivery.
每一個迭代版本都是滿足一定需求的最終系統，如果明天客戶說剩下的功能我們不要了，那么這個系統明天就應該馬上可以交付了！（想想這是多么偉大的一件事情啊！）
Programmers are Responsible Professionals是我喜歡的一個觀點，像Fowler，Rod Johnson，Eric，Kent Beck，Bob大叔等一系列世界級軟件開發大師，都是凡事必須要落實到代碼的理論和實踐相結合的典范，也是我最佩服的軟件專家。
When you want to hire and retain good people, you have to recognize that they are competent professionals.
由于受到建筑工程的影響，程序員一直被認為是建筑工人，即所謂的軟件藍領。軟件是一種創造性活動，這一點我想每一個深入編程、并且對編程進行過深思的人都能體會到這一點，在編寫每一行代碼時，都是在設計！而我想建筑工人在砌每一塊磚時，大概不需要設計吧。我以前也一直受傳統軟件工程思想的毒害，結果有一個問題一直想不通，就是我得怎么做設計（傳統意義上的設計），才能在編寫代碼時像砌磚一樣，根本不再需要動腦筋呢？所謂的詳細設計真的很詳細嗎？那為什么我感覺將它們轉換成代碼時同樣很費腦子呢？不過現在我知道了，原來前提已經假設錯了！