这两天部门内部在讨论全功能团队的相关东西，希望后续能慢慢的实施起来。这里全功能团队的概念，简单来说就是希望能够减少团队的规模，加快产品交付的节奏，类似于敏捷开发模式中的小步快跑，能够频繁的有版本上线运行。总体方向来说是好的，这套东西很多互联网公司也玩的很顺畅，但是在华为，最起码在我所在的部门内，还非常缺乏这方面的积累和氛围。整个研发的运作模式和管理层都是从传统的运营商转型过来的，团队庞大，低效，笨重。。。等等一系列的缺点。
关于这种团队模式的优缺点，如何根据自身的项目实际来运作，以及在这种模式下工作带给测试人员的变化和挑战，感觉部门内部普遍都还缺乏清晰的认识。昨天晚上讨论的时候，面对大家的质疑，测试经理显得有点控不住场面。今天整个部门的会上，当部门领导问到测试人员对于这种模式怎么看时，我们的测试经理也是支支吾吾，没有一个清晰明确的答案。
说说我自己心中理想的团队模式吧：
1.团队的规模一定要控制，个人感觉二十人以下是比较合适的，再大就不好控制了，而且这些人一定要坐在一起工作，彼此间应该是一站起来就能看到对方的距离。随着人数的增多，人与人之间交互，沟通，协调的成本会急剧上升，有一个著名的曲线图是这么画的，开始随着人数的增多，研发效率会有一个上升，但到了一个临界点后，效率不但不会上升，还会下降。这一点在自己的工作中也是深有体会，看着人增多了，其实带来了很多低效的问题。
2.这个团队的外部环境一定要简单，团队内部对于主要目标有自己的掌控力和绝对的自由。我们现在的研发团队，经常受到很多外界因素的干扰和冲击，什么配套软件要换了，临时需要赶个进度加个需求，设计方案出现变动等等之类的。一旦进度完不成，最简单的方法就是加人和加班，很多时候在疲于奔命，很难想象这种环境下能够做出好产品。一个优秀的团队，内部应该是轻松又有激情的工作氛围，团队有自己清晰明确的目标，不能受外界过多因素的干扰，简单的说，就是要聚焦。举个简单的例子，10个人需要干三个月的任务，不是三十个人一个月就能做完，这两者之间绝对不是相等的关系。
3.团队内部有快速清晰的信息共享和反馈机制，对于用户的反馈和需求能够第一时间获取到，有快速的决策机制，对于问题能够快速形成结论。
4.团队成员的能力和职责，这个话题就比较广泛了，作为测试人员，我一直在想的问题是，在这样的团队模式中，测试人员的定位是什么？测试人员能够为这样的团队带来什么帮助和价值？
相信做过测试的都会有这样的感觉，时间长了感觉真的是挺无聊和枯燥的，整天对着页面点啊点的，开发人员也不重视，总是带着种鄙视的眼光看待测试人员，长此这样下去，能有什么发展呢？对于这种情况，我想起了以前看一个测试牛人博客里写的一句话：“没有哪个职位鄙视哪个职位，只有能力强的鄙视能力差的”
仔细想想，测试人员相对于开发人员，优势在哪里呢？对于业务的理解能力，思维的缜密程度，问题的敏感度，这些都是优势。除此之外，我认为技术的提升永远都不会过时。测试设计思路，场景分析能力，用例设计方法，研发模式，测试框架，测试工具，这些是测试人员的知识结构，除此之外和开发人员同样的，代码阅读和编写能力，算法，数据库，网络协议等等，这些知识和技能不管做什么职位都会用的上。同时也会拓宽发展方向，帮你赢得别人的尊重和认可，不管是和人沟通还是跳槽都会多一份底气。
再回到一开始的问题，在这样的全功能团队模式中，测试人员的比例会下降（按照今天会上的说法，开发和测试的比例是5比1），但是我认为这不是简单的减少测试人员（如果只是简单的减少测试人员，那我认为这种模式注定会失败的）。比例下降应该是专职测试人员的比例会下降，有一部分测试人员会承担起编码的工作，提供单元测试用例，帮助开发人员写单元测试代码，对核心代码做白盒测试，构建团队的自动化测试框架，编写自动化测试用例，帮助团队编写测试工具，甚至承担一些开发的工作，这样就会出现一个新的角色，测试开发工程师。这种角色的成员最好是测试人员出身，但同时又具备和开发人员同等的代码编写能力，这种角色在业界已经很普遍了，我记不清是在什么网站上看到的，google里的software test engineer这个职位干的就是这些事，他们绝大部分时间都是和开发人员一样在写代码。我认为这样的定位，是全功能的团队模式中测试人员真正体现价值的地方。而保留少量的专职测试人员，从用户的实际使用场景出发，对系统做整体的集成验证。
这样的话，就要求团队成员都具备独立的特性设计，开发，测试的能力，对于习惯了之前的研发模式，尤其是对于测试人员，是一个不小的挑战。但同时也是一种解脱，不用再天天跟在开发团队后边，把所有事情收尾，落个吃力不讨好的结果。
我心中理想的运作模式应该是这样：团队全体成员一起获取到需求信息，能够确定出清晰的目标和计划，争议问题快速形成结论，开发人员编码时同步完成单元测试，测试人员具备代码审视和白盒测试的能力，缩短BUG的发现和修改周期，绝大部分低级问题能够在前期发现解决。有成熟的自动化框架和明确的接口文档，冒烟测试和回归测试绝大部分依赖自动化用例完成。
最后说说测试人员的发展，其实在前边已经涉及到一部分了，不管做什么职位，技术始终是最重要的。如果是因为不想写或者不会写代码而去做测试，那我觉得还是不要做软件了，换个行业也许会更好。。。。做测试不是不懂技术，不去学习的借口。软件测试有很多专门的分类，黑盒测试，白盒测试，自动化测试，性能测试，先有一个扎实的基础，每个专项做精了都会有个不错的发展前途。就我自己而言，基本上这些分类或多或少的都做过，以后的职业发展，我个人是比较倾向去做测试开发工程师的，单纯的黑盒功能测试做久了是挺没意思的，再往后会争取向着测试架构师之类的角色努力吧。