IT海盗：这是微信的解构与建构连载的第四篇，依然干货连连，读起来激情澎湃。微信敏捷开发中的“微循环”是什么？张小龙怎样在看似“混乱”的流程管理中无招胜有招？

敏捷是一种态度，试错是一种信仰。——微信团队Harvey

敏捷开发

敏捷开发是一种常用的软件开发模式，与传统的“瀑布式开发”相比，敏捷开发能够持续满足不断变化的需求变动。微信团队的情况正是这样，“整个开发过程中产品会不断修改，这是我们的特色。”Harvey说，“哪怕在发布前的十分钟，我们也要允许产品决策者提出变更。”“为了给产品决策者提供最大的自由度，敏捷原则成为整个开发流程的指导原则，”“极度敏捷”也成为技术团队乃至整个微信团队的追求。

微信团队的开发流程同样包含瀑布式开发中的主要步骤，“决策——需求评审——细化产品设计——交互设计——开发——迭代——灰度发布——测试——上线运营”，“但是这个过程我们（微信团队）是并发来做的，”Justin说。同时，整个开发过程中充满了由需求变动驱动的“微循环”。

在每一个“微循环”的起点——需求提出环节，产品经理、交互团队和技术团队的同事会一起，对平时收集到的用户需求和意见进行讨论。微信客户端UI组组长Kink认为，“如果只是产品经理闭门想产品，其实是不大好的；可能产品经理提出的需求在交互设计层面并不是最终需求，只是一个表面现象，用户需求需要更深层的挖掘；而从开发的角度看可能有简洁的方式来达到目的，但表现为不同的形式。”通过三个团队的成员共同讨论确定下来的产品方向，他认为往往“更靠谱”而且降低了项目夭折的可能性。接下来，由于交互团队、技术团队都参与到需求的生产环节中，对产品的大致形态比较清楚，交互、技术这两个团队的工作就可以和产品团队的工作并行开展。Kink说：

大家都明白产品是什么样的，就可以同步开始了，交互可以做交互方案，视觉可以选定方向，开发同事可以做代码设计。等交互方案出来，视觉设计师可以马上根据交互方案实现，开发同事一看到交互方案就可以开始写代码了。

在项目推进的过程中仍会发现各种问题，这时三个团队的负责人会再次碰头对问题进行讨论，如果问题不大，这种小规模的讨论就可以当时解决。；如果发现有比较严重的问题，团队成员会花更多的时间讨论当初的设计是否存在缺陷，这种讨论Allen、Harvey也会参与进来。如果确定问题在于原本的需求设计不合理，那么新一轮的“微循环”又会启动。

整个微信团队都在南方通信大厦的10楼，这使得团队成员之间的面对面交流十分方便。“面对面交流”既是敏捷开发倡导的原则，也是团队从邮箱时代积累的经验。Kink认为：“无障碍沟通有助于敏捷的实现，大家不管什么时候什么地方碰到面就聊：这边有什么困难，那个需求的时间点，设计上有什么能改善的……很多问题是在茶水间里一次三五分钟的讨论中解决的。”Lake对此的评价是：

1小时说的话，打出来要10小时，而且面对面沟通可以快速反应，有什么问题大家直接就可以讨论了。如果有面对面沟通的条件尽量用这种方式，但不是那种冗长的会议形式。在座位旁边两三个人五到十分钟的交流，然后快速散开，就一个问题迅速进行讨论，得出结论，散开，这是我们的工作生活，这个是必须的。

在敏捷开发中，需求的快速变动要求开发团队不断修改甚至是重写代码，这给开发团队带来了巨大的困难和压力。为了预防和缓解这个问题，微信团队在基本技术架构中确立了“大系统小做”、“让一切可扩展”、“必须有基础组件”等几个原则。技术团队认为这样的技术构架能保证“产品层面的改动对技术层的影响不会太大”，为技术团队适应敏捷提供基本能力。Justin回顾朋友圈的开发过程时说：

比如朋友圈这个产品经历了很多次变动，出了好几十个版本，但是有东西是不变的，就是数据模型是不变的。所以我们在产品设计和细节还没出来的时候，我们从后台到协议设计到本地存储的整个数据结构设计都已经做好了，界面的框架也可以先做，等设计最终确定的时候，我们技术这边已经进入ready的阶段。这是我们和别人不同的地方。