敏捷实践指导思想

许多人都经历过因为缺乏实践指导而导致的项目梦魇。有效实践的缺失会带来不确定性、重复的错误以及徒劳无功。客户失望于延期的进度、增长的预算和糟糕的质量；开发者也感到沮丧，因为他们用的时间更长却写出了质量更低劣的软件。

观察到很多公司的软件团队被困在不断增长的过程方法的泥泞里，一群行业专家挺身而出，拟定了一系列可以让团队快速响应变化的价值观和原则。他们成立了敏捷联盟。在随后的几个月里，共同创造出一份价值陈述。这便是《敏捷宣言》。

总结一句话，敏捷软件开发的目的是：帮助组建有凝聚力的软件研发团队，不断地在有限时间内交付高质量的软件产品。

四条宣言

个体交互优先于过程和工具

因人成事，人是项目成功的最关键因素，团队建设比环境搭建更重要。

对于人，愿意沟通、喜欢团队合作、水平达标的程序员优于单纯的编程才能好的程序员。选择合适的团队成员，营造一个沟通、合作、积极向上的工作环境更重要。

对于过程和工具，够用即可。不要预先假设手头上的工具无法支撑需求，除非在尝试后发现确实如此。别去购买先进又昂贵的源代码版本控制工具，在你能证明无法支撑需求之前，先找个免费的用着。

总结：发挥人的主观能动性优于工具和过程的约束，一旦发现问题，首先判断是不是人除了问题，及时的沟通可以解决则不使用过程和工具。建设好团队，然后让他们自己从基本需求出发，去配置环境。因人成事。

可以工作的软件优先于面面俱到的文档

文档很重要，没有文档的软件就是一场灾难。但是，太多的文档比没有文档更可怕。对于软件开发，需求是经常发生改变的，如果时刻保持文档和代码同步，需要花费大量的时间，性价比太低。

正确的文档需要短小精悍，言简意赅。所谓短，说的是最多只有12到24页；所谓精，则是说它应该描述整体设计的基本原理，只包含系统中高层次的结构。

代码和团队是给新人传递信息的最佳文档。团队成员的大脑里关于系统的路线图无时无刻不在改变。传递这样的路线图，除了人与人之间的交互，没有其他更快、更高效的方式了。

客户合作优先于合同谈判

项目的需求处于不断变化的状态，重大的变化并不少见，有整个功能模块被移除，也有新的功能模块被插入。不过，合同和项目都顺利生存下来了。成功的关键是和客户的紧密合作，而且合同保证了合作关系，而不是尝试划定范围的细节以及固定经费下的时间计划。

成功的项目需要客户规律和频繁的反馈。不同于依赖一纸合同和一份工作量陈述，软件的客户应该和开发团队在一起工作，给团队的工作提供频繁的反馈。始终朝着客户想要的软件进行研发。

响应变化优先于遵循计划

能否响应变化往往决定着软件项目的成功和失败。制定计划时，需要保持灵活，时刻准备着来自业务和技术的改变。做好的计划策略是为接下来的两周安排详细计划，接下来三个月安排比较粗糙的计划，再远就是非常粗略的计划。对于接下来的三个月时间，只要粗略地知道需求就好。对于一年以后的系统，只要有个模糊的想法就行。

十二条原则

通过及早、持续交付有价值的软件，来满足客户的需求更为重要

尽早交付部分功能的系统和系统质量之间有很强的相关性，初期交付的功能越少，最终交付的系统质量越高。增量频繁交付和最终质量也有强相关性，交付越频繁，最终的质量也越高。努力在项目刚开始的几周内就交付一个具有基本功能的系统。然后，以每两周增量迭代的方式，持续地交付系统。

接收需求变化，轻量级的敏捷流程可以驾驭任何有利于提升客户竞争优势的变化

这是一份关于态度的声明。敏捷过程的参与者不惧怕变化。他们认为改变需求是好事，因为这意味着团队学会了很多可以满足市场需要的知识。敏捷团队会非常努力地保证软件的灵活性，这样，当需求变化时，对系统造成的影响是很小的。通过一些面向对象设计的原则和模式，可以维持这种灵活性。

频繁交付能用起来的软件，频率从两周到两个月，倾向于更短的时限

尽早（项目刚开始之后的几周）、频繁（此后每隔几周）地交付可工作的软件。我们不赞成交付大量的文档或者计划，因为它们不是真正的交付物，我们关注的是交付满足客户需要的软件。

业务人员和开发人员必须合作，这样的合作贯穿于整个项目中的每一天

为了保证项目能以敏捷的方式开展，客户、开发人员以及相关利益者就必须进行有意义的、频繁的交互。软件项目不像发射之后就能自动导航的武器，它必须不断地引导。

围绕着主动性强的个人来立项。为他们提供必要的环境和支持，同时信任他们能够干成事情

激发团队成员的主观能动性，给他们提供所需要的环境和支持，并且相信他们能够完成工作。在敏捷项目中，人被认为是取得成功最关键的因素。所有其他的因素，比如过程、环境和管理等，都是次要的，并且，当这些因素对人有负面影响时，就要改变它们。例如，如果办公环境对团队造成阻碍，就必须改造办公环境。如果某些过程形成阻碍，这些过程就得整改。

开发团队内部以及跨团队之间，最有效和最高效的信息传递方式是，面对面进行对话

在敏捷项目中，成员面对面交谈。面对面交谈是最主要的沟通方式，也会有文档，但是文档不会包含项目的所有信息。敏捷团队不需要书面的规格、计划或者设计文档，除非这些文档是紧急且重要的，团队成员才会去写，但这不是默认的沟通方式，面对面交谈才是。

能用起来的软件，就是衡量进度的基本依据

敏捷项目是通过统计当前软件满足多少客户的需求来度量项目进度的。他们不会根据所处的开发阶段、已经写好的文档的数量或者已经创建的基础设施代码行数来度量进度。只有当30%的必需功能可以工作时，才可以确定30%的完成度。

敏捷流程倡导可持续的开发。发起人、开发人员和用户都能够长期保持一种稳定、可持续的节拍

责任人、开发者和用户应该能保持长期的、恒定的开发速度敏捷项目不是50米短跑，而是马拉松长跑。找到团队合适的研发速度最重要，使团队工作在一个可以让整个项目开发始终保持最高质量标准的速度上。一味加班加点不可取。

持续保持对技术卓越和设计优良的关注，这是强化敏捷能力的前提

高质量是高开发速度的关键。保持软件尽可能的整洁健壮是开发软件的快车道。因而，所有的敏捷团队都致力于编写最高质量的代码。

简洁为本，极简是消除浪费的艺术

敏捷团队不会试图去构建那些华而不实的系统，他们总是使用和目标一致的最简单的方法。他们并不过多关注预测未来会出现的问题，也不会在今天就做出防卫。相反，他们会在今天以最高的质量完成最简单的工作，深信即便未来出现了问题，也可以从容处理。

最好的架构、需求和设计，是从自组织团队中涌现出来的

敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务最佳方式。敏捷团队的成员共同解决项目中的所有问题。每位成员都有权参与项目所有的方面参与权力。不存在单个成员对系统架构、需求或者测试负责的情况。整个团队共同承担那些责任，每位成员都能影响它们。

按固定的时间间隔，团队反思提效的方式，进而从行为上做出相应的优化和调整

每隔一定时间，团队会对如何更有效地工作进行反省，然后做出相应的调整敏捷团队会不断地对团队的组织方式、规则、惯例和关系等进行调整。敏捷团队知道团队所处的环境在不断变化，并且知道为了保持团队的敏捷性，就必须适应环境变化。