مقاله آشنایی با متدولوژی های چابک در مدیریت نرم افزار

بخشی از مقاله

آشنايي با متدولوژي هاي چابک در مديريت نرم افزار

چکيده :
در دهه اخير، روشهاي توسعه چابک به عنوان روشهايي جديد، متفاوت و موثر مطرح گرديده اند. جديد، بدان جهت که بيش از ده سال از انتشار اولين مقالات و کتابها در اين زمينه نمي گذرد. متفاوت ، بدان جهت که رويکردهاي آنها، ازاصولي پيروي مي نمايند که در مواردي به طور کامل در مقابل روشهاي متداول پيشين قرار گرفته است و
موثر، بدان جهت که با اقبال جامعه توسعه دهندگان در مورد توسعه گونه هايي ازپروژه هاي نرم افزاري روبرو شده است .در چندسال گذشته و از سالهاي پاياني قرن بيستم ميلادي، توجه فراواني به اين روشها به عنوان راه حل مقابله با تغييرات درمحيط توسعه جلب شده است .اين روشها با تاکيد بيشتر به نظرات مشتري و تعامل با وي و همچنين توليد نشرهاي کوچک و متعدد، سعي در کنترل سريع تغييرات و کمتر نمودن زمان مورد نياز و هزينه ها دارند.
در اين مقاله سعي خواهيم نمود ضمن تبين مفهوم چابکي متد xp را به تفصيل مورد برسي قرار داده وسپس چندين ويژگي مهم را در مورد روشهاي FDD وDSDMو ASD و Crystal مورد تحليل و بررسي قرار دهيم .

واژه هاي کليدي :
روشهاي چابک ، منشور چابکي،Crystal، DSDM، XP ،FDD ،ASD

مقدمه
وجود يک روش توسعه مناسب براي يک پروژه نرم افزاري از اهميت ويژهاي برخوردار است .در دهه هاي اخير،تلاشهاي متنوعي براي ارائه روشهاي توسعه موثر که توان پشتيباني از محيط هاي گوناگون توسعه و نيازمنديهاي متنوع مشتريان را داشته باشند، صورت پذيرفته است .در دهه اخير، روشهاي چابک ١ به عنوان نسل جديد روشهاي
Agile Methods 1
توسعه مطرح گرديدند و تلاش نمودند
بر مشکلات روشهاي گذشته غلبه نمايند .به هر صورت روشهاي چابک نيز،محدوديتهايي دارند[٢,٣] که يکي از آنها مربوط به معماري نرم افزار و عدم توجه لازم به اهداف و مزاياي آن است [٤,٥] . در ارتباط با نگارش اين مقاله، ذکر اين نکته لازم است که بسياري از واژگان مورد استفاده به عنوان ادبيات روشهاي چابک ، کمي با اصطلاحات علمي متفاوت هستند و به همين علت ،معادلسازي آنها با واژگان فارسي اندکي سخت است . از آنجائيکه روش -هاي چابک از ميان خبرگان صنعتي ظهور نموده اند، شاهد واژگان عاميانه تري در اين حوزه هستيم .در مجموع ، به نظر مي رسد که ميل حاميان چابکي به غيررسمي عمل نمودن ، تنها محدود به توسعه نرم افزار نمي شود.
١- چابکي
چابکي توانايي ايجاد و پاسخ به تغييرات به منظور کسب سود در محيط متغير حرفه است [٦].
همانطوريکه در تعريف بالا نيز قابل مشاهده است ، چابکي و چابک بودن ارتباط تنگاتنگي با مسئله تغيير دارد.
تغييري که از دگرگوني هاي محيطي حرفه ناشي مي شود و سازمانها را ملزم به مقابله مي نمايد .
سازماني که نخواهد و يا نتواند در مقابل تغييرات عکس العمل مناسب نشان دهد بايستي منتظر لطمات شديد و در نهايت ناکامي و مرگ باشد.
اما نکته جالب اين تعريف آنجاست که سازمانهايي که توانايي و چابکي لازم براي مواجه با تغييرات را داشته باشند، مي توانند با ايجاد تغييرات در بازار و محيط حرفه، عرصه را بر رقباي خويش تنگ و تنگتر نموده و در پي آن ، سود بيشتري را کسب نمايند.
در محيط هاي متغير معمولا طرحها اشتباه از آب در مي آيند[٧] که اين مسئله در محيط هاي توسعه نرم افزار به خاطر عوامل محيطي انساني که تغييرات و تلاطم در آنها امري طبيعي است ، نمود بيشتري دارد .تاکيد چابکي برتوانايي افراد براي پاسخگويي به تغييرات و توجه کمتر به برنامه ريزي و فراهم نمودن طرحهاي مفصل است .
البته اين بدان معنا نيست که روشهايي که چابکي را مدنظر قرار مي دهند، برنامه ريزي نميکنند، بلکه برنامه ريزي به گونه اي است که انعطاف پذيري لازم براي مواجهه با تغييرات و کسب سود را دتغايشيتهرات بامشحدي .طدير اوزاقحع ديزمفارنايترکهمي روند، ديگر روش هاي مبتني بر طرح پاسخگوي نيازها نيستند .در اين شرايط ، روش هاي چابک ، تنها روش هاي کسب موفقيت هستند .اما اين نکته نيز قابل تامل است که اين روشها نيز با افزايش فراوان و لحظه اي تغييرات ممکن است دچار مخاطراتي شوند.

