敏捷實施經驗貼——關於敏捷路上那些大大小小的「坑」

6 人贊了文章

摘要：敏捷轉型並沒有那麼簡單，不是把那一套運作模式運作起來就可以，畢竟每個公司的情況都有所差異，僅僅把敏捷那一套運作模式照搬過來是遠遠不夠的。對於管理者來說，希望通過敏捷提升軟體交付的效率和質量，並且希望通過敏捷轉型打造一個高效、學習型的團隊。其實，敏捷是一個很強大的工具，運用的好確實可以收到很好的管理和交付效果；但是運用的不好，很可能就會事倍功半。本文將總結在過去的一段時間裡，我們自身在敏捷轉型過程中踩過的坑，希望對大家在做敏捷轉型或者實施的有一定借鑒意義和幫助。

隨著互聯網、大數據的發展和成熟，包括新零售等概念的提出、探索和落地，越來越多的企業開始進行敏捷轉型，在軟體開發過程中採用敏捷的方式，期望可以提升開發效率，改善交付質量。敏捷也不再局限於互聯網行業，很多傳統行業——包括銀行、保險、電信、零售等等也逐漸開始認同敏捷的開發方式和流程，在企業內部的系統開發過程中把敏捷與原有的流程相互融合，以更好地適應高速、快節奏所帶來的不確定性，進一步提升IT部門和系統更好地服務企業戰略目的和滿足市場需求的能力。

對於管理者來說，希望通過敏捷提升軟體交付的效率和質量，並且希望通過敏捷轉型打造一個高效、學習型的團隊。其實，敏捷是一個很強大的工具，運用的好確實可以收到很好的管理和交付效果；但是運用的不好，很可能就會事倍功半。

本文將總結在過去的一段時間裡，我們在轉型過程中踩過的坑，以作前車之鑒。也聊聊在轉型過程中，哪些優秀的實踐可以嘗試，走上漸進變革的道路。

1. 敏捷是不是可以縮短項目周期，或者說「敏捷就是快」？

在接觸敏捷之前，大家對敏捷都是一知半解，更多的停留在字面意思的理解上：「敏捷就是快」。一旦有人覺得不快時，就會發出質疑：我們的敏捷做對了嗎？

其實，敏捷並不意味著「快」，「敏捷」在百度字典中的解釋是「反應迅速快捷」。在軟體開發中，敏捷是使用各種管理的手段（例如，3個角色，5個事件）來確保軟體開發人員能夠對於外部或者內部的需求或者變化能夠迅速的做出反應，保證軟體系統的功能或者其他特性能夠滿足市場或者用戶的要求。

敏捷模型和瀑布式開發模型是對立的，瀑布式開發模型主要是「按部就班」的進行需求調研、系統設計、詳細設計、功能開發、測試、上線，以及運維等，我相信大家對於瀑布式開發模型非常熟悉，現在大部分的甲方IT部門或者乙方公司都採用這樣的交付管理手段。同樣，大家和我也有相同的感觸，系統的需求可能不斷地在變化，或者是調研不清楚，亦或設計不能夠滿足用戶需求，沒有別的選擇，只能硬著頭皮加班加點修改，呵呵，這也是程序員經常吐槽的地方…本質上，瀑布式的開發模型是「非常害怕變化的」，一旦有「任何的風吹草動」整個項目組都緊繃神經，進而通宵達旦；而敏捷模型則是「擁抱變化的」，敏捷拒絕「一成不變」，崇尚軟體系統功能「持續增強」，它是把整個軟體交付周期「拆」成一個一個小的瀑布模型，每個瀑布模型持續一周或者兩周，我們把它稱作「衝刺」，在每一個衝刺中都要進行需求的討論和確認，都要對交付的成果進行評審，並且項目組還要進行自身的反思和回顧，這樣即使變化來了，我們通過敏捷模型能夠「輕鬆的應對」。

有一個例子，共享單車剛剛起步的時候，市場上共享單車的公司不多，共享單車的創新是通過互聯網和手機支付的手段，幫助和方便用戶完成 「最後一公里」的交通出行。起初共享單車業務邏輯是一輛自行車的成本大約200元人民幣，設計壽命是3年，用戶騎行一次大約需要支付1塊錢，一輛自行車一年差不多可以收回200元的成本，第二年和第三年就可以實現盈利。但是，沒有想到不到半年時間，其他的共享單車如雨後春筍般的出現，而且價格更低，並且有各種優惠活動。第一個吃螃蟹的共享單車企業原來的商業模式已經失效，但是他們發現他們有一個很大押金池子，如何有效的利用這筆資金成了他們「最後的救命蒿草」，他們的軟體系統功能如何支撐「有效的利用這筆資金」成為了他們迫在眉睫要解決的問題。如果採用瀑布式的開發模型，按部就班，「3個月或者半年之後交付」，可能市場又不知道發生了什麼變化。而敏捷的模型則可以在一定程度上很好的應對這樣的突發情況。

