為交付保駕護(hù)航, 提高交付效率

愿景回顧

1. 讓研發(fā)只需要關(guān)注于自己的代碼, 讓產(chǎn)品只需要關(guān)注于自己的產(chǎn)品.
2. 瓦力發(fā)力為國(guó)內(nèi)機(jī)票研發(fā),測(cè)試以及產(chǎn)品經(jīng)理,提高研發(fā)主導(dǎo)在生產(chǎn)交付過(guò)程中的交付效率.

重視原則

1. 在反復(fù)的代碼修改及測(cè)試的過(guò)程中, 避免以下問(wèn)題:

• 避免代碼未合漏上線.
• 避免代碼未測(cè)帶上線.
• 避免上線未代碼同步.
• 避免上線非所測(cè)代碼.

2. 能夠提高協(xié)作效率, 降低溝通成本:

• 在協(xié)作過(guò)程中, 以過(guò)程引導(dǎo)的方式進(jìn)行一站式操作.
• 在溝通過(guò)程中, 能傳遞信息的過(guò)程中到達(dá)快速,準(zhǔn)確, 清晰.

過(guò)程回顧

1. 瀑布轉(zhuǎn)敏捷

瓦力項(xiàng)目經(jīng)過(guò)系統(tǒng)設(shè)計(jì)和拆分以瀑布流方式進(jìn)行推進(jìn).逐漸變成敏捷方式, 需求變得越來(lái)越不明確, 需求變得越來(lái)越零碎.

2.從敏捷轉(zhuǎn)測(cè)試驅(qū)動(dòng)

項(xiàng)目初步交付后, 在實(shí)際打樣過(guò)程中, 問(wèn)題很多, 此時(shí), 我們的開(kāi)發(fā)流程變成測(cè)試驅(qū)動(dòng)式開(kāi)發(fā).以修復(fù)錯(cuò)誤及優(yōu)化為主.

在過(guò)程中的遇到的問(wèn)題, 不足之處, 改進(jìn)方法

主要問(wèn)題出現(xiàn)在: # 需求管理# , #產(chǎn)品設(shè)計(jì)# ,#系統(tǒng)設(shè)計(jì)#, #質(zhì)量管理#

案例分析:

1. 需求的變動(dòng)與反復(fù),

• 代碼合并對(duì)其他工單的影響, 是否能讓用戶可以接受.
• 測(cè)試節(jié)點(diǎn), 用戶對(duì)測(cè)試節(jié)點(diǎn)的需求廣泛. 一方面, 我們需要管控測(cè)試, 一方面我們需要放開(kāi)測(cè)試. 對(duì)我們系統(tǒng)能夠[保障上線代碼必定已經(jīng)測(cè)試過(guò)]的原則進(jìn)行挑戰(zhàn).
• 發(fā)布申請(qǐng)節(jié)點(diǎn)及正式上線節(jié)點(diǎn), 提供后悔的功能. 我們對(duì)國(guó)內(nèi)機(jī)票內(nèi)部發(fā)布管理的過(guò)程太過(guò)于理想化, 竟然到了已經(jīng)申請(qǐng)的那一步了, 還有掉隊(duì)的工單才來(lái)合并.

2. 不可預(yù)期的需求:

• 新增 [自動(dòng)新增工單]節(jié)點(diǎn)
• 兩個(gè)月后, 對(duì)這個(gè)[自動(dòng)新增工單]節(jié)點(diǎn), 用戶要求的場(chǎng)景有變動(dòng), 我們不得不進(jìn)行修改.

3. 對(duì)用戶進(jìn)行工作的過(guò)程缺乏足夠的用戶調(diào)研:

• 國(guó)內(nèi)測(cè)試人員視角. 測(cè)試人員真正就是要只關(guān)心測(cè)試, 卻花了很多時(shí)間到流程上去了. 瓦力任務(wù)的協(xié)調(diào)與跟蹤本身就是該瓦力自動(dòng)的事情.
• 國(guó)內(nèi)項(xiàng)目群組管理員視角. 我們項(xiàng)目進(jìn)行的進(jìn)度是什么?報(bào)表一直是個(gè)不重視的一塊.
• 研發(fā)人員視角, 真正需要關(guān)心的是什么? 真正需要操作的是什么? 能不能再少一些打擾, 少一些操作.

4. 部分過(guò)程性操作對(duì)用戶應(yīng)當(dāng)無(wú)關(guān):