١-١ چابکي در مقابل سنگين وزني
برخي بر آن باورند که روشهاي چابک در مقابل روش هاي سنگين وزن که مبناي کار خود را بر برنامه و مستندات قرار مي دهند، مطرح شده اند .اين گفته، چندان به واقعيت نزديک نيست .علت به وجود آمدن اين تفکر آن است که درابتداي پيدايش روش هاي چابک ٤، برخي آنها را روشهاي سبک وزن لقب مي دادند[٦].
در شرايطي که سبک وزن بودن روش ، بيشتر به کوچکي تيم پروژه و کاهش حجم کاري اشاره دارد، چابکي، عدم قطعيت محيط و نيازمنديها را مورد تاکيد قرار مي دهد .ممکن است از رويکردي چابک در يک پروژه به نسبت بزرگ با تيم توسعه توزيع شده استفاده گردد و پروژه با بهره مندي از اين رويکرد و با پاسخگويي مناسب به تغييرات به نتيجه مطلوب برسد [٨,٩,١٠].
به هر صورت ، چالشهايي در استفاده از روشهاي چابک مطرح گرديده است و عده اي بر اين عقيده ايستاده اند که با افزايش اندازه پروژه ، شاهد بروز مشکلاتي خواهيم بود [٤١١]آقايBoehmعقيده دارد که نياز است تا تلفيقي ازچابکي و طرح رانگي شکل گيرد[٣,١]. با اين استدلال که روشهاي چابک اگر چه در مواجهه باتغييرات موفق هستند،در مقابل پيچيدگي به خوبي عمل نمي کنند.[١] در ارتباط با اين مسئله، مقالات و تحقيقات متنوعي انجام شده است و سعي شده تا

Plan Driven 2
Heavyweight 3
Lightweight 4

روشهاي چابک را در مقابل افزايش مقياس توانمند نمود. ١,١٢,١٣,١] ,15,16,17]

