簡介： 《孫子兵法》中的論述雖然是關于戰(zhàn)爭的，但是其思想在項目管理領域對我們也是有借鑒意義的。本文以筆者的實際項目管理經驗為基礎，分享了《孫子兵法》在敏捷項目管理中的應用。希望能夠對讀者的實際項目管理工作有所啟發(fā)。

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

談到“敏捷”首先容易讓人想到的是各種優(yōu)秀實踐。這些優(yōu)秀實踐固然有可以借鑒的地方。但是在具體實施的時候往往要根據(jù)項目的實際情況進行調整，而不是生搬硬套。

故兵無常勢，水無常形。能因敵變化而取勝者，謂之神。

——《孫子兵法•虛實》

作戰(zhàn)沒有固定的方式方法，就像水流沒有固定的形狀一樣。能夠根據(jù)敵情的發(fā)展變化而采取靈活措施取勝的人，才可以稱得上是用兵如神。

敏捷開發(fā)中的各種優(yōu)秀實踐在具體實施時也同樣要根據(jù)項目的實際情況作適當?shù)恼{整和變通。比如，敏捷開發(fā)中優(yōu)秀實踐“客戶參與”（Customer Involvement）特別強調了現(xiàn)場客戶（On-site customer）對于開發(fā)團隊的重要性。而筆者所帶的項目組在無法爭取到這樣的資源的情況下采取了一種變通方式來實現(xiàn)“客戶參與”。我們把需求評審、分析過程中遇到的疑問與問題登記到“需求問題確認列表”。項目組中的每個人都可以自行往這個列表中登記問題。“需求問題確認列表”中的疑問、問題由專人或者問題登記人自己通過電話、電子郵件、即時通訊工具等方式與客戶方的需求負責人進行確認。確認的結果以及確認的原始記錄（如電子郵件內容）都會記錄到“需求問題確認列表”的“確認結果”一欄中，并由問題確認人對確認結果進行知會全組人員。如果有必要的話，項目組的任何一個人都可以組織全體人員對問題及其確認結果進行討論。而“需求問題確認列表”我們也會定期發(fā)給客戶方以便再確認和備忘之用。這樣一個過程，雖然沒有客戶與開發(fā)團隊在一起辦公，但是一定程度上規(guī)避了開發(fā)團隊對需求的理解的偏差問題。從而實現(xiàn)了與“客戶參與”同樣的效果。

因此，實施敏捷開發(fā)的關鍵是使我們的團隊成為“敏捷”—— 理解并實現(xiàn)敏捷各個優(yōu)秀實踐所要達到的效果，而不是做“敏捷”—— 對敏捷開發(fā)的優(yōu)秀實踐全盤照搬，為了“敏捷”而“敏捷”。

迭代開發(fā)的精髓 —— 順應自然規(guī)律和反饋

夫兵形象水，水之行避高而趨下，兵之形避實而擊虛。

——《孫子兵法•虛實》

用兵打仗的規(guī)律就像水，水流動的規(guī)律是避開高處而往低處流。用兵的規(guī)律則是避開敵人的鋒芒而攻擊其薄弱的地方。這是自然界規(guī)律給《孫子兵法》的啟示。同時，也給了我們在軟件開發(fā)方面的啟示 —— 發(fā)現(xiàn)自然規(guī)律并順應它。

敏捷開發(fā)中往往存在這樣一個現(xiàn)象：某個迭代中提出的需求，過了幾個迭代甚至于下一個迭代就被推翻了。這種現(xiàn)象很大程度上是因為客戶自己也不清楚需求是什么或者說他們的業(yè)務需要（need）是什么。而迭代開發(fā)的精髓就在于它考慮到這種現(xiàn)象及其產生的原因，因而采取小批量、頻繁交付的開發(fā)模式。這使得我們可以根據(jù)上一個迭代（或者之前所有的迭代）中獲取的經驗（包括什么樣的需求才是符合客戶的業(yè)務需要）對當前迭代的目標和活動作出調整?？梢?，迭代開發(fā)的精髓在于順應自然規(guī)律 —— 人們認識事物需要經歷一個由淺入深、由錯到對的過程。同時，也在于它利用了反饋的功效 —— 當期迭代所掌握的知識和經驗會反饋到下一個迭代，從而影響其目標和活動。

同樣，迭代開發(fā)過程中團隊成員對需求的理解也往往一開始不是那么清晰。隨著具體開發(fā)、測試工作的進展其對需求的理解才漸漸明朗。

正如《太公陰符》所說“圣人知自然之道不可違，因而制之”。規(guī)律是不可抗拒的，順應規(guī)律可以幫助我們取勝。人類對事物的認識，往往不可能一下子就洞若觀火，而是要經歷一個逐漸深入的過程。開發(fā)人員也好、測試人員也好，其對需求的理解就是一個例子。不管我們如何努力地去理解、分析需求，其結果往往還是一開始理解得不夠全面、透徹，待到具體寫代碼、寫測試用例的過程中，思路才慢慢清晰起來，腦子中的疑問也越來越多。隨著這些疑問的解決，對需求的理解也慢慢變得清晰、全面、透徹了。所以知道了這個規(guī)律，我們就要“因而制之”了 —— 迭代開發(fā)過程中不要只知道往前走，適當?shù)臅r候停下來，甚至往回走，重新去審視下需求，往往會有新的發(fā)現(xiàn)。此時再根據(jù)對需求的新的理解去重新審視代碼和測試用例，這樣就能發(fā)現(xiàn)迭代初期時所發(fā)現(xiàn)不了的問題，最終使得交付的軟件中隱藏的缺陷數(shù)降低。

