رفع باگها
بهبود جنبه های قابل مشاهده از نرم افزار به عنوان رابط
بازتولید، بدون تدابیر حفاظتی از کد در مقابل تولید و ایجاد خطا در آن، کار پرمخاطره ای است. تدابیر حفاظتی شامل کمک به آزمون رگرسیون شامل تست واحد خودکار یا آزمون پذیرش خودکار، و کمک به استدلال های رسمی میباشد[۴۴].
تست واحد در توسعه آزمون رانده[۴۰]
توسعه آزمون محور به یک سبک برنامه نویسی اشاره دارد که در آن سه فعالیت شدیدا به هم وابسته هستند: برنامه نویسی، تست (در قالب نوشتن تست واحد) و طراحی (در قالب بازتولید)[۴۱].
می توان آن را مختصراً توسط مجموعه ای از قوانین زیر توضیح داد:
نوشتن یک تست واحد که توصیف یک ویژگی از برنامه باشد.
اجرای تست، که بایستی شکست بخورد چرا که برنامه فاقد آن ویژگی است.
نوشتن کد مختصر و ساده برای موفقیت تست.
( اینجا فقط تکه ای از متن فایل پایان نامه درج شده است. برای خرید متن کامل پایان نامه با فرمت ورد می توانید به سایت feko.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. )
بازسازی کد تا زمان تطابق با معیارهای سادگی
تکرار و جمع آوری تست های واحد در طول زمان.
تست ویژگی های کامل انجام شده در طول تکرار[۴۱]
BDD یا “توسعه رفتار رانده”[۴۲] یک ترکیب و پالایش از شیوه های TDD یا “توسعه آزمون رانده”[۴۳] و ATDD یا “توسعه آزمون پذیرش رانده”[۴۴] میباشد[۴۱].
BDDبا استفاده از نکات زیر TDD و ATDD را تکمیل میکند:
اعمال تکنیک “پنج چرا”[۴۵] برای هر داستان پیشنهادی کاربر به طوری که این پیشنهاد به صورت واضح به نتایج کسب و کار مرتبط باشد.
تفکر از خارج، به عبارت دیگر اجرای فقط آن دسته از رفتارهایی که نتایجی کاملاً مرتبط به کسب و کار را منجر میشود. این امر موجب به حداقل رسانی ضایعات[۴۶] تولیدی خواهد بود.
توصیف رفتارها در یک نماد که به طور مستقیم در دسترس کارشناسان حوزه، تست کنندگان و توسعه دهندگان در جهت بهبود ارتباطات.
اعمال این نکات در تمامی مراحل تا پایین ترین سطح انتزاع نرم افزار و توجه خاص به توزیع رفتار، که منجر به تکامل کم هزینه تر میشود[۴۵].
تیمهای کوچک[۴۷]
یک تیم در حوزه چابک یک گروه کوچک از افراد میباشد که به یک پروژه یکسان و تقریبا به صورت تمام وقت اختصاص داده شده اند. اقلیت کوچکی از اعضای تیم ممکن است همکاران پاره وقت و یا مسئولیتهای رقابتی داشته باشند. مفهوم تیم مستلزم پاسخگویی مشترک است: خوب یا بد، نتایج را به جای هر فرد باید به کل تیم نسبت داد. از تیم انتظار می رود که دارای همه صلاحیت های لازم، اعم از فنی (برنامه نویسی، طراحی، تست) و یا کسب و کار (دامنه دانش، توانایی تصمیم گیری) [۱۴].
نقش ها و مسئولیت به اندازه نتایج مهم نیست: توسعه دهنده ممکن است تست، تجزیه و تحلیل و یا تفکر در مورد نیازها را انجام دهد. یک تحلیلگر و یا متخصص دامنه می تواند ایده های در مورد اجرا و … پیشنهاد بدهد. یک تیم باید حداقل شامل سه نفر باشد و به طور کلی ( و نه الزام آور) نباید از ده تجاوز کند[۱۴]. نکته در اینجاست که تمرکز و توجه سازمان بایستی به حداقل سازی تعداد افراد تیم باشد .یک فرد تنها ممکن است در بیش از یک پروژه به طور همزمان فعالیت کند، اما دور از انتظار است که آنها خودشان را در یک زمان متعلق به بیش از یک تیم در نظر بگیرند.
طراحی آنی[۴۸]
وقتی تیم به طراحی ساده رو می آورد، توسعه دهندگان معمولاً تصمیمات طراحی جزیی را به صورت لحظه به لحظه به کار میبرند که این تصمیم گیری ها ممکن است عواقب گسترده داشته باشد، با انجام تمرین طراحی ساده، دو نفر یا بیشتر از توسعه دهندگان یک جلسه برای طراحی سریع برگزار میکنند[۴۶] . معمولا با بهره گرفتن از وسایل کمکی طراحی مانند کارت های CRC.
برخی از دستورالعمل های مهم برای جلسه طراحی موثر عبارتند از:
۱- توجه به گزینه های طراحی قابل استفاده به طوری که انتخاب نهایی بر اساس ملاحظاتی چون سادگی و یکپارچگی مفهومی در بین گزینه ها میباشد.
۲-ارزیابی هر گزینه بر پایه یک سناریوی مشخص و منسجم میباشد. توجه به اینکه چگونه طرح های ممکن طراحی، میتوانند کمک کنند که تست های پذیرش نیازمندی های کاربران یا داستانهای کاربر را آشکارتر نماید. این تمرین با نام “طراحی لحظه ای”[۴۹] نیز شناخته میشود[۴۱].
کنترل نسخه[۵۰]
کنترل نسخه[۵۱] نه تنها در مورد تمرین های چابکی مورد بحث است بلکه در حال حاضر در صنعت نیز به صورت گسترده مورد استفاده است. با این وجود ذکر دلایل زیر در مورد آن لازم به نظر میرسد[۴۷]:
هرچند اندک، اما هنوز هم تیمهایی هستند که از نسخه های منسوخ ابزارهای کنترل نسخه استفاده میکنند و حتی تیمهایی که کلا از ابزارهای کنترل نسخه استفاده نمیکنند.
کنترل نسخه فقط یک “تمرین خوب”[۵۲] نیست، بلکه یک توانمند ساز برای سایر تمرینهای چابک مانند یکپارچگی مداوم[۵۳] نیز میباشد.
جامعه چابکی، همانند جامعه منبع باز[۵۴]، به انواع خاصی از ابزارها و تمرینها تمایل دارند: سیستم هایی با توانایی کار همزمان (مدل “ادغام”[۵۵] به جای “قفل”[۵۶])، و اخیرا علاقه مند به سیسمتهایی با مدلهای توزیع شده (بیش از مدل های متمرکز)[۴۸].
از این رو برای تیم چابک، انعکاس صریح سیاست ها و زیرساخت های کنترل نسخه مفید است. همچنین اطمینان از هماهنگی تیم چابک و تمرین های مهندسی سودمند است.
تیم های یکجا[۵۷]
یک تیم (یک تیم ایده آل شامل مالک محصول و یا متخصص دامنه) یک فضای اختصاص داده شده برای مدت زمان پروژه، جدا از فعالیت های گروه های دیگر، دارد. این فضا با امکانات متفاوتی مجهز شده است: ایستگاه های کاری (مناسب برای زوج کاری اگر تیم از تمرینهای مربوطه استفاده میکنند)، وایت بردها، فضای دیوار برای نمایش تابلوهای وظیفه، طرحهای پروژه و یا سایر نمودارها[۵].
جدایی محل استقرار افراد تیم معیار مهمی است. محیط کاملا باز نمونه مناسبی برای این تمرین نیست. بعضی محققان پیشنهاد میکنند که سرو صدا (عمدتا مکالمات) مربوط به فعالیتهای نامربوط اثر مخربی بر تمرکز مورد نیاز برای کار پروژه دارد، اما شنیدن ناخودآگاه مکالمات مربوط به پروژه نه تنها قابل تحمل است بلکه کار گروهی را افزایش میدهد. به هر حال اینکه تا چه حدی امکان یکجا بودن افراد تیم و در اختیار داشتن فضایی مناسب برای کار برای آنها فراهم باشد، نشان دهنده میزان بهره گیری تیم از این تمرین است[۱۰].
سرعت تیم[۵۸]
در پایان هر تکرار، تیم میزان تلاشهایی را که در ارتباط با داستان های کاربر کامل شده را محاسبه می نماید. این کار سرعت تیم (در انجام داستانهای کاربر) نامیده می شود[۵]. با دانستن سرعت، تیم میتواند مدت زمان مورد نیاز برای تکمیل پروژه را تخمین بزند. این تخمین بر اساس داستانهای کاربر باقیمانده و با فرض اینکه سرعت تیم در تکرارهای باقیمانده تغییری نخواهد کرد (رجوع به تمرین سرعت پایدار)، محاسبه خواهد شد. این پیش بینی با وجودی که به ندرت دقیق است اما صحیح میباشد.
تیم های چابک برای دو نوع رخداد یک علامت هشدار دهنده در نظر میگیرند: شکست در تکمیل یک داستان کاربر و یا دیدن نمودار الاکلنگی[۵۹] (بالا و پایین شده) در سرعت کار [۴۹].
زمان-بسته[۶۰]
یک زمان-بسته به زمانی از پیش تعیین شده اطلاق میشود که جهت تکمیل برخی اهداف توسط یک شخص یا گروه در نظر گرفته میشود. در زمان-بسته، بیشتر از اینکه ادامه کار تا اتمام آن و ارزیابی آنچه انجام شده مهم باشد، توقف کار در پایان زمان تخصیص داده شده و ارزیابی آنچه انجام شده اهمیت دارد[۵]. جعبه زمان میتواند در مقیاسهای متفاوتی استفاده شود. روش ” Pomodoro”[61] کارهای شخصی را در حدود جعبه های زمان ۲۵ دقیقه ای سازماندهی میکند. در کاربرد های متفاوت دیگر مقیاس های زمانی مختلف از یک روز تا چند ماه استفاده شده است. چالش مهم جعبه زمان این است که کار باید در پایان زمان متوقف شود و پروسه مرور گردد: آیا دستیابی به هدف حاصل شده است و یا، در هدفهای چند قسمتی، قسمتی از هدف حاصل شده است؟ چنین تمرینی به مفید بودن زمان اختصاص داده شده کمک میکند و باعث میشود از حساب کردن روی وقت اضافه و کشیده شدن کار به بعد از موعد مقرر جلوگیری شود. به این ترتیب هم تاخیرات را کنترل میکند و هم روی مفید بودن تمرکز میشود.
برنامه نویسی زوجی[۶۲]
برنامه نویسی زوجی شامل دو برنامه نویس میباشد که یک ایستگاه کاری مشترک ( یک مانیتور، کیبورد و ماوس) دارند. فردی که کیبورد را در اختیار دارد “راننده”[۶۳] و دیگری که در روند کدنویسی نقش دارد اما تمرکزش بر روی روند کلی میباشد “هدایتگر”[۶۴] نامیده میشود. انتظار میرود که برنامه نویسان هر چند دقیقه یک بار نقشهایشان را با یکدیگر عوض کنند[۱۰]. چنین تمرینی کمک میکند که کد تولید شده دارای کیفیت بهتری بوده و در نهایت قابلیت بهبود (دوباره سازی) را نیز داشته باشد[۴۴].
کانبان[۶۵]
در مبحث چابک وقتی صحبت از روش Kanban برای بهبود مستمر (یا برخی از مفاهیم آن) استفاده میشود، معمولا موارد زیر دیده میشود[۵۰]:
در این نوع تیمها بر روی استفاده از تکرار، ارزیابی تلاش و سرعت به عنوان اندازه گیری های اولیه پروسه تاکیدی نمیشود.
آنها به “زمان عرضه”[۶۶] به جای سرعت تکیه میکنند.
در بیشتر دگرگونیهای قابل رویت، تخته کار با “تخته Kanban”[67] جایگزین میشود. برخلاف تخته کار، تخته Kanban در هر بار شروع هر تکرار پاک نمیشود. ستونهای آن نمایشگر وضعیتهای متفاوت پروسه از هر “واحد ارزش”[۶۸] که عموما (و نه لزوما) مساوی با داستانهای کاربر هستند و به علاوه هر ستون ممکن است با یک “محدودیت کار در جریان”[۶۹] در ارتباط باشد.[۵۱]
