文章目录

上个项目接近尾声,我以developer的身份加入了现在的项目,姑且叫做项目A吧。说实话A项目蛮神奇的,干了一年多了只有一次release,8月初要进行第二次release了,但是测试环境还未搭建好。

该项目是个分布式团队,分布在成都和澳洲两个地方。由于成都这边团队都是清一色的developer,没有qa,严重阻碍了交付的进度。所以我跑到澳洲出差1个月来了解一下整个项目的context,并争取能找出一种解决方案来实现让成都团队中有人能够担任QA职责。目前已经在项目中呆了3周了,2周在成都,1周在澳洲。通过这三周的观察,我总结出了项目中目前存在的一些问题。

  1. 此项目是一个一个遗留系统,里面使用到的各种技术很多,有些技术很冷、很偏,维护起来较难。

  2. 此项目相关的依赖也比较严重,大大小小有将近10个依赖项目。

  3. 集成及系统测试环境搭建太晚,严重缺乏及时的端到端测试,导致大量卡被堆积在ready for test中,却没有足够的测试人员来测试。

  4. 由于data security的原因,成都团队无法触及集成测试环境及系统测试环境。(公司是一个保险公司,不允许客户数据被在澳洲以外的人看到)

  5. 成都团队对业务了解不深入(至少在客户这边看来),每张故事卡做完都需要澳洲团队review代码。

  6. 每个人看似都在认真工作,但交付完全跑偏,压力堆积在team leader, Iteration manager等人身上。

虽然我们称为敏捷团队,但这个团队怎么看也不像是敏捷团队。为什么会导致这么多的问题那?我分析了一下,觉得大致有两方面的原因。

  1. 由于特殊的data security问题,导致了项目不能满足敏捷团队中起码的开放原则。在一个敏捷项目中,首要的就是开放。无论是程序中的每一行代码,还是数据库中的每条数据,都不能是某人或某些人的私有财产,团队中的每个人都能有所触及,这样才不会引起项目中的盲点,导致一个对团队大多数人来说的黑区。而成都团队无法触及项目中的真实客户数据,直接导致了成都团队无法做真正的端到端测试,即使开发者也难对自己开发出的功能进行验证,只能mock掉大部分的集成点。

  2. 团队中的成员没有完全做到以交付为目标。敏捷项目中的最终目标就是以交付产品为目的。如果BA只管给墙上添加story,developer只顾埋头开发story,虽然每个人都在尽力做自己的本职工作,但story并没有很好的进入done column。这是因为由于多种原因,测试环境并没有尽早的搭建起来,大量story堆积到了测试环节,使得一个敏捷项目愣是变成了瀑布型。在这种情况的早期阶段大家就应该要有所觉察,developer应该停止开发story,而是协助QA尽早建立起测试环境,协助QA一起来做测试。大家应该一起关心当前项目的delivery的状况,找出其中的block并商讨出一定的解决方案。

既然存在这么多的问题,接下来应该怎么做那?我想应该从以下几个方面着手。

  1. 尽快建立起集成测试及系统测试环境,准备好测试数据,保证测试的正常进行。
  2. 和团队人员讨论出一种测试策略,比如采用给集成环境灌输fake data的方式使成都团队能避免或部分避免data security的干扰,能够开展测试。
  3. 基于上面几点,建立起端到端的自动化测试,使得QA脱离手工测试的苦海,完善我们的质量保护网。

希望自己能在剩余的3周onshore中能够有所进展。其实我比较鼓励大家在做自己手头工作的同时能够多多思考,不能将自己局限在某一个角色之中,这样子才不会日复一日重复昨天的工作,而是在工作中能够有所提高,提升自己的专业能力和职业素养。这些都是日后前进的宝贵财富。

文章目录