這是《落葉》文集里第?69?片落葉，希望你能喜歡，不為別的，只為這份堅持。
之前聊了一些老兵在實施敏捷的過程中所遇到的現(xiàn)實問題和解決方案，其實還有一些沒找到或者也許沒有解決方案的問題，今天就來聊聊這些吧，也是想說明一點：敏捷不是萬金油。
【問題描述-1】：開發(fā)工程師對自動化測試的認知和理解還很粗淺，所以在做架構(gòu)設(shè)計和代碼實現(xiàn)時并沒有考慮如何有效地支持自動化測試框架。
【分析】：高效的敏捷團隊離不開自動化測試框架的支撐，持續(xù)集成的自動化構(gòu)建環(huán)境，自動執(zhí)行的 BVT 腳本，用于版本回歸的自動化腳本，等等這些都是敏捷流程中不可或缺的一部分。如果前期設(shè)計階段沒有考慮進去，因為代碼結(jié)構(gòu)的復(fù)雜度，過程中很難對架構(gòu)進行調(diào)整，所以只能在自動化方案的設(shè)計階段，考慮能否按模塊去做一些相對簡單的改動，比如針對一些非標準控件去增加 ID 屬性，從而便于自動化腳本能夠識別到它們。
【問題描述-2】：團隊中的測試工程師，黑盒測試經(jīng)驗豐富，但技術(shù)是短板，短期內(nèi)很難基于代碼去做單元測試或白盒測試。
【分析】：這是在產(chǎn)品開發(fā)初期，對測試工程師的要求相對單一導(dǎo)致的，如今只能逐步引導(dǎo)部分優(yōu)秀的黑盒測試工程師轉(zhuǎn)型，或者是補充新鮮的技術(shù)類測試工程師資源，無論是哪種方案，都不是短期能立竿見影的，學習、提升、熟悉、磨合。。。都是需要時間的。
【問題描述-3】：產(chǎn)品的功能模塊之間，耦合度和依賴性比較大，在做一個規(guī)模較大的需求時，通常需要 DB、Server、Page 和 Client 同時支持，所以在 User Story 的細化、Task 拆分、以及不同的 Scrum Team 之間的協(xié)作上有很大難度。
【分析】：首先不可能為了敏捷而去大幅度調(diào)整產(chǎn)品代碼架構(gòu)，這個只能在合適的時期，逐次分批地進行調(diào)整。其次，在 User Story 的細化和 Task 的拆分上盡量降低耦合性。如果 DB、Server、Page 和 Client 都是由不同的 Scrum Team 在承擔任務(wù)，那就需要通過 Scrum of Scrum 的形式去管理項目，從而保證所有模塊在每個迭代的步調(diào)是一致的。
【問題描述-4】：雖然 Major Release 也能做到在一個 Release 周期內(nèi)的每個迭代都能提交可發(fā)布版本，但運維團隊的部署節(jié)奏還跟不上，所以出現(xiàn)產(chǎn)品研發(fā)團隊即使在1個季度里提交了3 個可發(fā)布的迭代版本，但運維團隊卻只能發(fā)布其中的最后1個 。
【分析】：因為產(chǎn)品的復(fù)雜度決定了 Deployment 的步驟繁多，而且不同組件之間還有 Hard Dependency 和 Feature Dependency，同時，線上部署也還沒有做到完全的自動化，上線成本較高，這也是在敏捷實施過程中一個暫時不可調(diào)和的矛盾。
【問題描述-5】：線上產(chǎn)品的小版本并存和定制版本太多，而自動化測試覆蓋率不高，導(dǎo)致在某些安全問題修復(fù)和 OS/Browser 版本更新時，Scrum Team 可能需要在一個迭代周期內(nèi)同時在很多 Branch 上進行代碼合并和大量的手工回歸測試，SM 也很難保證團隊在一個迭代周期里只Focus 在當前 Sprint 的計劃任務(wù)上。
【分析】：提高持續(xù)集成測試和自動化測試覆蓋率，同時要盡可能地說服客戶盡快都升級到最新的版本，逐步減少小版本并存的現(xiàn)象。
作者簡介：14 年測試經(jīng)驗 + 11 年項目管理經(jīng)驗 + 11 年團隊管理 = 一個測試老兵
