敏捷已经不是一个新话题了，虽然人们都多多少少听说过敏捷，但大部分人都还是觉得敏捷的概念很飘渺，或者对敏捷究竟是什么很模糊。敏捷的起源甚至可以追溯到上个世纪 80 年代。在软件开发领域中，敏捷始终是个热门话题，然而当实际应用敏捷时，却又总让人觉得困境重重。是什么原因导致了这样的现象？必须要从什么是敏捷说起。
什么是敏捷？
敏捷在广义上指一种思想或指导原则。它倡导由跨职能成员组成的自组织团队进行增量式、迭代式的开发，尽早地交付产品并获取反馈，从而不断地演进产品。它旨在交付高质量的产品并建设团队的响应能力。
大家一定也会经常听到 Scrum、极限编程（Extreme Programming，简称 XP）这样的词汇，第一反应似乎它们就是敏捷，这其中的的差异是什么呢？
正如前面所说，敏捷是广泛意义上的原则，比较有代表性的是敏捷宣言:
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
而 Scrum 及 XP 则是基于这些原则在具体层面的实现，比如 Scrum 专注于项目管理管理过程，XP 专注于研发管理、研发工作流，这也正是我们用来实践敏捷的框架。
传统开发模式的困境
传统瀑布模型对于产品研发的过程定义非常明确，团队通常也是按照过程由单一智能的人员组成，只对相应的过程负责。我们常说「计划赶不上变化」，在当下的这样日新月异的环境中，更是如此，频繁的需求变更相信是所有研发人员的噩梦。因此，传统瀑布模型的长反馈链显然不能满足复杂多变的环境。而且由于按过程分工，导致每个环节之间只专注于过程，而缺少对产品整体的认识，也带来了透明性不足、容易低谷潜在成本的问题。
取而代之的是敏捷模型，由跨职能人员组成团队进行迭代式的开发。它提供了一种简单的框架（是框架而不是过程），建立了快速反馈的机制，能够让团队自我管理，持续提升产品质量，并且降低成本，从而提高 ROI（Return on Investment）。
敏捷「神话」
「神话」指的是夸大了敏捷的作用，或者说本质是源于对于敏捷的认识过于片面。当敏捷成为「神话」的时候，往往是滥用的结果。举两个例子来说明：
神话一： 敏捷让团队跑得更快
敏捷采用迭代式的开发，其主要目的是抽取一个 MVP（最小可用化模型）尽快让用户体验到真实的功能，从而快速获取反馈，并列入后续的迭代计划。这与传统开发模式，做一个大而全面、相对「完美」的计划相比，实际上是缩短了反馈的过程，并且通过多次迭代降低了风险。团队跑得快体现在节奏感很快，但如果是以交付一个理想产品的最终形态作为衡量标准，所需要的时间与传统模式相比就没有那么明显的缩短了。其实在敏捷开发理念下，更注重的是在快速反馈多次迭代的环境下，能够交付更多的潜在产品价值。
神话二：敏捷过程是轻量的
这个观点也只对了一半。敏捷在某些方面确实是轻量的，正如前文所说，快速迭代的前提是每一次发布内容的轻量化；又如敏捷宣言的第二条「工作的软件 高于 详尽的文档」，敏捷与另一种重文档的开发模式 DSDM（Dynamic System Development Method）相比恰恰相反。但值得注意的是也并不是不要文档，这里只是不提倡以文档驱动开发，文档作为沉淀在敏捷开发当中还是至关重要的。另一方面，其实敏捷开发也有「重」的环节，比如提倡的仪式感，又如产品管理环节当中的规划过程，团队需要投入更多的精力去拆解需求。
本文到此结束，下一篇文章将从敏捷转型的第一步「搭建敏捷团队」开始为大家一层一层揭开敏捷的面纱。
作者：Teambition Scrum Master 张子秋
网友评论