منبع پایان نامه درمورد نرم افزار، کسب و کار، ناخودآگاه

مداوم
21
مرور تکرار / نمايش
2
تست واحد اتوماتيک
22
تست پذيرش توسعه آزمون رانده
3
بک لاگ اولويت بندي شده
23
تکرارهاي کوتاه
4
گذشته نگري
24
ويژگيهاي قابل تحويل در پايان هر تکرار
5
مالکيت جمعي کد
25
قابل ديدن بودن و ارزشمند بودن ويژگي ها براي مشتري در يک تکرار
6
سرعت پايدار
26
مشارکت روزانه مشتري/مدير يا صاحب محصول
7
بازتوليد (بهينه سازي کد)
27
ساخت ده دقيقه اي
8
تست واحد در توسعه آزمون رانده
28
تعريف انجام شده
9
تست ويژگي هاي کامل انجام شده در طول تکرار
29
تکرارهاي تثبيت کننده
10
تيم هاي کوچک
30
تاکيد مستندسازي بر مستند نمودن تصميمات به جاي برنامه ريزي
11
طراحي آني
31
ارتباطات همگام
12
زمان بسته
32
تيم چند وظيفه اي با يک هدف
13
برنامه نويسي زوجي
33
تيم خود سازمان ده
14
طرح ارائه
34
اجراي اتوماتيک تست ها
15
استقبال از تغييرات مورد نياز
35
شرح و بسط به موقع نيازمندي ها
16
نمودار Burn down
36
قرارداد محدوده مذاکره شده
17
بازي کارتها/ برنامه ريزي کارتها
37
انجام تست ويژگيهاي “تکميل شده” در هر تکرار
18
جلسات ايستاده روزانه / اسکرام روزانه
38
مديريت پيکربندي
19
استاندارد کد نويسي
39
نوشتن نيازمنديها به شکل داستانهاي غيررسمي
20
طراحي غير رسمي/طراحي مختصر
40
برنامه ريزي تحويل
تست واحد32
تست واحد، يک قطعه برنامه نوشته شده توسط برنامه نويس است که بخشهاي محدودي از کدهاي منبع را تست ميکند. نتيجه به دست آمده از اين بخش به صورت باينري مشخص ميشود[40]. اگر رفتار برنامه مطابق با نتيجه مورد انتظار باشد آن تست “موفق” و در غير اين صورت با “شکست” مواجه شده است. برنامه نويس ها معمولا حجم بالايي از تستهاي واحد (بسته به حجم رفتارهاي مورد انتظار از نرم افزار) توليد ميکنند و آنرا “قطعه تست”33 مي نامند. مولفين فعال در زمينه چابک براي رفع هر گونه ابهام اصطلاح “تستهاي برنامه نويس” را در مقابل “تستهاي کاربر” استفاده ميکنند تا بر نقش مسئولان انواع تستها تاکيد کنند [41]. اجراي چنين تست هايي به دليل کثرت آنها و به جهت سرعت دادن به ساخت سيستم بايستي به صورت اتوماتيک باشد[42].
بک لاگ اولويت بندي شده34
يک بک لاگ ليستي از وظايف تکنيکال و يا ويژگيهايي است که مشتري آنها را از تيم توسعه درخواست کرده و تيم بايستي آنها را توسعه دهد و در عين حال براي تکميل پروژه جهت تحويل ضروري هستند[5].
* اگر موردي در بک لاگ وجود داشته باشد که هيچ نقشي در جهت دستبابي به هدف پروژه نداشته باشد بايد حذف گردد.
* از طرف ديگر، اگر مورد يا مواردي باشند که براي پروژه لازم به نظر ميرسند بايد به بک لاگ اضافه شوند.
تشخيص ضروري و کارآمد بودن وظايف موجود در بک لاگ به ميزان سطح دانش تيم در آن زمان مشخص بستگي دارد. بديهي است که با بالا رفتن سطح دانش تيم، بک لاگ در طول مدت پروژه دائما در حال تغيير باشد[17].
بک لاگ يک نقطه اوليه براي ثبت دانش در مورد نيازمندي ها و همچنين تنها منبع توانمند براي تعريف کارهايي است که بايد انجام شود. نحوه مديريت بک لاگ مي تواند بر اساس روشهاي چابک متفاوت بوده و توسط مشتري، نماينده مشتري و يا تيم توسعه انجام گردد[18].

