DSDM در چابک چیست؟

روش توسعه‌ی سیستم‌های پویا (DSDM)

روش توسعه ی سیستم های پویا (DSDM) در انگلستان در سال 1994 توسط کنسرسیومی از شرکت‌های انگلیسی معرفی شد. این کنسرسیوم در آغاز با 16 شرکت آغاز به کار کرد. اما اکنون بیش از 1000 عضو دارد و شرکت های صنعتی عظیمی مانند IBM، مایکروسافت و زیمنس عضو آن هستند. مبنای این روش این است که به جای ثابت در نظر گرفتن ویژگی‌های محصول و تنظیم زمان و منابع، زمان و منابع را ثابت درنظر گرفته و ویژگی‌های محصول را براساس آن تنظیم می‌نماید.

پیش از مطالعه این مقاله، برای اطلاعات بیشتر مقاله ی “مدیریت چابک چیست” را مطالعه کنید.

فرآیندهای روش توسعه‌ی سیستم‌های پویا

آخرین نسخه‌ی فرایندهای DSDM شامل 7 مرحله است. با این حال، مراحل اول و آخر، جز مراحل اصلی در نظر گرفته نمی‌شوند. زیرا به عنوان بخشی از پروژه محسوب نمی‌شوند. این مراحل عبارتند از:

• پیش از پروژه: در این مرحله تمرکز بر تامین منابع ضروری برای آغاز پروژه است. همراه با برنامه‌ی (امکان‌سنجی) برای مرحله بعدی است.
• هنگام پروژه: در این مرحله پنج مرحله اصلی DSDM قرار دارند که دو مرحله اول به طور متوالی(مطالعه دامنه تجاری (امکان سنجی) و انجام تحلیل اولیه سیستم (طرح توجیهی) ) و سه مرحله باقی‌مانده به صورت چرخه‌های درهم تنیده هستند. (شامل مراحل تکرار مدل وظیفه ای، تکرار طراحی و ساخت و اجرا). این مراحل در زیر نشان داده شده است:

• پس از پروژه: در این مرحله تمرکز بر تعمیر و نگهداری سیستم است. (مشابه بیشتر تکنیک‌های تکراری –افزایشی) که از طریق تکرارهای بیشتر مراحل اصلی به کار گرفته شده است.

در ادامه توصیفی مختصر از کارهایی که در هر  5 مرحله اصلی DSDM صورت می‌گیرد آورده شده است:

1. امکان سنجی: در این مرحله کوتاه که بیشتر از چند هفته زمان نمی‌برد، کارهای زیر صورت می‌گیرد:

• کسب دانش کلی به اقتضای طبیعت پروژه، گستره، ریسک ها و محدودیت‌های آن.
• بررسی مناسب بودن روش DSDM برای پروژه. این کار با استفاده از فهرست معیار‌های سازمانی پروژه روی پروژه صورت می‌گیرد که “فیلتر مناسب بودن”، نامیده می‌شوند. این فیلترها، ویژگی‌هایی را که پروژه باید داشته‌ باشد تا DSDM در آن کاربرد داشته باشد را تعیین می‌کند. فهرست زیر تعدادی از این ویژگی‌ها را که اهمیت بیشتری دارند در بر می‌گیرد:
  • سیستمی که ایجاد می‌شود باید تعامل درونی و همچنین قابلیت‌های بسیار مشهودی مثل نمایش، گزارش و کنترل برای کاربر داشته باشد. بنابراین، این امکان را فراهم می‌کند که نمونه‌ها به صورت مؤثر به کار گرفته شوند.
  • سیستم باید به خوبی گروه‌های کاربر را تعریف کرده ‌باشد که در نتیجه نمایندگان کاربر را می‌توان شناسایی و مانند مشارکت کنندگان فعال درگیر کار کرد.
  • سیستم نباید از نظر محاسباتی پیچیده باشد (بیشتر تجارت محور باشد تا علم محور).
  • استنباط، تشخیص، اولویت‌بندی یا اجرای انفرادی خواسته‌ها نباید پیچیده باشند.
  • نباید قید یا مسئله مهمی وجود داشته باشد که توسعه‌دهندگان مجبور شوند قبل از کد نویسی، خواسته‌ها را به صورت کامل مشخص کنند.
  • اگر سیستم بزرگ است، باید امکان قسمت کردن آن وجود داشته باشد.
  • مشاور مدیر ارشد باید اصول DSDM را فهمیده و آن را پذیرفته باشد.
