اجرای روش اجایل و تجزیه و تحلیل آن

خلاصه مقاله

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

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

این مقاله یک مورد مطالعاتی درباره پیاده سازی رویکرد eXPERT در شرکت توسعه نرم‌افزار را توضیح می‌دهد.

۱. مقدمه

از میان تمام روش‌های سبک‌وزن (lightweight)، برنامه‌نویسی (XP) eXtreme  بیش‌تر مورد پذیرش برنامه‌نویسان پروژه‌های الکترونیکی است. پروژه الکترونیکی، پروژه‌ای است که باید به سرعت تحویل داده شود و نتایج  آن مهم و با اولویت است؛ همچنین این پروژه‌ها باید در محیط پرتلاطم کسب‌وکار و فن‌آوری به خوبی مدیریت شوند.

مطالعات اخیر نشان می‌دهد که بهره‌وری و کیفیت نرم‌افزار با اعمال اصول XP افزایش می‌یابد. با این حال حتی پروژه‌هایی که با چندین و یا همه شیوه‌های XP همسویی دارند هم با مشکلاتی مواجه هستند که اکثرا مربوط  به مدیریت پروژه، برآورد و برنامه‌ریزی است. با در نظر گرفتن این موضوع، یک رویکرد جدید براساس برنامه‌نویسی XP  ( eXtereme Programing)  و فرآیند نرم‌افزار شخصی (Personal Software Programming) ‏ایجاد شده‌ است.

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

این رویکرد eXPERT نامیده می‌شود و ترکیبی از اصول XP و PSP است.

رویکرد eXPERT دارای اهداف بلند پروازانه تجاری زیر است:

• افزایش بهره‌وری تا حدود ۲۰ درصد
• کاهش نقص‌ها تا حدود ۳۰ درصد
• کاهش هزینه‌های اضافی پروژه تا حدود ۱۵ درصد

هفت پروژه آزمایشی در SME‌های مختلف اجرا شدند و کاربرد رویکرد تعریف‌ شده در توسعه پروژه الکترونیکی را آزمایش کردند. مطالعه موردی حاضر یکی از آن پروژه‌های آزمایشی توسعه یافته توسط شرکت بلغاری Rila Solutions را توصیف ‌می‌کند.

ساختار مقاله به شرح زیر است: در بخش ۲ رویکرد eXPERT و در بخش ۳ تجارب کسب شده در  Rila Solutions را ارائه می‌دهیم. در بخش ۴ مجموعه‌ای از معیارهایی که باید در طول آزمایش جمع‌آوری شوند را تعریف می‌کنیم. همچنین در بخش ۵ نتایج آزمایش بر اساس معیارهای تعریف‌شده را ارائه می‌دهیم و در پایان یک نتیجه‌گیری کلی ارائه خواهیم داد. 

۲. رویکرد eXPERT

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

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

در جدول ۱ شیوه‌هایی را که رویکرد eXPERT مبتنی بر آن است را برشمرده‌ایم.

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

                                                                    جدول ۱ – کارکرد XP و PSP

رویکرد eXPERT [‏۲]‏ از طریق پنج فرآیند توصیف می‌شود: مدیریت نیازهای مشتری، مدیریت پروژه، طراحی، برنامه‌نویسی و تست (‏شکل ۱)‏.

هر فرآیند در فرمت زیر توضیح داده شده است:

• نمای کلی (اهداف)
•  ورودی‌ها
• فعالیت‌ها
• فرایند‌ها
• خروجی‌ها
• معیارهای تکمیلی
• اندازه گیری‌ها

شکل ۲ – فرمت فعالیت‌ها

شکل ۲ فرمت معمول برای شرح فعالیت را نشان می‌دهد: تسک‌هایی که باید برای تکمیل یک فعالیت انجام شود و مشخص کردن فردی که مسئول انجام آن است.

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

فعالیت‌های زیر فرآیند تست را توصیف می‌کنند:

• آماده شدن برای تست
• توضیح و اجرای تست پذیرش
• انجام unit تست موازی با برنامه‌نویسی
• انجام تست رگرسیون در زمان یکپارچه‌سازی
• انجام تست پذیرش پس از ادغام، به ویژه قبل از تحویل
• اندازه گیری فرآیند (تلاش، کاستی‌ها)

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

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

