敏捷开发原则

原则1：最优先要做的是尽早、持续地交付有价值的软件，让客户满意。

这条原则包含了三个独立的重要概念：尽早发布软件、持续交付价值，以及让客户满意。

    客户在真正拿到可工作的软件之前，都很难想象软件到底应该如何工作。这样说来，既然客户只有在看到了可工作的软件之后才可能给你真实有信息量的反馈，那么获得反馈的最佳方式就是尽早交付（early delivery）：尽早给客户交付第一个可工作的软件版本。即便是只交付了一个可以工作的特性给客户使用，这也是一种突破。这对整个团队都是有益的，因为客户可以给出有价值的反馈，这样开发团队才能朝着正确的方向推进敏捷原则项目。这对客户来说也是有益的，因为拿到了软件就可以使用。也就是说，开发团队实际交付了真正的价值。尽管只是一小部分价值，但是比到最后一点价值都不交付要好，特别是在客户因为等了很长时间还没有看到软件而越来越愤怒的情况下。

真正与客户协作的团队可以在开发过程中任意进行任何有必要的改变。这就是持续交付（continuous delivery）的意义所在。

    敏捷方法通常采用迭代，原因就在于此。敏捷团队选择出能交付最大价值的特性和需求，并据此计划项目的迭代。团队确定哪些特性能交付价值的唯一方法就是与客户协作，并利用前一次迭代收到的反馈。从短期看，团队可以通过尽早交付价值让客户满意，从长期看，交付最终产品的时候可以实现价值最大化。

原则2：欣然面对需求变化，即使是在开发后期。敏捷过程利用变化为客户维持竞争优势

欣然面对需求变化的第一步是尝试从客户的角度看问题。

    客户最初提出的需求有了变动，实际上客户承认自己犯了错误。尽管开发团队不能按期交付产品，客户也是一样不能按时使用新变化的产品特性的，如果新需求能够产生客户需要的价值，那么这个项目需求的改动就可以产生价值。而不是你开发出来的产品特性不是客户想要的需求，导致产品没有价值。

欣然面对需求变化意味着什么呢？它意味着以下几点：

• 不要认为有变化就会有人“倒霉”。允许犯错并及时发现问题及时得到解决。

•  开发团队和客户都是一条绳上的蚂蚱。客户和开发团队都对需求的变化负责，需求的错误对开发团队和客户同样严重，抱怨没有任何意义。

• 我们不把变化拖到最后。尽早修复错误，才能把损失降低到最低。

• 我们不要再把变化当成犯错。根据当时的信息，我们已经尽力了，出了错事情才会变得更加明朗，让我们看到现在必须如何改变决策。

• 我们通过变化学到东西。这是团队成长的最有效方式，也是团队学会更好地合作开发软件的最有效方式。

原则3：频繁交付可工作的软件，从数周到数月，交付周期越短越好

    团队通过每一轮迭代，发布可工作的软件。每一轮迭代结束时，回顾、探讨本轮迭代的过程并吸取教训，并且通过客户的尽早反馈(需求变化或本次交付的某些特性不满足客户需求等)进行可预测的进度安排，让团队尽早掌握变化，把接下来一轮迭代中最有价值的特性优先开发。所以，欣然接受变化的同时不引入混乱的关键，在于频繁发布可工作的软件。

原则4：在团队内外，面对面交谈是最有效、也是最高效的沟通方式

    面对面的沟通让大家的思考方式保持同步，用同样的方式去看待世界，而且都能开放地讨论正面和负面的想法，那么大家最终会有一致的视角。如果此时发生了一个变化需要重新思考，团队成员不需要花时间互相解释。

    团队沟通的终极目标是形成一种集体意识，在成员之间建立不必直说也能领悟的共同知识，因为反反复复解释同样的事情实在太过低效。如果没有集体意识，团队中不同职责的人需要付出更大的努力才能匹配视角。一个团队越能形成集体意识，越能共享同样的视角，就越容易对同样的问题形成一致的答案。这就为团队构筑了处理变化的坚实基础，可以跳过冲突，立即编写代码，而且不会因为维护文档而分心。

