自二十多年前推出以来，敏捷产品开发实践已大受欢迎。虽然这些实践得到了广泛的接受，但肯定有人在实践中挑战和质疑这些方法。
有太多太多的原因让人们追捧「敏捷开发」，这些追捧既有目的性极强的也有无脑跟风的。我在好多论坛或者交流群也见过有人问关于自己的团队适不适合「敏捷开发」的问题。所以今天，我来说说究竟什么样的团队才适合「敏捷开发」。
1. 小团队
这点应该毋庸置疑。从生活经验上来看，小动物一般用敏捷来形容，比如兔子、猫（当然，大动物也有，如：这头猪真胖，但它竟然还这么敏捷）。
小团队不会出现大团队那种尾大不掉的情况，「敏捷开发」进度可能每天都会变化，小团队有著更低的管理成本，产品经理可以很好的把控整个团队节奏。当然，小团队也是要五脏俱全的。
2. 需求聚焦
如前文所说，大家采用「敏捷开发」肯定是有目的的。不管什么目的，肯定是为了快速响应、快速上线。这时，产品需求一定要聚焦、再聚焦。
有太多团队都是开发到后期突然要改一些不影响大局的东西，比如介面不好看、Icon不精致、互动不酷炫、需求Cover面窄。这些东西放在普通开发节奏的团队中是没有大问题的，但是在「敏捷开发」团队中，只会拖慢整个团队进度，本末倒置。
3. 工作内容无边界
及时补位的思想是要深入到每个团队成员心里的。
「敏捷开发」的团队或是初创团队一般都是一个人当好几个人用，每个人都是多面手（这也是好多朋友觉得小公司好的一点，即负责的内容多、成长快），原因就是他们的工作没有边界。
比如底层开发生病了，中间层大哥一定要顶上；比如QA人手不够了，产品经理写测试用例并参与测试也是常见的事。
4. 团队无明显短板
越小的团队越容易暴露问题，木桶理论在小团队中更容易体现。
「敏捷开发」过程很容易被团队中的短板所影响，这事虽然其他成员也有及时补位的精神，但每个人精力毕竟有限，我们还是希望能够每个人各尽其职。补的应该是未知的突发情况，而不是可预见的短板，这两个本身就不是一回事。
5. 互相信任
团队目标必须高度一致，并且相互信任，尽量少的辜负其他人。
产品绝对信任开发评估结果，开发绝对信任产品发起的需求等等。少质疑多沟通，才能快速实现目标。
好多大团队都会有各种需求评审、用例评审，每天文山会海，而「敏捷开发」会尽可能简化这个流程。但是我们要说的评审只是手段，目的还是要锤炼产品需求。因此纠结于是否该简化评审流程的朋友们，请尝试理解“不要把手段当目的”这句话。弱化评审的前提一定是产品经理自己已经将需求想明白，即满足团队预期、满足产品预期，再进行交付。
6.拥抱变化
之所以采用「敏捷开发」，真正的目的是快速响应、解决问题。当外界环境发生变化的时候，一定要及时接受并拥抱变化。
所谓的变化来自两方面。一方面是外部变化，比如产品方向和预期不符、市场反馈不好等；一方面是内部变化，比如效果图或者互动真的需要改动才能上线等。
面对这种未知的问题，团队里的相关人员需要及时调整心态，一起拥抱变化。
个人经历
我所在的两个团队可以勉强算作是「敏捷开发」团队。
第一个产品20个月释出26个正式版，50多个Beta版，且保证每个Beta版有可以让使用者明显感知的新特性；第二个产品7个月释出10个正式版，20多个Beta版。
第一个团队满足上述所有条件，「敏捷开发」地非常顺畅；第二个团队由于有短板存在，导致「敏捷开发」非常吃力，加上后期团队成员心态变化，所以基本走上了各种评审的道路。
然而，我想说的是所谓的「敏捷开发」与非「敏捷开发」并没有谁好谁差的本质区别，只是哪个更适合团队。就像前面所说，不要把手段当作目的，主要还是看解决什么问题。
敏捷开发的优点
应对变化
也许敏捷开发实践为开发团队和企业带来的最大优势可能是它强调响应变更，并专注于处理重要事项。敏捷方法并没有迫使我们试图在9个月，12个月或24个月的预测中预测未来。一个适当导向的敏捷团队列出了他们可以处理的最重要的事情; 当他们完成列表中最重要的事情时，他们会转移到下一个最重要的事情…等等，无限制地。这种焦点有很多好处：
- 客户可以更快地获得他们最重视的问题的解决方案
- 利益相关者可以以渐进的方式对事物进行优先排序，以反映特定时间的实际市场状况
- 开发人员感到受到重视，因为他们正在处理真正重要的事情，并且会经常使用该产品的人（至少在理想情况下）得到深入的反馈。
接受不确定性
敏捷开发给组织带来的第二大价值来源是，它的实践接受了我们在第一次启动时对项目一无所知的事实。这与更“传统”的阶段门和瀑布方法形成鲜明对比，在任何人接触键盘以输入他们的第一行代码之前，预计需求将“完整”。
敏捷反而接受我们将继续发现更多信息; 我们可能会发现某个特定的技术解决方案无法满足客户的需求，或者我们可能会发现在所述问题下面存在完全不同的问题，通过解决问题，我们不仅可以解决建议的问题，还可以解决其他客户问题。将敏捷原则应用于我们的方法允许我们接受未知并优先发现和实验，以在我们完全致力于解决方案之前消除不确定性。
更快的审核周期
为了使团队既接受不确定性又对变化做出反应，随著工作的完成，需要快速迭代和周期性的全面审查 - 以确保考虑新的发现并评估当前的努力。大多数敏捷实践既可以进行时间间隔工作（Scrum），也可以控制“正在进行的工作”（看板）的数量，以确保在合理的时间内完成工作。然后，与客户或客户代理（例如内部服务团队或利益相关方团队）一起审查这些工作。
重点是确保从实际用户（或尽可能接近用户）的快速审查和反馈解决瀑布方法的最常见失败 - 在6-9个月的封闭式开发之后交付没有人真正想要或喜欢的产品周期。
释放功能的灵活性更高
除了与客户或客户代理进行更快速的审核周期之外，专注于以时间框或工作量方式迭代工作交付工作软件，使企业在将产品交付给最终用户时提供更大的灵活性。
在更传统的方法中，发布在所有计划工作完成时发生…或者更糟糕的是，在利益相关者设定的日期发布，无论实际工作在该日期如何完美。另一方面，敏捷方法提供了足够的功能
减少前期工作
在敏捷开发方法出现之前，不仅产品需求试图预测6-9个月内需要什么，而且它们还试图成为一个百科全书式的合同，概述和详述产品设计和开发的几乎每个方面。通常会看到产品需求文档（“PRD”）和技术要求文档（“规范”）超过50页或更多，并概述了开发人员将用作确切交付清单的具体可交付成果 - 仅此而已。
敏捷反而将我们的重点放在定义和优先处理要解决的问题上; 与我们的开发人员合作设计，指定和修改工作需要完成; 并且只施加将产品或项目转移到下一阶段所需的努力量。减少在前期工作中的调查，文件编制和合同谈判中产生高昂的前期成本。
敏捷开发的缺点
尽管敏捷可以提供的好处，但它并不适合所有人。因此，了解敏捷方法的缺点非常重要。考虑到这一点，以下是敏捷的五个主要缺点：
资源规划不佳
因为敏捷是基于这样的想法，即团队不知道他们的最终结果（甚至是几行的交付周期）从第一天开始就会如此，因此预测成本，时间和成本等方面的努力是一项挑战。项目开始时所需的资源（随著项目变得更大，更复杂，这一挑战变得更加明显）。
有限的文档
在敏捷中，文档在整个项目中发生，并且通常“及时”用于构建输出，而不是在开始时。结果，它变得不那么详细，经常落到后面。
分散的输出
增量交付可能有助于将产品更快地推向市场，但它也是敏捷方法的一大缺点。这是因为当团队在不同周期中处理每个组件时，完整的输出通常变得非常分散，而不是一个有凝聚力的单元。
没有限制结束
敏捷在开始时需要最少的计划这一事实使得很容易陷入困境，提供新的意外功能。此外，这意味著项目没有有限的结束，因为从来没有清楚地看到“最终产品”的样子。
难以衡量
由于敏捷以递增的方式递送，因此跟踪进度需要您查看周期。而“随时随地”的性质意味著您无法在项目开始时设置许多KPI。长时间的比赛让测量进度变得困难。
总结
- 「敏捷开发」需谨慎，一定要扪心自问团队是否满足上面说的几点。
- 「敏捷开发」不是万能的，解决问题才是王道，切勿盲目崇拜。
References
- What is Scrum Team?
- What is a Self-Organizing Team in Scrum?
- How Scrum Team Works? - A Brief Guide
- How to be a Good Product Owner in Scrum Project?
- What is Product Owner's Role in Scrum?
- Agile Development: How to Become a Qualified Scrum Master?
- What is Pig and Chicken in Scrum?
- Project Manager vs Scrum Master vs Project Owner
- What Are The Three Scrum Roles?
- What is a Scrum Master? The Role and Responsibilities
- What is Cross-Functional Team in Agile?
- As a Scrum Master, How Can You help Your Project Owner?