اسکرام یا XP ؟

اسکرام یکی از محبوب ترین چارچوبهای اجایل در همه جای دنیاست و در این شکی نیست ولی آیا همه نیازهای یک تیم توسعه نرم‌افزاری رو برطرف میکنه و اگه صرفا از این چارچوب استفاده کنیم می‌تونیم صفر تا صد یک پروژه نرم‌افزاری رو با موفقیت جلو ببریم؟ بدون شک پاسخ دوستانی که تجربه اجرای عملی حتی یک پروژه رو داشته باشند منفیه چون که در اجرا متوجه شدن که اسکرام فقط بعضی از دیسیپلین‌های چرخه حیات نرم‌افزار رو پوشش میده.ولی برای اینکه نگاه دقیق تر و علمی‌تری به پوشش اسکرام از ارزشهای اجایل بصورت کیفی داشته باشیم بد نیست با استفاده از یک چارچوب بررسی کمی، ارزشهای اجایل اسکرام واکس‌پی رو با هم مقایسه کنیم. من اینکار رو قبلا در یک تحقیق با استفاده از چارچوب Quantitative Framework for the Evaluation of Agile انجام دادم و به خاطر اینکه از حوصله این نوشته خارج نشه خلاصه و ماحصل اون رو تویه این نوشته میارم.اين چهار چوب معيارهایی(سنجه‌هایی) رو بر اساس چهار ارزش کليدی اجایل تعريف مي‌کنه. اگر فرض کنيم که ارزشهای اجایل رو P در نظر بگيريم برای هر ارزش، تقابل دو مشخصه هر ارزش را با Pi.1 و Pi.2 نشون میده و معيار ارزيابی نهایی بر اساس فرمول زير بدست می‌یاد:m (Pi) = m (Pi.1) + m (Pi.2) i=1..4برای مثال ارزش P1 نشون دهنده "ارزش افراد و تعاملات بالاتر از فرآيندها و ابزارها" با دو معيار اندازه‌گيری دو مشخصه "ارزش افراد و تعاملات" (P1.1) و معيار اندازه‌گيری مقدار "ارزش فرآيندها و ابزارها" (P1.2) میشه.مشخصه‌های هر ارزش با اولويت بالاتر در بيانه اجایل بصورت اعداد مثبت از 0 تا 5 سنجيده و ارزش با اولويت کمتر بصورت منفی از 5- تا 0 در نظر گرفته مي‌شن. بدين ترتيب هر اصل بيانيه اجایل در بدترين حالت مقدار 5- (یعنی مقدار 5- برای مشخصه منفی و 0 برای مشخصه مثبت) و در بهترين حالت مقدار 5 را خواهد داشت ( 0 برای مشخصه منفی و 5 برای مشخصه مثبت). اگر نتيجه مقدار صفر یا نزديک به صفرباشه نشون دهنده مشخصه مثبت (با ارزش بالاتر از ديد چابکی) به مقدار کافی بر مشخصه منفی (دارای ارزش کمتر از ديد چابکی) غلبه نمیکنه و شرط چابکی به مقدار کافی برقرار نمیشه.ارزش افراد و تعاملات بالاتر از فرآيندها و ابزارها P1نرم افزار کارا بالاتر از مستند سازی جامع P2همکاری با مشتری بالاتر از قرارداد کاری P3پاسخ‌گویی به تغييرات بالاتر از پيروی يک طرح P4در اینجا خیلی وارد نحوه محاسبه و جزئیات نمیشم. نتیجه پوشش کمی ارزش های اجایل اسکرام و اکس‌پی رو در نمودار زیر می‌بینیم.به وضوح ديده میشه که XP پوشش بهتری نسبت به اسکرام از ارزشهای کليدی اجایل دارهاسکرام از دسته روشهای مديريت پروژه‌گراست والبته اسکرام مزایای زیادی دارهاز جمله مزایای اسکرام میشه به موارد زیر اشاره کرد- باعث استفاده بهینه از زمان و هزینه میشه- قابليت شکستن پروژه‌های بزرگ به تکه‌های کوچکتری به نام اسپرينت رو داره که مدیريت پروژه‌های بزرگتر رو راحتر میکنه- ماهيت اسکرام باعث اعمال نظرات ‌‌ذی‌نفعان و مشتريان در محصول نهایی بصورت تدریجی و در طول انجام پروژه می‌شه- با انجام کارها در اسپرينت‌های با طول زمانی کم امکان بازخورد مشتريان رو اعمال میکنهاما متاسفانه اسکرام دارای معايبی و نواقصی هم هست که البته میشه با شناخت دقيق اونا رو برطرف کرد به‌گونه‌ای که مزاياش رو تحت تاثیر قرار نده . از جمله این نواقص می‌توان به موارد زیر اشاره کرد:- تمرکز اسکرام بيشتر بر تمرينات مديريت پروژه متمرکز شده و در مورد مهندسی نرم‌افزار برای توليد محصول تمرينات ‌خاصی را مشخص نمی‌کنه و اصلا حرفی برای گفتن نداره- اسکرام به کيفيت و کفايت اعضای تیم خیلی وابسته است، و در صورت وجود یک عضو با کیفیت کم دچار مشکل میشه- در بسیاری موارد زمان و دامنه‌ی درگیر در پروژه اسکرام از قبل قابل تخمین نیست- در اسکرام در مورد مستندات توسعه نرم‌افزار بصورت صريح صحبت نمیشه و کلا هر چیزی که مربوط به اجرای کار باشه اسکرام براش هیچ راهکاری ندارهدر شکل زیر پوشش جنبه‌های مختلف چرخه حیات نرم‌افزار توسط سه چارچوب اسکرام – XP و RUP رو می‌بینیم البته RUP از دسته متدولوژ‌های سنگینه (Heavy methodologies) و فقط برای شاخص پوشش در این نمودار نشون داده شده.خوب حالا با این اوصاف چه باید کرد؟البته اگر بنا بر انتخاب یکی از این دو بود من قطعا XP رو ترجیح می‌دادم چون XP واقعا برای توسعه‌دهندگان نرم‌افزار کاربردی تره و کسانی که درگیر اجرا و عملیاتی کردن پروژه هستن قدر ارزشهای کلیدی و تمرینهای ناب XP رو می‌دونن که به نظر من بدون وجود اونا واقعا کاری رو نمیشه پیش برد (جزئیاتش بمونه اگر خدا بخواد برای نوشته‌های دیگه) ولی خوشبختانه حداقل اینجا مجبور به انتخاب نيستم و از این خوان گسترده می‌تونیم به فراخور استفاده کنیم.خوب پس یک جواب میتونه استفاده از چارچوب ترکیبی باشه. چرا اسکرام و اکس پی رو با هم استفاده نکنیم؟ که البته خیلی‌ها هم در سراسر دنیا اینکارو میکنن.ترکيب و تلفيق اسکرام و XP یک ترکيب خوب و مناسب به نظر می‌رسه چرا که در XP تمرکز بر روی تمرين‌های مهندسی و استانداردهای توسعه است اما XP در راهکارهای مديريت پروژه چندان شفاف و قوی نیست و البته XP روی پروژه‌های با اندازه کوچک از کارایی زیادی برخورداره و کاملا" وابسته به مشتريانه که این موضوع ريسک شکست پروژه رو افزايش می‌ده از طرفی ديگه تمرکز اسکرام بر تمرين‌های مديريت پروژه است و در مورد تمرين‌های مهندسی نرم‌افزار حرفی برای گفتن نداره. این دو واقعا میتونن نقاط ضعف همدیگه رو پوشش بدن و نقاط قوت همدیگه رو تقویت کنند من به شخصه از ترکیب این دو در اجرای پروژه‌های مختلف در طول سالها استفاده کردم و بسته به شرایط نتیجه قابل قبول بوده البته این رو هم بگم که گر چه این دو روش با پوشش مناسب همدیگه روش خوبی رو برای ما به ارمغان میارن ولی در نهایت مسائل مهم دیگه‌ای در تولید نرم‌افزار وجود داره که هیچکدوم از این دو راهکاری برای اونا ندارن ؟!!!و باید جای دیگه به دنبال اونا بگردیم. شاید بشه در فرصتی دیگه در موردشون صحبت کنیم.