我眼中的敏捷宣言

提到敏捷这个词，相信大多数人已经不再陌生。

最初我们所说的敏捷即为敏捷开发，尽管在行业竞争日趋激烈的今天，敏捷一词已不再局限于软件开发行业。

敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

“敏捷”（Agile或agile）一词由“敏捷软件开发宣言”中开始推广，“敏捷软件开发宣言”定义了相关的价值和原则。

对于实践过敏捷开发的开发人员或团队来说，我想大多数人是认同的，当然不同人对敏捷开发的理解自然不尽相同，这里仅针对敏捷开发宣言谈谈自己的理解。

敏捷宣言

敏捷宣言于2001年由十七名软件开发人员在犹他州的雪鸟度假村讨论共同起草。

这里将分别就每一条谈谈自己的薄见。

个体和互动 高于 流程和工具

先从右项说起

在整个项目的历程中可能需要一些工具来支持我们更好地完成工作，例如在项目前期可能需要原型工具，开发阶段我们会用 Jira 或 Trello 等来做卡墙，使用版本管理工具来管理我们的代码，QA 需要依赖一些工具进行测试，Dev 们同样需要 IDE 支持日常开发工作，这一切都是工具的支持。

同样我们可能也会有一些工作上的流程，例如一张 story 卡从“Ready for Dev” 到“Done”都需要经历些什么，我们在和客户进行日常交流沟通的时候也可能需要遵循一定流程。

这些工具和流程合理运用的话固然能够帮助我们更好地完成交付，但是如果没有运用好的话很有可能会反向促进。

合适的工具能很好的帮助开发，但当在开发人员面前出现大量庞大笨重甚至不好用的工具和开发环境时，就会像缺少工具一样，这样是违背了我们的初衷的。或者说在开发过程中，出现夸大了工具的作用，当开发工具对开发起起决定性的影响时，可能就需要反思是不是一开始的做法是不是有问题呢？

流程和工具是定的，但人却是活的，强大的方法和工具如果离开了人员和团队的支持，也终将只是摆设。

敏捷开发中鼓励团队成员更多地交流和互动，在敏捷项目中我们会拥有各种不同职能的成员，每个成员都需要关注如何实现高价值的交付，定时和团队的其他成员一起查看团队的整体进度，计划下一步工作，并且对于遇到的问题讨论解决方案。同时团队的及时交流互动能够及时拉通项目成员间的信息，避免在某些事情上存在歧义，团队的及时有效沟通能够也帮助提高效率。

在日常工作中，我们可能遇到不同的“突发状况”，例如某关键成员请假，这时日常的沟通就使得团队能快速找到 backup，使得项目上下文不至于中断或者被 block，这些情况是既定的流程和强大的工具无法解决的。

工作的软件 高于 详尽的文档

在传统的瀑布式开发方式中，文档作为各阶段传递信息的载体。需求文档中定义详细的用例和细节，原型图中定义每个组件的形式、放置位置等，数据库设计图、测试用例文档等，如果没有文档，开发的工作将不能顺利展开。

编写一份详尽的文档固然可以使我们的工作更好的开展，但这些是基于需求既定的情况，如果需求在开发过程中随时可变，这种不确定性就会使得维护文档变得异常艰难。但是在大多数项目中，除非这个项目已经花了充足的时间去思考需求，否则不可能一开始就清楚所有细节。而更多的是，团队在开发过程中客户才越来越清楚自己想要的是什么。对于这种情况，维护文档的工作是很痛苦的，文档的维护需要投入大量的时间和精力，如果考虑和代码的同步时，工作量更是急速上升。有失必有得，如果一味追求文档必然会在代码质量上有所下降。

但是我们是否想过，我们提供的这些详尽的文档对客户来说是否真的有价值呢？客户需要的可能是一个可以正常运作的软件来实质性地解决某些问题。对于开发团队来说更是如此，我想没有人愿意话费大量时间来编写这些繁杂且琐碎的文档。通过频繁地提供可以工作的软件也可以使客户看到团队的价值对于客户关系的提升也有一定的促进作用。同时，对于开发团队来讲，小步迭代也能够在日常的工作中加深对业务的理解。

客户合作 高于 合同谈判

项目的开发当然都是基于合同，在组建开发团队之前，项目经理就会和客户方沟通，确定一些法律条文以及交付产品包含的功能等。在进行开发了之后，如果需要修改合同，则需要经过一些列复杂的流程。所以在开发过程中，客户可能就是简单询问一下进度，如果没有大的问题就不会存在合同的修改，等到最终交付的时候如果出现了和最初合同谈判阶段不一致的功能或问题时才会通过谈判进行解决。所以说，如果仅仅依靠合同谈判来进行开发的话，开发过程中就无法及时获得客户的反馈从而及时修改，等到最终交付的时候才发现问题就会大大降低效率。

我们在谈项目的时候应该是尽可能地寻求客户合作的价值而不是一味追求合同谈判。软件开发的最终目标是提供给客户可工作的有价值的软件，而只有客户才知道自己真正想要的是什么。敏捷团队中提倡开发团队和客户紧密协作，在每一个迭代中经常提供反馈，尽早地和客户沟通才能更早暴露问题，将问题的影响降到最低，不致于到最终交付的时候手忙脚乱。

响应变化 高于 遵循计划

当拿到合同后，项目经理就会开始组建团队进行开发，然后作出一系列的计划，包括需求、测试、开发、部署等一系列详细的步骤，开发过程中就得遵守这些步骤。

但是值得注意的是，计划永远赶不上变化，我们无法预见在开发过程中会遇到什么变数，尤其是在敏捷项目中，存在太多的不确定性，这个时候如果我们一味遵循最初的计划肯定是行不通的。所以在敏捷项目中，我们一般不会定太长的计划，常见的是设立较短周期的迭代，在每一个迭代开始之前，我们会开迭代会议，确定本迭代需要完成的交付任务以及每一个故事卡的优先级等。即使如此在每一迭代中也有着不确定性，例如临时出现更高优先级的卡或者当前迭代工作量不够时就会相应作出调整。通过不断的响应变化来消除过程中的不确定性。

尽管右项有其价值，我们更重视左项的价值

这一条常常会被大家所忽略，但恰恰这条才是最重要的。

我们在提倡左项的时候并不是说要否定右项，只是说在某些具体情况下左项更重要一些。

例如，我们说个体和互动高于流程和工具，并不是意味着流程和工具就不重要，相反，正是有了这些才能够更好地支持我们的工作；我们在开发过程中仍然需要文档的支持，在和客户交流的时候以及一些交接工作等；为了双方的利益我们依然需要合同谈判；敏捷不是不需要计划，相反我们可能需要更多的规划，在规划、执行、调整中不断消除或减少不确定性。

重新读了敏捷宣言，感觉理解更深刻了一些，同时也因为有了一些实践对理解也有一定的帮助，以上仅仅总结一些个人的理解。