١-٢ چابکي و افراد
اغلب روشهاي چابک مبناي کار خود را بر افراد و تواناييهاي آنها قرار مي دهند .فردگرايي در اين روشها، يکي از ارکان محسوب مي شود و يکي از دلايل انعطاف پذيري اين روشها، همين اتکا بر افراد و توانايي هاي آنهاست .بطوريکه برنامه نويسان علاوه بر کدنويسي در ديگر فعاليتهاي توسعه همچون برنامه ريزي، تحليل ، طراحي و آزمون نيز سهيم هستند .اين نکته باعث افزايش نقش روز افزون برنامه نويسان در توسعه سيستم و بهره مندي هر چه بيشتر از تجربيات آنها است .اين موضوع در شرايطي مطرح مي گردد که برنامه نويس در روشهاي پيشين ، تنها اجرا کننده تصميمات بالادستي ديگر نقش داران پروژه به حساب مي آمد .اين ماجرا تا بدان جا بود که تخمين غلط مدير پروژه در زمانبندي به حساب عدم کارآيي برنامه نويس نوشته مي شد .مدير پروژهاي که به علت دوري از عمليات واقعي توسعه و درگير نبودن با مشکلات فراوان و متنوع آن ، برآورد غلطي از ويژگيهاي پروژه و توان اجرايي نيروهاي خود داشت ، برنامه نويسان را متهم به ضعف و عدم کارآيي مي کرد.
آقاي Beckبه عنوان پايه گذار روش XP بر اين نکته تاکيد مي ورزد و به خاطرات تلخ يکي از دوستان برنامه نويس خود اشاره مي کند[١٨]با اين اوصاف ، شايد بتوان روشهاي چابک را نگرشي پايين به دباانسوت برتخاوادسيتدهگاازيبرمندايمرهيتنيويکسهان بيشتر در پي برنامه ريزي، بودجه بندي و زمانبندي در اتاقهاي مجزا و محيطي مجرد وانتزاعي است
به هرصورت طبق مطالعات انجام شده 19-رضایت شغلی در تیم های چابک تقريبا دو برابر تيمهاي غيرچابک برآورد شده است .اين نشانه موفقيت روشهاي چابک از منظر دستيابي به رضايت شغلي توسعه دهندگان به عنوان يک فاکتور مهم در موفقيت تيم هاي توليد کننده نرم افزار است .
١-٣ منشور چابکي ٥
در سال ٢٠٠١، هفده نفر از افرادي که در زمينه روشهاي چابک فعاليت داشتند از جمله آقايان Beck،Fowler Cockburn در شهرSnowbird به ابتکار ظ artin دور يکديگر جمع شدند تا علاوه بر تبادل نظر و بحث به استراحت و اسکي بپردازند. نتيجه اين گردهمايي، منشوري بود که به منشور چابکي شهرت يافت . اين منشور بر چهاراصل ذيل استوار است .
•فردگرايي و تعامل ٦ برتر از فرآيندها و ابزارها.
•نرم افزار قابل اجرا برتر از مستندات مفهومي.
•همکاري با مشتريان ٨ برتر از مذاکرات بر روي قرارداد.
•پاسخ به تغيير ٩ برتر از دنباله روي از طرح مفهوم کلي ارزشهاي اين بيانيه که تبيين کننده ديدگاه توسعه نرم
افزار چابک است ، چنين مي باشد:
١-٣-١ افراد و تعاملات :
در توسعه نرم افزار چابک ، دانش ، مهارت و توانايي افراد و برخورداري از انگيزه و روحيه خودسازماندهي آنان و نيز تعاملات مؤثر بين افراد، حائز اهميت است .
چرا که اين افراد هستند که نرم افزار را توسعه مي دهند نه ابزارها و فرآيندها .واضح است که ابزارها و فرآيندها مهم هستند
Agile Manifesto 5
Individuals and Interactions 6
Working Software 7
Customer Collaborations 8
Respond to Change 9
3

اما مهمتر از آنها، افرادي هستندکه با آنها کار مي کنند .اين روش توسعه نرم افزار در اصل مردم گرا ١٠ است تا فرآيند گرا ١١ در واقع متدهاي چابک تاکيد مي کنند که هيچ فرآيندي را نمي توان جايگزين مهارتهاي تيم توسعه دانست و نقش يک فرآيند صرفا پشتيباني از تيم توسعه در جهت رسيدن به اهدافشان است .نگرش مردم گرا بودن به شيوه هاي مختلفي در متدهاي چابک متجلي مي گردد و تاثيرات گوناگوني دارد از جمله آنکه به جاي تحميل يک فرآيند به تيم توسعه ، بايد آن فرآيند مورد پذيرش تيم قرار گيرد از آنروي که اجراي يک فرآيند، مستلزم تعهد و همکاري فعالانه تمام اعضاي تيم است . ديگر آنکه، توسعه دهندگان بايد قادر باشند تصميمات تکنيکي اتخاذ نمايند .به بيان ديگر مسئوليت ها به صورت مساوي بين مدير پروژه و توسعه دهندگان تقسيم مي شود و بدين ترتيب توسعه دهندگان در راهبري پروژه نقشي مساوي با مدير را ايفا مي کنند.

