手上的這個專案終於快要結束了，已經忙碌了兩個多月，每天不停地加班。趁著專案尾聲趕緊總結一下專案經驗，不然就沒時間啦。在公司上班就是這樣，上一個專案還沒有來得及好好消化，又要馬不停蹄地投入到下一個專案中去。

這個專案基於海思平臺，我的職責是平臺開發。專案的主要成員有平臺組，CA組，bootloader組，app組等。其它幾個組的開發都是基於我們平臺組，因此我們組先投入，他們後續進場。下面說說專案的進行吧。

專案開始的第一步是資訊蒐集。要蒐集的資訊有很多，主要是：1.專案立項資料；2.專案的硬體原理圖和PCB圖；3.記錄硬體的外圍裝置的IO口配置資訊；4.確認工具鏈版本；5.確認sdk版本，也包括使用的核心版本等資訊。我們的工具鏈和sdk都是原廠提供的，裡面可能包含有多個不同的版本，使用之前一定要向原廠確認清楚使用哪個版本。

第二步就是任務清單。把專案的工作量拆分成一個個小任務，拆分得越細越好，最好讓任務以0.5天為一個單位。如果我對某個模組不熟悉，那就找熟悉這個模組的人替我拆分。然後把所有的任務記錄到excel表格裡面，在這裡我用的是騰訊文件，可以一鍵把文件分享給團隊成員，使幾個成員之間協同辦公。現在這種團隊專案管理的軟體有很多，比如說teambition，worktile都很好用，就看個人的喜好了。記錄到表格以後列出重要任務的完成時間節點，這個時間節點是根據專案立項的時間節點來定的，但是我們自己的重要任務的完成時間節點肯定要提前，因為要考慮到意外的事件導致的延遲情況。

第三部就是開始搭建開發環境了。首先建立SVN倉庫，把原廠提供的乾淨的sdk上傳到伺服器端。然後熟悉原廠工具的使用，熟悉這個平臺的編譯和燒錄過程，儘快把編譯出來的程式燒錄到開發板上讓程式先跑起來。

第四步全力解決最重要的問題。最重要的問題一般是如果不解決其他人就沒法幹活的問題。我的這個專案是一個高清機頂盒的專案，程式跑起來後一直無法鎖頻播放。當時花了一天時間才解決這個問題，解決了之後平臺組的其他夥伴才陸陸續續地投入到這個專案當中。

第五步是事先約定團隊的協作方式。組員使用的伺服器不一定都一樣，那麼我們首先會約定好檔案共享的路徑，放入驅動庫及其它共享檔案。建立一個叮叮群，拉入團隊成員，把檔案共享的路徑放在群公告上面。檔案共享的路徑最好不要更改，否則容易導致其他人取錯了檔案。接下來就開始分配任務了。上面的任務清單已經公開，我們平臺組的成員都很清楚所有的任務。第一次的任務由我指派，後面的任務誰先完成了誰自己到任務清單裡面取出下一個任務接著做（這裡假設我們的成員都是敬業的，工作積極的），這樣能夠動態地分配任務。每天下班後我會統計每個任務的完成進度，定時更新，讓成員瞭解彼此之間的進度，起到一個互相督促的作用，或者有的成員遇到問題卡殼了，我們也能及時一起探討。我讓每個成員每天早上來先更新程式碼，每天晚上走之前最好上傳當天修改的程式碼到SVN伺服器，前提是自己驗證過OK的。有的檔案不能上傳但是其他人也有用到，如果更改了，就要及時放到共享路徑下。這樣能避免一些由於成員之間檔案不同步造成的問題。在做專案的過程中，我們對團隊的成員很信任，覺得別人不可能犯這種低階的錯誤，但是往往這種錯誤犯的很多，而且有的時候還不好查出來。那麼我們要汲取教訓，儘量避免這種錯誤。我們的程式要經過平臺的自測試用例的嚴格測試，我們會記錄測試的結果，pass或者failed。後續的app或者bootloader遇到問題，我們會首先參照平臺自測試用例有沒有類似的問題，所以我們要維護好我們的自測試用例表格，不允許隨意修改。一般是其他成員修改了問題並且程式碼上傳了，我再驗證，確實沒有問題了，由我修改自測試用例表格，並且在表格裡面加入SVN版本資訊，確保可以追溯到修改了哪些程式碼解決了哪些問題。下面是一張自己畫的專案進度的表格：

最後就是軟體的開發和測試了，就是寫程式碼，除錯解bug的過程。寫一個複雜的函式之前，我最好還是畫一下流程圖，寫完之後走讀一下程式碼邏輯，寫一個測試函式，傳入一些臨界引數，測試一下寫的函式，儘量減少重複debug的次數，提高效率。後面是進行所有平臺模組的整體測試了，我們的平臺的自測試用例很多，基本上對每個模組的每個函式介面都進行了測試。一般情況下，如果我們的自測試沒有什麼問題的話，app開發基本上也不會遇到多少底層驅動的問題。自測試完了之後開始梳理問題，哪些問題我們自己可以解決，哪些問題需要原廠解決。如果需要原廠解決的問題需要儘早報告給原廠，因為有的原廠遇到這種不是晶片方案開發階段的問題可能處理起來會很慢。後面就是合併原廠的patch，並進行下一輪的平臺自測試，儘量把自測試的問題解決到最少，這樣後面開發遇到的問題會少很多。