其实敏捷这个词，在中国已经流行很久了。

　　我也一直没有认真的去分析它的存在，价值，意义以及有可能带来的一些负面的影响。

　　直到我换了一份工作。

　　上一家公司，其实也是一种敏捷的团队。

　　版本的频繁发布，开发团队的不断自己修缮。然后测试团队的人员跟进各个项目，进行业务了解，需求探知，然后测试。

　　之所以没有很深刻的感悟。是因为当初的测试团队和开发团队物理上是分开的。

　　无论手里接多少个项目，项目之间是否有关联，所有的测试团队的成员都在一起。对于因为做不同的业务而产生的可能会有的gap，我设定了一个share meeting来补足。每个人都对于其他人的项目业务，项目的难点，现存的问题以及解决方案都会有些了解。一旦需要项目反转，人员调动，也不会是全新的手足无措。

　　还有一点，是我以前没有意识的很清楚的。那个时候跟我合作的开发团队，是有很深的业务知识的。对于各个业务之间的关联，对于系统的整体业务逻辑，对于框架基本都是了解的，甚至有的算是十几年的资深。

　　所以系统的这种敏捷模式，即便是变化时时有，偶尔也引入一些问题，但是总体上还是好的，可控的。

　　即便如此，因为出了一些新入开发人员对于某些需求的修改，导致其他功能的失效，让我很是担心了一回。也因此提出了风险盘整和整体变化控制必须到QA的理念。

　　而今想来，这些还真算是小case了。

　　新的公司，是国内的开发团队，模仿的或者说自我心里认同的也是所谓的敏捷开发。

　　但是对于业务不甚了解，需求不完全知道，架构体系关联一没有耐心而没有时间三没有精力去了解的，这样的团队们也可以自诩为敏捷吗?

　　他们之所以版本频发，甚至频发到跟踪都难，是因为自己改一次，错百出。自我却没有任何的检讨。认为这就是敏捷。甚至因为UT的“麻烦”和“浪费时间”而轻轻越过。。这也叫敏捷?这叫全无规矩，没有章法好不好?

　　我终于了解，什么叫做山寨，也真是纳闷了，中国的山寨真是落地生根啊!

　　而且，目前对我来说，最为麻烦的问题不仅仅在于对应这样的开发团队。

　　还因为我的测试团队被打散了。

　　这边公司的业务对应很多不同的客户，每个客户的需求又会幻化成若干项目。然后每个项目都不大，所以测试人员需求也不多。于是我的测试人员就变成了分散到各个项目的游兵散豆。跟着各个项目拼杀。

　　在人家的一亩三分地上活动，加上又要占用人家项目的budget。对于业务和测试了解并不深入的开发PM们于是就觉得，测试人员自从进入他们的项目的那一刻，就属于他们的管辖范围了。于是我很悲催的就失控了。其实我的这种悲催是这个公司从成立以来就是如此的。所以我只能说我很悲催的认识到原来还可以这样。

　　上周跑到各个项目去做了解，继续还能悲催的看到分散在各个项目里面的测试人员间或做一些和测试无关的事情。PM们认为，我让你测试人员入场，就牺牲了其他的resources的人头预算，所以你帮我一下也是应该的。而追求利益最大化的老大们也认为，多了解一些对于测试人员也是好的吗。。。

　　于是，我坐在这里写proposal。从没有任何一个proposal让我写的如此艰难。现状分析，影响范围，解决方案。。其实我自己都没有很好的解决方案。

　　我自问没有能力真的一下子去了解那么多项目的日常运作和业务。但是不控制的结果是我基本上沦为了一个RM，分人头。。而这样的结果不是我如何，而是我的Tester们被置于何地?他们的依靠又在哪里?

　　但是若是分开，独立出来，又有若干可恨的客户，因为安全的因素必须使得某些项目在独立的开发间。。

　　分开，分离，让Tester们，开发PM们修正自己的想法，转换思维。让开发和测试真正的开始独立并行，亲密合作。。梦想啊，怎么样才能让它落到现实呢?

　　*******

　　后记，在这里也不是向开发人员和团队抱怨什么。他们也有很多的无奈。因为文化，体制导致的和客户的不对等或者因为沟通的问题导致的自己没有转圜的余地。

　　Anyway，这些都是我在面对的，和要解决的。

　　曾经我对自己说，如果真的想做，就算用牙咬，我也会撕出一片自己的天空。而今，2012年的我，是否还有当初的勇气呢?