١-٣-١ نرم افزار کارا : ارائه نرم افزار کارا مهمتر از ارائه مجموعه اي از مستندات به مشتريان است .اگرچه وجود مستندات کافي براي آموزش کاربران و نگاهداري سيستم لازم است اما هدف اصلي توليد نرم افزار است نه مستندات . در واقع يکي از تفاوتهاي ملموس متدولوژي چابک با ساير متدولوژي ها اين است که در اين روش ، حجم مستندسازي بطور قابل توجهي کم است چرا که اين روش بيشتر کدگرا ١٢ است تا مستندگرا و بر اين ديدگاه نيز تکيه دارد که بخش اصلي مستندات را کدهاي برنامه تشکيل مي دهند.

People‐oriented 10
Process‐oriented 11
Code‐oriented 12
١-٣-٢ همکاري با مشتري:
از جمله مشکلاتي که اغلب توسعه دهندگان نرم افزار با آن مواجه هستند، عدم درک کافي يا مناسب نيازمنديهاي مشتري و تعاملات غير مؤثر با مشتري است .داشتن قرارداد براي يک پروژه مهم است اما براي ارتباط با مشتري کافي نيست .روش چابک در توسعه نرم افزار بر همکاري و مشارکت مداوم با مشتري و افراد ذينفع در طول حيات پروژه تاکيد بسيار مي ورزد.
١-٣-٣ پاسخگويي به تغييرات :
نيازمنديهاي مشتري دستخوش تغيير مي شوند، محيط حرفه اي که نرم افزار مرتبط با آن است ، تغيير مي کند، تکنولوژي به مرور زمان تغيير مي کند .تغيير يک واقعيت در توسعه نرم افزار است .واقعيتي که فرآيند توسعه نرم افزار بايد آن را پشتيباني کند .توسعه نرم افزار چابک بر پاسخگويي سريع به تغييرات و توسعه مداوم ، تمرکز مي کند .در واقع آنچه که موجب مي شود روشهاي چابک از تغييرات استقبال نمايند اين است که اين روشها قابل پيش بيني نيستند بلکه داراي خاصيت تطبيقي ١٣ مي باشند.
ساير روشهاي توسعه نرم - افزا(plan‐driven) ميکوشند کل فرآيند توليد را با جزئيات کامل ، براي مدت طولاني طرح ريزي نمايند .
اين شيوه تنها تا زماني که تغييراتي پديد نيامده ، کارآمد است .بنابراين ذات اين روشها در مقابل تغييرات مقاوم است .در حالي که روشهاي چابک مي کوشند که سيستم و حتي روند توليد را با تغييرات تطبيق دهند وبا آن پيش روند.
بنابراين :
مورد اول با تکيه بر مهارت افراد، به توانايي و تعاملات بين آنها توجه و رغبت دارد و به تاکيد بيش از حد بر روي فرآيندها، طرحها و ابزارها انتقاد مي ورزد .به
Adaptive 13
4

