软件测试过程中，为了避免同一个测试人员多次测试同一个 Story 容易造成思维定势而导致漏测，很多项目组采用交叉测试来规避这个问题。但是，交叉测试能够达到预期收益的一个重要前提是参与交叉测试的测试人员对当前迭代中所有的 Story 及测试用例都要有所熟悉。这样才能使一个测试人员接手另一个测试人员之前测试过的 Story 时能够对该 Story 的测试用例进行重新审视，从而发现被遗漏的、甚至是错误的测试用例，而不是仅仅拿一个新的 Build 在现有的测试用例下再测试一遍。基于交叉测试实施的这个前提条件的考虑，笔者要求在迭代开发过程中每个测试人员都能够讲解自己对任意一个 Story 的理解。

　　其用战也，胜久则钝兵挫锐，攻城则力屈，久暴师则国用不足。夫钝兵挫锐，屈力殚货，则诸侯乘其弊而起，虽有智者不能善其后矣。故兵闻拙速，未睹巧之久也。夫兵久而国利者，未之有也。故不尽知用兵之害者，则不能尽知用兵之利也。
                                            ——《孙子兵法•作战》

　　作战持续时间长了，容易使国力受损，而敌国则容易趁虚而入。所以孙子兵法说不知道用兵的害处，则不能真正知道用兵的好处。

　　同样，很多管理措施都是有其利与弊的一端，不知其弊端，则很难发挥其利的一端。比如，为了控制缺陷的数量，在每个 Story 被测试出一定数量或者严重程度的 Bug 后，有的项目组会规定此时对应的开发人员要给全组人员买零食或者请吃饭之类惩罚性措施。但是，这样的措施会不会导致开发人员在缺陷被发现时出现推诿的现象，试图不承认其是缺陷或是由其引入的呢？这是措施落实前所要考虑的措施可能存在的弊端。

　　项目经理的思想境界

　　是故百战百胜，非善之善也；不战而屈人之兵，善之善者也。
                                            ——《孙子兵法•谋攻》

　　每次打仗都取胜不是战争的高境界，战争的高境界是不费兵卒而取得胜利。《孙子兵法》的这个论断，给了笔者很大的启发：项目经理在解决项目管理过程中遇到的问题时要选取一个较高的高度去解决问题。

　　敏捷开发得以流行之后，有人把 CMMI 那套“重型”过程全盘抛弃了。取而代之却往往是毫无章法，而又无法对项目的各个维度进行有效控制的开发过程。笔者曾经接手过一个号称实施敏捷的濒临危险状态的项目。这个项目存在很多问题，虽然这些问题都很常见。诸如严重的返工现象、漏测试现象、人员组织纪律性差以及人员技能水平低等等。所有这些问题当中，笔者当时认为为重要和迫切的是严重的返工现象所带来的质量问题。而对于质量的改进，笔者当时并不是通过解决漏测试问题，虽然它也会导致一些质量问题。而是从规范开发流程入手，采取缺陷预防的相关措施去控制质量。笔者当时所采取的措施是基于这样的认识：通过各种措施尽可能地发现缺陷并将其修复不是质量管理的高境界，质量管理的高境界是通过缺陷预防将缺陷扼杀于摇篮之中！

　　应对困境

　　昔之善战者，先为不可胜，以待敌之可胜。
                                           ——《孙子兵法•军形》

　　从前的那些善战的人，总是先能做到自己不被敌人战胜，然后等待时机去战胜敌人。

　　《孙子兵法》启发我们在面对困境的时候，首先要做的是不被困境中的各种问题击败，即要保证项目的成功交付。然后才是等待时机去将这些问题击败。这种情形，尤其适合在团队中出现某些违背团队目标的人，而一时间你又无法对其进行处理的情形。这时候，作为项目经理其实可以等待时机再处理，只要你们保证项目的成功交付。

　　纷纷纭纭，斗乱而不可乱。
                                           ——《孙子兵法•兵势》

　　尤其是在面对困境的时候，项目经理更要能够沉住气，而不能自乱阵脚。这样，整个团队才不会乱。一如两军对战，主帅一乱势必导致其军自乱。面对危急情况，项目经理的表现得沉着冷静，也能够给团队成员一个好的榜样。