مقایسه روش‌های اجایل و سنتی در توسعه یک محصول

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

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

این مطلب پیش‌تر در وب سایت شخصی‌ام نیز منتشر شده است.

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

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

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

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

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

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

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

روش سنتی، واترفال یا آبشاری در توسعه محصولات نرم‌افزاری
روش سنتی، واترفال یا آبشاری در توسعه محصولات نرم‌افزاری

حالا که نسبت به مدل آبشاری یا سنتی، دید احتمالا بهتری پیدا کردید (البته اگه نمی‌دونستید) می‌روم سراغ روشی که در اجایل برای مدیریت پروژه‌ها یا توسعه محصولات استفاده می‌شه.

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

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

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

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

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

این مطلب یه بخشی از یک مطلب خیلی مفصل‌تر و طولانی‌تر هست که در روزهای آینده در مورد اجایل منتشر می‌کنم.

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