در این جا خیلی به توضیح فرآیند تست و جزئیات آن نمی‌پردازیم. اطلاعات بیشتر در مورد تمام فرآیندهای تعریف‌شده و اجرای روش اجایل را می‌توانید در قسمت [‏ ۲ ]‏ پیدا کنید.

فعالیت‌های توصیف‌شده در رویکرد eXPERT [‏ ۴ ]‏ براساس شیوه‌های XP  مطرح شده است. اصلاحات خاصی عمدتاً در رابطه با اندازه‌گیری اثربخشی این فعالیت‌ها و میزان کاستی‌ها ارائه شده است. این اندازه‌گیری برای شناسایی علت‌های به وجود آمدن مشکل و حذف آن‌ها در آینده مورد نیاز است.

نمودارهای جمع‌آوری داده‌های پروژه از الگوها و اصول PSP پیروی می‌کنند، اما برای تناسب با روش XP و به ویژه برای انعکاس ویژگی‌های آن اصلاح می‌شوند؛ یعنی این که برنامه‌نویسان به صورت pair کار می‌کنند و فرآیندهای طراحی، تست و برنامه‌ریزی به شدت به هم مرتبط بوده و به صورت موازی اجرا می‌شوند.

رویکرد eXPERT نقش‌های زیر را تعریف می‌کند: مشتری، رهبر پروژه و برنامه‌نویس.

نقش‌های تعریف‌شده در XP (‏برنامه‌ریز، مشتری، مربی، پیگیری‌کننده، تست‌کننده، مشاور، رئیس)‏، با برخی مسئولیت‌های اضافه شده که ناشی از اعمال PSP است، خیلی نزدیک هستند. 

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

اگر رویکرد eXPERT را با XP مقایسه کنیم، به نظر می‌رسد که eXPERT ساختارمندتر بوده و درک و کاربرد آن توسط SMEها آسان‌تر است، چرا که معماری آن فرآیندگرا است. در عین حال به اندازه XP روشن نیست (‏به خصوص برای برنامه‌نویسان).

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

در ادامه به مطالعه موردی شرکت Rila Solutions خواهیم پرداخت. 

۳. آزمایش Rila Solutions

 ۳.۱ – تشریح شرکت

Rila Solutions  یک شرکت توسعه نرم‌افزار است که عمدتا بر توسعه پروژه‌های مشتری محور با زمانبندی و بودجه محدود تمرکز دارد. توسعه نرم‌افزار برای مشتریانی که دانش تخصصی در حوزه فناوری  IT و راهکارهای آن ندارند و حتی مشتریانی که پیشینه‌ IT ندارند، در  این شرکت متداول است.

به همین دلیل، Rila Solutions همیشه تلاش می‌کند تا در کنار رسیدن به فناوری‌های مدرن، در جستجوی و اجرای روش اجایل برای رسیدگی به الزامات جدید هم در روش‌های توسعه نرم‌افزاری باشد.

eXPERT به عنوان یک رویکرد برای درگیر کردن مشتریان انعطاف‌پذیر و سخت در نظر گرفته می‌شود. eXPERT به عنوان رویکردی به مدیریت ارشد شرکت معرفی‌ می‌شود که انعطاف‌پذیری مورد نظر برای تکمیل پروژه به موقع و مطابق برنامه زمانبندی و بودجه را دارد.

مدیریت شرکت با شروع یک پروژه آزمایشی با استفاده از روش eXPERT موافقت کرد و برای بررسی اثربخشی آن نتایج مقایسه‌ای درخواست کرد.

یک چالش برای اتخاذ رویکرد eXPERT، صدور گواهی‌نامه ایزو ۹۰۰۱ فعلی شرکت و مراحل و تغییراتی بود که باید قبل از استفاده و اتخاذ هرگونه رویکرد اجایل جدید در شرکت انجام می‌شد. انجام هرگونه نوآوری در شرکت و فرآیند تایید شده فعلی، باید کاملا بررسی شده و وضعیت فعلی برای کل چرخه عمر پروژه اصلاح شود.

۳.۲ – تشریح آزمایش

اجرای eXPERT در Rila Solutions  چندین مرحله اصلی را پشت سر گذاشت:

 مرحله ۱ – شکاف بین چرخه عمر پروژه فعلی که قبلاً تایید شده است را تجزیه و تحلیل کنید.

