項目傳遞為什麼失敗？-記我在某個項目中的迷思

上個項目接近尾聲，我以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中能夠有所進展。其實我比較鼓勵大家在做自己手頭工作的同時能夠多多思考，不能将自己局限在某一個角色之中，這樣子才不會日複一日重複昨天的工作，而是在工作中能夠有所提高，提升自己的專業能力和職業素養。這些都是日後前進的寶貴财富。