• انجام فعالیت‌های سنتی تحلیل، امکان سنجی و داشتن توجه خاص به تکنولوژی، زمانبندی و امکانات مدیریتی.

نتایج این سه کار اول در گزارش امکان‌سنجی جمع می‌شوند. گزارش ممکن است با نمونه‌سازی اولیه از سیستم تکمیل شود که “نمونه امکان‌سنجی” نامیده می‌شود. هدف اصلی آن تشخیص گستره و امکان‌پذیری فنی پروژه است.

2. طرح توجیحی: طرح توجیهی عمدتاً کارهایی را که در ادامه آمده در بر می‌گیرد:

• شناسایی فرآیندها و اطلاعات موجود در دامنه تجارت که به سیستم وابسته‌اند، مانند انواع کاربرانی که با سیستم تعامل دارند یا از آن تأثیر می‌پذیرند. فهرستی از انواع کاربران و شناسایی نمایندگان کاربران که برای مشارکت در کارهای بعدی کمک خواهند کرد.
• تعیین و اولویت‌بندی خواسته‌های اصلی و فرعی سیستم به صورت کلی این خواسته‌ها بر طبق چیزی که DSDM قوانین MOSCOW می‌نامد، اولویت‌بندی می‌شوند. دسته‌بندی خواسته‌ها به صورت زیر است:
  • باید باشند: خواسته‌های ضروری که موفقیت پروژه به آن وابسته است.
  • باشند: خواسته‌های مهمی که برای موفقیت پروژه ضروری نیستند.
  • می‌توانند باشند: خواسته‌هایی که اثر مهمی بر روی پروژه ندارند و می‌توانند از عملکرد سیستم حذف شوند.
  • نباشند: خواسته‌هایی که بخشی از عملکرد پروژه نیستند.

پروژه باید دستیابی به خواسته‌های نوع اول را تضمین کند و برای رسیدن به خواسته‌های نوع دوم با جدیت تلاش کند. خواسته‌های نوع سوم تنها در صورتی محقق می‌شوند که زمان و منابع، این امکان را فراهم کنند نتایج این دو کار به “سند تعیین دامنه تجارت” شناخته می‌شوند.

3. تکرار مدل وظیفه‌ای: در این مرحله، تکرار فرآیند برمبنای مشخصاتی که حین طرح توجیهی به اختصار بیان شدند. تحلیل‌های دقیق سیستم‌ها از طریق ارزیابی نمونه اولیه انجام می‌گیرد. کارهای زیر باید در کل این مرحله انجام شوند:

• تحلیل ریسک به منظور ارزیابی ریسک‌هایی که در توسعه خواسته‌ها وجود دارند. این تحلیل حین تکرارها پالایش می‌شود. بر مبنای بازخورد و تجارب به دست آمده از نمونه‌ها، و در نهایت منجر به گزارش تحلیل ریسک توسعه می‌شود.
• انتخاب خواسته‌ها بر طبق ریسک توسعه آن‌ها (ریسک بالاتر به معنی اولویت بالاتر) و ساخت مکرر نمونه‌های اولیه اصلی به منظور نشان دادن وظایف نمایندگان کاربران و پالایش خواسته‌ها بر مبنای بازخوردها. آزمون ها حین فعالیت‌های نمونه‌سازی با جدیت انجام می‌شوند، و سوابق با دقت ثبت می‌شوند. نمونه‌هایی که در این مرحله تولید می‌شوند، نه تنها نطفه‌ای است که سیستم نهایی در نهایت، از آن منتج خواهد شد، بلکه بخش اصلی مدل وظیفه‌ای سیستم را نیز تشکیل می‌دهند.
• اصلاح و فهرست کردن خواسته‌های فرعی این فهرست نیز جزء تشکیل‌دهنده مدل وظیفه‌ای است.
• در صورت لزوم، استفاده از مدل‌های ثابت (نمودارهای کلاسیک) برای مدل کردن جنبه‌های ساختاری حوزه دامنه‌ای که تحلیل شدند. این مدل‌ها نیز به مدل وظیفه‌ای ملحق می‌شوند.
• کارهای زیر به صورت پی در پی در تکرار‌ها صورت می‌گیرند (مشابه فعالیت‌های چرخه نمونه‌سازی‌های سنتی).
  • شناسایی چیزی که باید تولید شود (محصولات) .
  • توافق بر سر زمان انجام تولید (برنامه).
  • تولید محصول (محصولات).
  • بررسی صحت تولید محصولات از طریق بازنگری اسناد، شرح نمونه‌ها (با آزمودن بخشی از سیستم)

