现代项目管理中，敏捷研发越来越流行；言必称敏捷，似乎不敏捷就是跟不上时代。敏捷真的就是现代软件项目的灵丹妙药吗？它是否真的是一个普适的研发方法？

敏捷缘起

先说结论：敏捷研发其实是一个非常有局限性的方法，不具备普适性！ 它的发展壮大只是因为契合了互联网高速发展，较好匹配了互联网应用对需求变化和发布频率的需要。

而互联网软件，相比传统软件，还具备增量交付，线上问题可快速修复，对质量问题容忍度相对较高等特点。这使得敏捷开发会更容易在互联网项目中落地。

而随着互联网巨头们对敏捷方法的采用，以及敏捷机构的大力推广，到今日敏捷似乎成了可以放诸四海而皆准的通用方法。也诞生出像Scrum、SAFe、LeSS、Nexus等等各种框架来应用敏捷

但我们观察这些框架的发展过程和应用场景，其实会发现每种框架都有不小的约束。小型框架如Scrum对团队人数有特别限定，有会议仪式的要求；大型框架如SAFe有对组织架构、多种配套角色和专门团队的要求。等等…

而大型框架的诞生，也是在实践中应对实际项目的真实运作，演进而来，是为了应对特定场景的问题，不断添砖加瓦，增加了更多的角色、仪式、流程。但这，似乎也在重蹈传统软件研发流程发展脉络，也同样是在向高复杂度团队的方向上一路狂奔！

敏捷的局限

所以我们不由得要反思一下，敏捷是否真的是一种有普遍适用性的方法？是解决传统问题的灵丹妙药？

不能排除敏捷中强调协作、响应变化等思想的正面价值，敏捷宣言本身，对传统僵化的软件流程进行变革是极为必要的。

但问题在于，敏捷是托生于对软件研发流程的思考，提出敏捷宣言的十七位大牛专家，无一例外，都来自软件开发领域。我们不能说这些大牛的思想和视野不够超前，但这个宣言，本身主要是针对软件开发这个领域的原有问题提出的解决思路。

也就是说，敏捷方法，先天只针对软件开发，而不是针对软件产品和项目管理。组成一个软件项目，经营一个产品，除了开发，还有产品、设计、运营、客服、质量、安全等等其他角色，这些角色的缺位，使这个方法在产品级落地时，就会缺少对应视角的针对性思考，而更多只关注在研发角色在产品中遇到的问题上。

正是因为这个先天的局限，敏捷在实际落地中，往往会遇到各种各样的问题。项目孵化期，专注研发时，是敏捷最容易产生价值的时期。但一旦产品走向正轨，需要面对更多不同单位、角色的协作时，敏捷往往就会显现力不从心的一面。

敏捷的价值

任何企业、项目的成功，其实离不开两部分，制度和文化。

• 敏捷方法，因为其先天的局限性，作为制度，不具备普适性。
• 但敏捷方法中传递出来的文化和价值观，才是敏捷的价值所在，无论是否采用敏捷方法，即便我们使用传统流程，拥抱敏捷的价值观，也依然能够帮助项目走向成功。

个人浅见，更多关于敏捷研发的介绍文章可参见合集：