عنوان مثال ، محيط توسعه نرم افزاري را در نظر بگيريد که فرآيند وروندهاي کاري به طور دقيق مشخص شده اند و ابزارهاي جديد، پيچيده و با قابليت به نسبت بالا در اين محيط دردسترس افراد مي باشند، اما تيم توسعه متشکل از افرادي است که با اين روشها و ابزارها آشنا نيستند .چنين تيمي درتوسعه نرم افزار به احتمال قوي دچار مشکل خواهد شد، چرا که کساني که نرم افزار را توسعه مي دهند، افراد هستند ونه ابزارها و فرآيندها .اشتباه نشود، فرآيندها و ابزارها مهم هستند اما مهمتر از آنها افرادي ميباشند که با آنها کار ميکنند .البته اين موضوع براي مديريت معمولا قابل پذيرش نيست ، چراکه نگاهي ابزارگونه به افراد و تفکري مبني بررابطه مستقيم بين زمان و افراد در ذهن دارد، يعني مي توان با افزايش افراد به نتيجه بهتري رسيد، در صورتي که چنين موضوعي صحيح نيست .[20]
مورد دوم بر توجه بيشتر به ساخت نرم افزار قابل اجرا به نسبت مستندسازي اشاره دارد. اگر از مشتري پرسيده شودکه آيا ترجيح ميدهد، نرم افزار قابل اجرا در اختيار داشته باشد و يا يک مستند ١٠٠ صفحه اي، چه پاسخي شنيده مي شود؟ در ٩٩ تا ١٠٠ درصد موارد پاسخ نرم افزار قابل اجرا خواهد بود .مستندات براي آموزش کاربران و نگهداشت سيستم مورد نياز هستند، اما نبايستي فراموش گردد که هدف اصلي توسعه نرم افزار است و نه توسعه مستندات .اين درشرايطي است که مستندسازيهاي حجيم از مشکلات هميشگي روش هاي توسعه بوده است .
در سومين اصل ، مشکلي که همواره توسعه دهندگان نرم افزار با آن روبرو هستند، مورد توجه قرار مي گيرد و آن عدم دستيابي به درک مشترک و همکاري نامناسب بين توسعه دهندگان ومشتريان است .
داشتن قرارداد براي يک پروژه مهم و ضروري است و وجوه قانوني آن را در بر دارد، اما براي ارتباط با مشتري کافي نيست .در توسعه نرم افزار نياز به مشارکت و همکاري مداوم با مشتري وجود دارد .به خصوص که کشف نيازهاي مشتري از مشکلات هميشگي توسعه دهندگان است .
مورد پاياني، بر پاسخگويي به تغييرات تمرکز مي نمايد .
خواسته هاي مشتري از سيستم نرم افزاري تغيير مي نمايد، محيط حرفه اي که نرم افزار بر پايه آن توسعه يافته است ، دچار تغيير مي گردد و همچنين تکنولوژي به مرور زمان دگرگون مي شود .تغيير تنها مفهوم ثابت در دنياي نرم افزار است . به عبارت ديگر، تغيير يک واقعيت بدون ترديد و تلخ در توسعه نرم افزار است ، واقعيتي که روش توسعه بايستي مواجهه با آن را پشتيباني نمايد. برنامه ريزي و داشتن طرح توسعه براي يک پروژه اشتباه نيست بلکه اگر پروژهاي طرح نداشته باشد، جاي نگراني دارد. نکته آن است که طرحها معمولا اشتباه از آب در ميآيند و نبايستي آنها را بدون اشکال وکاملا درست فرض نمود و کورکورانه از آنها پيروي نمود.
بسياري از دست اندر کاران توسعه نرم افزار موافق با اصول چابکي هستند، اما اينکه در عمل چقدر پايبندي به آنها وجود دارد، سوال ديگري است .مديراني که بر درستي طرح اوليه اصرار مي ورزند و تغييرات را نمي پذيرند، هنوز وجوددارند. چابکي ابزاري نيست که در شرکت و يا سازمان نصب شود و از فرداي آن تمامي مشکلات گذشته پايان يابد.چابک بودن بايستي به صورت فرهنگ سازماني طراحي و نهادينه شود، و به همين جهت است که منشور چابکي تنهاتاکيداتي را به عنوان اصول پايه معرفي مي نمايد، تا هر سازماني بنا به شرايط خود از آن بهره مند گردد.
١-۴ قوانيني که زير بناي بيانيه توسعه نرم افزار چابک را شکل مي
دهند، به قرار زير مي باشند :
• جلب رضايت مشتري با ارائه سريع نرم افزار کارا
•پذيرش تغييرات در نيازمنديهاي مشتري و اعمال آن حتي در اواخر
زمان توسعه نرم افزار
•ارائه مکرر نرم افزار کارا
(ارائه آن هرچند هفته يکبار، بهتر
از هرچند ماه يکبار است ).
•عامل اصلي سنجش پيشرفت پروژه ،
نرم افزار کارا است .
•ميزاني از سرعت توسعه که بتوان آنرا با گامهاي مداوم و ثابت ، حفظ نمود.
•همکاري نزديک و روزمره بين صاحبان تجارت و توسعه دهندگان سيستم
•گفتگو رو در رو و تعاملات شفاهي، بهترين شکل ارتباطات است .
•پروژه ها با افرادي که داراي انگيزه و قابل اعتماد هستند، پيش مي روند.
•توجه مداوم به طراحي خوب و کيفيت بالا از نظر فني
•سادگي
•تيم هايي که اعضاي آن داراي ويژگي خودسازماندهي و خودراهبري هستند.
•قابليت انطباق با شرايط در حال تغيير
روشهاي چابک از برنامه ريزي کل پروژه و در نظرگيري تمامي جزئيات آن در ابتداي کار، اجتناب نموده وپروژه را به بخشهاي کوچک تقسيم مي کنند و سپس با برنامه ريزي هر بخش و تکميل آن و افزودن آن به ساير بخشها، پروژه را پيش مي برند .اين بخشها غالبا در بازه هاي زماني کوتاه مدت (iterations) که معمولا بين ١ تا ۴ هفته است ،توسعه مي يابند .هر بازه زماني يک چرخه توسعه نرم افزار کامل است که شامل برنامه ريزي،آناليز نيازمنديها، طراحي، برنامه نويسي ، يونيت تست و تست نهايي ١٤است .اين شيوه ، ريسک کلي پروژه راکاهش مي دهد و امکان تطابق با تغييرات را نيز به سرعت فراهم مي کند .هدف آن است که در انتهاي هر بازه زماني بخش قابل ارائه اي از نرم افزار با حداقل
ميزان اشکالات توليد شود اما اين بخش لزوما شامل عملکردهاي کافي نيست و ممکن است براي ارائه يک محصول و حتي يک مشخصه جديد، چندين بازه زماني لازم باشد.
کارهايي که در هر بازه زماني انجام مي گيرد، بر اساس اولويت بندي صورت گرفته در جلساتي است که درابتداي هر بازه زماني با حضور نماينده مشتري يا مشتريان و توسعه دهندگان سيستم ، برگزار مي شوند.
اما نکته اي که در اينجا شايان ذکر است اين است که با توجه به وجود بازه هاي زماني کوتاه مدت در روشهاي چابک ما با توسعه مبتني بر تکرار(iterative development) مواجه هستيم . در واقع توسعه مبتني بر تکرار، با ايجاد يک مکانيسم بازخورد در بازه هاي زماني کوتاه مدت ، راه حلي براي کنترل فرآيند غير قابل پيش بيني است .در توسعه مبتني بر تکرار، نگارش هايي از سيستم نهايي توليد مي شود که در برگيرنده جنبه هاي مورد نياز سيستم است .اين نگارش ها مي توانند عمليات کوچک و مطمئني را انجام دهند .توسعه مبتني برتکرار در فرآيندهاي تطبيقي ضروري است بدان دليل که اينگونه فرآيندها بايد با تغييرات ايجاد شده در جنبه هاي مورد نياز سيستم تطبيق پيدا کنند و چنين چيزي با طرح ريزي بلندمدت براي سيستم سازگار نمي باشد.بنابراين در يک فرآيند تطبيقي طرح هايي کوتاه مدت براي يک بازه زماني کوتاه مدت ايجاد مي شود.
تطبيق دو جنبه دارد:
١- تغيير در نرم افزار براي تطبيق با تغييرات ايجاد شده در نيازمنديهاي مشتري
٢- تغيير در فرآيند توليد .بدين مفهوم که روند توليد در پايان هر بازه زماني بازديد، نقاط ضعف و قوت بررسي وتصميماتي براي بازه زماني بعدي اتخاذ مي شود.
6

