敏捷转型感想

        在接触敏捷之前，大多数人会一知半解，更多的是将敏捷当作一套理论执行，被各种各样的框框线线所约束，从而得出结论——走敏捷，不太行，面子功夫。当然我本人在最开始也有这样的想法。这是初入敏捷最大的误区。

        我们习惯去参考别人的模型，踩别人走过的路，却忽略了适合自己的才是最好的。不同的团队结构、不同的产品路线、不同的痛点问题，在敏捷路线制定过程中都会有或多或少的差异。如果不能从结合自身特点出发，往往很容易将解决问题本身当成转型，带来的结果就是阻力重重。

        我们传统模式的开发，在需求稳定、人员稳定的状态下，运作还算良好。随着团队内承接的需求、产品越来越多，复杂度越来越高，容错率越来越低，开发人员依赖度越来越高的情况下，传统模式暴露出了很多问题：信息同步有问题，实施效率变慢，交付质量变差等。于是，从落地解决问题的角度出发，尝试采用敏捷模式。

        1、重建沟通机制，保证跨团队、跨部门的协作有效性

        2、随着团队规模越来越大，进行合理拆分

        3、尽可能的进行人员解耦，避免同一个人多团队

        4、晨会、看板、迭代回顾会的按期进行和合理利用

        .......

        推进过程我们遇到的典型困难有：

        1、其他事务工作影响正常迭代的进行。比如日常工单的处理，生产问题的解决，或者不定时的一些安全审计整改工作，这些工作都会影响正常迭代的进度。经过一次次的踩坑，我们总结了以下方式避免这种影响：（1）将常规的日常工作预留进迭代时间，比如工单处理是没要做的事务，提前将这部分工作占用的资源进行预留（2）梳理问题和工作清单，进行问题过滤，优先处理紧急且耗时不多的事项，将其他事项留到下个迭代。

        2、第三方原因导致的迭代无法完成。比如依赖于第三方的接口，需要一定时间和审批流程申领的资源等。应对措施如下；（1）在迭代开始前明确依赖于第三方和第三方能够提供的资源，尽可能的降低迭代实施任务的不确定性（2）在迭代任务中，区分内部任务和外部任务（3）需要第三方支持时，及时进行沟通协商，降低由于缺少沟通造成的影响。

        敏捷开发的核心在于快速迭代，主动拥抱变化。我们日常接触的需求和排期的实施周期往往在两个月左右，这就需要将实施周期进行拆分，将月度拆分为两周左右的小实施周期，然后进行一轮一轮的迭代。在中大型项目里，每一轮进行常规迭代会可能出现开发整体缺少连贯性或者出现一些由于实践问题而忽略的代码质量问题，于是，我们加入强化迭代，在两个常规迭代之后加入一轮强化迭代，确保前两次迭代完成的任务能够有一个质量保证，在强化迭代中进行性能优化、问题修复、体验走查、安全性检测等，在这个过程我们的确发现了很多问题，同时也给了开发人员一定的时间去识别和处理这些在常规迭代的过程容易忽略的问题，这也是在敏捷开发一轮轮的迭代实施中摸索出的适合团队项目的迭代方式。