گذشته نگري 35
تيم توسعه جلساتي منظم و معمولا مطابق با تکرارها را در جهت بازتاب فعاليتهاي انجام شده در بازه زماني بين جلسه جاري و جلسه پيشين برگزار ميکند. در اين جلسات در مورد راه حل ها و يا بهبودهاي لازم در جهت هدف تيم تصميم گيري ميشود[5].
اين جلسات معمولا از قالب مشخصي پيروي ميکنند. قالب هاي متمايز، بر اساس حجم زماني جلسه، معمولا بين يک تا سه ساعت ميباشد. يک دليل عمده براي استفاده از يک قالب مشخص، ايجاد فرصتي براي صحبت کردن به همه اعضا تيم در يک جلسه ميباشد.
مالکيت جمعي/همگاني کد36
اعضاي تيم طبق يک قرارداد که ميتواند مکتوب و صريح، فقط به صورت لفظي و يا کاملا ضمني باشد، به يک مالکيت جمعي در مورد کد ميرسند[10].
“ماليکت همگاني کد” همانطور که از نامش بر مي آيد، قرارداد صريحي است که بر اساس هر عضو تيم نه تنها اجازه دارد، بلکه به عنوان يک وظيفه بايد در صورت نياز، چه در جهت تکميل فرايند توسعه براي حل يک خطا و چه در جهت بهبود ساختار کلي، در فايل کد تغيير ايجاد کند[10].
سرعت پايدار37
هدف تيم داشتن پايداري نامحدودي در سرعت کار است. اين مهم مستلزم امتناع از چيزي است که در صنعت نرم افزار به “شر ضروري”38 نام گرفته است مثلاً ساعات کاري طولاني، حتي شب کاري و کار در آخر هفته[43]. اين تمرين چيزي بيش از قراردادي است که بين تيم و مديران آن منعقد شده است.
اصطلاح “سرعت پايدار” توسط Kent Beck براي جايگزيني تمرين “40 ساعت کار” در تمرين هاي XP پيشنهاد شد[10].

بازتوليد (بهينه سازي کد)39
بازتوليد به معني بهبود در ساختار داخلي کد منبع يک برنامه موجود بدون تغيير در رفتار خارجي آن ميباشد. واژه بازتوليد به يک رفتار مشخص مانند استخراج متد و يا تعريف پارامتر اشاره دارد [10].
بازتوليد معاني زير را در بر نميگيرد[44]:
1- بازنويسي کد
2- رفع باگها
3- بهبود جنبه هاي قابل مشاهده از نرم افزار به عنوان رابط
بازتوليد، بدون تدابير حفاظتي از کد در مقابل توليد و ايجاد خطا در آن، کار پرمخاطره اي است. تدابير حفاظتي شامل کمک به آزمون رگرسيون شامل تست واحد خودکار يا آزمون پذيرش خودکار، و کمک به استدلال هاي رسمي ميباشد[44].
تست واحد در توسعه آزمون رانده40
توسعه آزمون محور به يک سبک برنامه نويسي اشاره دارد که در آن سه فعاليت شديدا به هم وابسته هستند: برنامه نويسي، تست (در قالب نوشتن تست واحد) و طراحي (در قالب بازتوليد)[41].
مي توان آن را مختصراً توسط مجموعه اي از قوانين زير توضيح داد:
* نوشتن يک تست واحد که توصيف يک ويژگي از برنامه باشد.
* اجراي تست، که بايستي شکست بخورد چرا که برنامه فاقد آن ويژگي است.
* نوشتن کد مختصر و ساده براي موفقيت تست.
* بازسازي کد تا زمان تطابق با معيارهاي سادگي
* تکرار و جمع آوري تست هاي واحد در طول زمان.

