CSM敏捷实践|如何让团队的迭代效率更高？

在互联网行业，敏捷应该不是陌生的名词了。互联网产品快速发展的特性，决定了“小步快跑”的管理思想，持续迭代，不断的改进产品。而应用敏捷基本上可以让迭代周期减少一半，在追求效率和产出的互联网，这确实是一剂良方。

在产品研发过程中，从需求管理到最终的产品运营，全过程应用敏捷的思想，让产品团队成为产品的主人和管理创新的驱动者。

当产品团队自发的去持续优化产品，不断提升产品质量和研发效率时，整个团队的工作效率就提升了，产品的迭代周期自然会缩短，他们会树立更高的目标去挑战，当他们持续地周而复始时，卓越就成为了团队的习惯。

在敏捷实施的过程中，从产品经理的角度来说，更应该关心需求是否也可以迭代的方式去产出，合理的按照价值和优先级去安排每个迭代需求，是产品经理需要关注的。这会保证每个迭代开发人员在实现的都是优先级最高的需求。

从开发人员角度来讲，对每个迭代的任务的需求理解和工作量安排是他们所要关心的，要合理的分配每个人的任务，以达到最大化的效率利用，进而保证每个迭代的高效产出。

团队动态背后反应的问题可能是多方面的，不同团队不同阶段碰到的瓶颈也不同，下面用三个维度来进行分享有效的实践案例：

需求协作

简单点说就是，每个迭代开始前，让产品，开发和测试三方一起来看看接下来迭代的需求，确保大家对这些需求的理解一致（注意这里强调更多的是一致的理解而非需求正确，因为这次需求的正确性已经不是这些人讨论能解决的）。

具体讨论的方式是为每个需求写出验收条件或者测试用例，使用的例子越具体理解的一致性越高，当然讨论会更费时。这个主要针对需求-›开发-›测试过程中需求理解不一致导致的返工或修bug，通常有一半以上的bug都来源于此。

最简单的应用这个方式就是在写代码前，测试和开发一起看看针对这个功能可以有哪些测试用例，开发带着这些测试用例来开发。

团队结构

选择恰当的团队结构：职能团队，组件团队和特性团队。

职能团队即按职能划分：需求分析团队，开发团队，测试团队等。

组件团队即按系统架构的组件来划分：前端团队，后端团队，平台团队等。

特性团队则按照需求特性来组织团队，每个团队都能独立完成整个功能，较少或不依赖于其他团队。

这三种团队结构越往后团队效率越高，但不同的组织上下文不同，所处现状的约束也不同，需要选择现阶段可行的团队结构，逐步朝特性团队调整。

拆分需求

这里的需求指的是对用户有价值的需求，而非针对某个组件，拆分出来的需求也要对用户有价值。

需求拆分的力度参考：一个团队（人数为5~9人）在一个迭代内（迭代长度为1~3周）能“完成”的需求在5~7个左右。这里要完成的定义需要和团队一起商量决定，但至少要包括编码完成，测试完成，无严重bug。

这里提升的效率指的是整体需求的交付效率，而非个体或局部的效率。针对的是不同工作间的等待，排队，重复等浪费，缩短反馈周期。

敏捷开发在互联网行业中的应用是大势所趋，个人觉得会深刻影响到传统的瀑布式项目流程。

从实际经验来看，敏捷开发也确实有很大的优越性，能够更快的适应需求变更，灵活的安排资源的投入，每个迭代的产出都是产品的阶段性目标，也有可能就是一个小版本的发布，对于崇尚“持续迭代、小步快跑”的互联网产品来说，非常适合。