上個專案接近尾聲，我以developer的身份加入了現在的專案，姑且叫做專案A吧。說實話A專案蠻神奇的，幹了一年多了只有一次release，8月初要進行第二次release了，但是測試環境還未搭建好。
該專案是個分散式團隊，分佈在成都和澳洲兩個地方。由於成都這邊團隊都是清一色的developer，沒有qa，嚴重阻礙了交付的進度。所以我跑到澳洲出差1個月來了解一下整個專案的context，並爭取能找出一種解決方案來實現讓成都團隊中有人能夠擔任QA職責。目前已經在專案中呆了3周了，2周在成都，1周在澳洲。通過這三週的觀察，我總結出了專案中目前存在的一些問題。
此專案是一個一個遺留系統，裡面使用到的各種技術很多，有些技術很冷、很偏，維護起來較難。
此專案相關的依賴也比較嚴重，大大小小有將近10個依賴專案。
整合及系統測試環境搭建太晚，嚴重缺乏及時的端到端測試，導致大量卡被堆積在ready for test中，卻沒有足夠的測試人員來測試。
由於data security的原因，成都團隊無法觸及整合測試環境及系統測試環境。（公司是一個保險公司，不允許客戶資料被在澳洲以外的人看到）
成都團隊對業務瞭解不深入（至少在客戶這邊看來），每張故事卡做完都需要澳洲團隊review程式碼。
每個人看似都在認真工作，但交付完全跑偏，壓力堆積在team leader, Iteration manager等人身上。
雖然我們稱為敏捷團隊，但這個團隊怎麼看也不像是敏捷團隊。為什麼會導致這麼多的問題那？我分析了一下，覺得大致有兩方面的原因。
由於特殊的data security問題，導致了專案不能滿足敏捷團隊中起碼的開放原則。在一個敏捷專案中，首要的就是開放。無論是程式中的每一行程式碼，還是資料庫中的每條資料，都不能是某人或某些人的私有財產，團隊中的每個人都能有所觸及，這樣才不會引起專案中的盲點，導致一個對團隊大多數人來說的黑區。而成都團隊無法觸及專案中的真實客戶資料，直接導致了成都團隊無法做真正的端到端測試，即使開發者也難對自己開發出的功能進行驗證，只能mock掉大部分的整合點。
團隊中的成員沒有完全做到以交付為目標。敏捷專案中的最終目標就是以交付產品為目的。如果BA只管給牆上新增story，developer只顧埋頭開發story，雖然每個人都在盡力做自己的本職工作，但story並沒有很好的進入done column。這是因為由於多種原因，測試環境並沒有儘早的搭建起來，大量story堆積到了測試環節，使得一個敏捷專案愣是變成了瀑布型。在這種情況的早期階段大家就應該要有所覺察，developer應該停止開發story，而是協助QA儘早建立起測試環境，協助QA一起來做測試。大家應該一起關心當前專案的delivery的狀況，找出其中的block並商討出一定的解決方案。
既然存在這麼多的問題，接下來應該怎麼做那？我想應該從以下幾個方面著手。
- 儘快建立起整合測試及系統測試環境，準備好測試資料，保證測試的正常進行。
- 和團隊人員討論出一種測試策略，比如採用給整合環境灌輸fake data的方式使成都團隊能避免或部分避免data security的干擾，能夠開展測試。
- 基於上面幾點，建立起端到端的自動化測試，使得QA脫離手工測試的苦海，完善我們的質量保護網。
希望自己能在剩餘的3周onshore中能夠有所進展。其實我比較鼓勵大家在做自己手頭工作的同時能夠多多思考，不能將自己侷限在某一個角色之中，這樣子才不會日復一日重複昨天的工作，而是在工作中能夠有所提高，提升自己的專業能力和職業素養。這些都是日後前進的寶貴財富。