簡介

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

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

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

角色介紹

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

• 王章：敏捷顧問，有豐富的敏捷實施經(jīng)驗，對新思維、新方法狂熱。
• 思文：公司敏捷的推動者，執(zhí)行能力強，面對困難從不抱怨。
• 李俊：IT部門經(jīng)理，嚴(yán)謹(jǐn)、沉著，對新思維、新方法保持謹(jǐn)慎。
• 關(guān)杰：部門利益捍衛(wèi)者，對敏捷保持懷疑態(tài)度。
• 張麗：敏銳、務(wù)實，思維嚴(yán)密。

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

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

問題剖析

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

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

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

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

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

萬事開頭難

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

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

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

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

然而現(xiàn)實是殘酷的，最終項目延期三個月結(jié)束。

越挫越勇

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

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

在后面的項目研發(fā)過程中，又經(jīng)歷了幾次不同的挑戰(zhàn)，但是也讓敏捷的產(chǎn)品研發(fā)過程逐漸在公司生根發(fā)芽，逐漸發(fā)展?fàn)顟B(tài)，最終成為公司的常態(tài)管理形式。

?

總結(jié)

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

無論是互聯(lián)網(wǎng)公司還是傳統(tǒng)的軟件公司，為了創(chuàng)造獨特的產(chǎn)品、服務(wù)或成果而發(fā)起各種不同的形式的項目是行業(yè)的普遍選擇。

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

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

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

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

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

客戶對軟件更改和研發(fā)的腦力支出并不認(rèn)同等。

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

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

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

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

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

?

---

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

?

? ? ??本文來自： 溪源 | 長沙.NET技術(shù)社區(qū)。精彩好文，歡迎關(guān)注長沙.NET技術(shù)社區(qū)公眾號【DotNET技術(shù)圈】。

轉(zhuǎn)載于:https://www.cnblogs.com/xiyuanMore/p/11610112.html

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。