原则5：在整个项目过程中，业务人员和开发人员必须每天都在一起工作

    当业务人员和开发人员同在团队中开发软件的时候，最有效的方法是让他们在项目完整周期内每天坐在一起工作。业务人员及时检查开发团队的工作并给出反馈，业务人员也能及时给开发人员解答业务问题。这样修改的成本就很低。从整个项目的过程来看，每天与开发团队一起工作，每个业务人员的实际时间开销要少得多。这也是频繁发布可工作软件的开发团队应该把最有价值的特性优先开发的原因，这样的话，业务人员就可以第一时间享用到这些价值。敏捷团队与传统团队存在这样巨大的差异：传统的开发团队把业务用户看作是要谈判的客户；而敏捷团队则是与客户（通常是产品所有者）合作，在项目执行的时候客户具有平等的发言权。（这就印证了“客户协作高于合同谈判”的敏捷核心价值观！）

原则6：以受激励的个体为核心构建项目，为他们提供环境和支持，相信他们可以把工作做好

    如果公司里每一位同事都意识到团队开发的软件是有价值的，而且团队中所有人（包括产品所有者）都能理解软件是怎样为公司创造价值的，那么项目就可以以最佳状态运行。

    常见的情况是，公司绩效审查机制和补偿制度不利于员工采用高效的敏捷方式开发软件，这些做法对项目无益。这背后的问题往往包括以下几点。

• 在代码审查中，如果不断发现bug，程序员就会获得糟糕的评价，如果没有发现bug，程序员就会获得奖励。（这会导致程序员在代码审查中不愿意找bug。）

• 根据发现的bug 数奖励测试员。（这会导致测试员挑刺并降低报告质量。这种方式给程序员和测试员之间设置了敌对关系，会阻碍测试员和程序员之间的合作。）

• 根据业务分析员产出的文档量判定其绩效评级（而不是根据他们与团队分享的知识量评级）。

    最终，所有人的绩效都应该根据团队交付的成果来评定，而不是根据每个人自己的角色来判定。对于一个团队来说，好的环境会奖励下面几种人：认识到软件并没有解决的某个业务问题并将其修复的程序员，以及能够发现代码或架构中的问题并提交给团队的测试员。在持有同甘共苦态度的敏捷团队中，每一位成员都对项目有责任感，并且为项目的成功与否负责。

原则7：可工作的软件是衡量进度的首要标准

    状态汇报很难获得项目的真正状态。汇报本身就是一种不完美的沟通工具：也许有三个人读的是完全相同的状态汇报，但他们往往对项目进度持有完全不同的理解。此外，对于项目经理来说，状态汇报也会有极强的政治色彩。几乎所有的项目经理都有过这样的巨大压力：有时候需要在状态报告中略去一些会让经理和团队主管难堪的东西，而别人常常需要用这些信息进行决策。如果状态报告并不够好，进度该怎样汇报呢？答案就在可工作的软件中。只要真切地看到了软件在眼前工作，那么你就“得到了”项目的进展。你可以看到软件实现了什么，以及没有实现什么。如果经理承诺了要交付的功能没有

在软件中，那会很难堪，但是又不可能不去沟通这个问题，因为软件本身就足以说明问题。

可工作的软件可以更好地给所有人汇报项目最新进展，因为这是团队用来交流当前已经完成工作的最好方式。

     敏捷团队使用迭代式开发有这样一个理由：在每一轮迭代结束的时候交付可工作的软件，通过真实的产品向大家展示具体成果，团队可以让大家掌握项目进展的最新情况，而且这种方式几乎不可能会让人产生误解。

原则8：敏捷过程倡导可持续开发。赞助商、开发人员和用户要能够共同、长期维持其步调，稳定向前

    保持团队最高生产效率的方法就是：保持可持续的开发节奏，不要逞强，不要匆忙赶工，避免加班。

    硬性的截止时间是命令− 控制式的工具，是不切实际的截止时间。从长远来看，这种做法是不可靠的。众所周知，一个团队可以拼命工作几个星期干更多的活，但是团队的工作效率一般都会在这段时间过后一落千丈。这是有道理的：人们都会感到疲劳并且失去动力。为了加班，他们推掉了很多重要的公事和私事，然而最终这些事情总是会重新找上门来的。实际上，那些严重加班的团队不会比正常工作的团队交付更多实质工作，而且往往工作质量更糟。

    敏捷团队信奉的是维持可持续的开发节奏。他们会针对预留的时间制订切实可完成的计划。通过迭代式的开发，这种计划的可行性很高，因为预估接下来两周、四周或六周的工作量远比预估未来一年半的工作量要简单得多。因为只承诺交付能开发的内容，所以团队不会动不动就加班到深夜或周末。

    如果团队采用迭代式开发方法，不断交付可工作的软件，那么大家就可以对每一轮迭代制订计划，从而保持一个可持续的开发节奏。通过更简单、更适时的方法设计出来的架构更灵活更可扩展。如果团队使用了更好的设计、架构和编码实践，那么就可以开发出更易维护和扩展的代码。

