一個快速上市時間可保證產(chǎn)品的成功至關重要。 所以，要在較短的開發(fā)時間內(nèi)提供客戶嵌入式軟件項目的壓力對初創(chuàng)企業(yè)和小企業(yè)而言相當高。 本文提供了5項加速韌體(firmware)開發(fā)的秘訣，盡管它們是顯而易見的方式，但在實作時卻很少被真正使用。

秘訣1—設置一個實際的時間表
在過去幾年中，我曾遇到幾十個項目，開發(fā)商在研發(fā)計劃啟動后，自動將進度延后幾周。 管理者忽略功能的復雜性和技術障礙，并在沙灘上畫了一條線當作即將到來的厄運最后期限，若產(chǎn)品不是在所預定的日期完成。

問題總是被隱藏在8號球背后，也就是開發(fā)商往往被放大檢視。 當處在壓力的情況下，人體會釋放皮質(zhì)醇(cortisol)到大腦，但皮質(zhì)醇具備遞減推理有效性的效果和判斷！ 不完全是依照你和你的工程團隊所希望的進行，需要團隊達到極限狀態(tài)，以滿足一個最后期限。 設定合理的時間表可以幫助減少壓力，將使工程師更有效率，它甚至有可能使項目計劃能夠如期完成。

秘訣2—先開發(fā)一個架構(gòu)
當期限很短時，大多數(shù)開發(fā)者第一反應是溝通項目的設計和架構(gòu)層次，并且直接進入軟件的實作階段。 這想法是有一個記錄的軟件架構(gòu)是好的，但其需要花費太多時間，然而時間「供不應求」。

這種方法的問題是，為了加速執(zhí)行速度，開發(fā)人員需要妥善想通設計和規(guī)劃他們正在架構(gòu)的內(nèi)容。 該基本架構(gòu)是軟件的藍圖，一個建構(gòu)者不會在沒有藍圖的情況下企圖建造一個建筑物，且開發(fā)人員不應該嘗試去寫一個沒有相似基礎的韌體！

秘訣3—不要只依自己的時程表走
撰寫一個實時時程表或RTOS，對開發(fā)人員來說會是一個令人興奮和有意義的努力過程。 問題伴隨著從頭開始開發(fā)一個進度表，雖然這證明所有工作條件下，時程表操作正確，并非一個微不足道的努力，開發(fā)人員可能浪費許多時間重塑一個在市場上已存在數(shù)十種RTOS的韌體組成。 有些RTOS，諸如FreeRTOS是免費的，而其他僅要求一點費用，使用商用現(xiàn)貨軟件(commercially off the shelf，COTS)行程表取代自寫，可縮短開發(fā)時間，并且還可顯著提高系統(tǒng)的質(zhì)量和可靠性。

秘訣4—充分利用現(xiàn)有的中間件和驅(qū)動程序框架
微控制器(MCU)已經(jīng)變成極其復雜的設備，其現(xiàn)在與90年代中期的通用運算處理單元相當相似。 高階微控制器有板載緩存(on-board cache)、DMA和一個外圍設備的主機，以及超過200MHz的時鐘速率，為這些復雜的設備從零開始開發(fā)驅(qū)動程序需要很長的時間。

取代試圖掌握微控制器硬件，致力于尋找供貨商的驅(qū)動程序和第三方合作伙伴的原件，可摘要硬件「狀況」，并協(xié)助工程人員開始進入實作階段。 利用現(xiàn)有的中間件(middleware)和驅(qū)動程序框架可讓開發(fā)人員專注于產(chǎn)品差異化和功能，而不是關心硬件本身該如何工作的問題。

秘訣5—使用項目專家
工程師是一個非常聰明的一群人，且可以做任何事情，問題是，如果工程師在應用領域還沒有經(jīng)驗時，有時做任何事情都可能需要很長的時間。

當時間很短時，不要把一個毫無經(jīng)驗的「菜鳥」放進項目里，反而是要選一個項目專家(subject matter expert)。 利用項目專家似乎是顯而易見的方式，但當時間變得較為艱難時，許多團隊只是將骨架扔進項目中—任何骨架—實際的結(jié)果是連帶的損失和延遲交付。 采用項目專家在短期內(nèi)可能會花費更多金錢，但這樣的作法在項目按時交付與功能正確的長遠效益上，將遠遠過所付出的成本。

最終思考
當談到如何減少項目時間壓力與準時交付項目的秘訣時，有人可能會覺得我什么也沒做多過明白陳述，因為這五個技巧似乎是常識。 但一旦壓力來臨，常識常常被拋到九霄云外，只有認真嚴格的工程師及其團隊能維持腦袋的清醒，并遵循這些常識秘訣。

當截止時間很短，上述這些秘訣你可遵循或那些又被你拋到九霄云外呢？