我看的书是《敏捷软件开发：原则、模式与实践》是2003 年9月清华大学出版社出版的图书.
原书名： Agile Software Development: Principles, Patterns, and Practices
这本书的重要内容：
1.讲述在预算和时间要求下，软件开发人员和项目经理如何使用敏捷开发完成项目。
2.使用真实案例讲解如何用极限编程来设计、测试、量构和结对编程
3.包含了极具价值的可多次使用的c++和java源代码。
4.重点讲述了如何使用uml和设计模式解决面向客户系统
如果敏捷性（Agility）是指以微小增量的方式构建软件，那么究竟如何去设计软件呢？又如何去确保软件具有灵活性、可维护性以及可重用性的良好结构呢
在敏捷团队中，全局视图和软件一起演化。在每次迭代中，团队改进系统设计，使设计尽可能的适合当前系统。团队不会花费许多时间去预测未来的需求和需要，也不会试图在今天就构建一些基础结构去支撑那些他们认为明天才会需要的特性。他们更愿意关注当前的系统结构，并使它尽可能的好。
那么怎么才能保证全局视图和软件一起演化呢？在软件出现下面任何一种气味时，就表明软件正在腐化。敏捷团队的成员就会采取一些动作来阻止软件的腐化。下面列举的就是常见的设计的臭味——腐化软件的气味[1]。
1僵化性（Rigidity）：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其他改动。
2脆弱性（Fragility）：对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
3牢固性（Immobility）：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
4粘滞性（Viscosity）：做正确的事情比做错误的事情要困难。
5不必要的复杂性（Needless Complexity）：设计中包含有不具任何直接好处的基础结构。
6不必要的重复（Needless Repetition）：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
7晦涩性（Opacity）：很难阅读、理解。没有很好的表现出意图。
是什么激发了软件的腐化呢？在非敏捷环境中，由于需求没有按照初始设计预见的方式进行变化，从而导致了设计的退化。通常，改动都很急迫，并且进行改动的开发人员对于原始的设计思路并不熟悉。因而，虽然对设计的改动可以工作，但是它却以某种方式违反了原始的设计。随着改动的不断进行，这些违反渐渐地的积累，设计开始出现臭味。
然而，我们不能因为设计的退化而责怪需求的变化。作为软件开发人员，我们对于需求变化有非常好的了解。事实上，我们中的大多数人都认识到需求是项目中最不稳定的要素。如果我们的设计由于持续、大量的需求变化而失败，那就表明我们的设计和实践本身是有缺陷的。我们必须要设法找到一种方法，使得设计对于这种变化具有弹性，并且应用一些实践来防止设计腐化。
与传统的软件开发方法惧怕需求变化相反，敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持系统设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续的改进设计，以便于每次迭代结束所生成的系统都具有最适合于那次迭代中需求的设计。
上面的描述非常美好，读者不仅会问：敏捷开发人员如何知道要做什么的呢？
答案是：
（1）、他们遵循敏捷实践去发现问题；
（2）、他们应用设计原则去诊断问题；
（3）、他们应用适当的设计模式去解决问题。
软件开发的这三个方面的相互作用就是设计。
总结来说：敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净以及富有表现力。