總之，敏捷的核心是快速地應對變化，本質上，它並不能縮短軟體交付的周期。有時候我們感覺「敏捷快」是因為它能夠快速的響應市場或者用戶的需求變化，而不是以前瀑布模型中，用戶和項目組都為「這個功能是這個樣子的，而不是現在開發成的這個樣子」而相互的扯皮，推諉…

當然，我們在瀑布模型中也會主動或者被動地使用到「敏捷」，用戶提出需求變更，今天晚上或者明天就可以看到結果。

2. 之前的項目管理一般先出文檔，跟著文檔來開發，現在實施敏捷之後，大家主要是以溝通為主，有些需求不是一定要有文檔才能開發，可以說在開發過程中有些需求通過溝通取代了文檔。是不是敏捷就不需要文檔了？

在敏捷宣言中四個核心價值觀：

• 個體和互動 高於 流程和工具
• 工作的軟體 高於 詳盡的文檔
• 客戶合作 高於 合同談判
• 響應變化 高於 遵循計劃

其中，「工作的軟體 高於 詳盡的文檔」，對於這句話的解讀，以及根據實踐獲得的經驗，並不是實施了敏捷之後，就不需要文檔，俗話說「好記性不如爛筆頭」，有很多的文檔，還是必須要做的，例如功能設計文檔，DDD設計文檔，UI設計文檔等。從敏捷的思路來說，只是認為相互溝通的效果會比文檔去理解的效果要好，所以大部分的東西主張以溝通為主，文字為輔，如果溝通可以解決，那麼文檔如果沒有什麼附加價值就不寫，但是如果它還是很有價值的，比方說功能設計，是以後需要看的，那就要寫，所以做與不做看價值。

有價值的我們做，沒價值的不做，舉個例子，某銀行去做敏捷轉型之前，非常重視文檔，每個文檔都要思考很久才提交，他們一個項目的立項到結項要寫55份文檔，實施敏捷之後，從內部把文檔裁剪到17個，從55到17個，而不是從55到0。那保留些什麼，不保留什麼，要看這些文檔是怎麼用的，有沒有價值。

所以我們要自己判斷一下要的是什麼，不要的是什麼。總的來說，你用了敏捷之後不是沒有文檔，而是把沒有價值的文檔刪掉。

根據我們的經驗，文檔的更新也是一個敏捷和持續的過程，例如UI設計文檔，我們會不斷地與用戶或者利益相關者溝通UI界面，每個衝刺都要溝通碰撞，直到某一個功能的設計滿足美觀、易用的要求。在這過程中，我們的UI設計師會根據反饋設計出不同的版本，甚至前端工程師要先實現這些UI設計，根據實踐的效果不斷地調整，直到項目組滿意，再跟用戶溝通，如果用戶不滿意，我們回來繼續修改，就這樣不斷的「反反覆復」，持續地更新。

3.敏捷倡導以溝通來代替文檔，但是團隊不是一成不變的，有成員走有成員進，這時候我們如何要做好經驗的傳遞？

新人來直接看文檔就可以很快了解融入到團隊裡面是很難的，大部分的敏捷團隊是通過溝通融入進去的。

比如：已經寫好了一個文檔，已經進行開發，突然間需求變更過來了，大部分的時候，需求突然變更，是不會先改文檔再開發的，結果導致文檔跟開發的情況不一致，新人看完文檔後還是要再去理解代碼，所以我們假設只要文檔寫好，後邊的交接理解沒有問題，新人都能理解文檔里的內容，是不對的。

團隊人員的流動不會全部流動，可能是十個裡面兩三個的概率，團隊的其他人和新人溝通交流就好，如果有些比較重要的系統設計等，那就把系統設計重要的幾頁寫下來，比方說介面，如何調度等很緊要的東西寫下來，不需要面面俱到。開發結束寫文檔，也不需要擔心新人無法融入。

如果真的覺得我們缺少了某些文檔，應該在團隊里說明，我們的開發過程應該做那份文檔，比方說比較完整的測試用例，完整的需求場景描述等這些文檔。

還有一個做法，這個我們在新老交替經常使用，就是結對編程。我們會安排「師傅」帶著新人，一起做一段時間，在這段時間，「師傅」會將我們這邊的基本情況，系統架構，功能，技術棧，規範等教給新人。並且會分配給他一些編程的工作，這樣持續1-2周左右，新人基本上能夠融入到現有的團隊。

總之，通過純文檔的形式做新人的培訓是很難的，應該採用溝通 + 文檔的方式。

4.敏捷過程中還是存在傳統項目中項目經理這個角色？

