敏捷改造（上）：真實案例研發過程分析

背景

最近我去一家科技公司作敏捷諮詢，經過梳理該公司的研發過程，發現了該公司的研發過程當中許多能夠改進的地方，因而我便記錄下來，與你們分享學習。

本文會剖析該公司的研發過程，把每一個環節詳細分析一遍，以找出研發過程當中的問題和能夠改進的地方。而後再講解如何作敏捷改造。

研發過程分析

全景圖

下圖是該公司的研發全景圖，從時間線來看，上面一條時間線能夠看出整個需求流轉的生命週期，下面一條時間線能夠看出整個代碼流轉的生命週期。

下面咱們就把每一個環節拆開來仔細分析一下。

需求管理

現狀

如今是經過共享Excel來管理全部的需求，業務方在表格裏面填寫想要的需求，包括新需求或bug等，併爲每一個需求生成一個序號方便追蹤。

大概長下圖的樣子。這是很是典型的傳統需求管理方式。

問題

1. 大顆粒的需求能夠這樣管理，可是不能全部階段都這樣管理，會形成需求粒度太大，細節太多，邊界太模糊。
2. 若是不作story拆分，這樣的需求離能開發還有不少空間，須要作拆分、細化、轉化，最後才能開發。
3. 這樣的需求表格缺少不少細節，好比UI長什麼樣子，某個業務邏輯有多少條分支等。
4. 這樣的表格沒法知道業務方和研發方對需求的理解是否一致，很容易出現返工。
5. 此類表格管理需求，不便於業務方追蹤需求進度和狀態，以及可視化需求的轉化過程。

需求評審

現狀

產品經理會和業務方一塊兒開會，針對表格裏面的某個需求，來肯定這個需求的細節，以及怎麼作。確保雙方的理解是一致的。

問題

1. 需求評審會的時候沒有記錄過程當中確認的結論，致使會後你們又忘記當時的結論是什麼。
2. 因爲需求粒度過大，不少細節沒法詳盡的確認清楚，容易致使返工。
3. 因爲需求粒度過大，須要比較長的時間來完成需求評審，一般會花2小時以上。
4. 沒有sign off，沒法斷定需求是否經過了業務方的承認。
5. 需求澄清是一個隨時隨地的動做，但該公司缺少能隨時作需求澄清的氛圍或文化。

產品設計

現狀

拿到需求後，產品經理會根據需求以及和業務方的溝通，達成一致後開始設計產品文檔，把需求涉及到的原型圖，業務邏輯等所有畫到產品文檔上，以提供給開發人員進行開發。

問題

1. 需求一般都很大，產品經理不多把需求拆分紅story，也不多在JIRA等工具上拆卡建卡來管理全部的需求。致使產品設計週期很長，細節不少，沒法一次性考慮全面。
2. 產品經理設計產品文檔的時候，一般是本身設計，設計好了再給業務方或者開發看。沒有頻繁反饋和需求澄清，致使需求可能被腦補，並非業務方想要的。
3. 產品文檔目前是用版本管理工具來管理的，好比git，不便與查找和歸檔。
4. 需求、產品文檔、代碼沒有關聯關係，不方便後期查找某個需求相關的產品文檔和代碼。

技術評審

現狀

目前，產品經理設計完成後，會拉上開發和業務一塊兒進行技術評審，確保設計的產品文檔三方能達成一致。

問題

1. 因爲需求太大，評審時間太長，一般超過2小時，長此以往你們會愈來愈反感這樣的評審會議，而且會議後期你們的注意力也不集中了。
2. 細節太多，容易忽略某些細節，致使最後開發依然有不肯定的開發細節，而且開發的結果和業務方的指望不匹配。

開發

現狀

拿到產品文檔以後，後端會根據文檔中的業務邏輯，開發完成服務端的功能，前端會根據文檔中的原型圖或者高保真UI設計圖，開發完成客戶端的功能。

再來講說該公司的分支管理模式。

他們把分支分爲了：線上分支（master），測試分支（stable），開發分支（dev）等。

保證不一樣的分支作不一樣的事情，防止分支污染。

1. 線上分支（master）：是預上線環境和線上環境的分支，以這個分支爲準，其餘分支都是以這個分支爲基礎拉取。
2. 測試分支（stable）：測試環境分支，是給測試團隊測試使用，若是有些功能在本地及開發不容易測試，開發人員能夠到測試分支進行自測。
3. 開發分支（dev）：開發人員自測。