#p#

團隊規(guī)模和管理模式

對于敏捷開發(fā)常見的一個誤解是“敏捷開發(fā)只適用于小規(guī)模的團隊”。團隊規(guī)模小的確可以減少溝通的復雜性、也某種程度上減少管理的成本。然而大型團隊中也有使用敏捷開發(fā)的。敏捷開發(fā)是否可以用于管理大型團隊，問題在于我們如何實施。

凡治眾如治寡，分數(shù)是也；斗眾如斗寡，形名是也。

——《孫子兵法•兵勢》

要治理好人數(shù)多的軍隊如同治理好人數(shù)少的軍隊一樣，關鍵在于組織編制好。

類似的，大型團隊中使用敏捷開發(fā)，往往可以采用組織多個相對小型的敏捷團隊，實行分而治之。

不要忘記項目經理的職責

有些項目經理對團隊成員很友善、也很照顧，而項目的質量為何還是那么低下呢？

視卒如愛子，故可與之俱死。厚而不能使，
愛而不能令，亂而不能治，譬若驕子，不可用也！

——《孫子兵法•地形》

看待士兵如同看待自己的親生兒子，就可以和他們生死與共。如果這樣也不能夠調動他們、違法亂紀而不能懲治，士兵就像嬌慣的兒子，是不可以用來打仗的。

作為項目經理，能夠真心實意地關心和愛護團隊成員是好事，但是不要忘了作為項目經理的職責： 保證項目的成功交付才是最重要的。團隊成員要是不能履行自己的責任，服從主管的安排，具體落實工作，對其再如何關心也是無益的！

一個真正和諧的團隊不是大家在一起都是一團和氣、沒有沖突，而是大家都能朝團隊的共同目標 —— 項目的成功交付去努力，大家各盡其職。因此，對于阻礙這個共同目標的人和事，項目經理要把握不要忘記自己的職責的原則，該嚴則嚴，對于給過機會而仍然不思改正的人該處理就處理。

管理措施的制定要考慮其實施的前提條件和弊端

任何的管理思想和理論到最后都要體現(xiàn)為具體的管理措施。而管理措施的制定則要考慮其實施的前提條件及其弊端。

發(fā)火有時，起火有日。時者，天之燥也。日者，月在箕、壁、翼、軫也。凡此四宿者，風起之日也。凡火攻，必因五火之變而應之：火發(fā)于內，則早應之于外；火發(fā)而其兵靜者，待而勿攻，極其火力，可從而從之，不可從則上。

——《孫子兵法•火攻》

火攻的優(yōu)勢在于借助自然界的力量造成強大的打擊力。但是，真正要發(fā)揮火的威力，則要看實施火攻時的天氣條件以及火燃燒時敵人的反應情況 —— 一定要借助天氣干燥、風力風向、敵方混亂這些外部條件，才能夠“趁火打劫”?？梢?，火攻所可能產生的強大殺傷力是措施制定者所期望的收益，而火攻實施時的天氣情況、敵人反應情況則是其實施的必備前提條件。

相反，管理措施的期望收益自然容易想到的，但是容易忽略的是實施這些措施的前提條件。比如，“重構”（Refactoring）的目的固然是使代碼的質量日趨提高，但是容易忽略的是它的實施前提：“重構”要有自動化測試工具支持。否則，“重構”代碼所可能帶來的對現(xiàn)有功能的破壞會使其無異于自殺。