• 代碼合并過(guò)程, 修改為一鍵合并, 自動(dòng)適應(yīng)不同因素帶來(lái)的情況, 由系統(tǒng)進(jìn)行決策,而不是系統(tǒng)反饋給人進(jìn)行決策. 后端研發(fā)人員以此為例, 設(shè)定不同因素不同策略規(guī)則,做到用戶只要一個(gè)操作, 也只要一個(gè)結(jié)果,那就是執(zhí)行成功與系統(tǒng)無(wú)法自動(dòng)處理的執(zhí)行失敗.
• 構(gòu)建部署過(guò)程, 同代碼合并過(guò)程一樣, 用戶真正需要最直接的結(jié)果就是部署成功與失敗. 要先構(gòu)建才能后部署,只是系統(tǒng)內(nèi)部的一個(gè)流程罷了.

5. 已經(jīng)經(jīng)過(guò)測(cè)試, 上線之后依然問(wèn)題不斷, 反復(fù)修改返工, 導(dǎo)致項(xiàng)目周期成本上升:

• 需要考慮到測(cè)試用例覆蓋率. 比如新增GIT項(xiàng)目模塊,缺乏了對(duì)不同類(lèi)型項(xiàng)目的測(cè)試, java項(xiàng)目也進(jìn)行新增構(gòu)建結(jié)果的webhook接口調(diào)用, 導(dǎo)致java項(xiàng)目無(wú)法新增.項(xiàng)目無(wú)法新增, 導(dǎo)致項(xiàng)目無(wú)法使用瓦力, 甚至違背了瓦力提高效率的初衷,適得其反.
• 需要進(jìn)行單元測(cè)試. 對(duì)固有對(duì)外integration層需要維護(hù)好單元測(cè)試代碼, 確保長(zhǎng)期integration穩(wěn)定.對(duì)外部提供的服務(wù),要保持懷疑的態(tài)度,不能過(guò)于相信其質(zhì)量.
• 修改一個(gè)bug, 導(dǎo)致了另外一個(gè)曾經(jīng)發(fā)生過(guò)的bug. 我們對(duì)于以往已經(jīng)發(fā)生過(guò)的bug, 缺乏有效的跟蹤機(jī)制, 并且 需要冒煙測(cè)試和回歸測(cè)試. 經(jīng)過(guò)排查, 也是因?yàn)榇a質(zhì)量太差導(dǎo)致, 代碼可讀性及可維護(hù)性比較差, 比較重的地方, 就容易產(chǎn)生錯(cuò)誤.

6. 性能不足導(dǎo)致的返工:

• 使用Job架構(gòu)來(lái)消費(fèi)工單因代碼變動(dòng)而回退的機(jī)制,這點(diǎn)經(jīng)過(guò)了返工.
• Web 頁(yè)面使用定時(shí)器來(lái)刷新, 導(dǎo)致Web內(nèi)存溢出. 用戶在長(zhǎng)時(shí)間打開(kāi)著相同頁(yè)面的時(shí)候, 會(huì)讓瀏覽器內(nèi)存不斷上升, 最后不得不重啟瀏覽器. 比如: 工單處理頁(yè)面.
• 對(duì)技術(shù)要求要有量入未出的思考, 我們不僅僅需要考慮產(chǎn)出與投入的關(guān)系, 有時(shí)候, 成本可以降低到能解決問(wèn)題的程度, 也隱藏著要返工的風(fēng)險(xiǎn).

7. 線上故障,缺乏有效的引導(dǎo):

• 當(dāng)線上出現(xiàn)非系統(tǒng)導(dǎo)致的故障工單時(shí)候, 能讓用戶得以理解問(wèn)題, 是什么問(wèn)題導(dǎo)致,將會(huì)有效避免問(wèn)題, 將會(huì)更加有效的提高工作效率, 而不是一臉懵逼的請(qǐng)求刪除工單.
• 提交錯(cuò)誤的時(shí)候 , 溝通難度大. 應(yīng)該能讓用戶了解我們要通過(guò)錯(cuò)誤頁(yè)面的鏈接來(lái)有效排查問(wèn)題.

8. Bugfix 流程是目前用戶吐槽的高災(zāi)區(qū):

• Bugfix 流程設(shè)計(jì)缺乏了必要的研究, 在確定方案的時(shí)候, 沒(méi)有準(zhǔn)確進(jìn)行研究, 而是空口跟了祥富確定了方案, 這塊是不可取的, 我們需要用數(shù)據(jù)來(lái)模擬真實(shí)上線后的場(chǎng)景進(jìn)行權(quán)重.

