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

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

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

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

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

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

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

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

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

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

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

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