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