工做經驗總結

團隊管理

 

開發管理

1. 系統聯調

場景描述

　　當前的智能音箱項目組由 音箱設備端 -> Proxy代理 -> 語音語義及技能 三大系統組成。設備端負責用戶語音數據的採集、上傳至Proxy端，Proxy負責數據透傳，語音語義團隊將接收到的音頻數據進行解析並實現相應技能。技能按照相反的順序返回至音箱設備端。目前的現狀是整個工做流程不可靠，到底是哪一個環節也都說不清，可定性的定位故障點在Proxy與語音語義環節，至少proxy發送的音頻與語音語義接收到的數據是不一致的。整個調試還得三個小組分別派人聯調。

 

解決方法

• 從邏輯上來講應把這三個團隊劃分明確的邊界，對接部分肯定明確的輸入輸出。
• [ 用戶語音(輸入) - 智能音箱 - 音頻數據（輸出) ]    =>    [ 音頻數據(輸入) - Proxy - 音頻數據(輸出)]    =>    [ 音頻數據(輸入) - 語音語義 - 技能結果(輸出) ]。
• 從上述流程可知各團隊真正依賴的是音頻數據，因此各個環節均應生成相應的音頻數據文件，經過 BeyondCompare 等文件比較工具進行差別比較。
• 各團隊對接部分只需確保各自環節的輸入輸出正確性便可，這樣可避免相互的依賴關係。
• 每一個環節均實現打樁數據，便可直接根據已有的數據文件進行本系統模塊功能的測試，這樣可解決上一環節的依賴。
• 每一個系統均實現單元測試代碼，集成測試或系統測試時都可很是方便的實現自動化測試，定位問題故障。
• 網絡通訊環節可經過WireShark等抓包工具進行精準分析。

 

配置管理

1. 文件管理

場景描述

　　當前項目組中的項目資料SVN既包含項目管理文檔、我的工做文檔、第三方資料庫等。其中我的文檔中的工做成果可能包含比較大的第三方類庫、資源文件，第三方資料庫可能包含一個開發板的系統鏡像等，若是將全部數據都納入項目管理使用的SVN庫，必然形成版本庫文件過大，並且那些私有的大文件對絕大部分人來講是徹底不關心的。所以，我認爲對於大文件應該單獨保存，SVN中只需包含相應大文件的資源連接，用戶根據須要可自行下載。這樣既保證了數據的完整性，也保證了項目庫的簡潔性。

解決方法

• 文件管理應分爲大文件管理及小文件管理兩部分。由於大文件混雜在SVN、Git等受控庫時，初次下載代碼時均會下載大量大文件，嚴重影響下載速率及本地磁盤佔用空間。

• 大文件管理是指安裝文件、光盤鏡像、大於10M的文檔資料等，應經過共享文件、HTTP、FTP下載等方式管理。

• 小文件管理是指受控的代碼、文檔、資料、可交付成果等，應經過SVN、Git等方式進行管理。