敏捷团队的管理其实的确面临着很多的挑战。蔡老师分别从敏捷管理的挑战、接受敏捷、敏捷下面的组织结构、敏捷架构下的沟通、敏捷下的KPI考核、以及机会和发展几个方面进行深入的讨论。

　　其实我觉得各个公司施行敏捷的时候都会遇见这次讲师所分享的一些问题，基本上都是有共同点的。比如第一点，每个Scrum Team都会有自己的一个基调。每个测试你所跟随的人不同，跟随的team也不同，然后所接触的项目也不同，碰见的问题也不同，甚至作息时间也会有所不同。这样的情况下，管理其实是最最麻烦的。我自己之前也一直烦恼一个问题就是，在这样的情况下，我应该如何进行test team这样一个团队的横向分享，比如好的case，好的bug，又或者要push某个process的时候怎么办。我表示真的很烦恼，如有人有好的解法，还希望在我blog下面留言。

　　第二个问题点，如何在做好管理的同时，又避免Scrum Master和Test Leader同时给测试发号施令。这个问题其实也很常见。Master和Leader横向交流不同，每个人安排任务的切入点也不同，就往往会导致测试们很辛苦。一会儿要处理这个，一会儿要处理那个。最终会导致加班，情绪也不稳定。

　　第三个问题点，一旦敏捷了，就会造成很多的“不规范”，那么在这种情况下面应该怎么进行KPI的考评呢？

　　第四个问题点，当你的团队每个成员都被分派到了各个Scrum Team之后，如何保持test team一个高涨的氛围，如何去维持一个很好的气氛，是否能够一直保证大家一条心呢？

　　第五个问题点，Scrum Master和Test Leader如何体现自己的KPI。一旦敏捷了之后，作为一个leader的话，我相信很多人会觉得这个职位越来越虚，好像自己离团队成员以及项目越来越远，那么怎么样才能够体现自己的KPI呢，我相信也是很多人困扰的原因所在。

　　第六个问题点，测试管理者的出路在哪里，或者说规划，或者方向在什么地方？

　　如何去接受敏捷，这点我相信很多人也能够体会。如果你作为一个测试经理，那么推广敏捷我相信是非常值得期待的一件事情。但是敏捷并非那么容易被团队成员以及高层领导所接受，或者说那么快的接受。就测试成员来讲，首先他会多了一个“婆婆”，Scrum Master。至少从心理上来讲，会有一些抵触的心理。其次 ，每个测试人员被安排到独立的Scrum Team中，那么相比以前的团队合作可能会多出很多的工作量不说，可能相对dev和pm来讲更加的弱势。从企业高层来讲，我个人觉得一般会碰见这样几个问题。一种就是觉得现在的模式很好啊，为何要去改变呢？一种就是可能看到敏捷之后，觉得测试team更加偷懒了，没有doc的输出，没有一个团队的合作。所以综上所述，接受敏捷需要时间，需要引导。

　　敏捷模式下面的团队架构，蔡老师给出了四种架构，我自己其实比较偏向于测试人员上面一定要是测试leader，测试leader上面可以是别的一个职位。为什么呢？一方面来讲，测试leader和测试人员最为熟悉也是最贴近的一个角色，无论是工作安排还是沟通都比较好。另外，就如我上一篇写的文章中提到的，我还是认为能够理解测试的只有测试，所以无论安排和沟通测试leader能够更加从测试的角度出发进行思考，这样对于测试人员的发展会非常有利。

　　这种敏捷的架构中必须尽量要保证产品，项目，测试，开发等几个角色互相促进，互相帮助去推动产品，不要有什么勾心斗角。否则结果可能就和敏捷的初衷背道而驰。

　　敏捷模式下的沟通，这里其实就是两点，敏捷模式下测试经理和Scrum Master的沟通以及和组员的沟通。和Scrum Master的沟通主要是为了让Scrum Master分配的任务更加符合项目情况，符合测试人员 的水平。和组员的沟通主要是引导大家去接受敏捷，并且不停地指出错误纠正，帮助大家和Scrum Master更好的沟通，以免测试人员感觉自己被卖掉了。

　　测试管理者在该模式下还有一个很重要的沟通对象，就是自己的上级。其实这这点并不难，我更觉得在各个企业哪怕不敏捷也需要做到这样几点。定期的说明自己的想法和建议，包括怎么落实怎么执行。花时间好好总结自己团队完成任务的情况，业绩，让上级一目了然。最后就是引导上级去接受敏捷。

　　敏捷下面的KPI考核。这点其实哪怕不敏捷很多公司也很迷茫。敏捷之后，需要进行全方位的考核。1.测试人员所负责模块的质量。2.case和bug的质量 3.工作的态度和方法 4.Scrum Mater的反馈。主要要注意的就是作为测试管理者，要对于Scrum Master给出的feedback有所过滤，每个Master都会有自己的性格特征。作为管理者当考核的时候听取Master的意见的时候需要根据其不同的性格进行有针对性的过滤，以达到最好最公正的评价效果。 5.对于团队的服务 6.组内其他成员的反馈

　　在考核的过程中，测试管理者要像以前一样的了解自己的组员，而不是放到每个team之后就不理不问。我觉得甚至要比以前更加的了解。同时，考核也是one one的一个过程，在期间需要更多的引导测试人员主动去展现自己的业绩，主动去研究新的技术，主动帮助团队的成员，提升自己的主观能动性。这样敏捷才会越来越好，越来越有效。

　　敏捷模式下蔡老师还提到了一个补位的概念，顾名思义，就是要了解每个team项目，人员的特征。在一些特殊的，突发的情况下，测试人员可以进行灵活的补位调整，这样就不会对于项目、产品造成很大的影响。

　　敏捷带来的机会其实很多，就如我自己在创业团队中的初期一直是敏捷的一种模式，对于测试人员自身的要求会相应的提高，同时测试人员学到的东西也会更多。测试人员会相比以前的团队中认识更多的同事，会提升自己的人际交往能力。作为管理者，敏捷也在考验你的管理能力。就关于敏捷的好处来讲，我总结就是作为测试人员，你了解的流程更多了，你了解的产品项目信息更多了，你接触的技术面更广了。但有一点，需要大家谨记，就是要不停地和同行沟通，要不停地进行学习。

　　敏捷是把双刃剑，要看用的好不好。就如刚在微博上面发的一样，大家根据实际情况进行选择运用，否则很容易导致测试在企业中的流程也好，文档也好，技术也好没有沉淀和积累。合理运用传统流程和敏捷才是王道。
本文转载于51testing  如有版权问题 请找他们 本人只是学习备份而已！