从”蒸汽时代”到”高铁时代“,商米DevOps转型之路

作者：文振熙、刘文沣

商米科技成立于 2013 年，总部位于上海市杨浦区创智天地，是一家极具产品创新基因和互联网基因的公司。商米在短时间内迅速成长为一家近1000人的企业，产品研发人数占比一度超过70%。
做为一家初创企业，商米研发团队早期也经历过与当下大部分创业公司一样困境：协作基本靠吼、发布基本靠手的阶段。然而，业务的快速发展，团队规模不断的扩大，给商米带来了在「团队协作」和「工程效能」上的双重挑战。

一、蒸汽时代

为了能快速让团队进入步入正轨，商米研发团队早期采取和大多数企业类似的组织方式，以职能为单位的进行团队划分，分为前端、后端、Android端、测试、产品等职能团队，并采用传统瀑布研发模式组织团队协作。当时，我们称之为正规的研发模式。
每个团队由组长负责制，具体负责团队任务的分配、技术决策和人员培养，组员负责具体的研发任务。根据这样的职能协作的方式，商米建立了早期的研发流程：

产品经理进行原型图设计；
然后产品经理，分别找各个组长请求人员支持；
组长根据自己团队人员工作现状，将工作安排给相应的同学，接手产品开发任务，完成工作量评估、给出截止时间等；
最后再各自团队的同学，完成相应的工作之后，大家约好一个时间，集中联调一下，再交付给测试团队。

职能团队的组织方式，帮助商米走出了第一步。但是彼时，工程能力方面，却是一穷二白，别说CI/CD了，连部署工作都还是手工FTP上传文件，来进行服务器的发布。
没有专门的运维团队，服务器运维工作一直是后端团队承担，发布又是一个很重要的动作，出不的半点差错，只能让后端组组长进行发布，当业务不断发展，项目数量不断增多，负责发布的那个同学苦不堪言。
没有专业运维团队，没有现成的工具。只能硬着头皮去网上胡乱找一通，Jenkins太复杂，最后还不容易找到了一个简易的工具，解决FTP上传的问题，但最后的发布还是人工进行。
小结：通过建立职能团队，产品经理对接职能团队，寻找开发资源，以瀑布方式组织交付；工程能力方面，采用FTP纯手工上传方式进行发布，无专业运维团队。
团队的不断增长和快速发展的业务，又带来了新的挑战。团队间协作依赖，团队成员业务归属感差；同时，因为手工为主发布软件，通宵发布不是一件稀罕事。
无论是协作效率，还是工程能力上，这种老牛拉破车的状态，逼着商米团队进行转变。

二、电气时代

在寻找解决办法过程中，商米引入Scrum研发模式，尝试将职能团队改造基于业务线的跨职能团队：
资源独享，组建独立业务交付团队，每个团队都包含产品、测试、后端、前端、Android端，跨职能；
采用Scrum工作模式，引入Scrum Master 和四次Scrum会议（计划会、每日站会、评审会议、回顾会议）
跨职能团队恰好能解决当时商米遇到的团队协作上的问题，但却无法兼顾职能团队的优势，于是增加技术委员会团队来支持业务交付团队：

通过敏捷化演进，在团队协作上"虚线"和"实线"发生了变化：