軟件測試過程中，為了避免同一個測試人員多次測試同一個 Story 容易造成思維定勢而導致漏測，很多項目組采用交叉測試來規(guī)避這個問題。但是，交叉測試能夠達到預期收益的一個重要前提是參與交叉測試的測試人員對當前迭代中所有的 Story 及測試用例都要有所熟悉。這樣才能使一個測試人員接手另一個測試人員之前測試過的 Story 時能夠對該 Story 的測試用例進行重新審視，從而發(fā)現(xiàn)被遺漏的、甚至是錯誤的測試用例，而不是僅僅拿一個新的 Build 在現(xiàn)有的測試用例下再測試一遍。基于交叉測試實施的這個前提條件的考慮，筆者要求在迭代開發(fā)過程中每個測試人員都能夠講解自己對任意一個 Story 的理解。

其用戰(zhàn)也，勝久則鈍兵挫銳，攻城則力屈，久暴師則國用不足。夫鈍兵挫銳，屈力殫貨，則諸侯乘其弊而起，雖有智者不能善其后矣。故兵聞拙速，未睹巧之久也。夫兵久而國利者，未之有也。故不盡知用兵之害者，則不能盡知用兵之利也。

——《孫子兵法•作戰(zhàn)》

作戰(zhàn)持續(xù)時間長了，容易使國力受損，而敵國則容易趁虛而入。所以孫子兵法說不知道用兵的害處，則不能真正知道用兵的好處。

同樣，很多管理措施都是有其利與弊的一端，不知其弊端，則很難發(fā)揮其利的一端。比如，為了控制缺陷的數(shù)量，在每個 Story 被測試出一定數(shù)量或者嚴重程度的 Bug 后，有的項目組會規(guī)定此時對應的開發(fā)人員要給全組人員買零食或者請吃飯之類懲罰性措施。但是，這樣的措施會不會導致開發(fā)人員在缺陷被發(fā)現(xiàn)時出現(xiàn)推諉的現(xiàn)象，試圖不承認其是缺陷或是由其引入的呢？這是措施落實前所要考慮的措施可能存在的弊端。

#p#

項目經理的思想境界

是故百戰(zhàn)百勝，非善之善也；不戰(zhàn)而屈人之兵，善之善者也。

——《孫子兵法•謀攻》

每次打仗都取勝不是戰(zhàn)爭的最高境界，戰(zhàn)爭的最高境界是不費兵卒而取得勝利?！秾O子兵法》的這個論斷，給了筆者很大的啟發(fā)：項目經理在解決項目管理過程中遇到的問題時要選取一個較高的高度去解決問題。

敏捷開發(fā)得以流行之后，有人把 CMMI 那套“重型”過程全盤拋棄了。取而代之卻往往是毫無章法，而又無法對項目的各個維度進行有效控制的開發(fā)過程。筆者曾經就接手過一個號稱實施敏捷的瀕臨危險狀態(tài)的項目。這個項目存在很多問題，雖然這些問題都很常見。諸如嚴重的返工現(xiàn)象、漏測試現(xiàn)象、人員組織紀律性差以及人員技能水平低等等。所有這些問題當中，筆者當時認為最為重要和迫切的是嚴重的返工現(xiàn)象所帶來的質量問題。而對于質量的改進，筆者當時并不是通過解決漏測試問題，雖然它也會導致一些質量問題。而是從規(guī)范開發(fā)流程入手，采取缺陷預防的相關措施去控制質量。筆者當時所采取的措施是基于這樣的認識：通過各種措施盡可能地發(fā)現(xiàn)缺陷并將其修復不是質量管理的最高境界，質量管理的最高境界是通過缺陷預防將缺陷扼殺于搖籃之中！

應對困境

昔之善戰(zhàn)者，先為不可勝，以待敵之可勝。

——《孫子兵法•軍形》

從前的那些善戰(zhàn)的人，總是先能做到自己不被敵人戰(zhàn)勝，然后等待時機去戰(zhàn)勝敵人。

《孫子兵法》啟發(fā)我們在面對困境的時候，首先要做的是不被困境中的各種問題擊敗，即要保證項目的成功交付。然后才是等待時機去將這些問題擊敗。這種情形，尤其適合在團隊中出現(xiàn)某些違背團隊目標的人，而一時間你又無法對其進行處理的情形。這時候，作為項目經理其實可以等待時機再處理，只要你們保證項目的成功交付。

紛紛紜紜，斗亂而不可亂。

——《孫子兵法•兵勢》

尤其是在面對困境的時候，項目經理更要能夠沉住氣，而不能自亂陣腳。這樣，整個團隊才不會亂。一如兩軍對戰(zhàn)，主帥一亂勢必導致其軍自亂。面對危急情況，項目經理的表現(xiàn)得沉著冷靜，也能夠給團隊成員一個好的榜樣。

原文鏈接：http://www.ibm.com/developerworks/cn/rational/r-cn-sunzibingfainagileprojectmanagement/index.html