首页   >   A   >
    阿里云云效智能一体机

阿里云云效智能一体机

2020-08-18

注:想要了解更多关于云效解决方案,请点击:https://thoughts.aliyun.com/sharespace/5e8c387c0aa435001a74f7ab/folders/5e8c387c0aa435001a74f7a4

商米科技成立于 2013 年,总部位于上海市杨浦区创智天地,是一家极具产品创新基因和互联网基因的公司。商米在短时间内迅速成长为一家近1000人的企业,产品研发人数占比一度超过70%。

做为一家初创企业,商米研发团队早期也经历过与当下大部分创业公司一样困境:协作基本靠吼、发布基本靠手的阶段。然而,业务的快速发展,团队规模不断的扩大,给商米带来了在「团队协作」和「工程效能」上的双重挑战。

一、蒸汽时代

为了能快速让团队进入步入正轨,商米研发团队早期采取和大多数企业类似的组织方式,以职能为单位的进行团队划分,分为前端、后端、Android端、测试、产品等职能团队,并采用传统瀑布研发模式组织团队协作。当时,我们称之为正规的研发模式。

每个团队由组长负责制,具体负责团队任务的分配、技术决策和人员培养,组员负责具体的研发任务。根据这样的职能协作的方式,商米建立了早期的研发流程:

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

优势劣势资源不易空闲,需求排着队任何一个组员都能随时顶上延续性差:分配任务时可能熟悉需求的成员在另一个需求研发中,其他成员不熟悉此业务组长参与需求把关,设计方案得到保障归属感差:团队成员不对业务成果负责,有任务就做思考业务不深入,潜能发挥不出来组长分配任务,技术演进容易推动研发过程难以保证:研发过程中没有监管,验收阶段常常出问题相同专业成员坐在一块技术交流方便组长被高度依赖:组长要参与评审、分配任务、解决难题、审核代码、推动演进技术、成为最大瓶颈

职能团队的组织方式,帮助商米走出了第一步。但是彼时,工程能力方面,却是一穷二白,别说CI/CD了,连部署工作都还是手工FTP上传文件,来进行服务器的发布。

没有专门的运维团队,服务器运维工作一直是后端团队承担,发布又是一个很重要的动作,出不的半点差错,只能让后端组组长进行发布,当业务不断发展,项目数量不断增多,负责发布的那个同学苦不堪言。

没有专业运维团队,没有现成的工具。只能硬着头皮去网上胡乱找一通,Jenkins太复杂,最后还不容易找到了一个简易的工具,解决FTP上传的问题,但最后的发布还是人工进行。

小结:通过建立职能团队,产品经理对接职能团队,寻找开发资源,以瀑布方式组织交付;工程能力方面,采用FTP纯手工上传方式进行发布,无专业运维团队。

团队的不断增长和快速发展的业务,又带来了新的挑战。团队间协作依赖,团队成员业务归属感差;同时,因为手工为主发布软件,通宵发布不是一件稀罕事。

无论是协作效率,还是工程能力上,这种老牛拉破车的状态,逼着商米团队进行转变。


二、电气时代

在寻找解决办法过程中,商米引入Scrum研发模式,尝试将职能团队改造基于业务线的跨职能团队:

  • 资源独享,组建独立业务交付团队,每个团队都包含产品、测试、后端、前端、Android端,跨职能;
  • 采用Scrum工作模式,引入Scrum Master 和四次Scrum会议(计划会、每日站会、评审会议、回顾会议)

跨职能团队恰好能解决当时商米遇到的团队协作上的问题,但却无法兼顾职能团队的优势,于是增加技术委员会团队来支持业务交付团队:

遇到的问题技术委员会的作用敏捷组成员空闲委员会分配公共任务或借调其他团队设计质量难于保障委员会参与评估避免成员单方面敲定实现设计技术演进难以推动委员会与SM协商排期增加重构或改进计划技术交流减少委员会定期进行技术分享,每周收集成员工作情况

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