تقابل آریوپی و اجایل
مدیریت پروژه نرم افزاری, مقاله

تقابل آریوپی و اجایل(عروس بلد نیست برقص ِ می گه زمین کجِ…)

۱ 165

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

پیچیده بودن فرآیند تولید و توسعه نرم افزار باعث خلق متدولوژی ها و روش های متفاوتی شده. بالاخره برای مدیریت یک فرآینده پیچیده و فوق العاده پارامتریک و در عین حال پویا باید روش داشت! از روز اول خیلی از روش ها بکار گرفته شد و به مرور زمان ایراداتش گرفته شد و روش دیگه ای جایگزین شد. این خیلی هم خوبه! بالاخره پیشرفت یعنی همین. متدولوژی های توسعه نرم افزار تقریباً از دهه ۷۰ تازه آغاز شد. با Structured Programming  شروع شد و در سال ۱۹۸۰ رسید به SSADM. در دهه ۹۰ اتفاقات خوبی افتاد. OOP، RAD، Scrum و در پایان سال ۹۰ رسیدیم به XP و در اواخر همین دهه RUP و در اوایل دهه بعدی Agile معرفی شد و در سال ۲۰۰۵ اِی.یو.پی به یونیفاید پروسس ها اضافه شد. ذکر این نکته شاید برای شما هم جالب باشه که اوج تحول اسکرام مربوط به سال ۹۵ میشه سالی که هنوز UP شکل آنچنانی ای نگرفته بود البته مسلماً اون اسکرام با این اسکرام هم متفاوته. RUP هم که در سال ۹۶ تازه شکل گرفته بود در سال ۹۸ جون گرفت و در سال ۲۰۰۳ با توجه به حمایت IBM رسماً معروف شد. این در حالیه که Agile رسماً در سال ۲۰۰۱ معرفی شد و اسکرام بعنوان یک روش بکارگیری Agile به اجایل پیوست. البته این رو هم باید در نظر داشت که Incremental software development methods که سازگار با اجایل  هستن در سال های قبل به تدریج در حال تکمیل بودن. متدهای اسکرام، اکس پی و کریستال مربوط به قبل از سال ۹۶ هستن و در واقع تفکر اجایل قبل از ۲۰۰۱ هم وجود داشت همونطور که تفکر UP هم قبل از ۲۰۰۳ بود. تا اینجا ذکر این نکته مهم هست که اجایل چیز جدید و تازه ای نیست چراکه نزدیک ۱۰ سال از معرفی رسمی اون میگذره. اما چیزی که هست اینه که فراگیر شدن اسکرام و کلاً تفکر اجایل اخیراً اتفاق افتاده…

متاسفانه در بعضی از انجمن ها و جدیداً در برخی از شرکت ها ذهنیت غلطی دیدم امیدوارم تا حدی بتونم اصلاحش کنم. اون ذهنیت چیه؟ بذارید یه مقدمه اول بگم. عموماً تغییر چیز خوبیه مخصوصاً اگه این تغییر همگام با پیشرفت تکنولوژی باشه و ایرادات قبلی رو اصلاح کرده باشه. اما باور تغییر و باور علت تغییر خیلی مهم تر هست. من اگه فقط در ظاهر تغییر کنم بدون اینکه علت رو بدونم و باور نداشته باشم که این تغییر باعث موفقیت من میشه واقعاً بی فایده هست. بالاخره اکثر دانشجویان کامپیوتر در ایران در درس مهندسی نرم افزار با آر.یو.پی آشنا شدن. حالا اینکه چرا اون موقع کسی بجای آر.یو.پی، اجایل رو معرفی نکرد مشخص نیست! ممکنه بعضی از دوستان بگن اون موقع اجایل شناخته شده نبود یا عملیاتی نبود یا … به نظر من این دلایل قابل قبول نیست. البته شاید در بعضی از دانشگاه ها اینطور نبوده باشه ولی تا اونجایی که من از دوستان و آشنایان پرسیدم بالای ۹۰ درصد اینجوری بوده و مهندسین آینده هیچ چی در مورد اجایل نشنیدن. خوب بگذریم… پس به دلایل نامشخصی RUP بعنوان یک فریم ورک اصلی توسعه نرم افزار شناخته شد معرفی و عملیاتی شد. در خیلی از پروژه ها مورد استفاده قرار گرفت. پروژه های موفق داشت ناموفق هم داشت. اون چیزی که زنگ خطر بحساب میاد اینه که متاسفانه این تفکر داره ترویج میشه که دلیل عدم موفقیت برخی پروژه های نرم افزاری ای که از RUP استفاده کردن خودِ RUP هست و برای اینکه موفق بشیم باید متدولوژی رو عوض کنیم و مثلا اسکرام کار کنیم! شاید در برخی از پروژه ها این حرف صحیح باشه ولی عموماً اینطور نیست. این یک باور غلط هست مواظب باشید گرفتارش نشین. RUP یک فریم ورک گسترده هست و اون چیزی که باید در RUP بدرستی رعایت شه tailoring هست. کسی که این وظیفه رو بعهده میگیره باید علاوه بر تخصص، تجربه بالایی داشته باشه. عموماً پروژه هایی که موفق نمیشن در Tailoring مشکل دارن. این مساله به ضعف RUP برنمیگرده. متاسفانه هیچ مرجع کاملی برای آموزش RUP در کشور وجود نداره. خیلی از افرادی که RUP کار میکنن حتی نسخه جدید ۲۰۰۸ اون رو ندیدن!! یا شیوه پیاده سازیشون اصلاً از پایه غلط هست. من در مورد مزایا و معایب RUP نمیخوام صحبت کنم هدفم این هست که بگم شرایطی که RUP الان داره رو ما خودمون بوجود اوردیم نه کس دیگه و باید مواظب باشیم که این شرایط رو برای Agile و Scrum بوجود نیاریم به این معنی که قبل از عالم شدن شروع کنیم. البته این رو هم قبول داریم که این اتفاق احتمال وقوع کمتری در اجایل داره ولی باز مهم هست و قابل وقوع.

