敏捷转型16个月，总结期间得与失

本文将总结在过去的一段时间里，我们在转型过程中踩过的坑，以作前车之鉴。也聊聊在转型过程中，哪些优秀的实践可以尝试，走上渐进变革的道路。

到今天，我们已经在敏捷转型的路上已经磕磕碰碰的走了16个月。从启程时的兴奋到现在的淡然，回想起来还是“图样图森破”，原以为把敏捷那一套运作模式拿过来，随着时间的推移，一切就会好转起来。然而，并没有那么简单，受限于组织架构，仅仅是把敏捷那一套运作模式照搬过来我们就做不到，更别说照搬过来后能不能适应我们的产品研发了。

虽然，目前敏捷转型和预期比起来进展不够理想，但是在期间我们还是运作起来部分优秀的实践，提高了产品研发效率。本文将总结在过去的一段时间里，我们在转型过程中踩过的坑，以作前车之鉴。也聊聊在转型过程中，哪些优秀的实践可以尝试，走上渐进变革的道路。

1.敏捷初识，我们的敏捷做对了吗

在接触敏捷之处，大家对敏捷都是一知半解，更多的停留在字面意思的理解上：“敏捷就是快“。一旦有人觉得不快时，就会发出质疑，我们的敏捷做对了吗？另外一方面，由于刚接触敏捷，我们开始变得理论化，严格遵循敏捷定义的方式方法，条条框框，带着对敏捷的敬畏，天真的认为敏捷规定的都是好的，敏捷之外的方式方法都是不完美的，有缺陷的。对，这就是我在刚接触敏捷时，最大的两个误区。

1.1.目光不要只关注敏捷的快

快，仅仅是敏捷带来的一个结果而已。单纯的只关注这个结果，并不能对我们的转型带来什么帮助。关于快的定义，我们习惯性的参考别人做产品是什么样的节奏，找到业界的优秀企业作对比，认为做到那样才是快。然而，我们却很少去关注对应产品的品类和复杂度，忽略他们的组织文化、组织架构、人员素质、开发过程中的取舍等各种细节。看到别人家的孩子全是优点，自家的孩子一堆问题，却不去了解别人是如何解决那些问题的，付出了什么代价，只想取别人的优点，忽略别人的缺点。

欲思其利，必虑其害，欲思其成，必虑其败。–《便宜十六策·思虑》

我们在做敏捷转型时，引入了外部咨询培训，培训过程中老师举了一个例子：“他们以前做产品时，一天可以发20几个版本。”，这样的例子对于我们来说简直是太刺激了，我们的产品要一个多月才能发出去一个版本。虽然我们知道老师举例的产品是web端产品与我们的产品完全不一样，我们还是不由自主的认为我们是不是可以做到1周发一个版本，甚至更快，毕竟别人一天20多个版本啊。对，我们的目光完全被“快”吸引了，于是什么都围绕怎么能更快去开展改革，想方设法的充分利用资源，各种并行，反而导致混乱。

1.2.不忘初心，实事求是

我们是一家销售消费类硬件产品为主的公司，在引入敏捷之前，我们采用的瀑布开发模式，在产品复杂度低，研发人员较少的情况下，运作还比较良好。但是，随着产品复杂度的增加，研发人员增多，人员依赖度的增加，这样的研发模式变得十分笨重，连一个基本的信息传递都出了问题，集成一个版本变得十分困难，发布日期也总是一拖再拖。从结果上看就是我们不能按时发布，发布的周期比较长，产品研发变得“不敏捷”。然而要实际落地解决问题我们需要在这几方面改善：

建立新的沟通机制，保障跨领域协作的有效沟通。需求要进行有效的优先级排序，并控制数量，并承诺对应优先级需求的交付率。避免建立过大的团队组织，如果存在，需要根据业务的独立性，拆解为适当规模的小团队。团队之间人员要解耦，尽量避免一个人在多个项目团队。信息透明，尽量让团队成员能基于已有的信息自己做出决策，而不是询问上级。建立跨领域团队，并对团队进行敏捷开发知识的宣导和指导。引入持续集成。限制在制品，避免一个人同时开展多项工作，原则上不能超过2个未完成的任务。

等等……

我们不再纠结于是否一定执行了敏捷里面规定的活动，又或者说我们现在的项目过程，也谈不上是完整意义的敏捷开发，我们更注重什么样的招式能有效解决我们当下的问题。

1.3.我们的绊脚石

本文开篇讲到了组织架构导致我们并不能完整的引入敏捷开发的各项机制。我相信，做过敏捷转型的人应该都遇到了这样的问题。以下是我们在敏捷转型中遇到的一些实际问题，当你遇到这些问题时，不要惊讶，对于一个传统的成熟组织来说很难改变，尤其在没有上层领导积极推动的情况下。

没有产品经理，敏捷团队只关注开发与发布，不管开始，不管结果。

在我们公司的组织架构采用了弱矩阵形式，敏捷团队更多的起到协作开发前端需求的作用，他们不需要对产品直接负责，也不会关注产品在市场上的反馈。

测试与开发职责界限清晰。

在理想的敏捷中，在开发过程中就开始做测试，而我们还是需要开发完成后再进入测试，走上了“小瀑布模式”之路。

无法进行短周期迭代，放弃迭代。

由于走上了“小瀑布模式”之路，根本没办法做到较短周期的迭代，对于一个月一个版本来说，超过2周的迭代周期已经失去了实际的意义。

做好的功能都会发出去，基本没有功能灰度验证，功能越堆越多，维护越来越难。

需求人员都会认为自己想法是完美的，能有效提高产品的价值，他们更关注自己提的需求，而不是这个产品。

没有项目经理，只有项目负责人，项目负责人不专注，不专业。

由于公司项目是弱矩阵形式，项目更多的是协作作用，项目负责人更多的是起到拉通团队协作的作用，由于项目负责人往往身兼多职，并不能有效的持续投入精力优化项目过程。

等等……

2.成功的每一小步

固然，我们在转型中问题众多，还有很大的优化空间，但是和以前比起来我们还是取得了不小的进步，以下招式在实际项目开展过程中具有明显的实际意义，并不受传统组织架构排挤：

2.1.跨职能团队

对于传统企业来说，一般根据职能属性进行部门划分，各部门互相协作完成项目。然而，跨部门的协作成本明显过高，当产品需要频繁的跨部门协作时，这样的模式明显无法胜任。而在这时，公司必然也会暴露出由于这样的缺陷，导致的开发效率低下的问题。此时，以事业部或核心部门主导，建立虚拟的跨职能团队，也就顺理成章，一气呵成。跨职能团队能有效解决产品在开发时，频繁协作沟通的问题。在这样的团队里，沟通由实际的开发、测试、需求人员直接当面沟通，频率更高，信息失真也比较少，也避免了部门之间扯皮的问题。

2.2.每日晨会

编辑：未知