查看原文
其他

Offshore敏捷交付团队QA生存指南 | 洞见

郑达夫 ThoughtWorks洞见 2020-02-27

跨地域性的offshore敏捷交付一直以来都是一个充满挑战的工作,对于需要与各种角色进行交互的QA而言更是如此。我在2016年初进ThoughtWorks时就经历了这样一个项目。此间个人也经历了从忐忑不安到得心应手。现在此离岸项目已经交付完成,我也想总结一下这一年来的项目生存实践。

项目背景

客户:澳洲大型电信公司Digital部门,我所在的电商产品部门下有3个交付团队和1个Devops团队,每个交付团队有3-4个开发,1-2个QA,1个IM,BA则是按项目分配且全部都在Onshore。

系统与架构:基于AWS部署的Oracle的内容管理和电子商务系统,系统较重,且需要通过中间件从核心系统拿到数据。

QA职责

  1. 参加需求评审和技术评审会议,与BA讨论AC,与开发讨论实现方案。根据需求和技术方案制定测试策略。

  2. 准备测试数据,测试数据大多来自于第三方系统,可以自己手动创建,有时需要其他团队帮助。

  3. 对已开发完功能进行测试,即测试故事卡。

  4. 负责新功能上线。QA需组织系统发布启动会议,完成集成测试和回归测试,在上线后对系统进行主要功能的回归测试。

项目困难

Offshore的项目中存在的主要困难来源于三个方面:时间不同,空间不同,文化不同。

澳洲时间比国内早三个小时,算上各自午饭时间,与onshore团队的工作重合时间可能不到5小时,一旦过了澳洲的下班时间,有问题需要找onshore的团队就会很困难。

澳洲距离远,国内团队和澳洲团队只能通过视频会议、邮件、即时聊天软件等方式进行远程沟通交流。

基于国内的网络环境,在与澳洲团队工作的时候,网速、VPN都会对沟通和工作效率产生影响。

澳洲距离国内坐飞机大概要13个小时,较长的路途决定了不会有很多机会和预算让两地团队频繁的出差、相互交流。

同时由于不在一个地方工作,几乎没有比如团建活动,茶歇等能够促进团队成员互相了解、建立良好团队关系的机会,这对于敏捷团队的建立是非常不利的。

澳洲是移民国家,虽然相对于欧洲国家人们的思想更开放,更能接受不同的文化,但中西方文化的截然不同还是会在某些场合带来一些意想不到的问题。而且如果彼此双方对对方的文化完全不了解,交流起来也会缺乏共同话题,难以建立同属感。

生存指南

为了减少时差带来的工作时间重合度不高的问题,国内团队相应会提前上班时间,并且在非工作时间内也会注意澳洲团队是不是有紧急的问题需要解决,时刻保证澳洲团队能通过电话顺利联系上国内团队。

做好每天的工作计划,在有限的共同工作时间里,把需要澳洲团队帮忙解决的问题设置较高的优先级,然后预计会有阻碍或者依赖的工作点要优先提出来。而作为QA,我们应该合理利用共同的工作时间,把需要与onshore团队沟通的任务比如需求澄清, 故事启动,客户展示等工作优先完成,把可以独立完成的测卡工作优先级相对降低,这样就不会因为某些流程必须要两岸团队共同完成而阻碍。

网络环境的不同有时候会给测试工作会带来很多不便。为了最低程度降低网络环境带来的影响,首先我们要依赖于Techops团队搭建稳定可靠的VPN,再者作为QA在测试过程中如果遇到一些奇怪的问题,在分析问题原因的过程中应该考虑到网络的因素,必要的时候可以请onshore团队帮忙测试排除网络因素。

在解决两地团队相隔较远的问题上,我们制定了定期派遣项目人员去客户现场进行知识传递的计划。对于时长6周的现场出差,出差人员一定要提前做好计划,定时追踪知识传递的进度,在客户现场要尽可能的多了解项目的有关知识并和onshore团队建立良好的关系。作为QA,首先,一定要找到客户的质量经理一起安排好自己六周的知识传递计划并定时追踪进度。然后在客户现场需要找到一个onshore 的QA和他一起结对工作,在这个过程中你会很快的了解到一切关于QA的流程和工具,包括测试环境、测试数据、CI工具、Bug管理工具等等。同时,QA也需要找到一个对系统十分了解的开发工程师给你仔细讲解系统的架构和技术实现。最后,在知识传递过程中一定要学会记笔记,快速准确的把有用的信息及时分享给自己off shore团队,以个人带动团队共同成长。出差在客户现场,还有一点很重要的就是要利用面对面的机会与onshore团队建立良好的同事关系。茶歇和下班后的聚会都是很好了解对方的文化背景,兴趣爱好,建立团队认同感的机会。

虽然敏捷团队提倡“工作的软件高于详尽的文档”, 但是对于分隔两地的团队来说,有时候详尽的文档恰恰是提高沟通效率的必要手段。比如一个团队共享的wiki就能够帮助团队在不知道从谁获取知识时高效的查找到所需信息。作为QA,在离岸交付团队中,我们更需要注重测试的文档化。比如我们不仅应该详尽的对每张故事卡的测试案例和测试步骤文档化,而且还要记录测试环境的配置和测试工具使用说明,甚至有时为了使团队知道Bug如何重现,我们需要把重现步骤用截图的方式记录在Bug里。总之,在离岸交付中我们提倡并强调把自己所掌握的知识第一时间文档化分享给大家。

最后,为了提高团队的融洽度,获得彼此的信任。团队成员不仅要在技术等硬技能上体现出专业性,还要提高自己的软技能,学会怎样与有着不同语言,信仰,文化的同事进行无障碍沟通。这就需要首先努力提高自己的英语水平,适应不同的口音,再者要了解对方国家文化习俗,如果能在节日时送上祝福,或者闲时聊聊对方的文化,都能使对方感到亲切,获得认同感。同时,我们也要适时输出自己的文化,创造一个多文化的融洽的工作环境。

短短一年多的离岸交付因为限制很多,无法像在其他项目上一样积累足够多的经验,但在这个过程中,我在不断的突破限制、找到最佳实践的过程中也获得了个人能力的提升。现在我把这些经验总结出来,希望能帮助到现在或以后有相同工作场景的小伙伴们。


- 相关阅读 -

敏捷团队需要专职QA吗?|洞见

测试自动化后,我们需要怎样的QA?|洞见

点击【阅读原文】可至洞见网站查看原文&绿色字体部分的相关链接。

本文版权属ThoughtWorks公司所有,如需转载请在后台留言联系。

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存