خیلی از افرادی که ادعای RUP دارن واقعاً علم به حداقل ها رو هم ندارن و اصلا iteration ای ندارن و کاملاً دارن به سبک SSADM کار میکنن. این افراد جایگاه RUP رو با نادانی شون خراب کردن. این تفکر مسلماً به شکست خواهد انجامید چراکه باور این افراد درست نیست. علم به روش از خودِ روش مهمتر هست. وقتی من علم به ابزار رو ندارم چطور میتونم از ابزار استفاده کنم. مسلماً از یک روش در همه پروژه ها نمیشه استفاده کرد. ولی اگر در پروژه ای موفق نشدیم اول اینو بررسی کنیم که آیا روش رو درست انتخاب کردیم بعد ببینیم آیا علم به اون روش رو داشتیم و در آخر خودِ روش رو زیر سوال ببریم و دنبال توجیه بی دانشی خودمون باشیم.

دوستانی که میخوان از اجایل استفاده کنن حتماً اطلاعاتشون رو کامل کنن. خوشبختانه منابع خوبی مثل کورس هایی که داره در ایران برگزار میشه، وبینارها، کتاب های ترجمه شده و …. وجود داره. همچنین میتونن در انجمن چابک ایران عضو بشن تا با اشتراک سوادمون در این زمینه به آخر و عاقبت شرایط RUP (نه خود RUP) دچار نشیم.

موفق باشید.

Share

در باره نویسنده / 

حمیدرضا متقیان

مدیر محصول نرم افزار. علاقه مند به دنیای وب و ارزش آفرینی در کسب و کار.

یک دیدگاه

  1. delaram ۱۳۹۱-۰۷-۰۷ در ۱:۰۰ ب.ظ - 

    سپاس

ارسال پاسخ

ایمیل شما نمایش داده نمی‌شود. موارد مورد نیاز علامتگذاری شده است *

نوشته های تصادفی

  • جایگاه نقشه مسیر در تولید یک محصول نرم افزاری

    جایگاه نقشه مسیر در تولید یک محصول نرم افزاری

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

  • 5 افسانه Agile

    ۵ افسانه Agile

    بی شک برای استفاده از هر روش جدیدی دلایلی وجود دارد.  یکی از این دلایل می تواند برتری نقاط قوت روش جدید نسبت به روش فعلی باشد. اما آیا همیشه اینطور است؟ اگر شما به یکی از دلایل ذیل می خواهید به اجایل مهاجرت کنید باید بدانید که دچار افسانه زدگی Agile شده اید! این…

پربازدید ترین ها

  • بندهای حیاتی یک قرارداد تولید نرم افزار

    بندهای حیاتی یک قرارداد تولید نرم افزار

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

  • بایدها و نبایدها در ارائه پروپوزال

    بایدها و نبایدها در ارائه پروپوزال

    در اسفند ۸۸ در وب سایت بزرگ برنامه نویس به موجب سوال یکی از دوستان در مورد “شیوه ارائه طرح پیشنهادی نرم افزار”  توضیحاتی هر چند مجمل دادم که خوندنش خالی از لطف نیست: Proposal رو باید بر اساس RFP یا Request For Proposal ای که از مشتری میگیرین تهیه کنید. RFP از اهمیت زیادی…

  • the-internet-of-things

    آینده در دستان اینترنت اشیاء (IoT)

    Internet Of Things تحولی در آینده اینترنت است که مسلماً کسب و کار نرم افزار رو بسیار پر رونق تر و در عین حال فراگیرتر می کنه.  فرض کنید به خرید رفتید و خیلی راحت از یخچال خونتون استعلام میکنید که چه چیزهایی رو باید خریداری کنید؛ نیم ساعت قبل از اومدنتون میتونید سیستم تهویه…

عضویت در خبرنامه

بایگانی