项目交付为什么失败？-记我在某个项目中的迷思
上个项目接近尾声，我以developer的身份加入了现在的项目，姑且叫做项目A吧。说实话A项目蛮神奇的，干了一年多了只有一次release，8月初要进行第二次release了，但是测试环境还未搭建好。
该项目是个分布式团队，分布在成都和澳洲两个地方。由于成都这边团队都是清一色的developer，没有qa，严重阻碍了交付的进度。所以我跑到澳洲出差1个月来了解一下整个项目的context，并争取能找出一种解决方案来实现让成都团队中有人能够担任QA职责。目前已经在项目中呆了3周了，2周在成都，1周在澳洲。通过这三周的观察，我总结出了项目中目前存在的一些问题。
此项目是一个一个遗留系统，里面使用到的各种技术很多，有些技术很冷、很偏，维护起来较难。
此项目相关的依赖也比较严重，大大小小有将近10个依赖项目。
集成及系统测试环境搭建太晚，严重缺乏及时的端到端测试，导致大量卡被堆积在ready for test中，却没有足够的测试人员来测试。
由于data security的原因，成都团队无法触及集成测试环境及系统测试环境。（公司是一个保险公司，不允许客户数据被在澳洲以外的人看到）
成都团队对业务了解不深入（至少在客户这边看来），每张故事卡做完都需要澳洲团队review代码。
每个人看似都在认真工作，但交付完全跑偏，压力堆积在team leader, Iteration manager等人身上。
虽然我们称为敏捷团队，但这个团队怎么看也不像是敏捷团队。为什么会导致这么多的问题那？我分析了一下，觉得大致有两方面的原因。
由于特殊的data security问题，导致了项目不能满足敏捷团队中起码的开放原则。在一个敏捷项目中，首要的就是开放。无论是程序中的每一行代码，还是数据库中的每条数据，都不能是某人或某些人的私有财产，团队中的每个人都能有所触及，这样才不会引起项目中的盲点，导致一个对团队大多数人来说的黑区。而成都团队无法触及项目中的真实客户数据，直接导致了成都团队无法做真正的端到端测试，即使开发者也难对自己开发出的功能进行验证，只能mock掉大部分的集成点。
团队中的成员没有完全做到以交付为目标。敏捷项目中的最终目标就是以交付产品为目的。如果BA只管给墙上添加story，developer只顾埋头开发story，虽然每个人都在尽力做自己的本职工作，但story并没有很好的进入done column。这是因为由于多种原因，测试环境并没有尽早的搭建起来，大量story堆积到了测试环节，使得一个敏捷项目愣是变成了瀑布型。在这种情况的早期阶段大家就应该要有所觉察，developer应该停止开发story，而是协助QA尽早建立起测试环境，协助QA一起来做测试。大家应该一起关心当前项目的delivery的状况，找出其中的block并商讨出一定的解决方案。
既然存在这么多的问题，接下来应该怎么做那？我想应该从以下几个方面着手。
- 尽快建立起集成测试及系统测试环境，准备好测试数据，保证测试的正常进行。
- 和团队人员讨论出一种测试策略，比如采用给集成环境灌输fake data的方式使成都团队能避免或部分避免data security的干扰，能够开展测试。
- 基于上面几点，建立起端到端的自动化测试，使得QA脱离手工测试的苦海，完善我们的质量保护网。
希望自己能在剩余的3周onshore中能够有所进展。其实我比较鼓励大家在做自己手头工作的同时能够多多思考，不能将自己局限在某一个角色之中，这样子才不会日复一日重复昨天的工作，而是在工作中能够有所提高，提升自己的专业能力和职业素养。这些都是日后前进的宝贵财富。