如果用的是scrum模型，是沒有定義項目經理這個角色，這個職責被PO和scrum master分攤掉，如果不是用scrum的模式，比如用看板模型，就沒有說不要項目經理，而是繼續引用現有角色。從廣義的角度來說，敏捷中「沒有項目經理」這句話不是完全正確的，但如果你用敏捷scrum模型，確實沒有定義這個角色，但只是敏捷scrum模型而已，敏捷還有n多模型，項目經理的角色剔除或者不剔除要看我們使用的敏捷模型是什麼。

根據我們的經驗，Scrum模型中可以沒有項目經理，這個職責被PO和scrum master分攤掉。PO主要對產品負責，他以產品為引導驅動整個開發Team，類似「連長」「排長」的角色；而Scrum Master則是對整個軟體生產經營活動中的「規章制度」「流程」等負責，類似「政治委員」的角色。但是 ，我們在實際的操作過程中，還需要另外一個角色「技術負責人」，雖然說Scrum模型中定義的開發團隊，應該是一個自組織、跨職能的團隊，但是對於產品的架構、系統設計、開發規範等，都需要一個有經驗的技術牽頭完成，包括代碼質量保證等，我們嘗試過沒有這樣的一個人（說起來都是淚），最後前後端代碼的質量非常差，而且後端出現了嚴重的性能問題，原因就是沒有一個相對來說有一定技術權威的人，來配合項目組管理整個技術設計和規範。敏捷的轉型本質上是要為每一個人賦能，但是實際情況是，項目組內部的人員能力、經驗等會出現參差不齊的情況，如果是按照Scrum模型教科書式地推進，大家認為開發團隊是一個「自組織、跨職能」的團隊，讓他們「完全自我管理」，那麼就特別容易失敗。所以，不管是使用哪一個模型都是需要根據實際的情況來操作，而不是完全教科書式的轉型，但是剛開始的時候總是有一個摸索期。

5. 多組之間依賴性強，敏捷小組之間的協調，有一些團隊是依賴於某一個團隊的，這個團隊自己的任務和故事還沒進行下去的時候，可能就要幫其他團隊的任務，就阻塞自身的敏捷進行，團隊之間的協作應該怎麼更好去處理？

對於跨組協調，有很多模型可以使用，比如scrum的標配scrum scrum模型，scrum scrum模型能在跨組上面進行定期的溝通，以便溝通之後能儘快解決團隊之間存在的問題，如果沒有這樣的機制，進行定時的溝通；請人吃飯，搞好關係也是可以的，呵呵…

有跨組機制只是多一個方法和工具，無論你用新模型還是舊模型，跨組中肯定會存在協調問題。用了敏捷模型後，會給你一個溝通渠道，比如定時的會議，跟其他團隊去協同溝通。在選擇跨團隊協作機制的時候，簡單夠好用就可以，不用太複雜。

6.與傳統的項目管理方式對比，客戶方習慣了將開發拆分到任務層面並指定deadline，而且傳統的項目往往瀑布式比較多，會有大量的文檔，當以用戶故事的方式驅動開發，客戶方業務只能看到用戶故事，看不到具體內容，心中沒底，總是存在質疑。這樣的情況，我們應該如何和客戶進行溝通交流？

首先，我們要看當客戶是不是很了解，敏捷方法的推行是客戶方提出，還是我們推薦的。如果是客戶提出的，必然會按照這個方法去做，如果是我們主張，我們團隊有能力完成這樣的交付，我們就要給客戶解釋，消除客戶的質疑。

我們可以把以前的工作方法寫一個flow給他，新的方法也寫一個flow給他，進行一個簡單演示，之前的flow，從需求到PRD，PRD到設計的一系列流程，以前的flow流程，和新的flow進行對比，敏捷化之後我們都會有與之對應或者替代的環節，比如計劃會對應需求到PRD這一過程，可能以前的flow你會看到PRD，現在敏捷化之後被用戶故事替代，其他也是一樣，你雖然看不到之前的，但是依然可以從某個方面獲取到進度以及其它方面需要的信息。

總體來說，遇到這種情況，我們自身先學一點這方面的能力，實施的技術人員和業務人員如果沒有完成敏捷相關培訓和教育，敏捷推行的時候，我們要幫助客戶簡單了解敏捷的意義，推行敏捷能夠帶來什麼樣的好處，但是歸根到底我們是做交付的，未必能給出一個很好的解釋。要讓客戶知道我們之間少了一方溝通交流的人來解釋敏捷實施過程遇到的問題，關於敏捷的教育培訓，客戶方自身那邊安排一下會更好。

總的來說，敏捷轉型不是一蹴而就的，而是一個持續的過程，在這過程中會有各種各樣的問題出現，而且不同的公司，不同的文化，遇到的問題也不盡相同。遇到問題很正常，我們只要「咬定青山不放鬆」，在問題當中不斷的解決問題，就一定能夠發揮敏捷真正的威力，不斷提升軟體交付的效率和質量。