敏捷改造（下）：真實案例敏捷改造

上篇分析了我作過的一個真實的項目的研發過程當中的種種問題，那麼這篇就來說解一下咱們如何針對這些問題作敏捷改造。

怎樣用敏捷作改進

小瀑布模式的缺點在於它的溝通成本、等待成本、返工成本依然很高，所以咱們能夠考慮從這3個角度出發去作改進。

我畫了一個圖來展現小瀑布模式和敏捷開發的詳細對比。

圖中紫色管道是小瀑布模式，藍色管道是敏捷開發，兩個管道是相同的團隊管道容量，換句話說，兩種模式的工做載量是相等的。

橫向是時間線，從左到右，按需求提出開始直到此需求上線，即爲此需求的生命週期。

首先，先說一下爲何這3個成本很高。

溝通成本

產品經理一般須要1-2小時來與業務方進行需求溝通，溝通完了以後，產品經理會有一個初步方案，而後會與團隊內部的技術人員，測試人員等，一塊兒評審這個需求，若是這中間有任何疑問，產品經理就須要不停的反覆在業務方與技術人員中間進行溝通。所以溝通成本是比較高的。

產品經理一般也須要1-2小時來與技術人員一塊兒作技術評審，時間比較長，不少問題細節須要來回反覆確認，溝通成本很高。

總結一下就是，因爲需求粒度比較大，每一個環節都比較重，有大量的細節須要討論和確認，所以帶來了較高的溝通成本。

等待成本

開發只有等產品文檔徹底設計好了，才能開始開發，因爲需求粒度過大，此設計過程相對過長，所以開發的等待時間也長，沒有充分利用開發資源。

同理，測試也是，只有等開發提測了才能作測試。但測試在此以前，會先寫測試用例，所以測試資源浪費還算較小。

但另一個問題是，測試一次性要寫很是多的用例測試，一次性測那麼多用例，測試的完整性徹底依賴於測試人員的耐心。

返工成本

測試若是發現問題，會讓開發返工，因爲需求粒度比較大，常常出現測試發現多個問題的狀況，那麼就會來回的屢次返工與測試。

甚至有時候返工會直接返到業務方去從新確認需求的細節。

---

敏捷研發過程改進

那麼敏捷是如何改進這個過程的呢？

首先敏捷是提倡小步快跑，擁抱變化。目前因爲需求粒度比較大，沒法小步快跑，同時開發到中間的時候的，需求忽然變化，應對起來也比較慢。

那咱們就能夠根據下圖來進行改造。

上圖中最大的變化就是把原來的需求A拆解成了3個story。

敏捷提倡小步快跑，那麼管理需求也同樣，只有需求足夠小，才更利於咱們快速理解和分析。而user story（用戶故事）則是敏捷裏面的一個能夠工做的最小單位。

用戶故事在軟件開發過程當中被做爲描述需求的一種表達形式；爲了規範用戶故事的表達，便於溝通；包含角色、活動、價值三個要素。

瀑布式的需求管理和敏捷需求管理的區別在於：

• 瀑布式的需求分析要求在一開始就獲取全部需求，分析全部細節，而且假設咱們能夠對軟件項目有個完美的預測。
• 而用戶故事則基於咱們不能完美預測，不能在一開始就知道全部細節的基礎。由於咱們對需求的理解是一個逐漸清晰的過程。同時，在項目開始時嘗試編寫全部的需求忽略了重要的反饋循環。用戶故事認可故事的時間維度，隨着時間的推移以及功能的增長，會有新的用戶故事產生，或者使故事的相關性發生變化。因此要延遲細節，融入業務到整個軟件開發過程當中，鼓勵交流和溝通。
• 另外，作了用戶故事拆分以後，產品經理或者BA須要補全細節，不停的作需求澄清，和業務方作sign off。
• 敏捷需求管理會藉助JIRA等工具進行可視化的看板或者scrum管理。而不是基於傳統的Excel管理。
• 每一個故事寫好以後，會讓業務方作card sign off，好比在卡下面留言ready to go等。若是每張卡作sign off太頻繁，能夠由產品經理或BA單獨找業務方用郵件等的形式針對一個epic統一作sign off。
• 敏捷裏其實沒有一個專門給業務方和產品經理/BA的需求澄清會，由於默認爲已經發生在平常工做中了，按理說應該分析一張卡確認一張卡，才能儘量減小因一張卡片理解不到位引發的大面積返工。

拆解成小的用戶故事以後有以下一些好處：

1. 原來產品經理和業務方的溝通成本隨着需求被拆成小的用戶故事而變小了。
2. 因爲用戶故事比較小，分析完成的時間就變快了，產品設計的時間也變快了，那麼開發開始的時間也就變快了，減小了等待成本。
3. 因爲開發時間更短，第一個用戶故事測試時間也就提早了，所以若是出現問題須要返工，那麼返工的時間比原來就更早，返工修改的內容也更少，能較快的完成返工並從新測試。總體返工成本就變小了。
4. 因爲各方時間都提早了，那麼第一個用戶故事上線的時間也提早了，業務方就能更早的看到需求的部分功能，就能更早的反饋問題。
5. 因爲每一個環節的溝通成本，等待成本，返工成本均減小了，所以整個需求的交付時間也就提早了。

從下圖就能夠看出，每一個環節相比以前都是提早的。敏捷的目的是可以讓團隊擁抱變化，快速響應。

敏捷開發改進

分支改進

原來的分支管理比較混亂，可能形成的問題已經在前面分析過了。

這裏就說說分支管理的最佳實踐是什麼。

1. 如今業界廣泛都採用了git flow，具體怎麼作能夠Google一下，網上有太多文章講這個，我就不贅述了。這裏就展現一張git flow的全景圖。
   

2. 每次git的commit message的推薦格式：Card ID: message

   1. Type主要有：feature, refactor, fix等。
   2. 每次git的commit推薦能關聯到每一個故事卡的卡號，這樣方便追溯每一個故事卡相關的改動。如今不少工具都支持經過message的卡號直接找到對應的故事卡，反之亦然。

CI/CD

• 從代碼的生命週期開始，CI/CD是保證每一個環節快速流轉的基礎，同時也是快速獲取反饋的途徑。
• 而CI的基礎則是自動化測試，好比最基本的單元測試。

• 每完成一張故事卡，理論上均可以持續部署到生產環境。而不該該等待全部需求都完成了，或者等先後端都完成了，再作上線部署。

  • 部署的步子越小，回滾的成本也就越低。

總結

圖裏的敏捷開發必定比上面的小瀑布快嗎？不必定，這裏還有幾個因素是須要考慮的。

1. 需求A拆解成story是有成本的。根據產品經理或BA的能力不一樣，以及需求複雜度的不一樣，拆卡花的時間也不一樣。
2. 小瀑布模式裏面，在沒有bug的狀況下只會測試一次。在敏捷模式下，相比原來的小瀑布，會針對story1和story2作迴歸測試。所以增長了測試時間。
3. 另外，決定敏捷開發可否運行很好的因素還有不少，只有不斷探尋最佳實踐，持續改進，才能無限逼近咱們指望的狀態。

總結起來，敏捷是經過小步快跑的方式，提高了響應變化的速度，以達到提高總體交付速度與質量的目的。

本文只是經過一個真實的客戶案例，來分析如何基於當前現狀作敏捷改造，本文並無寫徹底部敏捷改造的內容，由於敏捷包含的內容實在太多了，若是你們感興趣能夠給我留言，後面我會繼續分享這個案例中涉及到的其餘敏捷改造。