簡介

在9012年的今天，已經很少有人沒有聽過敏捷了。但敏捷真能解決這樣的問題麼？毫無疑問不太現實。畢竟中國式敏捷的笑話，也不是第一天出現在世人面前。許多公司都曾經實踐過敏捷，卻最終由於各種原因無法執行下去，水土不服是這些西方管理思想在國內最常見的問題。

而劉華老師也是在這樣的背景下編寫了這本書《獵豹行動·硝煙中的敏捷轉型之旅》，這本書的出版在敏捷社群掀起了一番波瀾。與其他介紹敏捷方法的書長篇闊論的介紹方法論不同，這本書以一個小說體的形式介紹了一個金融公司盛遠金融的敏捷轉型之旅，這一個個的小故事，既有受挫、又有成長，最終在這家企業中完成了轉型，實現了勞動生產力的解放和軟體研發實力的騰飛。

這家企業是如何做的？讓我們跟著作者的筆觸一步步走進這一幕幕吧。

角色介紹

作者引入了幾個角色，分別是來自諮詢公司的思域諮詢公司的諮詢顧問王章、曾經在某電商企業擔任過管理層的盛遠CTO思文、技術經理李俊、資深PMO關傑、專案總監張麗等主要角色。

• 王章：敏捷顧問，有豐富的敏捷實施經驗，對新思維、新方法狂熱。
• 思文：公司敏捷的推動者，執行能力強，面對困難從不抱怨。
• 李俊：IT部門經理，嚴謹、沉著，對新思維、新方法保持謹慎。
• 關傑：部門利益捍衛者，對敏捷保持懷疑態度。
• 張麗：敏銳、務實，思維嚴密。

李俊是一位經驗豐富的技術管理者，對專案管理擁有豐富的經驗。他總是善於製作嚴密的計劃，並能做到很好的把控。在過去的職業生涯中， 他在客戶和業務部門的口碑非常好，他一諾千金，總是能做到按時交付。但是在這背後，卻是壓榨得最為凶殘。團隊的流動性也非常大。他是一位瀑布模型的踐行者，雖然聽過敏捷的概念，但是卻認為敏捷是在為不做計劃和不寫文件找藉口。他認為專案成功的關鍵靠的是強大和嚴密的計劃能力、專案跟進能力和溝通能力，並努力實現客戶的承諾。在此之前，他也經歷過組織變革，但是這些變革往往雷聲大雨點小、要麼與實際嚴重不符，最終並沒有帶來什麼實際的好處。

而作為敏捷顧問的王章，作為盛遠金融敏捷轉型的實踐者，也充分得到了組織授權，感受到了思文對於敏捷的熱忱，渴望在這家公司創造一番事業。事實上敏捷很容易獲得基層的認可，不僅僅是因為敏捷不寫文件，而是敏捷倡導組織間的相互信任、自治以及通過技術手段例如自動化測試來取代繁文縟節的文件。他很快就根據公司的實際情況建立了具體的啟動方案，包括全面掃盲、體察民情、教育客戶的三大步驟，並獲得了思文的認可。

問題剖析

隨後，王章給全體IT同事進行了一次全面的培訓，從以下四個角度介紹了敏捷轉型的具體過程。

• 從傳統模式的問題（剖析瀑布模型的適應侷限以及給業務部門和IT部門帶來的痛點）、
• 轉向敏捷（什麼是敏捷？它與瀑布模型最大的區別在哪裡？具體方法和價值觀是怎樣的？）、
• 實施敏捷的好處（包括對業務部門和IT部門的好處）、
• 如何開始（具體的行動）

在培訓過程種，他也與大家一起總結了各部門的痛點，而在專案做的過程，根據業務部門的需求，雖然會給出估算和計劃，但是在專案開始時，卻只有預算和目標交付時間是確定的，很多因素都存在不確定性，包括：範圍和具體需求、可能的需求變更、人員不可控、估算的準確性、對現有系統的影響、環境搭建等。

這些正是瀑布式模型帶來的典型特點，事實上瀑布模型非常適合確定性非常高的專案，而這樣的專案幾乎是鳳毛麟角。面對軟體開發過程中的不確定性，需要採取措施管理和適應，真正實現“正確的做事”“做正確”的事。

隨後的培訓中，王章介紹了敏捷的價值觀和方法論，獲得了非常不錯的反饋，大家都對實踐敏捷的過程充滿了期待。

萬事開頭難

作為一家金融科技的公司，對資訊保安有著近乎潔癖的追求，因此工具的選型尤為重要，是選擇商業軟體，還是選擇開源軟體，往往都需要經歷一番波瀾。幾經周折之後，選擇了比較常用的敏捷管理工具，例如JIRA、Confluence、Github、Nexus、Jenkins、SonarQube、Ansible等工具。並建立了一套完整的DevOPS流程。

