敏捷项目管理实战之《孙子兵法》在敏捷项目管理中的应用

成为“敏捷”，而不是做“敏捷”

谈到“敏捷”首先容易让人想到的是各种优秀实践。这些优秀实践固然有可以借鉴的地方。但是在具体实施的时候往往要根据项目的实际情况进行调整，而不是生搬硬套。

故兵无常势，水无常形。能因敌变化而取胜者，谓之神。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《孙子兵法•虚实》

 

作战没有固定的方式方法，就像水流没有固定的形状一样。能够根据敌情的发展变化而采取灵活措施取胜的人，才可以称得上是用兵如神。

敏捷开发中的各种优秀实践在具体实施时也同样要根据项目的实际情况作适当的调整和变通。比如，敏捷开发中优秀实践“客户参与”（Customer Involvement）特别强调了现场客户（On-site customer）对于开发团队的重要性。而笔者所带的项目组在无法争取到这样的资源的情况下采取了一种变通方式来实现“客户参与”。我们把需求评审、分 析过程中遇到的疑问与问题登记到“需求问题确认列表”。项目组中的每个人都可以自行往这个列表中登记问题。“需求问题确认列表”中的疑问、问题由专人或者 问题登记人自己通过电话、电子邮件、即时通讯工具等方式与客户方的需求负责人进行确认。确认的结果以及确认的原始记录（如电子邮件内容）都会记录到“需求 问题确认列表”的“确认结果”一栏中，并由问题确认人对确认结果进行知会全组人员。如果有必要的话，项目组的任何一个人都可以组织全体人员对问题及其确认 结果进行讨论。而“需求问题确认列表”我们也会定期发给客户方以便再确认和备忘之用。这样一个过程，虽然没有客户与开发团队在一起办公，但是一定程度上规 避了开发团队对需求的理解的偏差问题。从而实现了与“客户参与”同样的效果。

因此，实施敏捷开发的关键是使我们的团队成为“敏捷”—— 理解并实现敏捷各个优秀实践所要达到的效果，而不是做“敏捷”—— 对敏捷开发的优秀实践全盘照搬，为了“敏捷”而“敏捷”。

 

 

迭代开发的精髓 —— 顺应自然规律和反馈

夫兵形象水，水之行避高而趋下，兵之形避实而击虚。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《孙子兵法•虚实》

 

用兵打仗的规律就像水，水流动的规律是避开高处而往低处流。用兵的规律则是避开敌人的锋芒而攻击其薄弱的地方。这是自然界规律给《孙子兵法》的启示。同时，也给了我们在软件开发方面的启示 —— 发现自然规律并顺应它。

敏捷开发中往往存在这样一个现象：某个迭代中提出的需求，过了几个迭代甚至于下一个迭代就被推翻了。这种现象很大程度上是因为客户自己也不清楚需求 是什么或者说他们的业务需要（need）是什么。而迭代开发的精髓就在于它考虑到这种现象及其产生的原因，因而采取小批量、频繁交付的开发模式。这使得我 们可以根据上一个迭代（或者之前所有的迭代）中获取的经验（包括什么样的需求才是符合客户的业务需要）对当前迭代的目标和活动作出调整。可见，迭代开发的 精髓在于顺应自然规律 —— 人们认识事物需要经历一个由浅入深、由错到对的过程。同时，也在于它利用了反馈的功效 —— 当期迭代所掌握的知识和经验会反馈到下一个迭代，从而影响其目标和活动。

同样，迭代开发过程中团队成员对需求的理解也往往一开始不是那么清晰。随着具体开发、测试工作的进展其对需求的理解才渐渐明朗。

正如《太公阴符》所说“圣人知自然之道不可违，因而制之”。规律是不可抗拒的，顺应规律可以帮助我们取胜。人类对事物的认识，往往不可能一下子就洞 若观火，而是要经历一个逐渐深入的过程。开发人员也好、测试人员也好，其对需求的理解就是一个例子。不管我们如何努力地去理解、分析需求，其结果往往还是 一开始理解得不够全面、透彻，待到具体写代码、写测试用例的过程中，思路才慢慢清晰起来，脑子中的疑问也越来越多。随着这些疑问的解决，对需求的理解也慢 慢变得清晰、全面、透彻了。所以知道了这个规律，我们就要“因而制之”了 —— 迭代开发过程中不要只知道往前走，适当的时候停下来，甚至往回走，重新去审视下需求，往往会有新的发现。此时再根据对需求的新的理解去重新审视代码和测试 用例，这样就能发现迭代初期时所发现不了的问题，最终使得交付的软件中隐藏的缺陷数降低。

 

团队规模和管理模式

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

 

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

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《孙子兵法•兵势》

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

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

 

不要忘记项目经理的职责

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

视卒如爱子，故可与之俱死。厚而不能使，
爱而不能令，乱而不能治，譬若骄子，不可用也！

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《孙子兵法•地形》

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

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

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

 

 

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

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

 

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

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《孙子兵法•火攻》

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

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

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

 

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

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《孙子兵法•作战》

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

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

项目经理的思想境界

是故百战百胜，非善之善也；不战而屈人之兵，善之善者也。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《孙子兵法•谋攻》

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

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

 

应对困境

昔之善战者，先为不可胜，以待敌之可胜。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《孙子兵法•军形》

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

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

 

纷纷纭纭，斗乱而不可乱。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《孙子兵法•兵势》

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