در دنیای چابک همه حواس‌ها معمولاً معطوف به اسکرام و کانبان است اما این دو فریمورک همیشه بهترین گزینه نیستند. برای پروژههای بزرگ، پیچیده و مبتنی بر «فیچر / Feature» که نیاز به ساختار، مدلسازی و پیش‌بینی‌پذیری دارند، «توسعه مبتنی بر فیچر / Feature Driven Development» یک جایگزین قدرتمند است.
FDD در اجایل برای سیستمها و تیمهای بزرگ، پیچیده و در مقیاس سازمانی طراحی شده و نرمافزار را در فرایندی پیوسته در قالب بخش‌های کوچک و ارزشمند - یعنی همان فیچرها - تحویل میدهد.
در این مقاله، توسعه فیچر محور را - از چرخه عمر آن گرفته تا نقشهای FDD - همراه با مثال‌های واقعی بررسی می‌کنیم و در نهایت سعی می‌کنیم به این سؤال پاسخ دهیم که آیا این فریمورک برای تیم شما مناسب هست یا خیر.
روش FDD چیست؟
«توسعه مبتنی بر فیچر / Feature Driven Development» یکی از انواع متدولوژی های اجایل است که حول یک ایده ساده شکل گرفته: تحویل نرم‌افزاری کارآمد به کاربر در قطعه‌های کوچک و ارزشمندی به نام فیچر.
برخلاف عمده چارچوب‌های ذهنیت اجایل، روش FDD در توسعه چابک نرم افزار، بسیار ساختارمند است؛ چیزی که برای سیستم‌های بزرگ و پیچیده که یکپارچگی و هماهنگی تیم ضروری است، بسیار مناسب است.
FDD در اواخر دهه 1990 توسط Jeff De Luca و با همکاری Peter Coad - دو متخصص حوزه IT و توسعه نرمافزار - در حین کار بر روی یک پروژه عظیم توسعه نرمافزار برای یک بانک سنگاپوری توسعه داده شد.
لوکا و کواد در مواجهه با یک سیستم بسیار وسیع، یک تیم بسیار بزرگ و انتظارات بسیار دقیق، برای ایجاد نظم، مسئولیت‌پذیری و پیش‌بینی‌پذیری، مدل Feature Driven Development را طراحی کردند. توسعه فیچر محور خود به‌دنبال خلق آن چیزی است که برای کاربر دارای ارزش و اهمیت است و از طرفی سعی دارد مهار پیچیدگی‌های فنی را به‌دست بگیرد.
توسعه فیچر محور مناسب چه پروژه‌هایی است؟
توسعه مبتنی بر فیچر مناسب سازمان‌ها و پروژه‌هایی است که پیچیدگی بالایی دارند و به مقیاس‌پذیری و ساختارمندی نیاز دارند. این رویکرد معمولاً توسط تیمهای بزرگ و پراکنده و به‌ویژه در صنایعی مانند فین‌تک، بانکداری، مخابرات و فناوری اطلاعات دولتی بهکار گرفته میشود؛ یعنی در پروژه‌هایی که دامنه کار گسترده است اما الزامات کسب‌وکار انعطاف‌پذیر نیستند.
شاید تا اینجا بیشتر از جواب، برایتان سؤال و ابهام ایجاد شده باشد! نگران نباشید، به‌صورت گام‌به‌گام مباحث و اصطلاحاتی که در هر بخش به آن اشاره میشود را با زبانی ساده و شفاف شرح خواهیم داد و این نوید را به شما می‌دهیم که در پایان این یادداشت، FDD و جوانب مختلف آن را به خوبی درک خواهید کرد.
شاید بپرسید «مدلسازی دامنه» یعنی چه؟! مدل دامنه در مهندسی نرمافزار، مدلی مفهومی از دامنه است، که داده‌ها و رفتار آن را در خود جای میدهد.
پیچیده‌تر شد؟ حق دارید! مدلسازی دامنه به زبان ساده یعنی این: تصور کنید می‌خواهید یک شهر کامل را با قطعه‌های لگو بسازید. پیش از ساخت باید بدانید:
-
چه چیزهایی قرار است در این شهر خیالی وجود داشته باشند؟ درخت؟ تیر چراغ برق؟ آدمک‌ها؟ آپارتمان یا خانه‌های ویلایی؟ …
-
اجزای این شهر چگونه در کنار یکدیگر قرار می‌گیرند؟ آدمک‌ها در پیاده‌رو قرار داده میشوند یا ماشین‌ها و راننده‌های لگویی نیز لازم داریم؟
به این می‌گویند مدلسازی دامنه؛ مثل کشیدن یک نقشه ساخت یا Blueprint که همه جزئیات و اجزای مهم و مورد نیاز ساختن یک ساختمان در آن به‌دقت تشریح شده‌اند.
در توسعه نرمافزار مدلسازی دامنه معنای زیر را پیدا میکند:
-
سیستمی که قرار است توسعه داده شود - حالا هرچه می‌خواهد باشد: سایت، اپلیکیشن، نرمافزار، … - چه اجزایی خواهد داشت؟
-
ارتباط این اجزا در نرمافزار چگونه است؟
تصور کنید می‌خواهید یک اپلیکیشن برای سفارش پیتزا توسعه دهید؛ در این «سیستم» شما اجزای زیر را خواهید داشت:
-
مشتری (سفارش‌دهنده)؛
-
مشتری، سفارش خود را ثبت میکند؛
-
هر سفارش، شامل یک یا تعدادی پیتزا میشود؛
-
هر پیتزا شامل چند مورد افزودنی - قارچ، گوجه، فلفل، پنیر اضافه، حتی آناناس! - میشود که مشتری انتخاب میکند.
این میشود فهرستی از آنچه سیستم مورد نظر ما به آن نیاز دارد و به این ترتیب دامنه سیستم را مدلسازی کرده‌ایم.
FDD برای چه نوع پروژه‌هایی مناسب است؟
|
مورد استفاده |
توضیح |
نمونه پروژه‌ها |
|
پروژههای بزرگ سازمانی / Enterprise-Level |
ساختار منظم FDD برای پروژههای چندتیمی و چندلایه با هزاران فیچر کارآمد است. |
سیستم‌های بانکی، ERP، پلتفرم‌های مخابراتی |
|
نرم‌افزارهای دارای ویژگیهای زیاد / Feature-Rich |
پروژه‌هایی که میتوان آنها را به فیچرهای کوچک و قابل‌تحویل شکست. |
پلتفرم‌های SaaS، CMS، موتورهای رزرو آنلاین |
|
پروژههای با دامنه ثابت و نیازمندی‌های مشخص |
مناسب پروژه‌هایی با قوانین کسب‌وکار شفاف و پایدار، چون FDD از مدلسازی دامنه آغاز میکند. |
نرم‌افزارهای بیمه، سیستم‌های اداری بیمارستان‌ها |
|
پروژههای با دامنه ثابت و نیازمندی‌های مشخص |
تقسیم‌بندی دقیق نقش‌ها مدیریت تیمهای گسترده و دورکار را آسان میکند. |
پروژههای برون‌سپاری‌شده، تیمهای چندنقشی (تحلیلگر، طراح، برنامه‌نویس، تستر) |
|
پروژههای نیازمند طراحی قوی و بدون خطا |
تأکید FDD بر طراحی و بازبینی مکرر، ریسک خطا و بدهی فنی را کاهش میدهد. |
سیستم‌های حیاتی: پزشکی، هوافضا، زیرساخت‌های صنعتی |
چه پروژه‌هایی برای FDD مناسب نیستند؟
|
نوع پروژه |
علت ناکارآمدی FDD |
مثال واقعی |
|
پروژههای با اهداف مبهم یا تغییرات زیاد |
FDD به مدلسازی اولیه نیاز دارد؛ تغییرات مداوم باعث بی‌فایده شدن مدلسازی میشود. |
اپلیکیشن استارتاپی نوپا که هر هفته تغییرات اساسی در ویژگی‌ها دارد. |
|
پروژههای با تمرکز زیاد روی طراحی یا UI/UX |
FDD بیشتر بر منطق و Backend تمرکز دارد؛ در پروژههای اولویت‌محور طراحی چندان کارآمد نیست. |
اپلیکیشن موبایل با تأکید بر رابط کاربری خلاقانه و انیمیشن‌های پیچیده. |
|
پروتوتایپ‌ها یا MVPهای سریع |
ساختار و مدلسازی FDD سرعت را پایین می‌آورد؛ مناسب تست ایده‌های سریع نیست. |
نمونه اولیه برای تست ایده در کمتر از دو هفته به‌منظور جذب سرمایه‌گذار. |
|
پروژه‌هایی که خروجی آنها فیچرمحور نیست |
چون FDD حول فیچرهاست، در پروژه‌هایی بدون فیچر مشخص کارایی ندارد. |
پروژههای تحقیقاتی، مهاجرت داده یا کارهای زیرساختی. |
|
پروژههای خلاقانه یا اکتشافی |
FDD به تحلیل و مدلسازی از ابتدا نیاز دارد؛ اما این نوع پروژه‌ها بر آزمایش و خطا و تغییر مداوم متکی هستند. |
توسعه یک دستگاه پوشیدنی جدید با هوش مصنوعی و حسگرهای در حال تحقیق |
چرخه عمر FDD: پنج مرحله کلیدی
چرخه عمر توسعه مبتنی بر فیچر شامل پنج مرحله اصلی است که هرکدام برای اطمینان از پیشرفت تدریجی به سوی یک محصول کامل طراحی شده‌اند. برای درک ساده‌تر این فرایند، اجازه بدهید با همان مثال «معماری یک شهر لگویی» پیش برویم تا هر مرحله را راحت‌تر درک کنیم.
-
ابتدا یک مدل کلی توسعه دهید
اولین گام شامل ایجاد یک مدل است؛ یعنی طرح یا نقشهای سطح بالا از اجزای اصلی سیستم که کمک میکند دامنه کار شفاف شود. به‌عنوان معمار و سازنده محصول، پیش از آنکه کاری را شروع کنید، باید مدل و نقشه محصول خود را با جزئیات طراحی کنید.
-
فهرست فیچرها را آماده کنید
در این مرحله، باید تعیین کنیم سیستم یا محصول چه اعمالی باید انجام دهد تا برای کاربر مفید واقع شود و او را به هدف خود نزدیک کند. در روش FDD، هر فیچر یک فانکشن یا کاربرد معنادار و ساده است مثل «محاسبه مجموع مبلغ سفارش» یا «ارسال پیامک کد تأیید».
فیچرها در این مرحله در یک «دسته فیچر یا Feature Set» قرار می‌گیرند؛ مثلاً فیچر ست «مدیریت سفارشات» میتواند شامل «ثبت سفارش»، «لغو سفارش» و «بررسی وضعیت پرداخت» باشد. زمان توسعه و تحویل هر فیچر باید زیر دو هفته باشد.
-
بر اساس فیچرها برنامهریزی کنید
هر فیچر محصول به توسعه‌دهندگانی مشخص اختصاص می‌یابد که بر اساس تخصص خود مسئول توسعه و تحویل آن فیچر خواهند بود. زمان تحویل هر فیچر را بر اساس وابستگی‌های موجود و همچنین ارزش تجاری‌ای که به‌همراه دارند، اولویت‌بندی کنید.
-
بر اساس فیچرها طراحی کنید
در این مرحله باید ساختار و معماری هر فیچر را مشخص کنید. وقتی می‌خواهید یک شهر لگویی بسازید، پیش از قرار دادن هر قطعه لگو به این فکر می‌کنید که این قطعه چطور در کنار دیگر قطعات خواهد نشست.
پیش از توسعه هر فیچر نیز باید ببینید آن فیچر چگونه با دیگر فیچرها و بخش‌های سیستم کار خواهد کرد و آیا به‌درستی با آنها هماهنگ خواهد شد یا خیر.
-
بر اساس فیچرها توسعه دهید و بسازید
وارد فاز عملی می‌شویم و توسعه‌دهندگان هر فیچر را به‌صورت تدریجی کدنویسی، تست و با سیستم ادغام میکنند. هر فیچر دو آزمایش را پشت سر خواهد گذاشت: تست واحد یا Unit Testing که آن فیچر را به‌تنهایی بررسی میکند و تست ادغام یا Integration Testing که آن فیچر را در تعامل با دیگر فیچرها و بخش‌های سیستم تست میکند. کد نوشته‌شده تنها پس از پشت سر گذاشتن تمام این آزمایش‌ها به کدبیس اضافه خواهد شد.
در نهایت مراحل چهار و پنج را برای هر فیچر مجدداً تکرار کنید و آرام‌آرام محصول خود را توسعه دهید. به‌این‌ترتیب هر یک یا نهایتاً دو هفته یک خروجی قابل ارائه دارید که ارزشی مشخصی برای کاربر/مشتری خلق میکند و در عین حال همراه با ارزش تجاری کسب‌وکار است.
ساختار تیم و نقشهای کلیدی Feature Driven Development
فرض کنید محصول دیجیتال شما قرار است درست مثل یک ماشین اسپرت طراحی و ساخته شود. در تیمی که مسئولیت ساخت این ماشین را بر عهده دارد بعضی‌ها طراحی میکنند، بعضی موتور را می‌سازند، بعضی ایمنی خودرو را بررسی میکنند و عده‌ای مطمئن میشوند که خودرو همان چیزی است که رانندگان و سرنشینان آن می‌خواهند.
با این فرض بیایید نقش افراد حاضر در تیمی که بر مبنای توسعه فیچر محور کار میکند را به زبانی ساده بررسی کنیم.
|
نقش |
چی کار می‌کنه؟ |
مثال |
نقش مشابه |
|
معمار ارشد / Chief Architect |
ساختار کلی سیستم را طراحی میکند. |
تصمیم می‌گیرد که رابط کاربری، بک‌اند و پایگاه داده چطور با هم کار کنند. |
مثل کسی که نقشه کلی ماشین را طراحی میکند. |
|
برنامه‌نویس ارشد / Chief Programmer |
برنامه‌های فنی را از روی معماری استخراج و تیم فنی را هدایت میکند. |
فیچر بزرگی مثل «داشبورد نرمافزار» را به بخش‌های کوچک‌تر تقسیم و مسئولیت هر یک را به دولوپرهای مختلف می‌سپارد. |
مثل مکانیکی که می‌داند هر قطعه چطور کار میکند. |
|
صاحبان کلاس / Class Owners |
مسئول بخش مشخصی از کد و نگهداری آن هستند. |
یکی مسئول ماژول ورود کاربران است، دیگری مسئول سیستم اعلان‌ها. |
مثل مهندسینی که هر کدام بخش خاصی از موتور ماشین را مدیریت میکنند. |
|
رهبران تیم فیچر / Feature Team Leads |
یک تیم موقت را برای ساخت یک ویژگی خاص هدایت میکنند. |
رهبری تیمی که قرار است قابلیت «ایجاد تسک جدید» را بسازد. |
مثل سرتیم‌هایی که مسئول تمام کردن یک بخش خاص از پروژه‌اند. |
|
برنامه‌نویس‌ها / Developers |
کدنویسی و تست بخش‌هایی از پروژه که به آنها واگذار شده است. |
کدنویسی «نمای تقویم» یا قابلیت «افزودن کامنت». |
مثل کارگرانی که در خط تولید واقعاً ماشین را سر هم میکنند. |
|
متخصصان دامنه / Domain Experts |
دانش کسب‌وکار و نیازهای کاربر را در اختیار تیم می‌گذارند. |
تسکها را اینطور تعریف میکنند: «کاربر باید بتواند 1 تا 3 تسک مهم هر روز خود را روی داشبورد ببیند». |
مثل مشتری یا مدیر محصولی که می‌دانند ماشین دقیقاً چه کاری باید انجام بدهد. |
11 نکته طلایی در توسعه محصول به روش فیچرمحور
تا اینجا باید به خوبی پنج مرحله از چرخه عمر روش Feature-Driven Development و همچنین نقشهای این روش را درک کرده باشید. حالا وقت آن است که سریع و کوتاه چند نکته مهم را گوشزد کنیم تا از اهمیت هر یک از مراحل FDD غافل نمانید.
-
از همان ابتدا مدلی منسجم خلق کنید.
مدل دامنه همان نقشه ساخت شهر لگویی شماست؛ آن را خیلی جدی بگیرید. هیچ ساختمان منسجم و قابل اتکایی بدون یک نقشه ساخت دقیق ساخته نمی‌شود. خشت اول، مهم‌ترین قطعه است.
مدلسازی، کار راحتی نیست و بهتر است از همان ابتدای کار از متخصصین مدلسازی دامنه کمک بگیرید. مدلسازی را به‌صورت تصویری پیش ببرید و برای این کار از ابزارهای مدلسازی مانند دیاگرام‌های UML استفاده کنید و مدل خود را با هر بینش تازه‌ای که به دست‌می‌آورید، بهینه کنید.
نکته کنکوری: عبارت UML مخفف Unified Modeling Language به معنای «زبان مدلسازی یکپارچه» است. یک زبان بصری منسجم که از نمادهای خاص خود استفاده میکند. این زبان‌های مدلسازی کمک میکنند سیستم‌های پیچیده، به‌سادگی قابل درک باشند؛ این زبان‌ها ارتباط بین اعضای تیم را آسان و در طول فرایند توسعه از آشفتگی و هدررفت زمان جلوگیری میکنند.
-
هر فیچر باید کوچک و قابل اجرا باشد.
مدل FDD بر مبنای بخش‌های کوچک و قابل ارائه بنا شده است. اگر فیچری که می‌خواهید توسعه دهید از حد مشخصی بزرگ‌تر باشد، راه را اشتباه رفته‌اید. برای اینکه از انتخاب فیچر درست اطمینان حاصل کنید، می‌توانید روش زیر را به کار ببندید:
“[Action] the [result] [object]”
e.g., “Calculate monthly revenue”
مدل «[شی] [نتیجه] [عمل]» که چیزی شبیه به مفهوم یوزر استوری است، کمک میکند آنچه می‌خواهید بسازید را به شکلی شفاف دربیاورید. این فرمول سه بخش ساده دارد:
بخش Action یا عمل: این فیچر باید چه کاری انجام دهد؟ (این فیچر باید «بسازد؟»، «باز کند؟»، «پاک کند؟»)
بخش Result یا نتیجه: خروجی کاری که این فیچر انجام میدهد، چیست؟ («تأییدیه؟»، «خالی کردن؟»، «کامل کردن؟»)
بخش Object یا شی: تعیین میکند اصلاً درباره چه چیزی صحبت می‌کنیم! («سفارش؟»، «پیامک؟»، «قیمت؟»)
به این مثال دقت کنید تا این فرمول کاملاً برایتان شفاف شود: «پیامک تأییدیه ارسال کن.»
چرا این فرمول خوب جواب میدهد؟ جواب این سؤال پنج بخش دارد:
-
شفاف و مشخص است؛ مثلاً «پیامک ارسال کن» یا «تأییدیه ارسال کن» کمکی به اعضای تیم نمی‌کند!
-
کوچک و متمرکز است؛ مثلاً «برای تأیید سفارش مشتری، پیامکی به شماره همراه ثبت‌شده او ارسال کن.» اطلاعات زیادی میدهد اما بخش مفید آن چقدر است؟
-
رصد و اولویت‌بندی آن آسان است؛ وقتی فیچرها در این قالب نوشته شوند، مدت زمان انجام، تکمیل و تحویل آنها و همچنین میزان اهمیت آنها به‌راحتی قابل انجام است.
-
همه اعضای تیم را هماهنگ میکند؛ مدیر محصول، دولوپرها، کارشناس تست، طراحان محصول و ذی‌نفعان با خواندن همین سه کلمه میتوانند سریعاً بفهمند چه چیزی در حال توسعه است.
-
کدنویسی را به ارزش تجاری متصل میکند؛ در این فرمول، ارزشی که هر فیچر در اختیار کاربر قرار میدهد بسیار واضح است.
-
نقش‌ها و مالکیت‌ها باید شفاف باشند.
روش FDD به همکاری بر اساس «نقش‌ها» متکی است؛ مثل «معمار شهر»، «کارگر» و «شهردار» که نقش‌هایی به هم متصل دارند. شما نیز در تیم توسعه محصول خود باید نقش‌ها و مسئولیت‌هایی کاملاً مشخص داشته باشید.
نقش‌هایی مثل «معمار ارشد»، «مالک کلاس»، «لید تیم فیچر»،… باید مشخص باشند. فراموش نکنید که آشپزهای متعدد و مسئولیت‌های ناواضح غذا را یا شور میکند یا بی‌نمک.
-
پیش از ساختن، طراحی کنید.
با عجله به دست گرفتن لگوها و شروع به ساخت کردن، نتیجه دلخواهتان را به همراه نخواهد داشت؛ پس برای ساخت محصول دیجیتال خود نیز سریعاً به سراغ کدنویسی نروید!
همیشه پیش از کدنویسی، فیچر مورد نظر خود را پروتوتایپ یا طراحی کنید؛ در فرایند طراحی از هم‌تیمی‌های خود بازخورد بگیرید و از نحوه قرارگیری و عملکرد این فیچر در دل سیستم اطمینان حاصل کنید.
-
بر مبنای فیچر پیش بروید!
باز هم تأکید می‌کنیم که بر مبنای فیچرها - یعنی قطعه‌قطعه - پیش بروید؛ در یک شهر لگویی اول تمامی جاده‌ها را نمی‌سازید تا بعد بروید سراغ ساختمان‌ها! هر تکه از محصول دیجیتال شما در فرایند توسعه باید «قابل استفاده» و «قابل آزمایش» باشد.
برخی از تیم‌ها برای توسعه یک اپلیکیشن در هفته اول تمامی دکمه‌ها را طراحی میکنند، سپس در هفته بعد منطق back-end را به‌صورت کامل می‌نویسند و تازه در هفته سوم این موارد را به هم وصل میکنند! در این فرایند سه هفته تا رسیدن به یک خروجی قابل ارائه زمان سپری میشود.
به جای این کار بخش به بخش پیش بروید؛ مثلاً برای یک اپلیکیشن سفارش غذا ابتدا قطعه مربوط به ثبت سفارش را کامل کنید:
-
یک دکمه برای ثبت سفارش
-
یک فرم برای انتخاب پیتزا
-
یک کد برای ذخیره‌سازی سفارش
-
صفحه نمایش پیام تأییدیه
پس از ساخت این قطعه به راحتی می‌توانید آن را تست و استفاده کنید.
-
بازبینی‌های منظم و سبک‌وزن داشته باشید.
توسعه فیچرمحور تیم‌ها را تشویق میکند به‌صورت منظم طراحی‌ها و کدها را بازبینی کنند. بازبینی منظم و پیاپی در روند پروژه باعث میشود تا حجم کم و سبکی از کار بازرسی شده و در صورت نیاز اصلاح و بهینه شود. بازبینی‌ها باید متناوب و کوتاه باشند و تمرکز هر بازبینی باید بر روی عملکرد و فیت بودن آن فیچر در معماری کل محصول باشد.
-
تست و آزمایش را خودکارسازی کنید.
تیمهای FDD باید فیچرها را با سرعت بالایی تحویل دهند؛ خودکارسازی کمک میکند سرعت و کیفیت کار در این فرایند حفظ شود. حین توسعه هر فیچر، تست آن را بنویسید و از پایپ‌لاین CI/CD برای خودکارسازی ادغام هر فیچر در سیستم استفاده کنید؛ صحت کدها و فیچر هر تیم فیچر را به‌صورت مجزا بررسی کنید.
-
روند پیشرفت فیچرها را به‌صورتی شفاف رصد کنید.
مسئولیت‌پذیری زمانی وجود دارد که شفافیت داشته باشیم. با استفاده از روش‌هایی مانند بورد کانبان، روند پیشرفت توسعه هر فیچر را به‌صورتی شفاف در برابر دید همه اعضای تیم قرار دهید تا همه افراد نسبت به مسئولیت‌های خود متعهد باشند. از توسعه فیچرهای جانبی یا هرگونه کار حاشیه‌ای جداً خودداری کنید!
8 نکته‌ای که تا اینجا بررسی کردیم به چگونگی اجرای روش FDD در عمل مرتبط بود؛ سه نکته بعدی اما که به‌اندازه تمامی نکات قبلی اهمیت دارند، به بعد فرهنگی و ذهنیت ماجرا می‌پردازد.
-
فرهنگ همکاری را ترویج دهید.
اعضای تیم باید در همکاری و رقابتی سالم با یکدیگر فعالیت کنند. هیچکس به تنهایی نمی‌تواند یک شهر کامل - حتی یک شهر لگویی - را بسازد. فرایند FDD تنها با همکاری مؤثر بین افراد به نتیجه می‌رسد.
-
بر مبنای فیچرها گفتگو کنید، نه تسکها!
در گفتگوها و جلسات تیمی در مورد کاری که انجام می‌هید صحبت نکنید، درباره آنچه کاربر از کار شما به دست خواهد آورد حرف بزنید! یعنی به جای اینکه بگویید «من ده تست نوشتم.» باید بگویید «امکان اضافه کردن کد تخفیف در زمان پرداخت را تست و تأیید کردم و حالا کاربران میتوانند از این گزینه استفاده کنند.»
-
ارزش تحویل بدهید، نه کد!
کدنویسی به‌تنهایی دردی از هیچکس دوا نمی‌کند. همه انرژی شما باید متمرکز بر خروجی‌های ارزشمندی باشد که یک درد واقعی از کاربر را دوا کند. هر هفته - و در برخی محصولات گاهی شاید حتی هر روز - باید در تلاش باشید چیزی را به کاربر تحویل دهید که او میتواند ببینید، استفاده کند و از آن سود ببرد.
مقایسه FDD با TDD و BDD
هر سه رویکرد توسعه رفتار محور یا Behavior Driven Development، توسعه تست محور یا Test Driven Development و توسعه فیچر محور یا FDD با هدف بهبود کیفیت و تحویل نرمافزار به کار می‌روند، اما تمرکز، هدف و کاربرد آنها با هم متفاوت است؛ جدول زیر به‌طور ساده و خلاصه تفاوت‌های کلیدی این سه رویکرد را بررسی کرده است.
|
تمرکز بر |
مسئول اصلی |
خروجی کلیدی |
مناسب برای |
|
|
FDD |
تحویل فیچرها |
توسعه‌دهندگان، معماران |
فهرست فیچرها |
تیمهای بزرگ و ساختاریافته با دامنه‌های مشخص |
|
BDD |
رفتار کاربر |
توسعه‌دهندگان، تسترها، ذی‌نفعان تجاری |
سناریوهای Gherkin |
هماهنگ‌سازی توسعه با منطق تجاری |
|
TDD |
صحت کد |
توسعه‌دهندگان |
تست‌های واحد / Unit Tests |
پیشگیری از باگ و بازسازی ایمن کد |
چارچوب توسعه ویژگی محور یک روش برنامهریزی و تحویل است که ساختار و نحوه سازماندهی تیم برای توسعه فیچرها را مشخص میکند؛ اما BDD و TDD روشهای توسعه‌ای هستند که معمولاً در دل چارچوب‌های دیگر مثل اسکرام، کانبان یا FDD قابل استفاده‌اند.
در عمل، تیم‌هایی که از FDD استفاده میکنند، ممکن است برای حفظ کیفیت کدنویسی‌های خود از TDD یا BDD نیز بهره ببرند. این روش‌ها مکمل هم هستند، نه جایگزین هم. FDD مثل نقشه راه پروژه است و BDD/TDD ابزارهایی هستند برای اطمینان از اینکه در مسیر درستی حرکت می‌کنید.
جمع‌بندی
در دنیای Agile که انعطاف‌پذیری حرف اول و آخر را می‌زند، توسعه مبتنی بر فیچر چارچوبی مقیاسپذیر و ساختارمند را ارائه میدهد. FDD رویکردی ایده‌آل برای تیم‌ها و پروژه‌هایی است که مقیاس‌پذیری، ساختارمندی و پیش‌بینی‌پذیری نتایج در اولویت آنهاست.
|
تفکر چابک فقط یک متدولوژی نیست، یک نگاه متفاوت به کار تیمی و حل مسئله است. در اجیلیتی، آموزش Agile با رویکردی عملی، تدریجی و متناسب با فضای کاری تیمهای ایرانی طراحی شده است.
|