嵌入式系統軟體敏捷開發
本文綜述了嵌入式系統敏捷開發(Agile Development)，敏捷宣言，敏捷的原則，很多的敏捷開發的實踐習慣，敏捷開發與瀑布開發流程的區別，敏捷的任務stories劃分，並行開發、敏捷的時間安排，敏捷的通訊交流方式等等。敏捷開發的其他別名包括極限程式設計(Extreme Programming),特性驅動的開發(Feature Driven Development (FDD)), 迭代式增量軟體開發Scrum，完全清楚（Crystal Clear）以及DSDM動態系統開發方法(Dynamic Systems Development Method)。
為什麼嵌入式系統軟體開發要採用敏捷開發呢？並不因為敏捷開發是現在的流行詞，更重要的是因為敏捷開發能提高你的效率，基於計劃驅動的實現方式會掩蓋很多的問題，當你發現時也許就晚了。計劃的開發並不能提供足夠的自信來掌控產品的釋出時間。軟體開發專案往往受制於較長的開發週期、推遲的釋出、無法預測的時間安排、較差的質量、不合客戶預期等。這些所有的問題會構成一個正的惡性迴圈，如下圖1所示。
模糊的需求
上面的惡性迴圈中有一些正反饋，如計劃安排、修改缺陷、以及需求更改的惡性迴圈。這正是迭代實現的敏捷開發可以有效解決的問題。基於瀑布的軟體開發流程定義需求-系統設計-測試-實現-測試-釋出的實現聽起來很誘人，但通過時間的考驗證明往往不能滿足需求。迭代開發，很多年以前就作為敏捷開發的重要的實踐方式，從1987年Fred Brooks作為國防部軍事軟體開發上建議從瀑布流程轉換成迭代開發開始就意味著瀑布模型在大型的DoD軟體專案上的失敗。在過去的十餘年間，敏捷開發更多的是和軟體開發聯絡在一起而不是和嵌入式，雖然嵌入式有其特殊性，但採用敏捷開發同樣有增益，因為嵌入式開發也有同樣的問題。
什麼是敏捷開發？
敏捷宣言包括：
- 個體和互動勝過工具和過程
- 可以執行的軟體勝過面面俱到的文件
- 客戶合作勝過合同談判
- 響應變化勝過遵循計劃
個體和互動勝過工具和過程
敏捷強調個人互動和團隊合作的重要性，很多開發流程總是把人的因素從軟體開發中排除，但是敏捷宣言的首要表述就是強調人和互動，工具是需要的，但是在團隊中的人創造了成功的軟體產品。
可以執行的軟體勝過面面俱到的文件
第二點是對開發流程的度量，文件也許有價值，但可以工作的軟體更有意義。但敏捷也並不意味著不寫文件。只是說文件需要時間來寫和維護，很多時候文件只是因為我們的流程需要文件而已，而敏捷開發者則能度量寫文件的意義，而創造客戶需要的文件。外需要記住的是文件並不能表明專案進度的，敏捷開發則是當50%的專案特性實現時才算專案50%完成了。雖然嵌入式軟體只和硬體一起交付一次，但並不表明不能用特性來跟蹤進度。
客戶合作勝過合同談判
這點是強調和客戶的緊密合作。客戶的互動很重要是因為軟體很難在初始時就能確定具體的特性和features。需求和市場往往瞬息萬變，客戶早些介入很更好的表明他們的需求。
響應變化勝過遵循計劃
最後一條是對現實中的複雜情況的應對。計劃很重要，但是情況變化很快也需要經常的變換，但這並不意味著敏捷開發沒有釋出的日期，而日期和承諾在敏捷開發中看的很重。敏捷開發者會在短的時間週期內來度量和計劃的一致性。
敏捷開發的基本原則：
- 優先順序最高的，通過早期和持續交付有價值的軟體來滿足客戶；
- 歡迎變更需求，即使在開發的後期提出。敏捷過程為客戶的競爭優勢而控制變更；
- 以兩週到兩月為週期，頻繁地交付可執行的軟體，首推較短的時間定量；
- 在整個專案過程中，每一天開發人員都要和業務人員合作；
- 由個體推動專案的建設，為個體提供所需的環境，支援和信任；
- 在開發團隊中或開發團隊間傳遞資訊的最為有效和高效的方法是面對面的交談；
- 衡量進展的重要尺度是可執行的軟體；
- 敏捷過程提倡可持續的開發；
- 發起人，開發者和使用者應該步調一致；
- 不斷地關注技術上優越的設計會提高敏捷性；
- 簡潔是最重要的，簡潔就是儘量減少工作量的藝術；
- 最佳的架構，需求和設計來自於自組織的團隊；
- 團隊要定期反省如何使工作更有效，然後相應地調整行為。
迭代開發
敏捷開發是一種迭代和增量開發（iterative and incremental development (IID)），IID通過把專案分割成一各個的2周到4周的迭代週期來獲取反饋資訊，每次迭代輸出的都是可以工作的軟體開發結果。每次迭代相當於一個單獨的專案，能釋出一個可以應用的產品。當然在初始的迭代中，也許只能看到軟體在測試環境中的情況或者原型。敏捷開發中的成員角色分為客戶和開發者，客戶定義和測試產品，開發者建立產品。入式軟體工程師需要理解反饋，設計的控制系統通常都有反饋機制來讓系統可控。基於迭代的敏捷專案能提供對專案至關重要的引數，如進度安排、需求和設計。把敏捷當做軟體開發的控制系統好了。專案預測、計劃和組織工程為若干個迭代。釋出的節奏有利於建立一個可以測量的速度，從而校正開發計劃，監控進度。如每次迭代完成20個點，而擠壓的工作有200個點，那麼可以說10次迭代完成工作。如果要求在8次迭代完成，那麼就需要增加人手，消減功能或者加班了。