原则9：坚持不懈地追求技术卓越和设计优越，以此增强敏捷的能力

    从长远来看，避免bug 比过后修复bug 要快得多。设计良好的代码维护起来也要简单得多，因为其开发方式易于扩展。敏捷团队在每一个软件项目开始的时候并不意味着要花大量时间进行大规模的设计。敏捷开发人员会培养起非常好的编程习惯，从而帮助自己编写设计良好的代码。他们不停地寻找设计和代码的问题，一旦发现问题，立即将其修复。在项目的开发过程中，只需要在当下多花那么一点点时间编写可靠的代码并及时修复问题，那么留下的这份代码库在未来就会非常好维护。

原则10：简单是尽最大可能减少不必要工作的艺术，是敏捷的根本

    敏捷团队避免开发不必要的特性以及过于复杂的软件，保证给出的解决方案尽可能简单。

    在已有项目中添加代码会让项目变得更复杂，如果还继续添加更多依赖这些代码的代码，项目会变得尤为复杂，会产生多米诺骨牌效应。采用迭代式开发以及在项目初期将文档量控制到最小，可以帮助你的团队避免交付不必要的软件。

    在软件项目中，最有破坏性的事情就是编写代码，然后编写更多依赖这些代码的新代码，再然后再编写更多进一步依赖的最新代码。代码的连锁变化会产生可怕的多米诺效应，最终出现一大堆无法维护的意大利面条式代码。

    把待定的工作最大化可以避免这种困境，而最好的实现方式就是开发没有太多依赖和不必要代码的系统。而要实现这个目标最有效的方式就是与你的客户以及利益干系人在一起工作，确保只开发最有用且最有价值的软件。如果某一项特性没有价值，那么对于公司来说，更节省成本的方法就是根本不要开发这项特性。为维护这些代码而产生的成本往往比这项特性给公司带来的实际价值要高。编写代码的时候，如果团队可以基于一些只实现单一功能的小型自包含的单元（例如类、模块和服务等）进行设计，那么这个团队就可以避免多米诺骨牌效应。

原则11：最好的架构、需求和设计来自自组织的团队

    自组织的团队对项目的所有方面都负有共同的责任：从产品构思到项目管理到项目的设计和实现。

    自组织的团队（self-organizing team）并没有明确的需求和设计环节。自组织团队会用合作的方式对项目进行规划（而不是依赖某个“负责”计划的人），而且会持续地作为一个团队改进计划。采用这种工作方式的团队通常会把项目分解为多个用户故事或其他类型的小块，从能够给公司带来最大价值的块着手，然后再考虑详细的需求、设计和架构。

    在敏捷团队中，所有人都对架构负有责任。尽管高级软件架构师和设计师仍然很重要，但是他不再孤立工作。实际上，如果团队从最重要的分块开始逐块构建软件，那么架构师的工作会更有挑战性（而且也更有意思）：敏捷团队不会在一开始就创建一个覆盖所有需求的大设计，而是采用增量式的设计，这就要求设计的系统不仅完整，而且还在项目变化的时候方便团队修改。

原则12：团队定期反思如何提升效率，并依此调整

    敏捷团队在每一轮迭代结束的时候和项目结束的时候会花时间总结过去，讨论总结经验，提高开发软件的能力。

    敏捷团队会不断地检查并调整，成员会检查自己项目运转的方式，并通过检查的结果对未来进行改进。增强团队实力的唯一方法就是经常回顾自己已经做的事情，然后评估作为一个团队这些事情做得怎么样，最后提出能改进的计划。如果在开始每一个项目的时候，给每一轮迭代以及每一个项目的收尾阶段预留了开会时间，总结并评估已经完成的事情，而且制订出改进计划，那么团队更有可能真正地坐在一起讨论他们已经完成的事情。这样可以从经验中吸取教训，提高效率。