簡介程序員
在9012年的今天，已經不多有人沒有聽過敏捷了。但敏捷真能解決這樣的問題麼？毫無疑問不太現實。畢竟中國式敏捷的笑話，也不是第一天出如今世人面前。許多公司都曾經實踐過敏捷，卻最終因爲各類緣由沒法執行下去，水土不服是這些西方管理思想在國內最多見的問題。 編程
而劉華老師也是在這樣的背景下編寫了這本書《獵豹行動·硝煙中的敏捷轉型之旅》，這本書的出版在敏捷社區掀起了一番波瀾。與其餘介紹敏捷方法的書長篇闊論的介紹方法論不一樣，這本書以一個小說體的形式介紹了一個金融公司盛遠金融的敏捷轉型之旅，這一個個的小故事，既有受挫、又有成長，最終在這家企業中完成了轉型，實現了勞動生產力的解放和軟件研發實力的騰飛。安全
這家企業是如何作的？讓咱們跟着做者的筆觸一步步走進這一幕幕吧。工具
角色介紹學習
做者引入了幾個角色，分別是來自諮詢公司的思域諮詢公司的諮詢顧問王章、曾經在某電商企業擔任過管理層的盛遠CTO思文、技術經理李俊、資深PMO關傑、項目總監張麗等主要角色。測試
- 王章：敏捷顧問，有豐富的敏捷實施經驗，對新思惟、新方法狂熱。
- 思文：公司敏捷的推進者，執行能力強，面對困難從不抱怨。
- 李俊：IT部門經理，嚴謹、沉着，對新思惟、新方法保持謹慎。
- 關傑：部門利益捍衛者，對敏捷保持懷疑態度。
- 張麗：敏銳、務實，思惟嚴密。
李俊是一位經驗豐富的技術管理者，對項目管理擁有豐富的經驗。他老是善於製做嚴密的計劃，並能作到很好的把控。在過去的職業生涯中， 他在客戶和業務部門的口碑很是好，他一言既出;駟馬難追，老是能作到按時交付。可是在這背後，倒是壓榨得最爲兇殘。團隊的流動性也很是大。他是一位瀑布模型的踐行者，雖然聽過敏捷的概念，可是卻認爲敏捷是在爲不作計劃和不寫文檔找藉口。他認爲項目成功的關鍵靠的是強大和嚴密的計劃能力、項目跟進能力和溝通能力，並努力實現客戶的承諾。在此以前，他也經歷過組織變革，可是這些變革每每雷聲大雨點小、要麼與實際嚴重不符，最終並無帶來什麼實際的好處。優化
而做爲敏捷顧問的王章，做爲盛遠金融敏捷轉型的實踐者，也充分獲得了組織受權，感覺到了思文對於敏捷的熱忱，渴望在這家公司創造一番事業。事實上敏捷很容易得到基層的承認，不只僅是由於敏捷不寫文檔，而是敏捷倡導組織間的相互信任、自治以及經過技術手段例如自動化測試來取代繁文縟節的文檔。他很快就根據公司的實際狀況創建了具體的啓動方案，包括全面掃盲、體察民情、教育客戶的三大步驟，並得到了思文的承認。編碼
問題剖析spa
隨後，王章給全體IT同事進行了一次全面的培訓，從如下四個角度介紹了敏捷轉型的具體過程。設計
- 從傳統模式的問題（剖析瀑布模型的適應侷限以及給業務部門和IT部門帶來的痛點）、
- 轉向敏捷（什麼是敏捷？它與瀑布模型最大的區別在哪裏？具體方法和價值觀是怎樣的？）、
- 實施敏捷的好處（包括對業務部門和IT部門的好處）、
- 如何開始（具體的行動）
在培訓過程種，他也與你們一塊兒總結了各部門的痛點，而在項目作的過程，根據業務部門的需求，雖然會給出估算和計劃，可是在項目開始時，卻只有預算和目標交付時間是肯定的，不少因素都存在不肯定性，包括：範圍和具體需求、可能的需求變動、人員不可控、估算的準確性、對現有系統的影響、環境搭建等。
這些正是瀑布式模型帶來的典型特色，事實上瀑布模型很是適合肯定性很是高的項目，而這樣的項目幾乎是百裏挑一。面對軟件開發過程當中的不肯定性，須要採起措施管理和適應，真正實現「正確的作事」「作正確」的事。
隨後的培訓中，王章介紹了敏捷的價值觀和方法論，得到了很是不錯的反饋，你們都對實踐敏捷的過程充滿了期待。
萬事開頭難
做爲一家金融科技的公司，對信息安全有着近乎潔癖的追求，所以工具的選型尤其重要，是選擇商業軟件，仍是選擇開源軟件，每每都須要經歷一番波瀾。幾經周折以後，選擇了比較經常使用的敏捷管理工具，例如JIRA、Confluence、Github、Nexus、Jenkins、SonarQube、Ansible等工具。並創建了一套完整的DevOPS流程。
隨後開始挑選第一個實踐項目，【信鴿】。這是一個計劃工期爲8個月的項目，可是因爲公司項目的典型特色，須要由PMO進行需求調研和業務分析，等來到李俊的項目研發團隊手中，已經只剩下六個月的時間。而李俊這邊因爲項目的特殊性，已經騰不出額外的資源，最終只能招聘到一位臨時軟件工程師，事實上這時已經只剩下不到五個月的時間。
可是這個項目依然沒辦法按照敏捷的流程拆分迭代週期，主要是因爲項目的需求文檔由許多個條目組成，每一個條目就是一個功能，可是僅僅按照功能進行拆分，幾乎沒法獨立開發、測試和上線交付事實上拆分出來的東西，單個部署都沒有業務價值。並且前期採用瀑布模型進行需求、設計然後面的開發、採用敏捷，最後的測試採用瀑布模型，顯然這樣的效益確實有限。
最終這個項目只能採用瀑布模型繼續開發。需求文檔的完成和簽署花了三個月，而後在花一個月涉及外部文檔，兩個月開發、一個月完成測試，一個月用戶驗收測試，而後上線，正好遇上8個月的時間。
然而現實是殘酷的，最終項目延期三個月結束。
越挫越勇
雖然經歷了一輪挫折，可是卻並未讓年輕的諮詢師就此放棄，他想起了曾經學習瞭解過的極限編程，同時又引入了kanban的精益軟件管理的工具，而後將其引入到項目中。而後讓李俊的項目團隊採用看板的來跟進新功能需求的研發和流程的平常優化。
而隨着平常流程優化這種常規功能的研發的逐漸開展，也讓團隊成員對於敏捷有了更深入的認識，在新項目開發過程當中，李俊的研發團隊將Scrum引入其中，完成了一次本來看起來不可拆分、不可妥協的功能開發，並得到了公司高管的承認。
在後面的項目研發過程當中，又經歷了幾回不一樣的挑戰，可是也讓敏捷的產品研發過程逐漸在公司生根發芽，逐漸發展狀態，最終成爲公司的常態管理形式。
總結
成功的項目千篇一概，失敗的項目各有不一樣。
不管是互聯網公司仍是傳統的軟件公司，爲了創造獨特的產品、服務或成果而發起各類不一樣的形式的項目是行業的廣泛選擇。
若是說項目的成功與否，取決於組織的管理形式自己，實際上也取決於項目經理對項目的掌控力。優秀的項目經理不只具有的優秀的專業技能、行業知識和軟實力，讓他可以靈活的駕馭各類不一樣類型的項目還能遊刃有餘，而普通型項目經理卻每每耗費了大量資源，最終還會讓項目陷入一座又一座的泥坑不可自拔。
對於軟件研發型項目經理來講，選擇合適的開發模型，彷佛是首要考慮的問題。固然，毫無疑問，最爲深刻人心的項目開發流程，莫過於瀑布式模型。這是一種種增量式開發模式，歷經從計劃=》需求分析=》軟件設計=》軟件編碼=》軟件測試=》軟件部署=》軟件驗收的各個環節。各個環節間既相互依賴，又可能相互迭代。
一環套一環，很更容易就陷入死循環的怪圈。例如，咱們很容易就想到瀑布模型存在的如下缺點：
- 項目前期耗費大量的時間進行需求調研、編寫了一大堆寫完就過時的文檔。
- 軟件交付時，大量層出不窮的bug和需求變動。
- 客戶對軟件更改和研發的腦力支出並不認同等。
我也常常聽到項目經理們的吐槽。尤爲從醫療行業的項目經理那裏聽到了最多的吐槽。在過去若干年的發展過程當中，醫療信息化領域的發展特別快。可是因爲醫療衛生行業涉及的領域太廣，因此讓標準化產品的研發過程變得很是困難，如今依然有許多醫院的信息化系統都是以定製開發爲主。而這些實施定製化開發軟件的公司，承受的巨大壓力常人不可思議。不一樣的院系、不一樣的醫生對需求的不一樣理解或者各類需求上的變化，老是讓開發者來回倒騰而無可自拔。上次就據說長沙某大型HIS企業的技術總監，爲了給客戶填坑，直接倒在了醫院的辦公室中，還好處理得當，否則還不知道會帶來什麼後果。
除了HIS領域外，製造業甲方爸爸也擅長給乙方掘墓。他們的技能是甩鍋。因爲流程衆多、涉及的人數廣，因此要確認需求是一件很是困難的事情。這種狀況下，除了絞盡腦汁應付其中，根本沒有更好的辦法。關鍵是他們中許多人還被免費軟件的迷魂藥給迷暈了頭腦，老是認爲軟件開發不過是簡單的碼格子，肆意的擴大需求範圍、更改需求，開發出大量華而不實的功能，讓程序員們費力不討好。
這些項目也是採用瀑布式開發模型的典型，試圖經過前期嚴密的需求調研、功能設計和驗收流程讓客戶儘量少的變動需求，實際上卻很難真正作到徹底可控。因此項目很難避免不延遲，最終給公司帶來了不小的負擔。
在這樣的背景之下，彷佛敏捷是一縷曙光。
但究竟該怎麼實施。這本書給出了一點參考。
---
本文版權歸原做者和博客園共同擁有。做品採用知識共享署名-非商業性使用-相同方式共享4.0 國際許可協議進行許可。
本文來自： 溪源 | 長沙.NET技術社區。閱讀更多精彩好文，歡迎關注長沙.NET技術社區公衆號【DotNET技術圈】。