تست ويژگي هاي کامل انجام شده در طول تکرار41
BDD يا “توسعه رفتار رانده”42 يک ترکيب و پالايش از شيوه هاي TDD يا “توسعه آزمون رانده”43 و ATDD يا “توسعه آزمون پذيرش رانده”44 ميباشد[41].
BDDبا استفاده از نکات زير TDD و ATDD را تکميل ميکند:
1- اعمال تکنيک “پنج چرا”45 براي هر داستان پيشنهادي کاربر به طوري که اين پيشنهاد به صورت واضح به نتايج کسب و کار مرتبط باشد.
2- تفکر از خارج، به عبارت ديگر اجراي فقط آن دسته از رفتارهايي که نتايجي کاملاً مرتبط به کسب و کار را منجر ميشود. اين امر موجب به حداقل رساني ضايعات46 توليدي خواهد بود.
3- توصيف رفتارها در يک نماد که به طور مستقيم در دسترس کارشناسان حوزه، تست کنندگان و توسعه دهندگان در جهت بهبود ارتباطات.
اعمال اين نکات در تمامي مراحل تا پايين ترين سطح انتزاع نرم افزار و توجه خاص به توزيع رفتار، که منجر به تکامل کم هزينه تر ميشود[45].
تيمهاي کوچک47
يک تيم در حوزه چابک يک گروه کوچک از افراد ميباشد که به يک پروژه يکسان و تقريبا به صورت تمام وقت اختصاص داده شده اند. اقليت کوچکي از اعضاي تيم ممکن است همکاران پاره وقت و يا مسئوليتهاي رقابتي داشته باشند. مفهوم تيم مستلزم پاسخگويي مشترک است: خوب يا بد، نتايج را به جاي هر فرد بايد به کل تيم نسبت داد. از تيم انتظار مي رود که داراي همه صلاحيت هاي لازم، اعم از فني (برنامه نويسي، طراحي، تست) و يا کسب و کار (دامنه دانش، توانايي تصميم گيري) [14].
نقش ها و مسئوليت به اندازه نتايج مهم نيست: توسعه دهنده ممکن است تست، تجزيه و تحليل و يا تفکر در مورد نيازها را انجام دهد. يک تحليلگر و يا متخصص دامنه مي تواند ايده هاي در مورد اجرا و … پيشنهاد بدهد. يک تيم بايد حداقل شامل سه نفر باشد و به طور کلي ( و نه الزام آور) نبايد از ده تجاوز کند[14]. نکته در اينجاست که تمرکز و توجه سازمان بايستي به حداقل سازي تعداد افراد تيم باشد .يک فرد تنها ممکن است در بيش از يک پروژه به طور همزمان فعاليت کند، اما دور از انتظار است که آنها خودشان را در يک زمان متعلق به بيش از يک تيم در نظر بگيرند.
طراحي آني48
وقتي تيم به طراحي ساده رو مي آورد، توسعه دهندگان معمولاً تصميمات طراحي جزيي را به صورت لحظه به لحظه به کار ميبرند که اين تصميم گيري ها ممکن است عواقب گسترده داشته باشد، با انجام تمرين طراحي ساده، دو نفر يا بيشتر از توسعه دهندگان يک جلسه براي طراحي سريع برگزار ميکنند[46] . معمولا با استفاده از وسايل کمکي طراحي مانند کارت هاي CRC.
برخي از دستورالعمل هاي مهم براي جلسه طراحي موثر عبارتند از:
1- توجه به گزينه هاي طراحي قابل استفاده به طوري که انتخاب نهايي بر اساس ملاحظاتي چون سادگي و يکپارچگي مفهومي در بين گزينه ها ميباشد.
2-ارزيابي هر گزينه بر پايه يک سناريوي مشخص و منسجم ميباشد. توجه به اينکه چگونه طرح هاي ممکن طراحي، ميتوانند کمک کنند که تست هاي پذيرش نيازمندي هاي کاربران يا داستانهاي کاربر را آشکارتر نمايد. اين تمرين با نام “طراحي لحظه اي”49 نيز شناخته ميشود[41].
کنترل نسخه50
کنترل نسخه51 نه تنها در مورد تمرين هاي چابکي مورد بحث است بلکه در حال حاضر در صنعت نيز به صورت گسترده مورد استفاده است. با اين وجود ذکر دلايل زير در مورد آن لازم به نظر ميرسد[47]:
1- هرچند اندک، اما هنوز هم تيمهايي هستند که از نسخه هاي منسوخ ابزارهاي کنترل نسخه استفاده ميکنند و حتي تيمهايي که کلا از ابزارهاي کنترل نسخه استفاده نميکنند.
2- کنترل نسخه فقط يک “تمرين خوب”52 نيست، بلکه يک توانمند ساز براي ساير تمرينهاي چابک مانند يکپارچگي مداوم53 نيز ميباشد.
3- جامعه چابکي، همانند جامعه منبع باز54، به انواع خاصي از ابزارها و تمرينها تمايل دارند: سيستم هايي با توانايي کار همزمان (مدل “ادغام”55 به جاي “قفل”56)، و اخيرا علاقه مند به سيسمتهايي با مدلهاي توزيع شده (بيش از مدل هاي متمرکز)[48].
4- از اين رو براي تيم چابک، انعکاس صريح سياست ها و زيرساخت هاي کنترل نسخه مفيد است. همچنين اطمينان از هماهنگي تيم چابک و تمرين هاي مهندسي سودمند است.
تيم هاي يکجا57
يک تيم (يک تيم ايده آل شامل مالک محصول و يا متخصص دامنه) يک فضاي اختصاص داده شده براي مدت زمان پروژه، جدا از فعاليت هاي گروه هاي ديگر، دارد. اين فضا با امکانات متفاوتي مجهز شده است: ايستگاه هاي کاري (مناسب براي زوج کاري اگر تيم از تمرينهاي مربوطه استفاده ميکنند)، وايت بردها، فضاي ديوار براي نمايش تابلوهاي وظيفه، طرحهاي پروژه و يا ساير نمودارها[5].
جدايي محل استقرار افراد تيم معيار مهمي است. محيط کاملا باز نمونه مناسبي براي اين تمرين نيست. بعضي محققان پيشنهاد ميکنند که سرو صدا (عمدتا مکالمات) مربوط به فعاليتهاي نامربوط اثر مخربي بر تمرکز مورد نياز براي کار پروژه دارد، اما شنيدن ناخودآگاه مکالمات مربوط به پروژه نه تنها قابل تحمل است بلکه کار گروهي را افزايش ميدهد. به هر حال اينکه تا چه حدي امکان يکجا بودن افراد تيم و در اختيار داشتن فضايي مناسب براي کار براي آنها فراهم باشد، نشان دهنده ميزان بهره گيري تيم از اين تمرين است[10].

سرعت تيم58
در پايان هر تکرار، تيم ميزان تلاشهايي را که در ارتباط با داستان هاي کاربر کامل شده را محاسبه مي نمايد. اين کار سرعت تيم (در انجام داستانهاي کاربر) ناميده مي شود[5]. با دانستن سرعت، تيم ميتواند مدت زمان مورد نياز براي تکميل پروژه را تخمين بزند. اين تخمين بر اساس داستانهاي کاربر

دیدگاهتان را بنویسید