敏捷開發--工做流程的梳理

2019年08月09日，上海受颱風利奇馬的影響，晚間狂風大雨。

臨下班，合做渠道WB在微信羣裏報告線上生產事故問題：趕快扒日誌看記錄，日誌顯示一切正常，看不出bug在哪裏，WB聲稱並未接收到我方CI的回調請求。晚七點多，肚子已經餓了，給WB說，看日誌CI沒啥問題，先撤了。

在出公司大樓通過一個拐角的時候，隱隱感受這情形代碼裏的配置項會不會有問題，內心非常忐忑，冒雨又折回。從新打開電腦，再捋一遍代碼的時候，bug像一道匕首直刺心頭：臥槽，這個路徑居然仍是測試環境 的路徑！項目組是公司敏捷開發團隊，每週五都會有生產版本發佈，趕快給負責版本控制的同事打招呼，等一下，搭個順風車。

在肯定了配置路徑有問題以後：亟待明確的是服務間調用是走內網仍是走外網，要不要NG轉發，走不走esb，是否是要申請通訊權限。簡單描述一下WB的該次請求：WB請求CI的NG--------》NG轉發到CI的Mule服務----------》Mule服務調用Gateway----------》Gateway轉發至應用微服務Application ---------》Application服務響應以後執行異步回調Mule服務---------》Mule服務請求WB接口地址 。中間涉及的防火牆和權限就暫且忽略，目前的問題點是：Application服務響應以後執行異步回調Mule服務，這個Mule服務內部接口地址規範是什麼，會負責系統維護的同事一番確認後，決定走內網Mulef5，這個時間點負責維護配置中心的同事已經下班了，當務之急硬編碼的方法先上了。

九點多回到家，以爲有必要覆盤一下爲何會遺留這種bug，2018年11月份進入CI公司的敏捷開發團隊。剛入司時對敏捷開發基本不瞭解，後來才發現這是一種近乎流水線的開發模式。做爲開發能夠說是一個不停機的多線程，從一個合做業務開發要介入需求溝通、網絡申請、防火牆權限申請、配置維護、數據維護、多環境測試聯調、線上支持。天天被各類合做羣微信轟炸，有時候盯着開發文檔和需求分析文檔去盤問需求的正確性 ，有時候也不得不去應答一些需求和業務上的問題，開發思路很容易中斷。對於單個的合做渠道追求對接速度快，省略了各類文檔和單元測試，缺乏代碼的複覈和管理。快速迭代，線上支持，這種公司層面的狀況是短時間沒辦法改善的，在這種工做模式下，應該梳理出標準的工做流程模式，嚴格按照流程模式在上線以前去複覈，才能避免易忽視的小問題。

以WB案例來講：

階段一：談合做階段

前期CI分公司業務人員與WB達成合做意向，肯定合做產品方向。

階段二：談需求階段

CI需求人員介入，經過溝通和場景分析，參考WB合做接口文檔，分析CI接口映射關係、業務字段關聯，草擬一份需求分析文檔供開發測試用。

階段三：方案肯定階段

此階段開發人員已經開始開發，開發對需求分析文檔中的一些問題會和WB方開發和CI方需求及業務人員確認，此階段開發人員主要解決加密解密、加簽驗籤，測試環境申請。CI業務人員明確WB合做方案和WB合做機構信息，CI業務人員同步方案和機構信息至測試系統。

階段四：開發者開發階段

此階段大體分三板塊：第一，Mule開發；第二，應用開發；第三，配置項維護。

階段五：測試聯調階段

此階段開發負責環境雙方網絡權限，Ng轉發路徑，Api訪問權限的開通，相關數據維護。測試人員介入進行本地測試，本地測試經過，WB方介入聯調。

階段六：生產環境準備階段

測試環境和生產環境在網絡權限和防火牆控制有很大差異，主要是權限和參數維護。應按流程梳理各個環節權限是否開通，各參數和WB提供生產參數是否有出入。確認無誤，進行上線。