敏捷，近几年非常火热的一个词，当前团队也在做新一轮的敏捷理论导入。后续会持续输出相关的内容。现在，我们就从头开始吧，聊聊个人对敏捷的理解。
01
如上图，是两部非常具有代表性的电视剧，从研发的角度来看，可以分别代表瀑布和敏捷两类研发模式。
《延禧攻略》，按标准的影视制作流程：编剧（需求文档输出）、开拍及后期制作（研发）、送审（测试）、上映（上线）。能不能得到观众的喜爱，靠的是宣传及主角IP。在大量的资金投入下，效果不会太差。但是，它的缺点也是很明显的，在影视制作过程中，如果遇到突发风险，没有修改的余地。比如某凡事件，让多少影视作品无法正常上线。
《Game Of Thrones》，按季播放的美剧，它的特点是把一个大IP切成小任务，边写边拍边播，观众看到剧的等待时间变短了（交付时间变短）。而且，它还可以根据用户的反馈不断的修改剧情，琼恩·雪诺明明已经死了，但是用户不买账，在后期又复活了。这就是敏捷的特点，小批量快速交付，及时收集用户反馈。在更短的周期内价值最大化，同时，也提升了应对变化的能力。
02
都说现在是VUCA的时代，需要我们拥有应对变化的能力，而敏捷，刚好为我们提供了这样一种能力。敏捷是应对既快速变化又复杂世界的一种策略，敏捷也是打造团队和创造价值的一种方式，选择适应变化是敏捷的精髓。
敏捷增强了管理变化优先级的能力：由于每个迭代都需要小批量的交付有价值的内容，那么每个迭代做些什么就显得特别重要，这需要产品经理能够明确的把握需求的优先级，有效地做出调整，对应来自客户和市场的变化。
敏捷提升了交付时效：原来一个项目，用户可能要等三个月、半年甚至更长的周期，才能看到项目内容，在这其间，项目对用户是黑盒的，最终给到用户的是惊喜还是惊吓，是不可预知的。通过敏捷，我们可以更早（一般是1个月或者2周）的交付部分有价值的功能，让用户尽早地参与进来，一起对最终的交付内容做保障。
注意，是提升了交付时效，不是提升了研发效率，这是两码事，也是大家对敏捷误会最最深的点之一。
当然，敏捷还会带来其他的收益，例如项目可视化、业务研发协同、降低项目风险等，不一一展开。
03
那么，是不是所有的场景都合适用敏捷来解决呢？答案显然是不是的，没什么东西是银弹，能解决所有问题。
如上，左边是根据Cynefin框架演化而来的，可以用敏捷来解决问题的场景。从需求和技术的不确定性来划分。
对于需求明确、技术明确的简单问题，那就用瀑布模式直接开干；
对于需求不确认，技术也不确认的混乱领域，需要通过创新来解决的，也不适合用敏捷的方式来进行；
剩余的其他领域，都可以通过敏捷的方式去尝试解决。
右边，通过业务与研发的信息透明度，划分了4个领域，分为了积压需求、优化需求、政治任务需求及空降需求。
从这个角度来看，敏捷研发过程可以帮助业务把需求透明可视化出来，同时可以知道研发有哪些优化需求，降低沟通成本，让研发知道业务想要做什么，让业务知道为了更好地实现业务，研发有哪些优化类需求，在迭代版本中去动态平衡。
同时，对于空降需求，也可以尽早地反馈，让研发知道业务还有哪些需求是有可能要做的，提交沟通、布局，避免到了迭代快开始时，研发才知道。
04
敏捷从来就不是也不应该是“目标”，它只是我们达成目标的途径之一。我们最终关注的是价值的实现和交付。上山的路远不止一条。
不同的业务场景和组织形态，可以选择不一样的落地实践，没有最好，只有适合。最需要我们敏捷的，是我们的思维。
如果只是生硬的去落地敏捷实践，而不从思维上做出改变，很难说你了解敏捷。
Dont do Agile, be Agile。
