领导关注多了未必是好事

       


    今天部门主管下午接到电话，好像是一个三级部门的领导打来的，该领导口气很不好（据说是被另外一个领导狠批了一顿），于是他便打电话来批我们主管，说的话无非是你们测试部是怎么测试这个产品的，这样的bug都发现不了，你们能力太差……诸如此类的话。
    其实，我们测试组主要负责后台服务器组件以及管理Portal等测试，被那位领导狂批的bug是客户端的，要说我们测试组有错，也就是没有在完成本职测试任务的同时参与到客户端界面的测试。可是，在目前的情况下（版本规划的粒度太粗、系统组和开发组在版本规划和实现上脱节、版本的需求来源混乱、和现场交流不畅、开发的测试意识淡薄，完全依赖系统测试、每周版本都需要上线升级、测试组人力紧缺等），我们测试组按时完成自身的测试任务都存在较大问题，更不用说去配合其它测试组的测试了。而且，像客户端那样明显的bug（同时打开发送短信窗口和IM窗口时，用户输入的文本会意外地在另一个窗口中显示）发现它并不困难，如果终端测试组能够结合一些最终用户的场景测试话。
    这些大领导们骂下属能够解决多少问题呢，如果你们真的关心项目的成败，还是给研发的兄弟们一点耐心和时间吧。感觉公司（至少是我们这个产品线）心态比较浮躁，大家都只想着赶快将手中的活干完，而忽视了对工作本身的思考，一味的赶着项目的进度，一味地迎合着某些领导们其实并没有深入思考的需求（所谓的政治任务），结果却发现：自己实现的产品特性和最终用户的实际需求相去甚远。
    不知道什么时候起，整个产品线开始逐渐摈弃了其实并没有走的很溜的IPD-CMM流程，开始大张旗鼓的推行所谓的“超越行动”，主张什么“我的流程我做主”。其实，从这个项目本身的角度出发，感觉敏捷模式并不适合这个项目的选型，毕竟这个电信级项目涉及到多个部件（IM、短消息、VOIP、NGN等），如果不将最基本的部件（客户端、用户Portal、团队空间、AccessAgent、IMU、通话能力等）的功能、性能稳定下来，整个项目的基础会非常不牢靠。因此，大的项目流程还是应该严格遵守，只是在具体实现的过程中可以参考一些敏捷开发的方式。现在的超越行动，只是那些喜欢裸奔的人的借口。
    目前大家都没有敏捷项目的经验，QA那里也没有相应的流程来支撑，因此整个团队处于一个摸索的阶段。前段时间奉部门主管之命和另外一个测试组的同事参与开发在现网升级前以及版本转E2E测试前的基本功能验证，感觉那种运作方式有点类似于敏捷模式：我们和开发坐在一起，一起参与开发团队的例会，发现问题及时知会开发，有什么疑问可以直接面对面的交流而不是通过电话或者邮件；现在测试组在推行测试前移，力求和开发人员一起参与需求的讨论、方案的设计，而且似乎越来越倾向于所谓的Agile方式，但是目前我们已经撤回了测试组。目前我们和理想的Agile方式相比，欠缺的是：1、人力，开发测试比例几乎是3: 1；2、座位的安排，没有和开发人员一起工作（sitting in the same bullpen）；3、意识，大家相互配合、紧密合作的战斗意识；4、技术，开发、测试技能的提升；