مرحله ۲ – رویکرد جدید در چارچوب استانداردهای فعلی شرکت توسعه نرم افزار پیاده سازی کنید.

مرحله ۳ – از eXPERT در یک پروژه واقعی و با توجه به راهکارهای آن استفاده کنید.

مرحله ۴ – به مدیریت در مورد تأثیر استفاده از eXPERT نتایج واضح و قابل مقایسه ارائه دهید.

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

. نتیجه گام اول یک سند برای «تحلیل گپ‌ها» بود که تفاوت‌های بین فرآیندهای شرکت که در حال حاضر تایید شده است و الزامات رویکرد eXPERT را نشان می‌داد. این سند، به عنوان یک سند پایه برای مرحله دوم «پیاده‌سازی» استفاده شد که شامل مراحل فرعی زیر است:

– فرآیند فعلی و تمام اسناد پشتیبانی را بروز کنید تا تغییرات اعمال شده در eXPERT را منعکس کند.

– یک سند با عنوان «راهنمای Tailoring» برای کارمندان شرکت و مهم‌تر از همه برای اعضای تیم درگیر در پروژه آزمایشی آماده کنید که به طور مفصل شیوه تطبیق‌پذیری eXPERT در شرکت و تغییرات در فرآیند شرکت را شرح می‌دهد.

– یک دوره کوتاه درباره اصول و شیوه‌های eXPERT و اجرای آن در داخل شرکت برای اعضای تیم پروژه آزمایشی در جهت آماده‌ کردن آن‌ها برای چارچوب و قواعد جدید مورد نیاز این رویکرد برگزار کنید.

در نتیجه مرحله «پیاده سازی»، فرآیند جدید و بروز شده شرکت با اتخاذ روش eXPERT به دست آمد. پس از راه‌اندازی تمام پیش‌نیازها برای اجرای موفقیت‌آمیز روش جدید، پروژه آزمایشی که از آن استفاده می‌شد، آماده شروع بود.

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

جدول ۲- معیارهای قابل اندازه گیری برای انتخاب پروژه پایه و آزمایشی

Rila Solutions به عنوان  شرکتی که گواهی ISO ۹۰۰۱ گرفته است. یک سیستم توسعه یافته برای پیگیری زمان به نام IVAN دارد. که در آن مدت زمان و تلاش انجام شده برای تمام پروژه‌های قبلی و فعلی شرکت ثبت شده‌ است.

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

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

پروژه پایه

Rila Solutions محصولی به نام سیستم مدیریت سرمایه‌گذاری را توسعه داده‌است که به عنوان چارچوبی برای توسعه سیستم‌های مدیریت مالی برای انتقال دانش و  تصمیمات سرمایه‌گذاری، ورود داده‌های مالی مختلف و نظارت بعدی استفاده می‌شود.

این  به طور کامل از طریق وب بدون هیچ گونه نیاز اضافی در مورد تجهیزات یا نرم افزار عمل ‌می‌کند. فن‌آوری که پشت این سیستم قرار دارد J۲EE با Oracle به عنوان پایگاه‌داده و سرورهای برنامه است.

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

پروژه آزمایشی Pilot

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

پروژه آزمایشی شامل یک Release و سه Iteration بود. داستان‌های کاربر (User Story) که برای هر Iteration فراهم شده بود، شامل دیدگاه مشتری از گردش کار و موارد استفاده برای سیستم بود.

۴. معیارهای eXPERT

در پروژه eXPERT مجموعه‌ای از معیارها در نظر گرفته شد که باید در طول آزمایش جمع‌آوری شوند [‏۶]‏. این معیارها برای نتیجه‌گیری در مورد رسیدن به اهداف پروژه تعریف‌شده و همچنین برای پاسخ به سوالات در مورد پذیرش رویکرد و اجرای روش اجایل مفید هستند. ابزار مورد استفاده برای جمع‌آوری معیارها و امکانات اتوماسیون این فرآیند خارج از محدوده این مقاله است.

۴-۱. بهره‌وری

بهره‌وری به دو روش تعریف می‌شود (‏جدول ۳)‏:

