Agile Alliance 与敏捷的一次碰撞-京东云开发者社区

#### 说体会
之前经历过瀑布式开发模式，一直到现在接触的敏捷式开发模式。对这两个研发管理模式的优点和缺点也都深有感悟。瀑布式的模式是线性的，返工付出的代价会很大；通过强制的完成日期和里程碑目标来确定各个阶段，很难做到动态的调整目标。

经过参加敏捷实践的系统性的培训，对开发管理有了新的认识，敏捷开发注重的是交互反馈，是合作，是及时得应对变化的需求，不是发生功能全部开发完成后，再去向客户或者产品经理去检查确认其正确性，而是开发中定时的不间断的进行反馈确认，避免了瀑布式的弊端。

#### 说敏捷
其实敏捷它涉及了很多有关人的因素，比如说人的习惯、团队的文化改变、契约的建立等等，这些都需要渐渐的去形成，去交流达成共识，不能一蹴而就，是需要一个过程的。因为它的核心点就是持续的改进并优化实践，可以说是一场没有终点的旅行。

敏捷是有一定的规章框架的，大部分人都以为Scrum框架不就是有：3个角色（PO产品负责人、ScrumMaster、团队），3个工作（待办列表，迭代列表，增量列表），5个会议（每日站会、迭代计划会、迭代回顾会、迭代评审会、产品梳理会），5个价值（专注、承诺、开放、尊重、勇气）吗，照搬过来套用就完了，不就是敏捷实践了吗。虽然符合敏捷的规章框架，但是如果想运用好它，你不能仅仅拘泥于他的规章框架，一定要找到适合自己团队的一套管理方法，一定不要为了敏捷而敏捷。
#### 说改变
##### 敏捷前：
- 之前的工作习惯是，不管产品提出多少需求，来一个做一个。接需求没有合理的控制，也无法可视化团队的资源使用情况。

- 还未进行敏捷实施之前，我们每天也有每日早会，但有时会针对发生的一些问题过度的深入讨论，导致拉长了早会的时间，间接的占用了整个团队的时间；

- 我们之前有复盘会，会针对每次的线上问题，或者需要优化重构的问题进行展开的说明，让大家都更深入的了解系统；但并不固定

- 需求梳理时很多是小组leader去和产品沟通确定决策方案，使得整天疲于奔走各种会议。

##### 敏捷后：
- 敏捷以后，**需求管理**，使用行云团队的所有资源使用情况，全部变为可视化的，一目了然。需求的优先级排期也更加清晰，认领任务时也清楚的知道需求的具体上线时间，背景及验收标准等等。每个迭代的需求吞吐量也可以评估出来，避免了一些过度的承诺。

- **每日站会**我们约定仅叙说昨天做过的，今天要做的，报问题点，会后决策。这样大大的提高了我们早会的效率。ScrumMaster在会中针对无效的讨论也会及时的给予提醒或制止，避免无效会议。早会时间一般控制在15钟之内。

- 现在的**回顾会**每次我们都是定期的去总结线上发生的问题形成技术债且完成它，进而定期的巩固系统，及时地将可能发生的问题止于萌芽，也会去检视一下我们团队自身的效能，如何能更上一层楼。这就**形成了持续提升的力量**，不像之前的断断续续。

- 针对**梳理会**我们团队设计了一个对外沟通模式即每个业务线都有专门的业务接口人，负责沟通、确定产品方案、问题反馈等，梳理会时产品可以直接找相关的接口参会。但后期的开发可以不是接口人，可以是团队的其他成员，这样可避免开发阶段的单点问题。

#### 说收获
我们团队为了提升每个人的参与感，ScrumMaster角色采用按季度轮岗制，只有感同身受了才能更好的提升自我管理，我觉得这是个很好的一个敏捷实践，我是第三位轮岗的ScrumMaster；我深刻感受到ScrumMaster并不是领导者，而是服务于团队的服务者；他的角色是如何使团队更高效沟通、合作，以及使整个团队如何快速地应对变化。其实**做得多并不等于价值多**，我们在工作的同时也要去思考这个问题。避免一些无价值的需求，而忽略了真正有价值的需求。

我们的SM轮岗制使得我们每个人都有机会服务于团队，使得我们每个人都能更好的自我管理，自我提升，最终通过持续的学习将团队变为一个以自我驱动为核心的队伍。
以上就是我作为一名ScrumMaster的一些体会，同时要感谢敏捷教练团队工作中的培养，用他们的经验指导我们团队少走了不少弯路。

最后我想说，其实敏捷看起来简单，但是实施起来并不容易，他还是具有一定的复杂性的，需要你不断的去摸索和持续的优化，但不管怎么说我还是觉得积极吸纳敏捷带来的好处还是远超你的想象的。

------------
##### Being Agile 京东物流技术发展部效能提升部
###### 作者：中台技术部 王继奎