فرآیند
کار در DSDM با فاز پیشاپروژه آغاز می‌شود. در این فاز توجیه‌پذیری پروژه را به‌کوتاهی بررسی و نتیجه را همراه با اطلاعات تکمیلی در سندی با نام terms of reference ذخیره می‌کنیم. تصمیم‌گیرندگان با کمک این اطلاعات فرمان توقف کار یا اجرای فاز بعدی را می‌دهند.
فاز بعدی، توجیه‌پذیری است. در این فاز زمان بیشتری صرف شناسایی پروژه و جنبه‌های کسب و کار، فنی، و مدیریتی آن می‌کنیم. اطلاعات گردآوری شده در سند ارزیابی توجیه‌پذیری ذخیره می‌شوند و برای تصمیم‌گیرندگان فرستاده می‌شوند تا فرمان توقف پروژه یا اجرای فاز بعد را بدهند.
فاز سوم شالوده است. در این فاز برنامه کلان پروژه را آماده می‌کنیم که شالوده پروژه به شمار خواهد رفت. بر پایه برنامه کلان می‌توان درک بهتری از توجیه‌پذیری آن نیز پیدا کرد و همه این اطلاعات در قالب سندی با نام چکیده شالوده در اختیار تصمیم‌گیرندگان قرار می‌گیرد.
اگر پروژه توجیه‌پذیر باشد، آن را در فازی تکرار شونده با نام توسعه تکاملی اجرا خواهیم کرد. در هر چرخه این فاز نسخه تازه‌ای از محصول پروژه آماده می‌شود و مانند همه پروژه‌های چابک برای گردآوری بازخورد و روشن کردن مسیر پیش رو به کار می‌رود.
فاز دیگر، انتشار است. این فاز را می‌توان پس از هر چرخه توسعه تکاملی یا با بسامدی کمتر تکرار کرد. در هر تکرار، تازه‌ترین نسخه نرم‌افزار در اختیار کاربران نهایی قرار می‌گیرد.
در DSDM فاز جداگانه‌ای برای پایان پروژه وجود ندارد و بخشی از آن از این روست که بسیاری از کارهای پایانی به تدریج در فاز انتشار انجام می‌شوند.
واپسین فاز، پساپروژه است که در آن منافع محصول پس از پایان پروژه رصد می‌شوند.
مدت‌زمان پروژه در DSDM ثابت است و حتی یک روز هم طولانی‌تر نمی‌شود. به عبارت دیگر، پروژه را تا زمانی که همه قابلیت‌ها ساخته شوند ادامه نمی‌دهیم، بلکه آن را تا زمان مقرر ادامه داده، حداکثر قابلیت‌هایی که امکان‌پذیر باشد را می‌سازیم. برای ساخت محصول در چنین سیستمی از تکنیک اولولیت‌بندی مسکو (MoSCoW) استفاده می‌شود. عبارت MoSCoW در این تکنیک مخفف این موارد است:
- (M)ust-have: قابلیت‌هایی هستند که ناگزیر باید در محصول نهایی باشند و بدون آن‌ها امکان استفاده از محصول وجود نخواهد داشت. موارد امنیتی در یک نرم‌افزار بانکی نمونه‌ای از این‌گونه قابلیت است.
- (S)hould-have: قابلیت‌هایی هستند که برای محصول کاملا لازم هستند و بدون آن‌ها به مشکل برخواهیم خورد، ولی می‌توان برای آن مشکل‌ها راهکارهایی یافت. برای نمونه، شاید بتوان به روشی دستی به هدف دست یافت.
- (C)ould-have: این‌ها قابلیت‌های جالبی هستند که می‌توانند ارزش محصول را افزایش دهند، ولی بدون آن‌ها مشکلی نیز به وجود نخواهد آمد. برای نمونه، امکان انتخاب میان تم رنگ روشن و تیره در نرم‌افزار بانکی این‌چنین است.
- (W)on’t-have: عناصری که ارزشی اضافه نمی‌کنند یا به هر دلیل دیگر مایل نیستیم در نرم‌افزار وجود داشته باشند.
در فازهای توجیه‌پذیری و شالوده، فهرستی از قابلیت‌های کلی نرم‌افزار فراهم کرده، با کمک روش مسکو اولولیت‌بندی می‌کنیم. این فهرست اولویت‌بندی شده قابلیت‌ها به‌تدریج در هنگام کار تفصیلی‌تر می‌شود.
برای این‌که پروژه انعطاف‌پذیری به‌اندازه داشته باشد لازم است که حجم قابلیت‌های (M) کمتر از ۶۰٪ باشد و حداقل ۲۰٪ از آیتم‌ها از نوع (C) باشند. وقتی مدت‌زمان لازم برای پروژه برآورد می‌شود،
- باید در حالت خوش‌بینانه برای به پایان رساندن همه آیتم‌ها کافی باشد، و
- در حالت بدبینانه برای به پایان رساندن آیتم‌های (M) کافی باشد.
در هنگام کار، وضعیت پروژه دایما ارزیابی می‌شود و پیش‌بینی می‌کنیم که تا زمان پایان پروژه چه آیتم‌هایی تکمیل خواهند شد. اگر پیش‌بینی کنیم که تا پایان پروژه امکان تکمیل همه (M)ها وجود نخواهد داشت، باید مسئله را به مدیران ارشد اعلام کنیم که یا پروژه را لغو کنند یا تغییرهایی بنیادین در آن بدهند.
به عبارت دیگر، در چنین پروژه‌هایی تضمین می‌کنیم که همه (M)ها تکمیل خواهند شد، کوشش می‌کنیم (S)ها را نیز کامل کنیم، و اگر توانستیم (C)ها را هم خواهیم ساخت.