4. تکرار طراحی و ساخت: در این مرحله تکرار فرآیند نمونه‌های وظیفه‌ای که در مرحله قبلی تولید شدند تکمیل و اصلاح می‌شوند. نمونه‌های بدست آمده از مدل وظیفه‌ای صرفا با هدف درک اصلاح و مدل کردن خواسته‌ها ایجاد می‌شوند. نمونه‌ها حین عمل طراحی و ساخت به طور مکرر اصلاح می‌شوند و به تدریج به زیرمجموعه نرم‌افزاری کارا تبدیل می‌شوند.

مانند مرحله قبل فعالیت‌هایی که در هر تکرار صورت می‌گیرند مشابه چرخه نمونه‌سازی فعالیت‌های سنتی هستند. آزمون‌ها به طور پیوسته انجام می‌شوند، موارد بررسی می‌شوند، نتایج مربوط حاصل می‌شود و تصمیم‌هایی به دقت اتخاذ و ثبت می‌شوند. نمونه‌های اولیه نیز به عنوان اسناد طراحی نگهداری می‌شوند.

برای اطلاع از چگونگی پیاده سازی، مقاله ی “چابک سازی سازمان ها” را مطالعه کنید

5. اجرا: در این مرحله از پروژه، افزایش‌هایی که در مراحل قبلی ایجاد شده‌اند به محیط کاربر منتقل می‌شوند و با سیستمی که تا به حال ساخته شده یکپارچه می‌شوند. هر تکرار شامل کارهای زیر است:

• آموزش کاربران و کارکنان پشتیبانی.
• تهیه دستورالعمل‌ها.
• انتقال افزایش به محیط عملیاتی؛ این کار طبیعتاً شامل یکپارچه کردن سیستم و تبدیل و تغییر مسائل و به دنبال آن دوباره‌سازی و آزمودن فعالیت‌ها است.
• بازنگری جامع اعتبار سیستم؛ با استفاده از بازخوردی که از کاربران به دست می‌آید و جمع‌آوری نتایج آن در مستندات بازنگری افزایشی براساس نتایج حاصل از بازنگری، موارد جایگزین ممکن است انتخاب شود. چهار حالت ممکن وجود دارد:
  • حالت اول: کلیه خواسته‌های برنامه‌ریزی شده برای رضایت مشتری عملی شدند، در این حالت پروژه پایان یافته تلقی می‌شود.
  • حالت دوم: حین توسعه بخش بزرگی از قابلیت‌ها که باید به دلیل محدودیت تایم باکس رها شوند آشکار می‌شود، در حالی که باید ایجاد می‌شدند. در این حالت، بازگشت به مرحله طرح توجیهی ضرورت دارد.
  • حالت سوم به دلیل محدودیت تایم باکس‌ها بخشی از قابلیت‌ها باید رها شوند در حالی که بایستی تحقق می‌یافتند. در این مورد بازگشت به مرحله تکراری، مدل وظیفه‌ای ضرورت دارد.
  • حالت چهارم: خواسته‌های فرعی باید به دلیل محدودیت تایم باکس نادیده گرفته شوند. در حالی که بایستی تحقق یابند. در این حالت بازگشت به مرحله تکراری، طراحی و ساخت ضرورت دارد.

انتخاب تعداد تکرار‌ها در هر چرخه و روش تکرار‌ها کاملاً وابسته به پروژه و تیم پروژه است. از این گذشته معرفی چند تیم فرعی توسعه با فعالیت موازی این امکان را مهیا می‌کند که مراحل هم‌پوشانی داشته باشند و بعد شکل‌پذیری دیگری به مراحل اضافه شود. بدین ترتیب تمامی این موارد، تیم توسعه را قادر می‌سازد تا فرایند را برای راحتی خود هماهنگ کند.