متدهاي چابک بر تعاملات مداوم و دائمي با مشتري، سادگي، تست ، بهينه سازي کدها ١٥، کپارچه سازي مداوم ١٦، بازخوردهاي مداوم ١٧ و بکارگيري ابزارهاي اتوماتيک جهت انجام عمليات تست و يکپارچه سازي و سايرراه کارها در جهت بهبود کيفيت و چابکي پروژه ، تأکيد بسيار مي ورزند.
٢- روشهاي چابک
تقريبا از سالهاي پاياني قرن بيستم ، روشهاي متنوعي در رده روشهاي چابک معرفي گرديده اند .
اين روشها اغلب تلاش بر پايبندي به اصول چابکي دارند .از جمله اين روشها مي توان XP [١٨,٢١,٢٢,٢٣]
, FDD١٨[24] و Scrum[25]و [٢٧] ASD٢٠[26] DSDM١٩و Crystal[28] را نام برد.
با وجود مشترکات فراوان ، هر يک از اين روشها، رويکرد مخصوص خود را دنبال مي نمايد و ويژگي هاي خاص خود را دارد. به عنوان مثال ، روش Scrum بيشتر رويکردي مديريتي را دنبال مينمايد در حالي که XP بيشتر بر توسعه محصول تمرکز دارد. براي آشنايي بيشتر با مجموعه اين روشها مراجع متعددي وجود دارد که خوانندگان مي توانند از آنها استفاده نمايند[٦,٢٧,٢٩] .