改進(jìn)措施:

1. 在需求分析上, 時(shí)刻和用戶保持溝通,了解客觀場(chǎng)景, 不以用戶意識(shí)為首, 不以主觀意識(shí)做決定, 而以客觀世界的真實(shí)問(wèn)題得以有效解決為主. ??

2. 在需求管理上, 以需求分析留下過(guò)程性資產(chǎn). 需求管理可以進(jìn)行跟蹤,分好輕重緩急.并做好可預(yù)期需求的規(guī)劃. ??

產(chǎn)品設(shè)計(jì),系統(tǒng)設(shè)計(jì)更貼近需求

3. 產(chǎn)品設(shè)計(jì)充分考慮調(diào)研用戶體驗(yàn),考慮用戶處理效率.

• 按鈕上讓用戶最少操作得到最優(yōu)結(jié)果, 系統(tǒng)能自動(dòng)化策略進(jìn)行的就自動(dòng)化, 減少人機(jī)交互.
• 界面上, 以用戶視角為核心考慮, 不同角色真正需要的東西是不一樣的, 不同場(chǎng)景下, 需要的也是不一樣的. 以不同角色和不同場(chǎng)景做界面設(shè)計(jì)分析. 留下過(guò)程性分析文檔.

4. 在系統(tǒng)設(shè)計(jì)上, 提高重視需求貼近程度.

• 技術(shù)與需求不分家, 架構(gòu)設(shè)計(jì)盡量貼近需求進(jìn)行設(shè)計(jì), 貼近現(xiàn)實(shí)場(chǎng)景, 保持?jǐn)U展性和可修改性. 對(duì)隱藏需求和可預(yù)期需求要重視.
• 架構(gòu)流程設(shè)計(jì)留下設(shè)計(jì)文檔(流程圖, 架構(gòu)圖), 說(shuō)明設(shè)計(jì)原因,及優(yōu)劣所在, 為滿足的需求是什么, 可滿足的隱藏需求和可預(yù)計(jì)的需求是什么 . 對(duì)未來(lái)不可預(yù)期的需求留下充分證據(jù).

質(zhì)量管理優(yōu)化

5. 質(zhì)量管理缺少跟蹤

• 在瀑布,敏捷,還是測(cè)試驅(qū)動(dòng)的過(guò)程中, 我們都出現(xiàn)了質(zhì)量問(wèn)題, 管理優(yōu)化意見(jiàn)如下:
  • 驗(yàn)收管理, 需求與實(shí)際不一致, 沒(méi)有及時(shí)得到復(fù)盤(pán). 后續(xù)跟進(jìn)需求變現(xiàn)不一致問(wèn)題需要跟進(jìn). 在需求管理需質(zhì)量管理中得到關(guān)聯(lián)記錄, 及時(shí)總結(jié)問(wèn)題所在.
  • 缺陷管理, 缺少應(yīng)有的詳細(xì)記錄, 包括復(fù)現(xiàn)步驟, 后續(xù)建立缺陷管理記錄以進(jìn)行系統(tǒng)冒煙測(cè)試, 回歸測(cè)試.
  • 用例管理, 內(nèi)部團(tuán)隊(duì)在測(cè)試系統(tǒng)模塊的時(shí)候, 分別依照需求進(jìn)行編寫(xiě)測(cè)試用例, 依照缺陷編寫(xiě)測(cè)試用例.

在過(guò)程中的優(yōu)點(diǎn), 持續(xù)發(fā)揚(yáng)

在瓦力開(kāi)發(fā)過(guò)程中值得肯定的點(diǎn)主要在與#放低姿態(tài)#,#用戶體驗(yàn)#, #故障修復(fù)#

1. 對(duì)用戶的姿態(tài)放低, 更加注重用戶體驗(yàn).對(duì)用戶更加尊重, 漸進(jìn)的我們?cè)诓粩鄬で笥脩舻目诒? 用戶的痛點(diǎn). 有了這個(gè)姿態(tài)是做出好的產(chǎn)品的前提.

2. 故障處理效率上得到很大提升, 線上出現(xiàn)BUG相關(guān)工單能夠及時(shí)得到響應(yīng)處理是值得肯定的. 但是在系統(tǒng)設(shè)計(jì)上 , 應(yīng)該主動(dòng)避免問(wèn)題的發(fā)生, 并且能夠部分引導(dǎo)用戶如何解決問(wèn)題.

3. 團(tuán)隊(duì)在技術(shù)能力逐步提高. 但依然不足,依然需要刻苦努力.