Principles
7. Work software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility.
Principles
4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. face-to-
该文档应该是短小并且主题突出的，应该仅描述系 统的高层结构和概要设计原理。 统的高层结构和概要设计原理。
为了培训新成员，应该通过团队交互和代码
代码和团队是最好的两份文档。
客户合作胜过合同谈判
不能向订购日用品一样来订购软件
如果客户仅仅写下一份他需要的软件的描述， 然后就让人在固定的时间内以固定的价格去开 发它，用这种方式来对待软件项目的尝试都是 以失败而告终的。
成功的项目需要有序、频繁的客户反馈。 不是依赖于合同或者关于工作的陈述，而 是让软件的客户和开发团队密切地在一起 工作，并尽量地提供反馈。
响应变化胜过遵循计划
响应变化的能力常常决定着一个项目的成败
当构建计划时，应该确保计划是灵活的、并且易于适 应商务和技术方面的变化
计划不能考虑的过远
计划没有变化快！
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: •Individuals and interactions over processes and tools 个体和交互 胜过 过程和工具 •Working software over comprehensive documentation 可以工作的软件 胜过 面面俱到的文档 •Customer collaboration over contract negotiation 客户合作 胜过 合同谈判 •Responding to change over following a plan 响应变化 胜过 遵循计划
Principles
10. Simplicity – the art of maximizing the amount of work not done – is essential. 11. The best architectures, requirements, and designs emerge from self-organizing selfteams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Kent Beck, Alistair Cockburn, Robert C. Martin, Martin Fowler, etc.
个体和交互胜过过程和工具
人是获得成功的最为重要的因素 一个优秀的团队成员未必就是一流的程序 员
优秀团队的成员可能是平均水平的程序员，但 他（她）们能很好的和别人合作、沟通。
客户作为团队成员
XP要求客户和开发人员在一起紧密工作，最好在 XP要求客户和开发人员在一起紧密工作，最好在 一个房间内 这个房间的墙壁上随意悬挂着大幅的、显著的图 表以及其他一些显示他们进度的东西。 客户指定义产品特性并排列这些特性优先级的人 或团体

XP的实践（Practices of XP） XP的实践 的实践（ XP）
Customer Team Member User stories Short Cycles
iteration plan release plan
Acceptance Tests Pair Programming TestTest-Driven Development Collective Ownership Continuous Integration Sustainable Pace Open Workspace The Planning Game Simple Design Refactoring Metaphor
敏捷方法 VS 工程方法
工程方法（Engineer 工程方法（Engineer Methodology)
借鉴了工程领域的实践，有着严格而详尽的规定，强 调项目的可控性； 官僚繁琐，要做太多的事情从而延缓开发进程。
敏捷方法（Agile Methodology） 敏捷方法（Agile Methodology）
敏捷方法是“面向人”的而不是“面向过程”的 敏捷方法是“面向人”的而不是“面向过程”的
工程方法的目标是，定义一个过程，不管是谁用，都 能运转良好； 而敏捷方法认为没有任何过程能代替开发团队的技能， 过程所起的作用，是对开发团队的工作提供辅助支持。
敏捷联盟宣言
The Manifesto of the Agile Alliance 敏捷联盟宣言， 2001
敏捷联盟（Agile alliance） alliance） 敏捷联盟（
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas /
较好的作计划的策略是：
为下两周做详细计划；为下三个月做粗略计划；再以 后就做极为粗糙的计划。 这种逐渐降低的细致度，意味着仅仅对迫切的任务才 进行详细计划，计划的其余部分仍然保持着灵活性。
原则（Principles） 原则（Principles）
1. Our highest priority is to satisfy the customer through early and continues delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
以客户的商业价值为最终目标，追求更低的成本、更 少的缺陷、更高的生产率、更高的投资回报； 对繁文纑节的官僚过程的反叛，轻装上阵、卸下包袱； 只要求尽可能少的文档，认为最终的文档应该是“源 代码”。
敏捷联盟（Agile alliance） alliance） 敏捷联盟（
2001年初，在犹他州的Snowbird，由于看到很多 2001年初，在犹他州的Snowbird，由于看到很多 软件开发团队陷入了不断增长的过程的泥潭，一 批业界专家聚集在一起概括出了一些可以让软件 开发团队具有快速工作、响应变化能力的价值观 和原则，他们称自己为“敏捷联盟” 敏捷联盟是一个非盈利组织，其宗旨是推广敏捷 方法的促进这方面的讨论。 在随后几个月，他们创建了一份价值观声明，也 就是敏捷联盟宣言。
敏捷方法的两个核心理念
敏捷方法是“适应性”的而非“预见性”的 敏捷方法是“适应性”的而非“预见性”的
工程方法试图对一个软件开发项目在很长时间跨度内 做出详细计划，然后依序开发。这类方法在需求和环 境有变化时并不能发挥效力，其本质是拒绝变化的； 境有变化时并不能发挥效力，其本质是拒绝变化的； 而敏捷方法则欢迎变化，它通过迭代获得反馈，目的 而敏捷方法则欢迎变化，它通过迭代获得反馈，目的 是成为适应变化的过程，甚至允许改变自身来适应变 化。
合适的开发工具（如IDE、Complier、版本 合适的开发工具（如IDE、Complier、版本 控制系统）对于成功很重要，但工具的作 用不宜被过分夸大
可以工作的软件胜过面面俱到的文档
没有文档的软件是一种灾难；然而，过多 的文档比过少的文档更糟糕
编制文档需要花费时间，使文档和代码同步， 编制文档需要花费时间，使文档和代码同步， 需要花费更多时间。 需要花费更多时间。 对于团队，维护一份系统原理和结构方面的文 对于团队，维护一份系统原理和结构方面的文 档是一个好主意