2001年2月11日至13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地，17个研发大牛聚到一起，交谈、滑雪、休闲，当然还有聚餐。他们试图找到共识，最终的成果就是《敏捷软件开发宣言》（Manifesto for Agile Software Development），敏捷宣言它给出的并不是一套完美的软件开发解决方案，而是新时代背景下软件开发的价值观。
01
这是几句话呢？这是6句话。而且，前后两句其实更重要，但往往被忽略，或者被故意扭曲。
“我们一直在实践中探寻更好的软件开发方法”：敏捷的落地实践方法一直在改进或者探寻中，没有最好，只有更好，不论是极限编程、Scrum、DSDM、Kanba、水晶方法、特征驱动开发等等，都是实践敏捷的一种方式，它不能完全代表敏捷。
工作的软件 高于 详尽的文档：对于客户和用户来说，在软件生命周期中所形成的详细文档，其本身对他们而言是没有太大价值的，他们不会关心软件是如何设计、开发、交付和上线的，他们更关心的是基于这些文档生成的可工作软件是否能够满足他们预期的目标，为他们创造真正的价值。
客户合作 高于 合同谈判：任何商务上的合作均避不开谈判和合同，通过达成一致并形成约束是双方甚至多方利益的基础保证。但多方所追求的价值最大化并不能通过谈判的内容和合同的条款来达到，相反这两者在某些特定的情况下可能会成为制约。只有摈弃传统的甲乙方关系，在一个平等互信的基调上产生的合作才能产生长远和稳定的合作关系，双方的价值诉求都达到了才是最好的结果
响应变化 高于 遵循计划：对于变化的事物，我们本就很难透过很长的一段时间来预测它在将来的状态，尤其处于当前的时代趋势，快速的变化让预测的准确性变得无法确定。不假思索地一味遵循那些基于可控和可预知的前提所制定的计划，是没办法让我们达到预期目标的。认识到变化的客观存在，并基于目标来不断调整来适应它，会比机械地去执行计划中的任务清单要显得明智得多
右项有其价值，我们更重视左项的价值：右项不是不重要，毕竟右项也是在软件行业的某一个阶段产生了巨大的作用，但是在当下的环境中，左边的项目更应该被重视，也是顺应新的时代背景
02
不论是敏捷理念，还是敏捷研发宣言，都是内在的思维，都是无形的。就像内功心法一样，看不见，但很重要，在具体的实践过程中，衍生出了很多具体的落地实践，下面列举一下几种常见的实践及他们的特点。
看板：看板方法的内容相对较少，核心只有三大原则：可视化、限制在制品、管理流动。引入看板不需要改变任何流程，只让流转规则可视化，让每个人的分工透明化，不会给团 队带来新的负担；通过看板的可视化，让团队决策的可视化，当我们关注看板反馈出来的“味道”时，很容易让成员理解团队的决策以及要解决的问题；最后，看板活动不需要增加额外的角色。现有的团队成员就足够完成。关于看板，可以参考我之前的文章（关于看板的思考与总结）
Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是一至四周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 以上文字来源于Scurm中文官网。有兴趣的可以看看。
结对编程（Pair Programming）是极限编程（Extreme Programming，简称XP）的十二个实践之一。它指的是两个软件开发人员共用一台计算机其中一个人负责具体细节工作而另一个人关注整体，但这两个人的角色可以随时互换。这是一种轻量、高效、低风险、柔性、可预测、科学而充满乐趣的软件开发方式。结对编程可改进设计质量、减少程序缺陷、降低人员风险、提高技术技能和团队合作精神。结对编程对人员的素质要求较高，比较推崇TDD。
03
这些东西有什么内在的关系呢？
如上图，敏捷是一种理念，一种心态。这种心态运用在软件的研发过程中，形成了敏捷宣言及对应的价值观（本文没有展开介绍，有兴趣的自行查阅），基于这些价值观，在不同的团队形态，不同的实践中，形成了不同的风格，诞生了不同的方法论，比如Scrum，比如KANBAN等等。
04
理念的东西描述完了，结合上一篇，主要回答的是什么是敏捷。虽然大家都在讨论敏捷，但很多时候大家的认识又不太一致。后续这个系列都会基于这些理念，结合自己的实践和ACP的课程内容，进行阐述。期间也会穿插一些敏捷测试实践的相关内容，欢迎持续关注。
