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.
由于受到建筑工程的影响，程序员一直被认为是建筑工人，即所谓的软件蓝领。软件是一种创造性活动，这一点我想每一个深入编程、并且对编程进行过深思的人都能体会到这一点，在编写每一行代码时，都是在设计！而我想建筑工人在砌每一块砖时，大概不需要设计吧。我以前也一直受传统软件工程思想的毒害，结果有一个问题一直想不通，就是我得怎么做设计（传统意义上的设计），才能在编写代码时像砌砖一样，根本不再需要动脑筋呢？所谓的详细设计真的很详细吗？那为什么我感觉将它们转换成代码时同样很费脑子呢？不过现在我知道了，原来前提已经假设错了！