٢-١ مروري بر روش XP
آقايBeck به عنوان بنيانگذار روش
XP اين روش را اينگونه تعريف مينمايد:

Refactoring 15
Continuous integration 16
Frequent feedback 17
Feature Driven Development 18
Dynamic Software Development Method 19
Adaptive Software Development 20
روشي سبک وزن براي تيم هاي با
اندازه کوچک تا متوسط براي توسعه نرم افزارهاي با نيازمنديهاي متغير و مبهم است .
اين روش توسعه بر روي کار تيمي ٢١ تاکيد فراواني دارد. مديران ، مشتريان و توسعه دهندگان همگي به عنوان اعضاي تيم ، تمرکز بر دستيابي به نرم افزاري مطابق اهداف تعيين شده دارند .کار تيمي حتي در توسعه به شکلي ديگر ادامه مي يابد و توسعه دهندگان در قالب تيمهاي دو نفري و فعاليت زوج برنامه نويسي فعاليت توسعه را انجام ميدهند [١٨] .
XP چهار ارزش معرفي مي نمايد که تاثيرگذار بر فعاليتها، نقشها و تمامي تصميمات اتخاذي در اين روش مي باشند.
اين چهار ارزش عبارتند از :
ارتباط ، سادگي، بازخور و جرأت [١٨].
در ادامه مروري بر هر يک از اين ارزشها خواهيم داشت .
٢-١-١ ارتباط
اولين ارزش XP ارتباط نام دارد .
بسياري از مشکلات پروژه تا زماني که بين افراد گفتگو صورت نگيرد،حل نميشوند .گاهي اوقات يک برنامه نويس تغييري بنيادي در طراحي ايجاد مي کند و به کسي نمي گويد. گاهي برنامه نويس از مشتري سوال نمي پرسد و بر مبناي نظر خود تصميمي را لحاظ مي نمايد. در مقابل ، مشتري از برنامه نويس سوالي را نميپرسد و روند پيشرفت پروژه اشتباه گزارش مي گردد. در بعضي شرايط نيز روابط نامطلوبي بين افرادوجود دارد و پروژه را دچار مشکل مي کند .برنامه نويسي را در نظر بگيرد که به علت اعلام اخبار ناگوار از پروژه به مدير ارشد، مورد غضب قرار مي گيرد و در مقابل مشتري اطلاعات مهمي را به برنامه نويس مي گويد ولي برنامه نويس از آنها چشم پوشي مي نمايد.
Teamwork 21
7

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

٢-١-٢ سادگي
دومين ارزش XP سادگي است و انتظار ميرود که ساده ترين طرحي که مي تواند وظيفه مورد نظر راانجام دهد، استفاده شود .
دستيابي به سادگي، معمولا به آساني محقق نميگردد. دليل اين مطلب آنست که معمولا به احتمالات آينده فکر ميشود .آيا اين ويژگي نيز درخواست مي شود؟ آيا جايي ديگر نيز بدان نياز ميشود؟ و نگرانيهايي از اين دست ، معمولا تيم را به سمت و سوي توسعه سيستمي پيچيدهتر از آنچه مورد نياز است ، ميکشاند و از عواقب آن نرسيدن به زمانهاي مورد نظر و کار و هزينه بيشتري را منجر مي شود. سادگي و ارتباط ، رابطه نزديکي با يکديگر دارند. با روابط مناسبتر، ميتوان دقيقتر سيستم و نيازمنديهاي آن را فهميد و در نتيجه از پيچيده شدن بيش از حد سيستم جلوگيري نمود و ساده ترين روشها را براي توسعه سيستم بکار برد.در مقابل درک و صحبت در رابطه با سيستمي که ساده تر باشد، آسانتر محقق مي گردد و ارتباطات موثرتر و پروژه موفقتر خواهد بود.

