Hi 欢迎来到易观方舟
有问题就找小舟助手
联系我们 周一至周五 10:00 - 18:00

产品咨询:4006 - 010 - 231 转 1

商务合作:4006 - 010 - 231 转 2

咨询与帮助

易观数科 | 快速迭代能否真正提升效率?

易家分享录  第1期

每一次分享,都是一次新的启航。易观内部每周例行开展技术分享活动,对于分享人而言是一次精神上的挑战和锻炼,对于听众来讲亦会带来新的思考和收获。赠人玫瑰,手留余香。现将分享内容以“易家分享录”栏目化的形式输出,以飨更多读者。

 

本期分享嘉宾是易观运维工程师盆哥,他以快速迭代为主题,探讨了如何提高开发效率和增长实践的问题,一起来听听他的分享吧~

“快速迭代”是当下IT互联网圈的流行标语,其思路源于敏捷开发模式——部分上线-反馈-修改-上线-再循环,因此又可称之为敏捷迭代。对比完备测试后上线的传统迭代, 敏捷迭代具有问题发现快和上线速度快的优点,这既是互联网思维的精髓,又是占得市场先机的法宝。

 

现实中不少团队在尝试敏捷迭代,但换来的结果却是日常熬夜上线搞的大家身心疲惫,团队的战斗力也急剧下降,可谓杀敌800自损1000。

 

敏捷迭代俨然成了一些工程师眼中的——七伤拳。那么敏捷的快速迭代到底能不能帮助团队提升效率吗?大概可能吧!对于上述悖论我想从在易观数科工作两年多的实际案例中给出答案。

一、 迭 之 殇

易观刚开始做方舟这款大数据产品时候,也是在开发交付问题上遇到了比较大的挑战。开发初期新功能需求比较密集,且稳定性不够好,需要频繁给客户升级新功能或是修复bug,团队也是自然而然地运用了敏捷迭代的方法,有问题改问题,有需求做需求。

 

每次上线都需要实施团队上前方操作,研发人员后方待命,一旦出现问题研发就会直接冲到第一线辅助。这个模式虽然取得了一些不错的成绩,但是伴随着客户数量的增涨各团队已经是不堪重负。

 

直到公司层面为了更好的服务客户在公司内部提出了“贴身研发”的概念时候暴了雷,“贴身研发”即客户需求至上,快上加快,这样一来需求的数量和随机性都突增。

 

 

研发和实施团队由于压力太大,便站出来反对频繁的迭代上线——认为还不如等功能都做好一次交付给客户来的省事,于是和产品团队“吵成”一锅粥,一时间团队几乎到了奔溃边缘。

 

但这也成为了促使团队深入反思蜕变的转折点。团队一起开会讨论,彻底梳理整个研发模式和交付流程的每一个环节,最终得出的结论是当前交付上线成本过高严重占用了团队的资源。

 

方舟大平台大数据组件多达10个以上,且多是集群私有化部署,属于重交付运维的产品服务。每一次上线不但要在技术层面去调控更新众多大数据组件,还要和客户做大量的前期沟通,这样交付上线成本必然比较高。

 

二、透过问题看本质

欲练绝世武功,先练心经,心中要有数。为了印证交付上述结论,我们透过问题看本质,用数字来剖析背后隐含的规律。

 

首先建立工作量估算不完全数学模型:

工作量=需求个数(批次) X  (平均开发成本+平均测试成本)  + 线上Bug个数 X (平均Bug修复成本+平均测试成本)   +  上线次数 X 上线成本 X 上线用户数

 

Workload = PRNum X (DevCost + TestCost)  +  BugNum X (BugCost +TestCost) + PubNum X PubCost  X UserNum

引入bug 率的概念:

bug 率 g =BugNum/PRNum:用于衡量一个团队bug控制能力,并假设无论是传统模式A 还是敏捷模式B不会对团队的bug率产生明显影响

传统模型:

上线次数近似等于Bug个数:PubNum = BugNum

假设全部上线后发现 bug ,立即修复上线

 

WorkloadA = PRNum X (DevCost + TestCost)  + BugNum X (BugCost +TestCost) + BugNum X PubCost  X UserNum

 

WorkloadA =  PRNum X (DevCost + TestCost  + gBugCost +gTestCost +gPubCost  X UserNum)

敏捷模型:

上线次数近似等于需求个数(批次)  PubNum = PRNum

假设线上bug都在下一次迭代中解决的, 只计算BugCost,不会增加额外上线成本

 

WorkloadB = PRNum X (DevCost + TestCost)  +  BugNum X (BugCost +TestCost) + PRNum X PubCost  X UserNum

 

WorkloadB = PRNum X (DevCost + TestCost  + gBugCost +gTestCost + PubCost  X UserNum)

 

将两种模型进行对比:WorkloadA - WorkloadB=  PRNum X PubCost  X UserNum X(g-1)

 

由此可得出:

第一,传统模式一次上线在bug率比较低的的情况下实际上工作量最小的。说明特定情况下,“敏捷迭代还不如等功能都做完一次上线省事”说法;

 

第二,团队 bug 率 g 大于1,传统模式的工作量会逐渐大于敏捷模式工作量 。说明传统模式对于bug率比较敏感,bug 率控制的不好的话就是一个无底洞;

 

第三,交付上线成本 PubCost 是造成敏捷模工作量上升的关键因素。说明敏捷模式相对于传统模式对交付成本比较敏感,客户数越多成本越高。

 

 

以上数学模型证实了交付上线成本过高导致总体迭代成本急剧上升的结论,同时易观大数据团队开启了一轮降低交付成本的计划。

 

三、易观是如何解决的?

易观的做法主要包括以下几点:

 

在发布方式上:借助易观自研强大的调度器实现版本或补丁发布完全自动化、版本 changelist 生成完全自动化、每日自动发布版本可多达到10个以上;

 

交付方法上:通过自动化工具的应用实现一键大数据集群部署、一键在线或离线版本升级,最快10分钟内完成从代码提交到交付客户完成;

 

交付一致性方面:通过对产品的架构改造,并配合版本管理体系的标准化实现增量交付,全量覆盖能够确保交付出去的版本内容完全可控;

 

沟通方式上:基于以上方式实现结合版本信息管理平台实现最高效的沟通是不言而喻,Only number 便可了如指掌。

 

 

经过以上4点变革,易观方舟团队打通了敏捷迭代环节中交付障碍,构建了完整且清晰敏捷闭环,加快了迭代速度的同时却没有较多增加的成本,让团队可以专注在产品研发本身,这成为易观方舟在如此短的时间里能取得喜人成绩背后的力量。

 

四、 结 束 语

 

直面自己的问题和敢于变革是易观在20年时代大潮下沉淀下的信经,也希望我们的经历能够鼓励到对数据科学孜孜不倦的你!

 

END

 

欢迎投递简历到hr@analysys.com.cn邮箱

 
 

相关推荐:

体验文中提到的功能

立即免费体验Demo

智能用户运营,就用易观方舟

连通内外部数据源,打通全端用户运营触点,构建智能用户运营闭环

体验Demo