簡介

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

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

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

角色介紹

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

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

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

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

問題剖析

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

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

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

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

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

萬事開頭難

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

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

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

最終這個項目只能采用瀑布模型繼續開發。需求文檔的完成和簽署花了三個月，然后在花一個月涉及外部文檔，兩個月開發、一個月完成測試，一個月用戶驗收測試，然后上線，正好趕上8個月的時間。

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

越挫越勇

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

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

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

?

總結

成功的項目千篇一律，失敗的項目各有不同。

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

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

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

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

項目前期耗費大量的時間進行需求調研、編寫了一大堆寫完就過期的文檔。

軟件交付時，大量層出不窮的bug和需求變更。

客戶對軟件更改和研發的腦力支出并不認同等。

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

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

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

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

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

?

---

本文版權歸原作者和博客園共同擁有。作品采用知識共享署名-非商業性使用-相同方式共享4.0 國際許可協議進行許可。?

?

? ? ??本文來自： 溪源 | 長沙.NET技術社區。精彩好文，歡迎關注長沙.NET技術社區公眾號【DotNET技術圈】。

轉載于:https://www.cnblogs.com/xiyuanMore/p/11610112.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的敏捷转型该怎么转？来看看这本书怎么说的吧的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。