敏捷之路
如何走向敏捷
敏捷開發是當今軟件工程和項目管理領域的前沿理論和實踐方法。 越來越多的企業和團隊在從傳統或者無序的開發方法中走向敏捷。有人懷疑敏捷只是一個一時的潮流，但實際上它正在逐漸成爲一個最終大多數相關企業都會選擇的方向。我們就在這篇文章中從開發團隊和項目管理方法兩個角度簡單探討一下如何走向敏捷。
團隊向敏捷的轉變
向敏捷開發轉換，首先要取得管理層的支持和團隊的認同。管理層的支持是關鍵，但團隊的認同也決定了敏捷執行的程度和結果。這個轉換過程可以分幾步、有選擇性地在一些項目中開始。
許多企業走向敏捷是從組織培訓開始的。培訓可以是內部的，也可以聘請外部顧問，最重要的是做培訓的人要有豐富的敏捷經驗。敏捷開發是一種經驗科學，書本上的知識只能起到一個瞭解的作用。真正的掌握需要在實踐中訓練。
培訓第一步一般從公司的管理層開始，尤其是負責開發或工程的副總裁、經理和項目經理等。培訓的過程是一個認知的過程，也是一個取得管理層支持的重要的步驟。第二步的培訓會集中在開發團隊中的帶頭人身上。有些公司採用的策略是從５０個人中選出１０個有領導潛質的人去培訓。這些階段比較典型的培訓是兩天的 Scrum 培訓。培訓以 Scrum 爲主，但會涉及敏捷的方方面面。
認識敏捷後開始實施。有些公司選擇小型的新項目實踐敏捷開發，這樣可以減少項目所受的公司其他非敏捷團隊的影響，並降低風險。但並不是所有公司都有這種運氣，有些公司不得不從已有項目的中間開始，也有很多成功的例子。如果從項目中間開始，或項目比較大，有些團隊可能會無所適從或不知所措。但只要有上層的支持和得力的指導，並完成一兩個敏捷週期，團隊一般會完全轉入敏捷開發的模式並不斷有所提高。
項目選好後是團隊的組建。敏捷的團隊有以下兩個特點：
· 敏捷的團隊是跨領域的平行聯合團隊，團隊中應該有來自所需要的各個平行領域的人員，包括測試人員，甚至客戶代表。目的是讓這個團隊能勝任開發週期中的所有任務。
· 團隊的職責和功能除了日常的開發任務外，要完成各種自我管理和組織功能。大多數的管理和決策不再由管理層單獨掌握，而是整個團隊商議決定。每個成員都要對項目管理中的範圍、時間、成本、風險等的概念和管理有一定的掌握。這樣每個成員在一定程度上都要成爲一個傳統意義上的項目經理。
在課堂上的培訓對團隊來說是個很好的開始，但他們更需要在實踐中的指導和訓練。不同的團隊、不同的公司在不同的項目中會碰到不同的問題。所以敏捷項目的進行中，最好能由經驗豐富的敏捷顧問指導。敏捷顧問會帶團隊走完一個或幾個開發週期，幫助團隊解決、糾正敏捷實施中的具體問題。這樣開發團隊會更快的進入敏捷的思維和模式。
項目管理如何過渡到敏捷
當前的開發團隊在項目管理上不外乎兩大類。 一類是比較正規，有不同程度的過程和方法管理的團隊。 由於 PMBOK® 在中國有很多的應用，我們下面會主要談到怎麼從 PMBOK® 的方法過度到敏捷。 另一類團隊是無序的或介於有序和無序之間的團隊。 他們的開發管理基本基於領隊人員的經驗，並無成型和穩定的套路。
從 PMBOK® 到敏捷
PMBOK® 定義和描述了一套有關項目管理的知識體系．這套知識體系比較全面，涉及項目計劃的集成，項目的範圍、時間、質量、成本、信息交流、風險、人力和物流等各個方面。相較與敏捷開發， PMBOK® 的最大不同體現在以下方面：
Ø PMBOK® 是計劃推動的開發，一般來說要求有大量的前期規劃和評估。 而敏捷是價值推動，靠經驗來優化。
Ø PMBOK® 重視文檔，每個階段都有正式的文檔要求。 敏捷重視結果，文檔往往被認爲是一種浪費。
Ø PMBOK® 的項目管理是自上而下的命令式管理。敏捷的管理是團隊的自我管理和經理們的服務式管理。
那麼 PMBOK® 在敏捷中就必須被完全拋棄嗎？在一定意義上講是這樣。因爲 PMBOK® 和敏捷有以上原則性的矛盾，敏捷的應用將給用 PMBOK® 管理的團隊帶來質的變化。但這並不等於 PMBOK® 中所有的東西都沒有用處了。 實際上， PMBOK® 中的大多數知識、概念和過程都很有用處，而且在敏捷中都被用到。所以規定要有 PMBOK® 規範的企業並非要否定一切才能過度到敏捷開發的模式。
從大量的前期計劃到階段性分批計劃
在 PMBOK® 中，項目開始前要在範圍、執行、成本等方面制定出詳細的計劃。在轉向敏捷的過程中，這些計劃並不是完全沒有了，而是被分散到各個短小的開發週期中了。例如， PMBOK® 要求項目開始前有儘可能詳細的需求，並制定正規的需求更改規範和過程。 而在敏捷開發中，項目開始前有的只是一個有關要開發的產品的高層次的遠景規劃，產品的功能需求是在開發過程中由用戶的反饋和開發團隊反饋一起來推動並逐步明確和細化的。正式的需求文檔變成了分散的產品的多個需求條目、功能或用戶使用案例等。至於需求變動規程，大多數敏捷方法都積極預期這種變化並把對變化的管理嵌入到每個週期甚至每天的開發過程中了。
還有一點經常被用來當作敏捷的不足。那就是敏捷開發不能在一開始給出項目的成本計劃。 所以看起來敏捷項目似乎無法進行成本的控制和管理，讓許多外包性的項目無法採用敏捷。 如果說要有一個大概準確的項目成本評估， PMBOK® 也無法做到。 PMBOK® 的做法是把所有的需求細化，然後把對每個最小單位的估計總和起來。這樣看似合理，但由於要對很久以後的開發作出估計，往往有很大的偏差。許多項目的失敗就起因於開始時的一個不實際的成本預算。敏捷項目中的成本預算和管理可以用由上而下的方法。項目開始前，由總體的規劃出發，把他交給整個團隊，討論評估出一個大概的範圍。 在每個週期開始前，團隊和用戶可以再對週期的成本進行比較準確的預估和管理，這時 PMBOK® 中的由下而上的方法就完全適用了。然後，在每個週期結束後都再次根據當時的狀況來調整對整個項目的成本估計。這樣的成本控制和管理往往更準確、實用。
在其他 PMBOK® 中涉及的對時間、質量、風險等的計劃和管理可以遵循同樣的原則轉化爲敏捷中的階段性計劃和管理來實施。
從由上至下命令式管理到面向團隊的服務式管理
管理方式的轉變是比較難的一方面。 這點在上面討論敏捷給企業帶來的變化時有所觸及 。 PMBOK® 中的項目管理風格是由上而下的計劃、分配、指定、跟蹤、評估和管理。在敏捷開發中，團隊要自我管理。計劃的制定，任務的分配，質量的管理，項目的執行等都由整個團隊協作進行。項目經理的職責是協調團隊完成這些自我管理任務，並幫助團隊排除遇到的障礙。項目經理要從命令式的管理思維轉換成服務式的思維和行爲。 用另一句話說就是，原來 PMBOK® 的項目經理是靠自己指揮一些人完成一項任務。而在敏捷中，項目經理可能更需要做的是建立一種機制使所有的人能在其中自我協調完成某種任務。而項目經理的日常職責是維護這種機制的正常運作和不斷改進。
從‘實用主義’走向敏捷
‘實用主義’經常被處於無序或半無序狀態的團隊拿來標識自己。這些團隊應該最容易走向敏捷。因爲如果真的是實用主義的話，敏捷最實用，自然應該是必由之路。這些團隊也並非都沒有實施任何有序的方法，他們的領導者或技術帶頭人會憑經驗或一定的自學掌握一些方法，然後他們會摸索着運用這些方法，有的甚至是在採用敏捷中的一些方法。這些團隊如果能和經驗豐富的顧問或其他運用敏捷比較成功的團隊交流，往往會認識到自己摸索的侷限性和離高層次敏捷開發的差距。這些差距往往不在於敏捷的形式，例如故事或需求條目牆，站立會議等，而是在於團隊的開發和應變的速度、效率和自我管理能力。一旦決定採用敏捷開發，由於這些‘實用主義’的團隊通常比較小而且沒有任何成型的包袱，他們沒有擺脫固有過程的障礙，可能會更容易地過度到敏捷開發。
尾聲
敏捷模式繼承和發展了以往的軟件工程理論和實踐，並熔入了人們對於軟件開發的新的理解和理念。我們相信敏捷是爲我國的軟件企業帶來效率、質量並促使開發團隊職業化，推動我們趕超世界軟件先鋒的一個很好的機會。我們在這篇文章中從團隊和項目管理兩方面簡單探討了企業和團隊如何走向敏捷的問題，希望能對大家有所幫助。