• اندازه کد توسعه‌یافته در KLOC (‏خطوط کد)‏ تقسیم‌ بر تلاش تیم، به صورت  انفرادی یا تیم جفت
• سرعت با تقسیم (Velocity ) / ( تلاش تیم به صورت جفت یا تکی برنامه‌نویس) محاسبه می‌شود. سرعت، مجموع زمان برآورد شده برای  User Story است که در یک Release / Iteration  اجرا می‌شود.

جدول ۳. معیارهای بهره‌وری

شرکت برای انتخاب روش اندازه‌گیری بهره‌وری آزادی است، اما روش انتخابی باید در تمام طول پروژه به کار گرفته شود. همچنین شرکت باید تصمیم بگیرد که بهره‌وری را در هر Iteration یا در هر Release اندازه‌گیری کند.

۴-۲. نرخ کاستی

دو نوع معیار برای نرخ کاستی تعریف شده‌ است. (‏جدول ۴)‏:

• تعداد کاستی ایجاد شده توسط یک تیم و هر برنامه نویس در طول هر Release / Iteration و در طول کل پروژه.
• درصد تلاش انجام شده برای رفع باگ در مقایسه با تلاش صرف شده برای کل پروژه.

جدول ۴. محاسبه نرخ کاستی

درجات احتمالی جزئیات برای هر دو نوع محاسبه عبارتند از:

•  برای تیم و برای هر برنامه‌نویس
• برای کل پروژه و برای هر Release / Iteration

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

۵. نتایج آزمایش Rila Solutions

برای شروع پروژه آزمایشی به مشارکت تمام اعضای تیم برای پذیرش و استفاده از روش‌های eXPERT نیاز بود. روش‌ها مورد استفاده در سه گروه دسته‌بندی شدند: شیوه‌هایی قبلا پذیرفته‌شده، شیوه‌های تغییر نیافته و تغییر یافته.

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

در آزمایش Rila Solutions  مشتری حضور فیزیکی ندارد اما با کمک یک وبسایت به صورت دائمی به اطلاعات دسترسی دارد که محیط «Staging» نامیده می‌شود و در آن  آخرین نسخه سیستم در حال اجرا است و از ارتباط مداوم با مشتری پشتیبانی می‌شود. به این ترتیب مشتری چشم انداز دائمی و کلی از وضعیت پروژه دارد. در این شرایط شرکت یک روش پشتیبانی «آنلاین» در نظر گرفته است که در این پروژه خیلی خوب عمل کرده است.

فرآیند بازساخت (refactoring) نیاز به بررسی کد و ایجاد تغییر در کد منبع سیستم دارد. این روندها زمانبر هستند بنابراین Refactoring در جایگاه خاصی استفاده می‌شود. این موارد گلوگاه‌های (Bottlenecks) سیستم در منطق کسب‌وکار هستند.

انجام تست قبل از تمرین کد تنها برای منطق کسب‌وکار اعمال شده‌است نه برای آزمون‌های پذیرش و نه در هنگام ارائه اپلیکیشن (‏htmls و jsps)‏.

بخش ارائه سیستم برای اطلاع مداوم از نظرات و تغییرات مشتریان در نظر گرفته شده است. به همین دلیل انجام تست قبل از تمرین کد برای این بخش‌های سیستم در نظر گرفته نشده است.

Rila Solutions به عنوان شرکتی که گواهی ISO ۹۰۰۰ دارد از اهمیت جمع‌آوری داده‌های تاریخی و استفاده از سیستم‌های ردیابی و گزارش دهی آگاه است. به این ترتیب قبل از اجرای شیوه‌های PSP مورد نیاز eXPERT از سیستم‌های ردیابی زمان و تلاش و باگ‌ها استفاده می‌شد، به این ترتیب معیارهای اصلی برای مقایسه نتایج برای پروژه با وضعیت اولیه در دسترس بودند.

با این وجود اجرای بعضی از اصلاحات در این سیستم‌ها برای پیاده‌سازی روش های PSP  به ویژه برای گزارش دقیق در این مورد انجام شد.

۵.۱. بهره‌وری

بهره‌وری بر اساس Iterationهایی که در قسمت ۴.۱ نشان داده شده است، محاسبه می‌شود. بهره‌وری با استفاده از معیار KLOC/EFFORT اندازه‌گیری می‌شود. این تلاش بر اساس ساعت‌های کار آدم‌ها اندازه‌گیری شده و برای هر Iteration «پروژه آزمایشی» مطابق با نیاز PSP جمع‌آوری می‌شود. خطوط کد تولید شده تنها برای همان Iteration اندازه‌گیری و  استخراج می‌شوند. آخرین Iteration بهره‌وری کمتری خواهد داشت چون تغییرات مورد نظر مشتری انجام و باگ‌ها هم برطرف شده است.  اجرای این کار نیاز به تلاش بیشتر اما KLOC کمتری داشت.

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

