下载掌阅APP，畅读海量书库
立即打开
如今，敏捷实践者（Agilist，坚守敏捷价值观和原则的人）已经突破百万。调查结果显示，全球大部分软件工程师都至少尝试过一些“核心敏捷实践”[VersionOne 2009]。
敏捷的基本原则已被阐述过无数次，而且许多作者都比我诠释得好。但我仍然觉得有必要在书中包含一个简短的介绍。作为一名敏捷专家，我倾向于按自己的方式来做事，所以我将用自己的“软件项目的七个维度”来表述各个敏捷要素。我将在第11章重拾这个主题。
首先最重要的是，敏捷认为人是独一无二的个体，而不是可替换的资源，同时人的最大价值不在于他们的头脑，而在于交互和合作。敏捷要求不同角色（开发、设计、测试和其他）的人员组成跨职能的小团队，并且最好处于同一个房间内。这些团队是自组织的，这意味着没有任何强加于他们的方法和过程。团队获得信任从而可以用他们认为最好的方法去完成工作——前提是他们知道怎么做，并对结果负责。
敏捷宣言明确指出，客户只有与产品开发团队一起工作才能创建出最好的产品。团队和客户（或客户代表）一起合作，维护一个始终变化的未完成功能列表，并持续为其设定优先级。这些功能的描述简明扼要，只有在团队着手处理时，这些功能才需要更全面的探索和文档化工作。对所有功能来说，简单是良好设计的关键，当功能实现后，客户将立即验证其有效性。
关注质量是产品取得成功的关键，所以技术上的精益求精在敏捷核心中找到了自己的一席之地。我们可以借助下列实践达到目的：测试驱动开发
（写产品代码之前先写测试代码）；代码审查（可以通过结对编程来实现）；定义完成的标准（检查清单）；迭代开发（由于新的变化或理解而改写代码）；重构（持续改进代码，即使没有需求变化的时候）。敏捷专家承认
涌现式设计
的必要性，即最好的架构不是预先就定义好的（可能有一个基本的形式），它可以在产品开发过程中逐步浮现出来。
敏捷专家认为，工具对产品成功的贡献微乎其微，然而敏捷文献中却充斥着对工具的描述和宣传。经验丰富的敏捷团队更喜欢使用工具来辅助进行每日构建、持续集成和自动化测试。敏捷软件开发需要团队自我激励。但重复性的劳动不仅枯燥无味，还会使人缺乏动力，因此这些工作需要自动化完成。很多敏捷专家也要求环境的支持，比如开放的办公环境，信息透明化工具，比如大的任务板和燃尽图。在敏捷环境中，工具的目的是促进团队的激励、交流与合作。
敏捷和时间有着特殊的关系。对于敏捷项目，与预算一样，交付日期和最后期限几乎可以任意选择。软件以较短的时间期限进行构建，通常是时间盒或Sprint，并以增量的方式进行发布，而每个发布都是一个潜在可交付的产品。这就确保了业务负责人可以依据其对功能的需要和时间的要求来进行时间安排，前后调整发布日期。同时，团队总是孜孜以求可持续的开发节奏，使其能够长期保持其开发速度。
敏捷宣言诞生的主要原因之一是为了拥抱变化。环境从来都不是静态的。昨天还价值连城的功能或许一夜之间就变得一无是处，即使已经交付给用户的功能也不能幸免。敏捷专家尝试通过缩短反馈和交付周期来应对挑战。频繁的产品发布不仅意味着收集反馈，还意味着把这些发现反馈到开发过程中。更重要的是，一旦发现新的需求，可以及时向用户交付新的功能和调整后的功能，从而提高其商业价值。
尽管敏捷宣言提倡人胜于流程的模式，但这并不意味着流程不重要。更为重要的是，敏捷环境本身就包含许多必要的流程：最小计划（或递进式规划），每天面对面的交流（通常是站立会议的形式），通过评估可以工作的软件来衡量项目进度（客户签收的功能）。敏捷专家也承认持续改进的必要性。据此，定期的回顾和反思可以不断地评估和调整过程本身。
以上便是我心目中的敏捷基本原则。当然，它们只是我个人的想法。一些敏捷专家或许并不认同我写的这些简短介绍。但这也是敏捷的一部分，我甚至想把“冲突”列为敏捷软件开发的第八个维度。就像你随后将要看到的一样，内部冲突既是复杂系统固有的一个方面，同时也是创新的土壤。对于那些乐于持续改进的人来说，它将是一种巨大的特权。