کیفیت و انعطاف بالا در برابر تغییرات، ارمغان متدولوژی سریع یا XP

این مطلب یکی از مقالات پرونده ویژه«متدولوژی‌ها، الگوها و معماری نرم‌افزار» شماره 207 ماهنامه شبکه است. علاقه‌مندان می‌توانند کل این پرونده ویژه را از روی سایت شبکه دانلود کنند.

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

متدولوژی چیست؟

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

مطلب پیشنهادی

قدیمی اما همچنان اثرگذار

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

برنامه‌نویسی سریع (Extreme programming)

ریشه شکل‌گیری متدهای توسعه چابک به دهه 90 میلادی بازمی‌گردد. این متدها به وجود آمدند تا مشکلات و نارسایی‌های متدولوژی‌های سنگین وزن آبشاری را حل کنند. مدیران پروژه‌ها و مهندسان ارشد نرم‌افزاری که در صف منتقدان متدولوژی سنگین وزن قرار داشتند و یک مانفیست چابک را ارائه کردند، بر این باور بودند که متدولوژی‌های سنگین وزن مدلی خاص از توسعه را ارائه می‌کنند که به‌شدت منظم بوده، به شکل غیرمنعطفی فرآیند‌ها را طبقه‌بندی کرده و اغلب آن‌ها سبکی خاص از مدیریت میکرو (Micro-Management) را ارائه می‌کنند. (درحالی‌که این گروه از مهندسان نرم‌افزار دست‌کم 30 سال پیش به چنین مشکلی اشاره داشتند، امروزه شاهد هستیم، تیم‌هایی که به سبک مدیریت میکرو هدایت می‌شوند در عمل سرخورده و بی‌انگیزه شده و انرژی کارمندان آن‌ها به‌سرعت هدر می‌رود. این مشکل ازآن‌جهت رخ می‌دهد که مدیران سنتی با کنترل بیش‌ازاندازه کارمندان خود راه هرگونه پیشرفت و موفقیت را بسته و زمینه را برای فرسودگی و دلسردی کارمندان فراهم آورده‌اند. مشکلی که امروزه بیشتر شرکت‌های داخلی نیز با آن دست‌به‌گریبان هستند. مدیرانی که به‌جای تعامل با کارمندان تنها به آن‌ها اعلام می‌دارند چه‌کاری را باید انجام دهند.) همین مسئله زمینه‌ را برای به وجود آمدن متدولوژی‌های چابک مساعد ساخت که از سال 1994 به بعد به دنیای نرم‌افزار وارد شدند. فرآیند توسعه یکپارچه (RUP)، اسکرام (Scrum) ،Crystal Clear، متدولوژی XP، توسعه تطبیقی نرم‌افزار، توسعه مبتنی بر ویژگی، سیستم‌های پویا از جمله متدولوژی‌های چابکی بودند که در دهه 90 میلادی ابداع شدند. اما سرانجام در سال 2001 میلادی مانفیست چابک منتشر شد و در نهایت مدل‌هایی را که به آن‌ها اشاره کردیم، با عنوان متدولوژی‌های چابک طبقه‌بندی کرد. شکل(1) متدولوژی‌های چابک را همراه با عملکرد آن‌ها به شکل طبقه‌بندی‌شده نشان می‌دهد. مانفیست منتشر شده در ارتباط با روش‌های چابک بر چهار اصل فردگرايي و تعامل سازنده به‌جای تمرکز خاص بر فرآيندها و ابزارها، ارائه نرم‌افزار قابل‌اجرا به‌جای مستندات مفهومي، همکاري با مشتريان به‌جای مذاکرات مبتنی بر قرارداد و پاسخ‌گویی به تغيير به‌جای انجام خطی فرآیندهای غیرمنعطف تاکید دارد. 

مدل توسعه XP

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

Pair Programming

Pair Programming یا به زبان عامیانه برنامه‌نویسی جفتی (دوبه‌دو) یکی از رایج‌ترین تکنیک‌هایی است که در توسعه نرم‌افزاری چابک به کار گرفته می‌شود و در آن دو برنامه‌نویس به شکل تیمی روی یک ایستگاه کاری مشغول کار می‌شوند. در هر لحظه یکی از این دو برنامه‌نویس به کدنویسی مشغول بوده و دیگری کد او را بررسی و نقد کرده و به فراخور نیاز راهنمایی‌‌اش می‌‌کند. این دو به‌صورت دوره‌‌ای جای خود را عوض کرده و کسی که راهنمایی و نقادی را انجام می‌داده دست به کدنویسی می‌زند و کدنویس مرحله قبل به نقاد فعلی تغییر نقش می‌دهد. در این الگو به نفر دوم که نظاره‌گر کدنویس است، مشاهده‌گر (observer) یا ناوبر (navigator) گفته می‌شود. در این ترکیب یک نفر می‌تواند نقش یک استراتژیست را بازی کرده، کدها را نقد کرده و نقشه راه کلی برنامه را مشخص کند و برای مشکلاتی که ممکن است در آینده رخ دهد راهکاری را ارائه ‌کند. در حقیقت نفر دوم به‌جای آن‌که به تکنیک‌ها توجه بیشتری داشته باشد به تاکتیک‌ها دقت نظر دارد. (شما نیز زمانی که در دانشگاه مشغول تحصیل بودید، در کلاس‌های کارگاهی که به‌صورت دو نفری برگزار می‌شد، بدون آن‌که اطلاع داشته باشید از متدولوژی XP و همین تکنیک استفاده می‌کردید.) 

