筆者做敏捷項目已經近兩年時間，對于敏捷的理解，認為最為關鍵的是需要注意兩個方面，它們是“高度迭代”和“持續不斷的客戶反饋”。
- 高度迭代：迭代就是指產品的開發過程中，一個完整的開發活動周而復始的進行，產品的功能、性能、可用性在周期活動的疊加中不斷得到更新和加強。甚至指在一個迭代周期內產品活動也具顯著的周期性。同時，團隊間、團隊內部成員的高度協作及時幫助解決了各成員的依賴性問題，因此，也促進了各個成員工作的順利開展，保障了產品活動穩定的持續性、周期性。以測試為例，傳統開發模式下，測試人員可以因進入測試階段的條件不完全滿足而繼續的等待。而在高度迭代的敏捷項目里，不同的是，我們希望測試人員能夠盡可能的做能夠做的工作，盡可能的早工作�！暗却痹诿艚蓍_發、敏捷測試范疇里已是一種錯誤概念了。
- 持續不斷的客戶反饋：指在產品開發任何時期，代表項目業務（Business）的利益干系人（Stakeholder）都要參與到產品的需求分析，設計，以及其他活動的決策制定中來。致力于在短時間內幫助團隊實現將客戶的需求轉化為高質量的可消費產品，并轉化成利潤。
敏捷開發自 2001 年《敏捷宣言》（“AGILE MANIFESTO”） 1 的創生，經過多年的打磨和退火已經成為今天非常流行和有過許多成功案例的開發模式。正如前人所說，傳統的東西就是用來打破的，傳統的瀑布式開發模式必然逐漸退出歷史舞臺，敏捷開發、敏捷測試是在新環境里產生出來的打破傳統的新開發模式。而敏捷也將會在將來，甚至現在轉化成更適合現代化軟件開發、測試團隊的方法和實踐。在本文的第一部分，我們以兩個游戲類比了敏捷和傳統開發的差異，這里為了進一步幫助大家對敏捷的價值有更清晰的理解，我們借鑒前人的研究結果：
圖 2. 敏捷與傳統開發的比較
首先敏捷開發過程比傳統開發要為項目和產品帶來更低的風險（RISK）。為什么呢？傳統開發缺乏持續的客戶反饋 , 產品一旦從需求階段退出，整個開發團隊近似封閉工作，團隊雖努力去實現曾經認定的目標，但因月有陰晴圓缺，市場需求也瞬息萬變（例如提出需求的客戶已經退休）。這使得產品在數月后，數年后發布時已經失去了占領甚至進入市場的最佳契機。
而如果你還在考慮使用傳統開發模式用現在乃至將來一、兩年的時間來開發一個結構復雜，精益求精而又功能龐大的產品，那么你得好好做好失敗的準備了。而正是因為出于對這種風險的考慮，越來越多的人認識到敏捷開發要比傳統開發能夠為企業帶來更大的利潤空間和更低的投資風險。