هنگام سفارشی‌سازی چارچوب فرایند، تیم توسعه همچنین باید زمانی قطعی (برنامه مقید شده برای توسعه) را مشخص کند. در DSDM قیدهای سختگیرانه‌ای برای منابع و زمان تعریف می‌شوند و خواسته‌ها تنها شاخص قابل تغییر پروژه است. بنابراین، DSDM خصوصاً مناسب پروژ‌هایی با خواسته‌های بسیار است، بر خلاف متدهای کلاسیک که در آن زمان و منابع اجازه تغییر دارند اما گستره ثابت است.

در DSDM قیدهای زمانی با استفاده از تایم باکس تعریف می‌شوند و یک تاریخ ثابت برای تکمیل کل پروژه مقرر می‌شود. یعنی، تعیین چارچوب زمانی کلی که در آن پروژه باید انجام شود.

حین مرحله طرح توجیهی، چارچوب‌های زمانی کوچکتر از ۲ تا 6 هفته، درون این چارچوب زمانی کلی جای داده می‌شوند و همچنین مرزهای موقتی برای چرخه‌های توسعه یا  تکرارها تعیین می‌شوند. به هر تایم باکس یک تاریخ پایان ثابت و مجموعه‌ای از خواسته‌های اولویت‌بندی شده اختصاص داده می‌شود. تاریخ‌های پایان امکان جابه‌جایی ندارند و خواسته‌های با اولویت پایین‌تر، در صورتی که تایم باکس اجازه کار روی آنها را ندهد، قربانی می‌شوند. در این حالت باید در تایم باکس‌های بعدی به آنها پرداخته شود. هر تایم باکس محصولات ملموسی را عرضه می‌کند و بنابراین، مبنایی برای کنترل و نظارت بر پروژه است.

مشابه متدهای دیگر توسعه چابک، DSDM بر اساس اصولی است که مهم‌ترین آن‌ها عبارتند از: مشارکت فعال کاربر، دستاوردهای مکرر، تیم‌های توسعه توانمند، بازگشت پذیری تغییرات و آزمون در همه مراحل پروژه.

نقش‌ها و مسئولیت‌ها

بطور کلی 15 نقش برای مصرف‌کنندگان و توسعه‌دهندگان در DSDM تعریف شده است. مهترین آن‌ها بشرح زیر توضیح داده شده است:

• توسعه‌دهندگان و توسعه‌دهندگان ارشد که تنها نقش‌ها در حیطه توسعه هستند. ارشد بودن نشان دهنده تجربه در آن کار است و همراه با سطحی از مدیریت در تیم است.
• هماهنگ کننده فنی که مسئول تعریف معماری و کیفیت فنی پروژه و کنترل آن است .
• مامور رسمی کاربران که وظیفه او آوردن اطلاعات کاربران به پروژه و دادن اطلاعات پروژه به دیگر کاربران است. به این منظور که شاید مامور رسمی کاربران نتواند تمام نقطه نظرات کاربران را مطرح کند از یک مشاور کاربران استفاده می‌شود.
• یک رویاگرا که یک مشارکت‌کننده از سوی کاربران است و درک قوی از اهداف کسب و کاری پروژه دارد. او تضمین می‌کنند که نیازهای اساسی پروژه تامین شده‌اند و با توجه به آن نیازها پروژه در مسیر درست قرار دارد.
• پشتیبان اجرایی، شخصی از سازمان مصرف کننده است که مسئولیت و قدرت مالی دارد. او همچنین در تصمیم‌گیری مسائل دارای قدرت است.

روش‌های کار  DSDM

برای به کار گیری این متد، سازمان‌ها باید بتوانند این  9 اصل را در سازمان خود رعایت کنند، این اصول در جدول زیر لیست شده‌اند:

جمع بندی

به عنوان یکی از اولین چارچوب های استاندارد چابک، DSDM توسعه نرم افزار را متحول کرده و باعث ظهور رویکردهای دیگری از جمله اسکرام شده است.

هر روش توسعه دارای نقاط قوت و ضعف است. اگر تیم شما برای پیش بینی پذیری، ثبات و کنترل دقیق هزینه ها ارزش قائل است، DSDM ممکن است مناسب باشد. با این حال، خلاقیت و انعطاف‌پذیری خود را از دست خواهید داد، که ممکن است برای استارت‌آپ‌های کوچک‌تر مناسب نباشد.