《孙子兵法》在敏捷项目管理中的应用(2)

团队规模和管理模式

对于敏捷开发常见的一个误解是“敏捷开发只适用于小规模的团队”。团队规模小的确可以减少沟通的复杂性、也某种程度上减少管理的成本。然而大型团队中也有使用敏捷开发的。敏捷开发是否可以用于管理大型团队，问题在于我们如何实施。

凡治众如治寡，分数是也；斗众如斗寡，形名是也。

——《孙子兵法•兵势》

要治理好人数多的军队如同治理好人数少的军队一样，关键在于组织编制好。

类似的，大型团队中使用敏捷开发，往往可以采用组织多个相对小型的敏捷团队，实行分而治之。

不要忘记项目经理的职责

有些项目经理对团队成员很友善、也很照顾，而项目的质量为何还是那么低下呢？

视卒如爱子，故可与之俱死。厚而不能使，

爱而不能令，乱而不能治，譬若骄子，不可用也！

——《孙子兵法•地形》

看待士兵如同看待自己的亲生儿子，就可以和他们生死与共。如果这样也不能够调动他们、违法乱纪而不能惩治，士兵就像娇惯的儿子，是不可以用来打仗的。

作为项目经理，能够真心实意地关心和爱护团队成员是好事，但是不要忘了作为项目经理的职责： 保证项目的成功交付才是最重要的。团队成员要是不能履行自己的责任，服从主管的安排，具体落实工作，对其再如何关心也是无益的！

一个真正和谐的团队不是大家在一起都是一团和气、没有冲突，而是大家都能朝团队的共同目标 —— 项目的成功交付去努力，大家各尽其职。因此，对于阻碍这个共同目标的人和事，项目经理要把握不要忘记自己的职责的原则，该严则严，对于给过机会而仍然不思改正的人该处理就处理。

管理措施的制定要考虑其实施的前提条件和弊端

任何的管理思想和理论到最后都要体现为具体的管理措施。而管理措施的制定则要考虑其实施的前提条件及其弊端。

发火有时，起火有日。时者，天之燥也。日者，月在箕、壁、翼、轸也。凡此四宿者，风起之日也。凡火攻，必因五火之变而应之：火发于内，则早应之于外；火发而其兵静者，待而勿攻，极其火力，可从而从之，不可从则上。

——《孙子兵法•火攻》

火攻的优势在于借助自然界的力量造成强大的打击力。但是，真正要发挥火的威力，则要看实施火攻时的天气条件以及火燃烧时敌人的反应情况 —— 一定要借助天气干燥、风力风向、敌方混乱这些外部条件，才能够“趁火打劫”。可见，火攻所可能产生的强大杀伤力是措施制定者所期望的收益，而火攻实施时的天气情况、敌人反应情况则是其实施的必备前提条件。

相反，管理措施的期望收益自然容易想到的，但是容易忽略的是实施这些措施的前提条件。比如，“重构”（Refactoring）的目的固然是使代码的质量日趋提高，但是容易忽略的是它的实施前提：“重构”要有自动化测试工具支持。否则，“重构”代码所可能带来的对现有功能的破坏会使其无异于自杀。

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

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

——《孙子兵法•作战》

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

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

转载自：http://developer.51cto.com/art/201210/359855.htm