۵.۲. نرخ نقص

معیار مورد استفاده برای اندازه‌گیری نرخ نقص تعداد نقص‌ها در Iteration است. تا جایی که آمار نقص‌ها در پایه و پروژه آزمایشی مشخص نباشد امکان مقایسه وجود ندارد. این اندازه‌گیری  بر اساس تعداد همه نقص‌ها ارائه شده است (جدول ۱۰). این عدد مربوط به نقص‌های گزارش‌شده توسط مشتری یا تیم تضمین کیفیت است و شامل خطاهای ایجاد شده در طول توسعه برنامه و Unit Test برنامه‌نویسان نمی‌شود.

۵.۳. انحراف زمانبندی نسبی

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

در عوض، به برنامه‌نویسان فرصت کار بر روی پروژه‌های دیگر داده شد (‏که یک رویه عادی در شرکت و براساس تصمیم مدیر تجاری است)‏. تصمیم مدیریت شرکت این بود که تغییراتی در زمانبندی پروژه ایجاد نکند زیرا برنامه‌ریزی در قرارداد مشتری در نظر گرفته شده و کاهش زمان پروژه برای شرکت مقرون به صرفه نخواهد بود. به خصوص در مورد استفاده از eXPERT، این تصمیم منطقی‌تر  به نظر می رسد چون وقتی اعضای تیم روی چند پروژه به طور همزمان کار می‌کنند استفاده از برنامه‌ریزی دونفره (pair program) نیاز به تلاش مضاعفی برای هماهنگی بین اعضا دارد.

به دلایل گفته شده کاهش در زمان‌بندی پروژه در معیارهای مطرح شده مد نظر نیست و به عنوان انحراف از برنامه محاسبه نمیشود.

۴. ۵ تفکیک هزینه نسبی

در هنگام شروع پروژه آزمایشی کار برآورد شده برای پروژه ۹۰۰ نفر بر ساعت در نظر گرفته شده بود. در نهایت مقداری که برای این پروژه گزارش شد ۸۰۴ نفر بر ساعت بود.

برای تمام این پروژه انحراف هزینه (Cost Deviation) این گونه محاسبه شد:

CD = (۹۰۰-۸۰۴) * CHR

Company hour rate :CHR    

۵.۵ تغییرات هزینه پروژه   

تغییرات هزینه پروژه در واقع ارزشمندترین معیار برای مدیریت شرکت است. نتیجه ارائه شده بر اساس انحراف هزینه واقعی نیست بلکه نتیجه واقعی بر اساس انحراف تلاش است (شکل ۴).             

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

مهم‌ترین موضوع در این معیار تلاش کم‌تر صرف شده‌ برای Iteration اول است که بر این اساس منجر به بهره‌وری بیشتر برای Iteration می‌شود (‏شکل ۳)‏. از آنجا که این شروع پروژه بود، تغییرات کمتری توسط مشتری مورد اعمال و  Source Codeهای جدید و  بیشتری ایجاد شد.

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

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

۵.۶. رضایت مشتری و توسعه‌دهنده

مشتری کنترل دائمی بر روی فرایند توسعه و پیشرفت محصول داشت و به صورت روزانه از او بازخورد گرفته می‌شد. در پایان پروژه مشتری از این رویکرد خیلی تمجید کرد. میزان رضایت توسعه دهندگان با کمک پرسشنامه و در پایان آخرین Iteration بررسی شد. تاثیر اصلی نمایان شده بر توسعه‌دهندگان نظم جدید توسط eXPERT اعمال‌شده بود. کار کردن ۴۰ ساعت در هفته با برنامه‌ریزی دو نفره نیاز به تمرکز زیادی دارد و برای توسعه‌دهندگان بسیار خسته‌کننده به نظر می‌رسید.

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

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

۵.۷. دستیابی به اهداف کسب‌ و کار

