敏捷項目管理實戰之《孫子兵法》在敏捷項目管理中的應用

成為「敏捷」，而不是做「敏捷」

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

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

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ——《孫子兵法?虛實》

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

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

因此，實施敏捷開發的關鍵是使我們的團隊成為「敏捷」—— 理解並實現敏捷各個優秀實踐所要達到的效果，而不是做「敏捷」—— 對敏捷開發的優秀實踐全盤照搬，為了「敏捷」而「敏捷」。

迭代開發的精髓 —— 順應自然規律和反饋

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

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ——《孫子兵法?虛實》

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

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

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

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

團隊規模和管理模式

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

凡治眾如治寡，分數是也；斗眾如斗寡，形名是也。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　——《孫子兵法?兵勢》

要治理好人數多的軍隊如同治理好人數少的軍隊一樣，關鍵在於組織編製好。

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

不要忘記項目經理的職責

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

視卒如愛子，故可與之俱死。厚而不能使，

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ——《孫子兵法?地形》

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

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

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

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

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

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

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　——《孫子兵法?火攻》

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

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

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

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

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　——《孫子兵法?作戰》

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

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

項目經理的思想境界

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

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　——《孫子兵法?謀攻》

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

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

應對困境

昔之善戰者，先為不可勝，以待敵之可勝。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ——《孫子兵法?軍形》

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

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

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

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　——《孫子兵法?兵勢》

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

摘自：IBM