مطلب پیشنهادی

طراحی و توسعه نرم‌افزارها به شکل V

باید‌ها و نبایدها‌ی به‌کارگیری مدل V در ارتباط با توسعه نرم‌افزارها

Code Review

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

استعاره

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

مالکیت کد

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

ساده‌سازی و شفاف‌سازی کدها

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

نشرهای کوچک

XP از مدل مارپیچی استفاده می‌کند که نشرهای کوچک 3 الی 4 هفته‌ای دارد. در انتهای هر انتشار مشتری محصول را بازبینی کرده، ایرادهای آن‌را شناسایی کرده و نیازهای مدنظر خود را ارائه می‌کند. 

یکپارچه‌سازی مستمر

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

حضور مشتری در محل

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

تست واحد/واحد آزمایش (ویژه همه کدها)

در برنامه‌نویسی کامپیوتر، تست واحد (unit testing) یک روش آزمایش نرم‌افزار است که بخش‌های مجزا و کوچکی از سورس کد را برای اطمینان از درست کار کردن آن‌ها بررسی می‌کند. در این روش، درستی هر قسمت از کد که به آن «واحد» گفته می‌‌شود، از طریق به‌کارگیری ورودی‌ها ارزیابی شده و به‌طورمعمول، تست واحد از سوی توسعه‌دهندگان
 انجام می‌شود. 

فضای کاری

در مدل XP روابط میان اعضای تیم با یکدیگر و با مشتری از اهمیت خاصی برخوردار است.

کار در بازه زمانی استاندارد

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

برنامه‌ریزی

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

مطلب پیشنهادی

نسخه‌ای شفابخش برای چابکی کسب‌وکارها

اسکرام چیست و چگونه آن را استفاده کنیم؟

قواعد و مفاهیم مدل XP

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

این فرآورده‌ها عبارتند از:

User Stories: به‌طورمعمول به ‌شکل متنی بوده و توسط مشتريان نوشته می‌‌شوند. از طريق داستا‌ن‌های کاربری نيازمندي‌های سيستم مشخص می‌شوند.

Iteration Plan: مجموعه‌‌ای از داستان‌های کاربری بوده که از سوی مشتری ارائه می‌شود. در هر مرحله از تکرار که نزدیک به دو هفته به طول می‌انجامد، این داستان‌ها نوشته می‌شوند. طرح‌‌ها بر مبنای اولويت مدنظر مشتری در دستور کار قرار می‌گیرند، البته به شرطی که دو طرف بر سر بودجه به توافق برسند. 

Task: زيرمجموعه‌ای از داستان‌های کاربری است. Task ها از نظر تکنيکی و کاری اولويت بيشتری دارند و بايد سريع انجام شوند. Task‌ها در مرحله طرح‌‌ريزی تکرارها (Iteration Planning) مشخص می‌‌شوند.

Metaphore: نشان‌دهنده يک تصوير کلی از سيستم است. برای هر عنصر در سيستم يک نام در نظر گرفته می‌‌شود. ارتباط بين عناصر درگير در سيستم از طريق استعاره‌ها (Metaphore) مشخص می‌‌شود.

Spike: اشاره به يک راه‌حل ضربتی (Spike Solution) دارد. راه‌حل ضربتی برنامه ساده‌اي است که به‌وسیله آن می‌‌توان راه‌‌حل‌‌های بالقوه را کشف کرد. در مواردی که داستان‌های کاربری حساس و مهم باشند، از راه‌حل‌های ضربتی استفاده می‌‌شود.

Planning Game: يک تعامل محصور (Close Interaction) بين مشتری و برنامه‌‌نويس است. برنامه‌‌نويس کار لازم را برای پياده‌‌سازی گزارش‌‌های مشتری تخمين می‌‌زند و مشتری در مورد حوزه و زمان نشرها تصميم‌‌گيری می‌‌کند.

Simple Design: تأکيد اصلی در اين روش روی طراحی ساده‌‌ترين راه‌‌حل ممکن بوده، به‌طوری‌که پيچيدگي‌‌های غيرضروری و کدهای اضافی به‌سرعت حذف ‌شوند.

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

Refactoring: بازسازی سيستم با حذف موارد تکراری، بهبود ارتباطات، ساده‌‌سازی و افزايش انعطاف‌‌پذيری سيستم است.

Pair Programming: به کدنویسی دونفره اشاره دارد که در اغلب موارد يک کدنويس و يک متخصص استراتژی با یکدیگر کار می‌کنند.

Collective Ownership: هر فردی می‌‌تواند کد را در هر زمانی تغيير دهد.

Continuous Integration: کد جديد در حداقل زمان ممکن به کد اوليه مرتبط می‌شود. بنابراين سيستم دفعات زيادی در روز یکپارچه‌شده و ساخته می‌شود.

40 Hour Week: حداکثر چهل ساعت کار در هفته کافی است. اين مورد اجباری است و بيشتر از اين ساعات کار مجاز نیست.

On- Site Customer: مشتری بايد به‌صورت تمام‌وقت در دسترس تيم توسعه باشد.

Coding Standards: قواعد کدنويسی بايد از سوی همه برنامه‌‌نويسان رعايت شود و ارتباط بين کدها مورد توجه قرار گيرد.

دیاگرام متدولوژی XP را بر مبنای فرآورده‌هایی که در بالا به آن‌ها اشاره شد، در شکل (4) نشان داده شده است.

کلام آخر

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