پنج فرآیند فرعی FDD و کارهای مربوط به هر کدام به طور مختصر در ادامه تشریح می‌شود.
- ایجاد مدل کلی
کارهایی که در این فرایند فرعی اجرا می‌شود، به شرح ذیل است:
- تشکیل تیم مدل سازی: شامل چندین متخصص توسعه نرم‌افزار (برنامه نویس ارشد) و یک یا چند متخصص دامنه مسئله. تیم تحت راهنمایی یک کارشناس مدل کردن (معمار ارشد) عمل خواهد کرد.
- . چرخه تکرار مدل: متخصصان دامنه خلاصه‌ای از دامنه مسئله را ارائه می‌کنند. سپس، دامنه مسئله به حوزه‌های مختلف تقسیم و دوباره مدل‌سازی می‌شود : هر حوزه به طور جداگانه تحلیل می‌شود و مطابق کارهای 1 تا 4 مدل‌سازی می‌شود. مدل‌های به دست آمده، در کار جمع می‌شود و مدل اصلی را ایجاد می‌کنند. توصیفات مدل نیز طی کار 6 اضافه می‌شود. این دوره آن قدر تکرار می‌شود تا زمانی که تمام حوزه‌های دامنه مسئله، به اندازه‌ای که موجب رضایت معمار ارشد باشد، پوشش داده شود و مدل‌سازی گردد. کارهایی که در هر تکرار دوره انجام می‌شوند عبارت‌اند از:
- هدایت جلسه بررسی خطاهای حوزه‌های دامنه: که توسط متخصصان دامنه ارائه می شود.
- مطالعه اسناد حوزه های دامنه مسئله (اگر موجود باشد).
- توسعه مدل‌های تیمی کوچک از دامنه مسئله با تقسیم تیم مدل‌سازی به تیم‌های کوچک‌تر (نه بیشتر از سه عضو)، و گماشتن هر تیم به توسعه نسخه خود از مدل شیءگرا برای دامنه مسئله. هر مدل شامل نمودارهای دسته با تمام ویژگی‌ها (شامل دسته‌ها، ارتباط داخلی آنها، و فیلدها و توابع دسته ها) خواهد بود، و در صورت لزوم، تعدادی نمودار ترتیب که آثار متقابل معمول بین اشیاء موجود در مدل را نمایش می‌دهند.
- توسعه مدل تیم از دامنه مسئله، با بررسی مدل‌هایی که توسط تیم‌های کوچک ساخته شده است. تیم، یا یکی از مدل‌های پیشنهاد شده را به عنوان مدل تیم ارتقا می دهد، یا مدل تیم را با ادغام کردن دو یا چند مدل تیمی کوچک تهیه می‌کند.
- اصلاح مدل جامع با تجمیع مدلی از دامنه مسئله با مدل جامعی که تا به حال ایجاد شده است. طبیعتاً چنین کاری نیاز به تغییرات دارد.
- نوشتن توصیفات مدل، جنبه‌های خاصی از مدل توضیح داده می‌شود که به صراحت در خود مدل مطرح نشده‌است؛ به خصوص گزارش‌هایی از روش‌های جایگزینی که تیم مدل‌سازی در طی فرایند مدل‌سازی بررسی کرده است.
- تهیه فهرست ویژگی ها
کارهایی که در این فرایند صورت می‌گیرد، به شرح زیر است:
- تشکیل تیم برای هر فهرست ویژگی، که شامل برنامه‌نویسان ارشد شرکت‌کننده در تیم مدل‌سازی فرایند فرعی قبلی است.
- تهیه فهرست ویژگی‌ها، که یک فهرست سلسله مراتبی سه لایه با ساختار زیر است :
- فهرستی از حوزه های دامنه مسئله (مجموعه ویژگی های اصلی)
- برای هر حوزه، فهرستی از فعالیت‌ها (مجموعه ویژگی‌ها) در داخل آن حوزه.
- برای هر فعالیت، فهرستی از ویژگی‌ها که گام‌های فعالیت را نشان می‌دهند.
فهرست ویژگی در یک فرایند از بالا به پایین طراحی می شود: تیم فهرست ویژگی، ابتدا حوزه‌ها (مجموعه ویژگیهای اصلی) را با بررسی دقیق اطلاعات به دست آمده از دامنه مسئله شناسایی می‌کند، به خصوص حوزه های دامنه مسئله (دسته ها) که همزمان با ساخته شدن مدل شیء‌گرای کلی در فرآیند فرعی قبلی، شناخته شده‌اند؛ سپس، فعالیت‌ها در هر حوزه، و ویژگی‌ها (گام‌ها) در هر فعالیت، با به کارگیری تجزیه بر پایه قابلیت‌ها تعریف می‌شود.
- برنامه ریزی بر مبنای ویژگی
کارهایی که در این فرآیند فرعی انجام می‌شوند، به شرح زیر است:
- تشکیل تیم برنامه‌ریزی شامل: مدیر پروژه، برنامه‌نویسان ارشد، و یک مدیر توسعه (که تلاشی برای توسعه را زیر نظر دارد و بدین لحاظ بر برنامه‌نویسان ارشد نظارت دارد).
- تعیین ترتیب فرایند توسعه نرم‌افزار، با برنامه‌ریزی برای ایجاد مجموعه‌های ویژگی و تعیین یک تاریخ (ماه یا سال) برای کامل شدن هر مرحله. این کار نیازمند آن است که وابستگی‌های موجود بین مجموعه‌های ویژگی، توزیع فشار کار در میان اعضای تیم توسعه، و ریسک‌هایی که با مجموعه‌های ویژگی مرتبط شده‌اند، در نظر گرفته شود. سپس، زمان تکمیل هر حوزه (مجموعه ویژگیهای اصلی)، هم چنانکه تاریخ تکمیل آخرین مجموعه ویژگیهای تشکیل دهنده آن تعیین می‌شود، مشخص گردد.
- محول کردن مجموعه‌های ویژگی به برنامه‌نویسان ارشد؛ بدین ترتیب، آنها مالکان مجموعه ویژگی‌هایی که برایشان تعیین شده‌است قلمداد می‌شوند.
- محول کردن دسته‌ها (حوزه‌ها) به برنامه‌نویسان؛ بدین ترتیب برنامه‌نویسان مالکان دسته‌ها قلمداد می‌شوند.
- طراحی بر مبنای ویژگی
کارهایی که در این فرآیند فرعی انجام می‌شوند، به ترتیب به شرح زیر است:
- تشکیل تیم ویژگی‌ها، که ویژگی(های) انتخاب شده برای توسعه در دوره تکراری جاری را، زیر نظر برنامه نویس ارشد که مالک ویژگی‌ها است، طراحی و پیاده می‌کند. پس از شناسایی مجموعه دسته‌هایی که ممکن است در تشکیل این ویژگی‌ها سهیم باشند، برنامه نویس ارشد، مالکان این دسته‌ها را گرد هم می‌آورد و تیم ویژگی‌ها را شکل می‌دهد.
- هدایت جلسه بررسی خطاها (اگر نیازی باشد)، با دعوت از متخصصان دامنه برای کمک به تیم ویژگی‌ها تا تمام حالات خاص مرتبط با ویژگی‌ها را درک کنند. این عملیات معمولاً برای ویژگی‌هایی با ریسک بالا انجام می‌شود، که ایجاد آنها نیازمند درک عمیق‌تر داده‌ها، الگوریتم‌ها، و محدودیت‌های مسئله است.
- مطالعه اسناد مرجع(اگر وجود داشته باشد)، برای دستیابی به درک بهتر ویژگی‌ها، مانند کار قبلی، این کار نیز معمولاً برای ویژگیهای با ریسک بالا که اسناد توصیفی در حال حاضر برای آنها موجود است اجرا می شود.
- ایجاد نمودارهای توالی که مانند قسمت‌های محوری مدل‌های طراحی مورد نیاز است تا نشان دهد که تأثیر متقابل اشیا باید در حین اجرا چگونه باشد تا هر یک از ویژگی‌ها ایجاد شود. تیم ویژگی، همچنین محدودیت‌ها و فرضیات مرتبط و مدل‌های طراحی جایگزین را که بررسی کرده‌است، با دقت ثبت می‌کند.
- اصلاح مدل شیءگرا (نمودارهای دسته) طوری که نمودارهای ترتیب به دست آمده از عملیات قبلی را تأیید کند. این بدان معناست که معمولاً اجزای جدیدی به مدل اضافه می شوند، بعضی از عناصر موجود تغییر می‌کنند، و در نتیجه باید مدل مجدداً بررسی و ساده‌سازی شود.
- آن نوشتن بدنه اولیه دسته‌ها و توابع آنها برای اجزای مدل شیءگرا، این جزئیات نسبتاً سطح پایین طراحی توسط مالکان دسته‌ها به عنوان آخرین اسناد طراحی که قبل از شروع برنامه‌نویسی مورد نیاز است تولید می شوند.
- بررسی طراحی توسط تیم ویژگی ها (در صورت امکان، با مشورت با دیگر اعضای پروژه) به منظور تأیید صحت اسناد طراحی تولید شده، انجام می شود.
نتیجه این فرآیند به صورت یک بسته به فرآیند فرعی بعدی انتقال پیدا می‌کند. این بسته طراحی شامل این موارد است: نمودارهای توالی تولید شده، اصلاحات مدل شی‌گرا، محدودیت‌ها، فرضیات و توصیفات طراحی‌های جایگزین که بررسی شده‌اند.
- ایجاد بر مبنای ویژگی
کارهای این فرآیند فرعی که به ترتیب عبارت اند از:
- پیاده‌سازی دسته‌ها و توابع آنها مطابق مشخصات داده‌شده در بسته طراحی، هر یک از مالکان دسته‌ها موارد لازم را (شامل برنامه های مربوط به آزمایش بخش ها) در دسته‌های مربوط به خودشان پیاده می‌کنند.
- بازرسی کد برنامه ها، قبل یا بعد از آزمایش بخش‌ها، که طی آن تیم ویژگی کد برنامه را برای اطمینان از درستی و مطابق بودن با استانداردهای برنامه نویسی امتحان می‌کند.
- آزمایش بخش‌های کد برنامه برای اطمینان از اینکه تمام دسته‌ها قابلیت مورد نیاز را ایجاد می‌کنند. مالکان دسته‌ها آزمایش بخش‌ها در سطح دسته‌ها و همچنین آزمایش بخش‌ها در سطح ویژگی‌ها را آن گونه که برنامه‌نویس ارشد مقرر می‌کند، اجرا می‌کنند.
- تبدیل به محصول. اگر بازرسی و آزمایش بخش‌های دسته‌های پیاده‌سازی شده موفقیت آمیز باشد، وظیفه برنامه‌نویس ارشد است که در مقام رهبر تیم ویژگی، مطمئن شود تمام دسته‌های مورد نیاز برای تحقق ویژگی‌ها، نهایتاً در نسخه اصلی برنامه قرار گرفته‌اند.
نقش‌ها و مسئولیت‌ها
در FDD نقش‌ها در 3 گروه دسته‌بندی شده‌اند: نقش‌های کلیدی، نقش‌های پشتیبان و نقش‌های اضافی.
- 6 نقش کلیدی عبارتند از: مدیر پروژه، مسئول معماری، مدیر توسعه، مسئول برنامه‌نویسی، صاحب گروه و کارشناسان دامنه.
- 5 نقش پشتیبان عبارتنداز: مدیر انتشار/عرضه، وکیل/معلم زبان، مهندس اجرا، ابزارساز و مدیر سیستم.
- 3 نقش اضافی که در هر پروژه‌ای نیاز هستند عبارتند از: آزمونگرها، ارائه دهندگان و نویسندگان فنی.
ممکن است یکی از اعضای تیم بتواند چند نقش را ایفا کند و یا یک نقش بین چند نفر تقسیم شود.
روش‌های کار FDD
همانند سایر متدهای چابک، اثر FDD روی سازمان با روش‌های کار آن بهتر سنجیده می‌شود تا فرایند آن. FDD بر مبنای هشت روش کار شکل گرفته است:
- مدل سازی دامنه
FDD با ساخت مدلی نسبتاً دقیق از سیستمی که قرار است ایجاد شود شروع به کار می کند. این مدل به دنبال طرح تمام جزئیات ویژگی‌ها نیست. بلکه هدف آن تأمین نقشه راهی برای پروژه است.
با اینکه مدل اولیه در ابتدای پروژه ساخته می‌شود، هر افزایش منتج از توسعه در آن لحاظ می‌شود، همان‌طوری که جزئیات به آن اضافه می‌شوند و اصلاحات صورت می‌گیرد. بنابراین، این مدل به طور مستمر محصول نهایی پروژه را تغییر می‌دهد.
- توسعه بر مبنای ویژگی
این مدل تمامی بخش‌های سیستم را شناسایی می‌کند، اما توسعه بخش به بخش صورت نمی‌گیرد. بلکه FDD مستلزم آن است که توسعه‌دهنده یک ویژگی در زمان باشد. FDD حد زمان توسعه یک ویژگی را دو هفته تعیین می‌کند.از آنجا که توسعه ویژگی ممکن است نیازمند تغییر یا افزودن بخش‌هایی به حوزه‌های متعددی باشد، دو روش کار بعدی در این متد به منظور مدیریت این روش کار (توسعه بر مبنای ویژگی) شکل گرفته‌اند.
- مالکیت بخش‌ها
FDD از پیش تعیین می‌کند که هر توسعه‌دهنده مالک یک بخش است. این مطلب مغایر با روش کار “مالکیت مشترک “در متدXP است و فلسفه خاصی هم دارد. در این روش توسعه ویژگی بستگی به درک کامل و دقیق مالک بخشی از محتوای بخش خود دارد. فلسفه این روش کار، این است که چنین فردی بهتر از هر فرد دیگری در تیم پروژه می تواند در این بخش تغییرات ایجاد کند. البته خاطر این روش کار هم این است که از دست دادن اعضای تیم می تواند فاجعه‌آمیز باشد.
این روش کار اساساً نیازمند آن است که مالک بخش مستقیماً در توسعه هر ویژگی که می‌تواند روی بخش او تأثیر بگذارد مشارکت داشته باشد. روش کار بعدی نحوه مدیریت این نیاز را تعیین می کند.
- تیم‌های ویژگی
هر ویژگی توسط تیمی متشکل از اعضای پروژه اجرا می‌شود که شامل مالک ویژگی (برنامه‌نویس ارشد)، و مالکان تمام بخش‌هایی است که از آن ویژگی متأثر می‌شوند. با مشارکت مستقیم متخصص هر بخش، هر ویژگی باید به سرعت و به بهترین نحو ایجاد شود. اگر حین ایجاد یک ویژگی، تیم دریابد که بخش دیگری باید تغییر کند، مالک آن بخش به سرعت به تیم ویژگی ملحق می‌شود.
بنابراین، در روش FDD، تیم‌های ویژگی بخشی پویا را تشکیل می‌دهند که بر مبنایی هفتگی یا روزانه، بسته به مدت زمان ویژگی، شکل می‌گیرند. هر تیم ویژگی تا زمانی که ویژگیهای مورد نظرش را مشخص و به مبنای جاری محصول منتقل نکند، کارش تمام نشده است.
- بازرسی‌ها
در FDD بازرسی‌های متعددی صورت می‌گیرد تا اطمینان حاصل شود که کیفیت طراحی‌ها و کدهایی که ایجاد شده‌اند مطلوب است.
هدف اصلی از بازرسی‌ها شناسایی نواقص در طراحی‌ها و کدها است؛ اما، این کار دو هدف مهم دیگر را نیز دنبال می‌کند. اول، کاهش ریسک روش کار مالکیت بخش ها؛ با اطمینان از اینکه بیشتر اعضای تیم پروژه درک درستی از هر بخش دارند. دوم، اطمینان از اینکه استاندارد کدنویسی پروژه سازگاری کامل دارد.
- زمان بندی منظم ایجادها
FDD از قبل هیچ گونه زمان‌بندی خاصی را برای ایجادها تعیین نمی‌کند، به جز اینکه منظم باشند. اینکه ایجادها هر چند وقت یکبار باید صورت گیرند، بر مبنای نیازها، قیود و محیط پروژه تعیین می‌شود. با این حال،FDD به دنبال آن است که ایجاد کمتر از یک هفته طول بکشند.
نظام ایجادها برقرار می‌شود تا سیستم به روز باقی بماند. سپس این سیستم می‌تواند مبنایی برای آزمودن هر ویژگی جدیدی باشد.
- مدیریت پیکربندی
این روش کار اهمیت مدیریت پیکربندی درست را برای موفقیت پروژه FDD باز می‌شناسد. پویایی تیم‌های ویژگی و زمان‌بندی منظم ایجادها، مدیریت دقیق ساخته‌های پروژه را ضروری می کند. با این حال، این متد از پیش، حرفی درباره مدیریت پیکربندی نمی‌زند. به سادگی معلوم است که تیم پروژه سطحی از مدیریت پیکربندی را که برای اندازه، پیچیدگی و گستره پروژه مناسب باشد به کار می‌گیرد.
- گزارش نمایش نتایج
FDD از سازوکار منحصر به فردی برای پیگیری و گزارش‌دهی پروژه استفاده می‌کند. این ساز و کار از فهرست ویژگیهای پروژه، مایلستون‌های توسعه ویژگی، به همراه چند معیار وزن‌دهی به مایلستون‌ها استفاده می‌کند.
FDD تمام مایلستون‌ها را برای هر ویژگی به صورت زیر تعریف می‌کند:
- جلسه بررسی دامنه – تکمیل شده است.
- طراحی – آماده بازرسی است.
- بازرسی طراحی – و هر گونه دوباره‌کاری و بازرسی مجدد آن تکمیل شده است.
- کد نویسی – آماده بازرسی است.
- بازرسی کد – هرگونه دوباره کاری و بازرسی مجدد ان تکمیل شده است.
- ارتقا به مرحله تولید – تمامی کدهای ویژگی بررسی شده و آماده برای ایجاد بعدی است.
جمع بندی
در این مقاله دریافتیم که توسعه ویژگی محور FDD یک رویکرد عملی چابک است که برای پروژه های طولانی مدت و پیچیده مناسب است. این یک انتخاب مناسب برای تیم های توسعه است که به دنبال یک روش ساده اما ساختار یافته چابک هستند که مقیاس پذیر باشد و نتایج قابل پیش بینی ارائه دهد.
توسعه ویژگی محور، جنبه‌های سنتی (مانند ساختار مدیریت سنتی‌تر از بالا به پایین و برنامه‌ریزی اولیه‌تر) را با شیوه‌های چابک (مثلاً تحویل محصول تکراری و افزایشی، تمرکز بر ارزش تجاری برای مشتری و کاربر نهایی) ترکیب می‌کند. این ترکیب راهی برای معرفی چابک در شرکت های بزرگتر ارائه می دهد که بیشتر تکاملی است تا انقلابی.
بنابراین، اگر اولین قدم‌های خود را در مسیر چابکی برمی‌دارید، FDD را با جزئیات بیشتری بررسی کنید. ممکن است این پل تکاملی باشد که تحول شما و سازمانتان را تسریع کند.
عسل نصیری ۵ تیر ۱۴۰۱
مقاله خیلی جالب و کاملی بود ممنون از آکادمی احمدزاده
سحر جاوید ۶ تیر ۱۴۰۱
ممنون مطلب خیلی ماربردی بود. به شخصه اطلاعی نداشتم در این باره
امید فنایی ۶ تیر ۱۴۰۱
چابک چقدر گسترده و کاربردی هست. ممنون از مقالات خوب شما.
حمیده نظری ۲۸ تیر ۱۴۰۱
توسعه ویژگی محور یک رویکرد عملی چابک است که برای پروژه های طولانی مدت و پیچیده مناسب است. این یک انتخاب مناسب برای تیم های توسعه است که به دنبال یک روش ساده اما ساختار یافته چابک هستند که مقیاس پذیر باشد و نتایج قابل پیش بینی ارائه دهد.