数据项目交付小记:测试报告&公共层&中台组织

本文涉及的产品
大数据开发治理平台DataWorks,Serverless资源组抵扣包300CU*H
简介: 最近项目交付上遇到了一些问题,我把自己的回答和想法记录一下,分享给大家。

问题(一)数据开发要不要写测试报告

     昨天在项目上,有位项目中的年轻数据开发者向我提了一个问题:他认为写测试报告只会增加他们的工作量,其实对开发工作本身并未有实际帮助,这是不是管理者对开发人员的一种过渡的压榨?尤其是在项目工期这么紧张的情况下。

       我开始其实是不理解这位年轻的数据开发者为什么会有这种质疑,尤其还是这么具有挑衅口气的问题。就像你给一个在马路上嬉戏小朋友说:不要在马路上嬉戏。反而遭到了嘲笑:我在这里玩的好着呢,你是不是有问题?

       第一个问题:软件开发,要不要做测试?

       在这个问题的场景下,但凡是正经上过计算机学科专业课的同学都会毫不犹豫的做出肯定的回答。但是为什么又会有人问出这种问题?所以,以此判断核心原因是不想写测试报告。理由也过得去,毕竟写个文档也是要花不少时间的。所以,这个问题就演化成,项目进度紧张的时候是不是可以把测试省略掉?或者是把写测试报告的事情省略掉?后面再补。

       如果是这个问题,会有截然不同的回答。其实越是进度紧张,作为管理者越难做出省去测试直接上线的决策。因为上线只是一个动作,上线代表了投产,如何能确定开发动作的质量达到上线标准呢?必然是测试。那怎么证明我们做了严谨的测试呢?必然是测试报告。在这里,我就是做了这样的决策。所以,如果一个开发人员质疑管理人员做的开发要测试,编写测试报告的时候,必然会遭到管理者的痛批。差不多就是你小子还想不想在这个行业干了,不干就快走,之前发的工资我都想要回来,以前一定是错付了。

       但是现实工作中,不做测试就上线的情况,大家都会遇到。大多还是因为时间进度的问题,或者就是跳过了单元测试、集成测试,直接到了业务测试。其实这位年轻的开发者,要表达的是:是不是直接进行业务测试,把中间的环节都省略掉。因为他体验到的实际情况就是这样,前面这些工作是没意义的,最后一把测试对了,就完事了。刚好这个项目在集成测试和业务测试环节,没有要求写测试报告。从严谨的软件工程来看,这几个环节都需要测试,也都需要写测试报告。所以,答案就是其实测试是不可以省略的,但是根据项目的实际要求,有些环节和文档是可以适当裁剪的。

       在这个项目,经历了单元测试、集成测试、业务测试三个环境。但是只要求了单元测试报告,集成测试和业务测试环节,通过缺陷管理系统去管理了测试和BUG修复的过程,所以,没有写对应的报告,项目组也是相当于在系统中有这么一份过程文档留下了。

       如果想什么都不写,不项目交付过程留痕,作为一个稍有规模的公司或者客户,应该不会允许这种情况出现,建议从事这个行业的新人还是要有这个心里准备。

       第二个问题:既然已经是裁剪了的测试工作和文档工作,为什么还会对这仅存的测试文档工作有质疑?

       我相信搞技术的同学不会只为不想写文档就故意诋毁这项工作的重要性,更何况过程文档是日常项目交付中一个重要的产出物。既然提出了这个观点,一定是这个观点是有事实支撑的。

       这个事实我们其实都知道,在上一个阶段的需求一直没确定,前期花了不少时间做的开发在后面都被修改和推翻了。也就是说,前期需求都没有搞清楚,做的很多工作都是白做的。自然这个单元测试和写测试报告的工作确实就是没有意义的了。

       这其实是另外一个课题了,在国内这个环境,好好的做出一份需求和设计,并能保证这个需求是符合最终业务需求是何其难(时间与人员)。业务人员很多时候是需要我们先做出来,然后再去迭代思考。所以,我们以这个前提去做的很多工作,就需要足够敏捷。在这个场景,更适合的方法是要跟业务反复去快速开发迭代,等到一切设计都完成,再去做这个单元测试的工作。而不是在反复迭代的过程中去做严格的单元测试工作,这样确实代价和成本都太高了。

       所以,作为一个做软件服务的公司,在遇到一个新的客户的时候,在需求阶段要尽早判断我们遇到的客户是什么样的客户。我早年在服务银行业客户的时候,还是传统的流程,需求定了就做开发,开发完成就测试,测试通过就上线了。即便业务后续有需求调整,也是下一个版本的事情,不会这么随意。但是这个流程是非常长的,时间会很久。所以,软件行业在一直强调敏捷。因此我不去强调对错与否,大多时候我们与客户第一次合作的时候,大都只能先尊重客户之前的工作方式。所以,我们要选的是我们应该与不同的客户如何去合作,遇到不同的模式采用不同的策略。

       说到了这里,我其实应该表达的差不多了,大概就是跟年轻的同学们讲个道理:测试是一个必要的软件开发的环节,但是怎么做,做多少,在什么阶段做,跟实际的项目情况由项目管理者(it`s me)来决定。

问题(二)要不要构建公共层

       在项目上,有位项目中的年轻数据开发者向我提了一个问题:感觉公共层没有必要做,并没有减轻反而增加了工作量。对此,我提出了我的观点:

       第一,我们项目开发有两个阶段,现在是第二阶段,我们是否发现我们在第二阶段在公共层投入的开发工作会少很多?如果没有公共层,我们是不是要做一些重复性的工作?或者我们其实还是要在应用层实现公共层的逻辑,也就是共用应用层的一张基础表?

       第二,我们做到这个阶段发现最大的困难是什么?是统一的公共维度。我们发现A部门有A部门的维度表,B部门有B部门的维度表,即便这是同一个名字的维度,也很难统一。这也是维度建模最核心的一致性维度的问题,这是开始实施数据中台模型开发的遇到的最大的困难。为什么之前没有遇到这个问题?如果我们公共层最后把这些问题都解决了,后面再用我们公共层的人是否就没有我们现在这么困难了?是不是就很容易实现企业级的数据的分析了?

       对于第一个问题,回答是肯定的,前人栽树后人乘凉。现在刚开始的时候,就是栽树的时候,感受不到乘凉的快感,反而会感觉不栽树更轻松。我们要看到现在在做的工作的长期意义,就自然就理解我们现在的困难是有必要的。

       对于第二个问题,公共层解决了什么问题。就是企业级的标准化的问题,之前都是在部门级视角来分析问题,各业务人员都是独立且割裂的。对于同一个问题的解释必然存在多种正确又不同的回答,但是数据中台是否就是应该是要解决这个问题?必然是。

       所以,回答是必须要做,而且这才是我们对客户宣传的中台的根本意义。不是在于当下,而是在于远期,不是部门级的视角,而是企业级的全局视角。

       建议对数据分层架构不了解的同学,可以看下我的这篇《数据仓库的分层架构与演进》文章。(https://developer.aliyun.com/article/892787

问题(三)没有人能继续交付数据中台

       在项目上,我服务的客户甲方负责人向我描述了我们项目交付结束后,因为没有足够的人,他们部门后续数据开发还是由各个应用开发自己做。我们卖了一个中台项目给客户,客户并没设置独立的职能单元搞中台,还是要把数据开发交给各个业务线自己搞,目前与我们合作的组织只是从技术上对业务线进行管理和支撑。

       去年早些时候,我写过一篇文章来表述自己对组织对数据中台的影响《构建数据中台的组织架构》(https://developer.aliyun.com/article/996978)。在我的观点里,构建数据中台的第一步必然是构建适应中台的组织架构。我之所以写这篇文章,也正是希望各企业对数据中台的事情不能只是说说而已,以为买了阿里的平台就拥有了数据中台,进而最终失败后又认为是阿里的问题。数据中台是一种企业架构,是要有对应的组织和活动来落地这套架构的。

       为此我是不赞成目前客户这种组织工作安排的,但是我也能理解这种安排。毕竟组织架构对一个组织来说是如此的重要,面对新新事物,必然会经历“观察-尝试-再观察-再尝试”这种阶段。客户迈出的第一步,就是购买了我们的产品和服务。但是,后续要怎么做?是徘徊的。继续按照我们现在的方式来做,还是还保持企业原来自己的方式。要是按照我们现在交付的方式来做,就需要专门的人员来持续的开发和维护这个大数据平台。要是按照原来的方式来做,对企业来说就是多了一个报表开发工具而已,把产品给各个业务部门继续用就好了。自然也不需要对组织做什么调整,更不需要新增什么人员了,这样对企业来说是更轻松的选择。

       简单的说,就是没有足够的驱动力来做这种变革。

       从个人的角度来看观察这个企业。这个企业之前是没有数据仓库的,各个业务部门自己的系统开发人员是各自按照需要去做数据开发的。所以,以前是没有一个统一的企业级视角的。企业内部的绩效部门其实是有对企业统一视角是有明确的需求的,绩效部门管理了上千个绩效指标,但是绩效部门只能管理这些指标的名义口径,具体实现还是业务部门自己定义和实现的。我们交付的平台是能解决这个问题的,之前的数据和业务都是分散在不同系统和不同团队的,但是现在这些都统一到云平台了。不需要过多调整,只需要按照我们现在的模式继续搞下去,自然就会趋近企业的统一视角的数据这个目标。但是,现在显然决策层不能立即做出调整,还是希望继续维持以前的模式。

       我并不认为这个决策能维持太久,新的思潮已经渗透到了这个组织。我们向IT管理层介绍了数据公共层的意义,也得到了管理层的重视。如果没有一个统一专业的团队去对这个数据公共层去开发和管理,要靠各个业务部门的业务系统开发人员兼职去做,我们如何能做到人员技能的专业化和内部管理协调的一致性?

       既然这样,我也就给些我的建议。希望管理者去思考上面我提到的专业化和统一的企业视角的问题,要构建一个有效的公共层去支撑企业数据分析需求,这是必不可少的。接下来,第一个困难是如何让之前直接在应用系统上做数据开发的应用系统开发人员掌握使用阿里云大数据平台做数据开发的能力。第二个困难是现有的大数据平台管理团队如何去协调和管理这些与其平行的团队和人员。第三个困难是研发效率。从效率的角度,职业化分工代表了专业和效率的提升,从而提升了生产效率。软件行业虽然是一个复杂的行业,也是遵循这种规律的。

       如上图左,汽车制造业目前普遍采取的流水线生产模式,专业化分工带来了劳动生产率的大幅提升,让小汽车深入了千家万户。如上图右,纯手工打造和调教的劳斯莱斯,导致其成本极其高,只能作为豪车进行小批量生产和销售。

       讲了这么多,其实还是希望企业在应对数字化转型这个大课题上,不论是拥抱数据中台还是怎么做,都要知道需要达成的业务目标是需要与其配合的组织结构来支撑的。我们可以审慎而又小心,可以多做一些尝试后再做出决策,但是希望我们能看到先进生产力的好处,尽快迈出坚定的一步。

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
一站式大数据开发治理平台DataWorks初级课程
DataWorks 从 2009 年开始,十ー年里一直支持阿里巴巴集团内部数据中台的建设,2019 年双 11 稳定支撑每日千万级的任务调度。每天阿里巴巴内部有数万名数据和算法工程师正在使用DataWorks,承了阿里巴巴 99%的据业务构建。本课程主要介绍了阿里巴巴大数据技术发展历程与 DataWorks 几大模块的基本能力。 课程目标  通过讲师的详细讲解与实际演示,学员可以一边学习一边进行实际操作,可以深入了解DataWorks各大模块的使用方式和具体功能,让学员对DataWorks数据集成、开发、分析、运维、安全、治理等方面有深刻的了解,加深对阿里云大数据产品体系的理解与认识。 适合人群  企业数据仓库开发人员  大数据平台开发人员  数据分析师  大数据运维人员  对于大数据平台、数据中台产品感兴趣的开发者
目录
相关文章
众筹十万美元搞火箭,搞研发全靠志愿者!这个“草根”航天组织已经开启载人测试
众筹十万美元搞火箭,搞研发全靠志愿者!这个“草根”航天组织已经开启载人测试
176 0
众筹十万美元搞火箭,搞研发全靠志愿者!这个“草根”航天组织已经开启载人测试
|
测试技术
《软件测试技术大全:测试基础 流行工具 项目实战(第3版)》—第2章2.2节融入测试组织
不同的软件企业由于种种原因会设置不同的软件测试组织形式和结构,没有哪两家公司的软件测试组织是一模一样的。即使是结构一样,由于职责范围和沟通方式不一样,也会导致测试组织的表现形式不一样。
1481 0
|
测试技术
《软件测试技术大全:测试基础 流行工具 项目实战(第3版)》—第2章2.1节 测试的组织形式
本章从测试组织的形式分析各种测试组织结构的利弊,提出了一个综合型的软件测试组织结构模型。然后介绍对于一个新加入测试团队的测试人员而言,如何找准自己的角色定位,如何快速地融入测试组织。最后看一下测试团队的建设需要注意哪些方面的内容。
1450 0
|
8天前
|
JSON Java 测试技术
SpringCloud2023实战之接口服务测试工具SpringBootTest
SpringBootTest同时集成了JUnit Jupiter、AssertJ、Hamcrest测试辅助库,使得更容易编写但愿测试代码。
37 3
|
1月前
|
JSON 算法 数据可视化
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)
这篇文章是关于如何通过算法接口返回的目标检测结果来计算性能指标的笔记。它涵盖了任务描述、指标分析(包括TP、FP、FN、TN、精准率和召回率),接口处理,数据集处理,以及如何使用实用工具进行文件操作和数据可视化。文章还提供了一些Python代码示例,用于处理图像文件、转换数据格式以及计算目标检测的性能指标。
59 0
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)
|
2月前
|
移动开发 JSON Java
Jmeter实现WebSocket协议的接口测试方法
WebSocket协议是HTML5的一种新协议,实现了浏览器与服务器之间的全双工通信。通过简单的握手动作,双方可直接传输数据。其优势包括极小的头部开销和服务器推送功能。使用JMeter进行WebSocket接口和性能测试时,需安装特定插件并配置相关参数,如服务器地址、端口号等,还可通过CSV文件实现参数化,以满足不同测试需求。
239 7
Jmeter实现WebSocket协议的接口测试方法
|
2月前
|
JSON 移动开发 监控
快速上手|HTTP 接口功能自动化测试
HTTP接口功能测试对于确保Web应用和H5应用的数据正确性至关重要。这类测试主要针对后台HTTP接口,通过构造不同参数输入值并获取JSON格式的输出结果来进行验证。HTTP协议基于TCP连接,包括请求与响应模式。请求由请求行、消息报头和请求正文组成,响应则包含状态行、消息报头及响应正文。常用的请求方法有GET、POST等,而响应状态码如2xx代表成功。测试过程使用Python语言和pycurl模块调用接口,并通过断言机制比对实际与预期结果,确保功能正确性。
248 3
快速上手|HTTP 接口功能自动化测试
|
1月前
|
JavaScript 前端开发 API
vue尚品汇商城项目-day02【9.Home组件拆分+10.postman测试接口】
vue尚品汇商城项目-day02【9.Home组件拆分+10.postman测试接口】
40 0