分支命名規範：姓名+需求名+日期

分支會根據上線須要，merge到stable進行測試，或者merge到master進行上線。以下圖。

問題

1. 分支管理混亂，每一個分支既可能合併到dev，也可能合併到master，緣由是由於這樣能夠解決僅部分功能要上線的問題，哪一個功能要上線，就合併哪一個分支到master。

   1. 理論上，拉了分支開發的代碼都是應該要上線的，不上線的代碼會浪費開發資源。
   2. 分支開發的時間也不該該太長，太長會致使代碼衝突變嚴重，回滾成本變高。
   3. 若是是由於測試沒作完而暫時不上線，那多是由於分支所表明的功能粒度太大了，測試時間太長，應該從源頭開始拆解需求。
   4. 若是是由於業務變動而暫時不上線，應該使用feature toggle來解決。
2. 功能分支雖然寫了開發者名字和需求名，但依然很難關聯具體的需求是哪個。
3. 雖然規定了從master拉取分支，但你們有的從dev拉取，有的從stable拉取，沒有統一規範。
4. 分支命名中的日期意義不大，由於分支理論上存在的時間應該儘可能短，才能避免更多的衝突，減小review的工做量，以及減小回滾的成本。其次分支拉出來的時間在git上都能清晰的看到。
5. 開發不多作需求澄清，會按照本身的想法實現某個需求，遇到不肯定的地方沒有和團隊討論，沒有找產品、業務確認。會致使最終實現和業務方的指望不匹配。
6. 沒有code review，沒法統一開發團隊成員對代碼的規範，沒法及時發現代碼中的問題，沒法作代碼層面的知識傳遞。
7. 沒有寫單元測試，沒法作到研發自測與質量內建，沒法保證代碼的正確性，沒法保證其餘人不會破壞原有代碼功能，沒法持續集成。
8. 沒有CI/CD，沒法及時獲取反饋，沒法快速部署，沒法快速發現問題。

提交測試

現狀

開發完成開發工做以後，本身測試經過了以後，會交給測試人員進行測試。測試人員在提測以前會根據產品文檔先寫測試用例。

問題

1. 提測的過程靠口頭傳遞，測試人員沒法可視化的知道開發進度，作了哪些改動，能夠部署哪一個環境，使用哪一個版本。

測試

現狀

測試會根據寫好的測試用例對功能進行測試，若是發現問題，會返回給開發，讓開發修復。

問題

1. 測試用例目前是用單獨的工具來管理，沒有和需求關聯起來。
2. 測試完成以後，沒有對業務方的showcase，沒法獲取業務方的驗收反饋。

上線

現狀

每一個需求基本上都包含了先後端，所以會等先後端都開發測試完成後，再一塊兒作上線。

問題

1. 上線內容比較多，一旦出了問題，會致使回滾成本比較高，定位問題比較慢。
2. 上線時間比較慢，不能讓業務方快速看到最終的功能。

總結

這樣的研發過程梳理完了以後，會發現其實這樣的過程就是咱們俗稱的小瀑布。它的特色是相比傳統的瀑布模式它更輕量級，但相比敏捷，它又更重量級。目前不少公司都在採用這樣的小瀑布模式。

• 小瀑布模式的缺點在於它的溝通成本、等待成本、返工成本依然很高，還有能夠優化的空間。
• 同時整個過程當中，需求評審、技術評審、用例評審都作得比較重，每次評審的內容都很是多，時間很是長，細節很是多。
• 整個過程當中的全部產出物並無明確的關聯關係，也沒有統一的管理工具和存儲位置，隨着時間的推移，全部知識管理將變得愈來愈難，新人的學習成本將變得愈來愈高。軟件項目中的信息量會在潛移默化中變成異常高的複雜度。
• 環節與環節之間沒有文字記錄明確一個環節的結束與開始，好比開發到測試。基本上是靠成員之間的口頭傳遞。
• 最後還發現該公司不是全功能團隊模式，而是按角色分的，一個角色可能會同時負責幾個項目，好比A開發上午在寫X項目的代碼，下午可能在寫Y項目的代碼了。

根據這些現狀問題，具體怎麼改造，將在下篇來具體講解。