目前比較流行且為大家所熟知的敏捷開發方法有XP、KANBAN、Scrum、Lean等等，敏捷開發方法一般提供了一系列的基於敏捷思想的最佳實踐，比如XP編程中的結對編程、重構、測試驅動開發、持續集成等優秀實踐。以上這些敏捷方法中，大家最為熟知、企業應用最普遍的可能是Scrum了。嚴格上來說，Scrum並不是具體的敏捷開發方法，而是一種敏捷框架，它定義了一個敏捷骨架。
不同的敏捷開發方法
不同於其他敏捷方法另外一個特點是：Scrum不僅僅適用於軟件開發
成功的實施敏捷開發給企業帶來哪些收益
調查顯示最常見的收益包括：
- 更好的管理變更優先級
- 提升項目透明性
- 更高的產出
- 提升團隊士氣
- 更短的產品上市時間
- ......
<code>"如果，你只是停留在敏捷的理論和僵化的指導性實踐，這可能對你的公司或團隊沒有太大收益。""如果能夠結合企業現狀，不斷的嘗試和持續改進，那麼，敏捷就會給你的公司和團隊帶來收益"/<code>
敏捷和傳統軟件開發方法的選擇
敏捷開發方法和傳統軟件開發方法各都有各自的特點，選擇敏捷還是傳統開發方式要具體情況具體分析。例如，如果項目環境和需求比較穩定、技術可控性強、項目週期短、項目複雜性和風險比較低，選擇傳統軟件開發方式往往更適合。相比，如果技術可控性比較低、需求易變、不太熟悉的新項目等等，可能敏捷開發方法更為合適。
敏捷 vs 傳統軟件開發
敏捷開發方法同樣適用於汽車行業
Scrum、KANBAN、XP等敏捷方法/框架在汽車行業已經有比較多的應用。需要說明的是，這些敏捷的落地並不是完全的照搬，而往往是結合企業現狀進行的 "定製化" 的敏捷。以Scrum為例，沒有企業會完全在企業中完全照搬全部的Scrum模型，而是會採用Scrum中適合企業業務現狀的實踐，同時進行額外的擴展以適應企業研發特點。
<code>"之前也探討過類似的問題，定製化之後還是敏捷開發嗎 ？個人觀點是，定製化之後可能不再是純粹的敏捷了，但，只要是遵循了敏捷哲學(參考敏捷的核心價值觀)，依然可以認為這是 "敏捷" 的。"/<code>
敏捷實踐覆蓋了ASPICE部分過程實踐
我們比較敏捷和ASPICE其實沒有太大意義，因為二者本質上屬於不同的事物。敏捷，是一種軟件開發思想，旨在提供 "更好的軟件開發方法"，其衍生出了指導性的原則、敏捷開發方法和框架以及一些最佳實踐。ASPICE，是用於汽車行業的軟件過程改進和能力評定的標準，其關注點在軟件過程改進和能力評定，提供了過程改進和能力評定模型。
敏捷和ASPICE並沒有明顯的衝突，二者可以共存，就好比是Scrum團隊依然會應用極限編程中的實踐。敏捷方法和實踐支持了一部分ASPICE中的過程，但是要在敏捷實踐和ASPICE之間做一一映射不是件容易的事情。
以MAN.3項目管理過程為例，敏捷實踐如下：產品清單、燃燒圖、發佈計劃、DoD、衝刺計劃、衝刺清單、衝刺評審、每日站會、回顧會議等。
以SWE.4軟件單元測試、SWE.5軟件集成和集成測試過程為例，敏捷實踐：TDD、持續集成和自動化測試、產品增量、重構等。
但是，ASPICE有些過程需要增加一些特定的敏捷實踐才能支持：
以SUP.1質量保證過程為例，以下是需要考慮的方面:
- Srum框架中僅包Development Team、Scrum Master和Product Owner三個角色。質量保證過程需要項目級別的、獨立QA角色，因此，敏捷需要擴展到項目級別，擴展新的QA角色以滿足ASPICE要求。
- "可以工作的軟件勝過面面俱到的文檔" 是敏捷的核心價值觀之一，弱文檔是敏捷的特點，但在質量保證活動的證據需要被文檔化。
敏捷和ASPICE適配中的一些問題
敏捷方法中的工件與ASPICE相關工作產品的同步。
敏捷有 "重個體，弱流程" 的特點，而ASPICE則 “重流程”。
敏捷的角色適當的擴展以滿足ASPICE在項目級別的要求。
ASPICE評審需要證據支持，其中的一些活動和設計需要記錄，另外，ASPICE中系統及軟件架構設計和詳細設計的文檔化至關重要。
敏捷所提倡的短迭代，尤其是Scrum中2-4周的衝刺週期，在ASPICE中可能會有所不同。例如當擴展到系統級別時週期應該適當調整。
閱讀更多 瘋狂架構 的文章