隨後開始挑選第一個實踐專案，【信鴿】。這是一個計劃工期為8個月的專案，但是由於公司專案的典型特點，需要由PMO進行需求調研和業務分析，等來到李俊的專案研發團隊手中，已經只剩下六個月的時間。而李俊這邊由於專案的特殊性，已經騰不出額外的資源，最終只能招聘到一位臨時軟體工程師，事實上這時已經只剩下不到五個月的時間。

但是這個專案依然沒辦法按照敏捷的流程拆分迭代週期，主要是由於專案的需求文件由許多個條目組成，每個條目就是一個功能，但是僅僅按照功能進行拆分，幾乎無法獨立開發、測試和上線交付事實上拆分出來的東西，單個部署都沒有業務價值。而且前期採用瀑布模型進行需求、設計而後面的開發、採用敏捷，最後的測試採用瀑布模型，顯然這樣的效益確實有限。

最終這個專案只能採用瀑布模型繼續開發。需求文件的完成和簽署花了三個月，然後在花一個月涉及外部文件，兩個月開發、一個月完成測試，一個月使用者驗收測試，然後上線，正好趕上8個月的時間。

然而現實是殘酷的，最終專案延期三個月結束。

越挫越勇

雖然經歷了一輪挫折，但是卻並未讓年輕的諮詢師就此放棄，他想起了曾經學習瞭解過的極限程式設計，同時又引入了kanban的精益軟體管理的工具，然後將其引入到專案中。然後讓李俊的專案團隊採用看板的來跟進新功能需求的研發和流程的日常優化。

而隨著日常流程優化這種常規功能的研發的逐漸開展，也讓團隊成員對於敏捷有了更深刻的認識，在新專案開發過程中，李俊的研發團隊將Scrum引入其中，完成了一次原本看起來不可拆分、不可妥協的功能開發，並獲得了公司高管的認可。

在後面的專案研發過程中，又經歷了幾次不同的挑戰，但是也讓敏捷的產品研發過程逐漸在公司生根發芽，逐漸發展狀態，最終成為公司的常態管理形式。

總結

成功的專案千篇一律，失敗的專案各有不同。

無論是網際網路公司還是傳統的軟體公司，為了創造獨特的產品、服務或成果而發起各種不同的形式的專案是行業的普遍選擇。

如果說專案的成功與否，取決於組織的管理形式本身，實際上也取決於專案經理對專案的掌控力。優秀的專案經理不僅具備的優秀的專業技能、行業知識和軟實力，讓他能夠靈活的駕馭各種不同型別的專案還能遊刃有餘，而普通型專案經理卻往往耗費了大量資源，最終還會讓專案陷入一座又一座的泥坑不可自拔。

對於軟體研發型專案經理來說，選擇合適的開發模型，似乎是首要考慮的問題。當然，毫無疑問，最為深入人心的專案開發流程，莫過於瀑布式模型。這是一種種增量式開發模式，歷經從計劃=》需求分析=》軟體設計=》軟體編碼=》軟體測試=》軟體部署=》軟體驗收的各個環節。各個環節間既相互依賴，又可能相互迭代。

一環套一環，很更容易就陷入死迴圈的怪圈。例如，我們很容易就想到瀑布模型存在的以下缺點：

1. 專案前期耗費大量的時間進行需求調研、編寫了一大堆寫完就過期的文件。
2. 軟體交付時，大量層出不窮的bug和需求變更。
3. 客戶對軟體更改和研發的腦力支出並不認同等。

我也經常聽到專案經理們的吐槽。尤其從醫療行業的專案經理那裡聽到了最多的吐槽。在過去若干年的發展過程中，醫療資訊化領域的發展特別快。但是由於醫療衛生行業涉及的領域太廣，所以讓標準化產品的研發過程變得非常困難，現在依然有許多醫院的資訊化系統都是以定製開發為主。而這些實施定製化開發軟體的公司，承受的巨大壓力常人難以想象。不同的院系、不同的醫生對需求的不同理解或者各種需求上的變化，總是讓開發者來回倒騰而無可自拔。上次就聽說長沙某大型HIS企業的技術總監，為了給客戶填坑，直接倒在了醫院的辦公室中，還好處理得當，不然還不知道會帶來什麼後果。

除了HIS領域外，製造業甲方爸爸也擅長給乙方掘墓。他們的技能是甩鍋。由於流程眾多、涉及的人數廣，所以要確認需求是一件非常困難的事情。這種情況下，除了絞盡腦汁應付其中，根本沒有更好的辦法。關鍵是他們中許多人還被免費軟體的迷魂藥給迷暈了頭腦，總是認為軟體開發不過是簡單的碼格子，肆意的擴大需求範圍、更改需求，開發出大量華而不實的功能，讓程式設計師們費力不討好。

這些專案也是採用瀑布式開發模型的典型，試圖通過前期嚴密的需求調研、功能設計和驗收流程讓客戶儘可能少的變更需求，實際上卻很難真正做到完全可控。所以專案很難避免不延遲，最終給公司帶來了不小的負擔。

在這樣的背景之下，似乎敏捷是一縷曙光。

但究竟該怎麼實施。這本書給出了一點參考。