٢-١-٣ بازخورد
درXP تاکيد بر روي نظارت نمودن ٢٢ بر وضعيت سيستم به طور مرتب ، دقيقه به دقيقه و روز به روز است .
نآمزومونهنهايهاوياحداز٢٣ ايان ست .موبضرونع ا،مه نويسان براي واحدهايي که توسعه

Monitoring 22
Unit test 23
مي دهند، موارد آزموني ٢٤ را تهيه مي نمايند. مشتريان نقل هاي کاربري را مي نويسند و برنامه نويسان آنها را تخمين مي زنند. آزمون کنندگان نيز سيستم را آزمون و از سيستم بازخورهايي را دريافت مي نمايند. بازخور وابستگي هايي با ارتباط و سادگي دار. در صورت دريافت بازخور بيشتر در رابطه با سيستم ، ارتباطات قويتر است . وقتي در حال گفتگو در مورد سيستم باشيم ، متوجه خواهيم شد که چه نکاتي را بايد مورد آزمون و اندازه گيري قرار دهيم . به همين شکل ، آزمون سيستمهاي ساده تر، آسانتر است .
همچنين زمانيکه براي سيستم ، موارد آزمون نوشته ميشود، نگرشي از ميزان سادگي سيستم نيز بدست مي آيد.
٢-١-۴جرأت
زمانيکه در توسعه سيستم ، اشکالي مانند مشکل در طراحي کلان سيستم شناخته شود و به تبع آن مشکل در آزمايش سيستم بروز کند، تيم مي بايست انسجام خود را حفظ کرده و درصدد رفع مشکل مربوطه باشد.
نکته ديگردر اين رابطه، بيرون انداختن کدي است که به نظر مناسب نوشته نشده است . اگر برنامه نويس در پايان روز به اين نتيجه رسيد که کدي نوشته است که به اندازه مطلوب مناسب نوشته نشده و طراحي قابل قبولي ندارد، بايستي جرأت کنار گذاشتن آن را داشته باشد و فردا از ابتدا بر روي آن بخش تمرکز نمايد، چرا که اصرار بر حفظ کدي که ميدانيم چگونه بهتر از آن را تهيه نمائيم ، کاري اشتباه است .
ارزش احترام نيز در سال ٢٠٠٤ توسط آقايBeck اضافه گرديد که بر حفظ احترام ميان اعضاي تيم تاکيد دارد.[٢١].
٢-٢ فعاليتهايXP
Test case 24
8

براي تحقق ارزش هايXP،فعاليت هايي در نظر گرفته شده است که اين فعاليت ها به شرح ذيل مي باشند: [18]
٢-٢-١بازي برنامه ريزي
محدوده نشرها بايستي با توجه به اولويت هاي حرفه ٢٥، ويژگيها و تخمينهاي فني معين شود .به طور کلي، چالش برنامه ريزي، مشکلات موجود در تعيين محدوده ، تخمين و اولويت بندي است . بنابراين برنامه ريزي، در واقع تصميم گيري در موارد زير است .

٢-٢-٢ محدوده ٢٦
چه ميزان از مسئله بايستي در قالب سيستم توسعه داده شود تا محصول ارزشمند باشد .مشتري که دررابطه با حرفه است ، اين توانايي را دارد که بيان نمايد، چه ميزان کافي نيست و چه ميزان بيش از حد است .
اولويت ٢٧ در اينجا بايستي تعين شود که بين دو بخش الف و ب کداميک بايستي توسط برنامه نويسان توسعه داده شود.
ترکيب نشرها ٢٨ تشخيص اينکه چه ميزان از سيستم بايستي توسعه يابد تا يک نشر براي حرفهاي که بدون نرم افزاراست ، مفيد واقع شود.
تاريخهاي نشر ٢٩ بايستي مشخص گردد که زمان هاي مهم نشر نرم افزار کدامها مي باشند.

٢-٢-٣ نشرهاي کوچک ٣٠
Business Priorities 25
Scope 26
Priority 27
Composition of releases 28
Dates of releases 29
Small releases 30
نشرها بايستي تا حد امکان کوچک و
در بردارنده ارزشمندترين نيازهاي حرفه باشند.
٢-٢-۴ استعاره
استعاره به افراد درگير در پروژه کمک مينمايد تا سيستم را بهتر درک نمايند و شامل عناصر اصلي