敏捷并非万能，其应用需要结合具体场景和时机。本文从产品经理的视角出发，探讨了敏捷方法在产品设计、用户研究、交互框架定义等阶段的适用性与局限性。

敏捷的思想虽然起源于软件开发领域，但是实际工作中被不断泛化到其他工作领域，比如：用户研究、产品设计、交互设计、视觉设计、业务协作等场景。

但切记一句：敏捷初心不假，切莫无节贪用！

敏捷被利益相关方中的商业利益相关者（你团队的vp）所钟情，无非是看中他的经济高效的预期。这里就是经典的不可能三角，速度、质量、成本，不能同时兼得。所以，敏捷受到不可能三角的约束，换句话说，敏捷是不可能三角里面的最优解。

特别在产研前期的用户模型构建阶段、需求（场景需求或者俞军老师口中的交易模型）定义阶段、交互框架定义阶段，即便我们的开发团队迫不及待的想进入敏捷的节奏里面，恨不得边设计边coding，但是这里还是不得不刹一脚，尽可能的给即便是我们口口声声所谓的“敏捷设计”方法预留时间。

敏捷就算应用到用户体验设计阶段，也意味着无法一蹴而就的达到最贴合用户目标的设计。但也正是敏捷方法具有自己独特的优势，支持设计者可以在过程中进行定义的修正和优先级的安排。

大设计->大开发，是不是严格的瀑布？

先设计、再研发，常规理解上很像是经典的瀑布式模式，尽管在大开发内部已经普遍流行敏捷方法。但不得不说由技术限制蕴藏的阻碍与机遇，对于支撑用户目标、市场目标、商业目标来说也同样重要，这就导致了技术对于设计的反向制约。

你会发现，大设计、大开发其实并不太适合直接放在瀑布流中的。实战的经验也发现了，如果你把它们当作瀑布，严格遵守设计之后再去做开发，它们就会给你猛泼一脸冷水！最后还不忘一口，呸！相反，有些市场机会就算商业和产品层面嗅探到了，但也可能由于需要技术发展的跟进才能进行场景的承接落地。比如移动支付、短视频、NFC、RFID相关的商业场景，哪个不是要依赖技术和硬件设施的成熟后才得以场景的落地。

一个产品经理把敏捷方法应用到工作中，特别是新产品、完全开发需要一定周期的，敏捷给你的最有价值好处就是用户对于体验的反馈。哪怕前期的用户研究如何细致，当用户真正面对和使用产品时，真实的体验反馈/态度、如何使用、哪里易错、哪里出奇不意，这些一定是更为宝贵的资源，切实的把你引领到藏宝阁。

敏捷，有所用，有所不用，最底层思想大致总结为三点：

1、别死磕计划，先干再说

需求会变、问题会冒出来，别等“完美计划”，先做最核心的功能，边做边调整，越快看到结果越好。

2、别自己憋大招，拉所有人一起搞

客户、老板、程序员天天碰头，有问题当场吵明白，别等到最后才发现做歪了。

3、做一点就立马给客户用，听骂声

早挨骂早改，别等做了一整年才发现全错。客户骂得越狠，你改得越快，最后东西才靠谱。

适合用敏捷的：需求不明确、老变卦的事（比如做个新App、搞市场活动）。

别硬用敏捷的：

• 需求100年不变的事（比如造桥，图纸定了就不能天天改）；
• 领导非要按自己说的做，不听团队反馈的；
• 团队躺平不沟通的，敏捷能急死你。

敏捷就是对付“变化多、要快”的武器，但如果你非要拿它砍柴，倒不如用菜刀。