نمودار ۵ دستاوردهای تجاری قابل اندازه‌گیری اصلی را پس از اعمال eXPERT در Rila Solutions نشان می‌دهد. این نمودار درصدهای بهبود را با توجه به اهداف کسب‌وکار تعریف‌شده در بخش ۱ نشان می‌دهد.

برداشت اول این است که افزایش بهره‌وری یک مزیت درصدی واقعی را در سایر مولفه‌های اندازه‌گیری شده ایجاد می‌کند. البته این نتیجه بر اساس  میزان بیشتر کد جدید برای پروژه آزمایشی در مقایسه با پروژه پایه است. پروژه پایه نیاز به اصلاحات بیشتری در ماژول‌های نرم‌افزاری موجود نسبت به پروژه آزمایشی دارد در حالی که پروژه آزمایشی نیاز به توسعه عملکردهای جدید بیشتری دارد. اولین هدف کسب‌ و‌ کار که افزایش ۲۰٪ بهره‌وری بود، ممکن است محقق شده باشد. هدف دوم کسب‌وکار کاهش نرخ عیب تا ۳۰٪ است که نصف آن با نرخ ۱۳.۳۳٪ به دست آمد. عیب‌های گزارش‌شده و اندازه‌گیری شده عمدتا عیب‌هایی سطح بالا و بحرانی بود که توسط تیم QA و مشتری گزارش داده شدند. درخواست‌های مشتری برای اصلاحات سیستمی در هر دو پروژه در نظر گرفته نشده؛ به همین دلیل هم مقایسه‌ای انجام نشده است. درگیر بودن مشتری در مراحل کار  یک مزیت محسوب می‌شود چون امکان رسیدگی سریع به خواسته‌های او را به وجود می‌آورد همچنین با بررسی سیستم سریعا بازخورد خواهد داد.
سومین هدف کسب و کار که کاهش تلاش بود محقق نشده است، اما کسب نتیجه حدودی  ۱۱.۵ درصدی برای تشویق به کارگیری eXPERT در پروژه‌های شرکت آتی کافی است.

۶. نتیجه‌گیری

رویکرد eXPERT برای پروژه‌هایی با هدف ارائه نرم‌افزارهای با کیفیت طراحی شده‌است؛ یعنی پروژه‌هایی که با نرخ نقص کم و در زمان کوتاه تر انجام شوند. آزمایش Rila Solutions نشان می‌دهد که استفاده از روش eXPERT در تیم‌های کوچک و در سازمان‌هایی با سلسله مراتب فلت نسبتاً آسان است چون در این روش داشتن ارتباط مستقیم با مدیریت برای موفقیت پروژه‌ها مهم است. استفاده از eXPERT برای پروژه‌هایی خوب است که در ابتدا مشخصات دقیقی از جزئیات ندارند.
استفاده از روش eXPERT برای پروژه‌هایی که هیچ تعریف روشنی در مورد نتیجه نهایی ندارند هم در اولویت قرار دارد.  زمانی که مشتری تنها یک پیش‌بینی و  تصویر کلی از سیستم بدون دانستن فریم های دقیق و ویژگی‌های نهایی محصول دارد.

قبل از پیاده‌سازی eXPERT در یک شرکت توسعه نرم‌افزار تعهد مشتری به پروژه باید به دقت ارزیابی شود. اگر ارتباطات کم رنگ شود مزایای به‌ دست‌ آمده از مشتری متعهد به راحتی از دست می‌رود.
به طور کلی معرفی یک رویکرد جدید دشوار است و معمولا سازمان برای سازگاری با آن نیاز زمان دارد. مطالعه انجام شده روی Rila Solutions بهبود قابل توجهی را در میزان بهره وری، کاهش نرخ نقص و کاهش تلاش‌های صرف شده برای انجام کار را نشان می‌دهد و این اولین گام برای کسب نتایج بهتر است.
مطالعه انجام شده روی مورد Rila Solutions بخشی از اجرا و پیدا کردن یافته‌های تجربی در اجرای روش‌ اجایل مبتنی بر XP است. برخی از معیارهای پیشنهادی را می توان در چارچوب XP – EF ادغام کرد که ممکن است در پروژه‌های آینده برای ارزیابی دقیق‌تر پذیرش eXPERT مورد استفاده قرار می‌گیرد.

این مقاله ترجمه‌ای از مقاله Analyses of an agile methodology implementation است.