動態系統開發方法（Dynamic Systems Development Method：DSDM）是在快速應用程式開發（RAD）方法的基礎上改進的。作為敏捷方法論的一種，DSDM方法倡導以業務為核心，進行快速、有效的系統開發，不僅適用於敏捷開發模式，也同樣適用於傳統的開發模式。它既能滿足單個團隊同一地點的簡單產品開發，還能滿足多個團隊不同地點、不同時區的複雜專案開發。
一、DSDM依賴於嚴格的時間控制
與傳統開發方法不同的是，DSDM強調專案的時間是固定的，功能和資源是可變的。也就是說，專案功能和資源的規劃需要配合實際開發效果進行規劃：如果在一週的時間內，功能太多無法交付，那麼就要去掉部分功能，以順利結束這一迭代。其基本觀點是，任何事情都不可能一次性完成，應該用20%的時間來完成80%的有用功能，以適應商業目的為準。因此，對專案任務的優先順序排序是十分重要的，DSDM應用MosCow優先順序排序方法，將專案任務分解為四種不同型別的要求：
- Must：必須做的；
- Should：應該做的；
- Could：可以做的；
- Would not：不要做的。
那麼，為了順利完成“80%”的有用功能，可以首要完成Must、Should項，或者說在完成Must、Should項的基礎上酌情考慮完成Could項。
二、DSDM的角色
任何敏捷開發方法論都有註明他們所構建的系統中應具備的角色，DSDM也不例外：
- 專案負責人——該職位上的人員由使用者或客戶方面推出，他們代表使用者或客戶行使決策權，並能夠根據需要分配資金及資源。
- 專案指導——專案指導者需要深入瞭解使用者業務、具備敏銳性，並有遠見卓識，能夠儘快鎖定最高優先順序要求，並基於此指導團隊來初始化專案。
- 使用者代表——一個理想的“測試使用者”，可以將使用者社群的觀點帶入到整個專案中。他們是整個開發過程中重要的反饋來源。
- 使用者顧問——另一種型別的使用者，應對手中的專案提出新穎或十分重要的觀點，因此，使用者顧問需要有資深的專業知識或其他獨特的專業能力。
- 專案經理——專案經理是管理整個專案的人。
- 團隊負責人——負責協調和促進團隊之間的協作。
- 解決方案開發人員——瀏覽系統要求，進行系統建模，開發可交付的程式碼並建立原型。
- 解決方案測試器——測試產品，並在出現錯誤時提供註釋和文件。在實施更正後，它們還能夠重新測試。
- 抄錄員——記錄專案進度的要求、協議、決定和其他有用資訊。
- 主持人——他們負責激勵和準備研討會，以保持進度的持續穩定。他們必須是使每個人都步入正軌的協調者。
- 專家角色——這些角色由各自領域或行業的專家擔任，根據專案需求提供額外的支援。他們可能因專案而異，也因團隊而異。這樣的角色包括業務架構師、質量經理、系統整合商等等。
三、DSDM的基本原則
- 使用者必須持續參與
使用者不僅提出產品需求，還要參與到開發過程中，及時給出反饋。
- 授予DSDM團隊決策權
DSDM團隊成員被授予能夠在出現問題後直接做出決定的權力。
- 強調產品的經常交付
產品的經常交付能夠讓開發團隊得到快速的反饋，並及時處理交付中發現的問題。
- 滿足業務需求
不要做過多無意義的功能增加，交付完成的標準就是實現產品的業務需求。
- 迭代開發
迭代開發能夠不斷完善業務解決方案，滿足業務需求。
- 開發過程中的所有變化可逆
開發過程要適應變化。
- 在高層次上制定需求的基線
要先達成高層次的目標，再進行需求細化。
- 測試自始自終貫穿於開發週期之中
開發人員完成一個模組的開發後，自己會進行單元測試。當模組整合到現有系統後，測試人員需要執行整合測試。另外，迴歸測試在DSDM中佔有很重要的地位。
- 所有利益相關者之間的通力合作是不可或缺的
產品的交付需要各方的參與、努力，單靠開發團隊是無法成功交付的。
四、DSDM的優勢
DSDM中既有傳統開發的優勢，又有先進的敏捷思維及理念，因此有效實施DSDM能夠幫助團隊得到切實有效的提高：
- 開發過程及結果能夠清晰、明確地展現出來；
- 使用者積極參與開發過程，更能滿足他們的需求；
- 有效的溝通能夠打破中間各環節的交流壁壘；
- DSDM更易於與其他敏捷方法論結合，因地制宜發展適合自己組織的開發方法；
- DSDM不侷限於IT領域，在非IT領域也有著廣泛的應用。