فایل های دانشگاهی

ارائه مدلی برای اندازه گیری میزان چابکی در شرکت های نرم افزاری بر اساس اصول چابک- قسمت ۱۰

استاندارد کدنویسی مجموعه ای از قواعد پذیرفته شده است که همه تیم توسعه در طول پروژه از آنها تبعیت می کنند. این استاندارد یک ساختار و قالب سازگار برای تولید کد منبع بر اساس زبان برنامه نویسی منتخب تیم ارائه میکند. این استاندارد همچنین ساختار ها و الگوهایی را که بایستی در طی توسعه از آنها پرهیز نمود را نیز به منظور کاهش بروز نقص معرفی مینماید]۴۲[. استانداردهای برنامه نویسی ممکن است همان مواردی باشند که توسط تهیه کنندگان زبانهای برنامه سازی پیشنهاد شده اند (مانند توصیه نامه جاوا که تهیه شرکت سان تهیه شده است) باشد یا اینکه توسط تیم توسعه راسا تهیه شده باشد.
طراحی غیر رسمی[۷۸]/ طراحی ساده پیش از شروع
تیم توسعه، “طراحی مختصر قبل از شروع” را با توجه به استراتژی طراحی نرم افزار خود و بر اساس اصول زیر دنبال میکند[۴۰]:

 

برای دانلود متن کامل پایان نامه به سایت 40y.ir مراجعه نمایید.

 

 

    • طراحی یک فعالیت در حال جریان است که شامل دوباره سازی وکشف راهکارهای جدید می باشد.

 

    • کیفیت طراحی بر اساس قوانین سادگی کد ارزیابی میشود.

 

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

 

  • تصمیمات طراحی را باید تا آخرین لحظه مسئولیت به تعویق انداخت، تا با جمع آوری هر چه بیشتر اطلاعات در مورد مزایای گزینه انتخاب شده، هزینه تحمیلی را تا جای ممکن کاهش دهد[۵۰].

 

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

 

 

  • تعریف “انجام شده”[۹۰]

 

تیم در مورد یک لیست از معیارهایی که باید قبل از افزایش محصول به عنوان “انجام شده”[۹۱] در نظر گرفته شود توافق و آنرا در جایی در اتاق تیم به معرض نمایش میگذارد. چنانچه کار انجام شده در پایان تکرار مطابق با معیارهای تعریف شده نباشد، آن کار نمیتواند جزء سرعت آن تکرار حساب شود. توسعه دهندگان نرم افزار معمولا به پاسخ سوال “آیا این ویژگی انجام شده است؟” توجهی نمی کنند. در واقع، ریشه این سوال مبهم است چون میتواند فقط به معنی “انجام برنامه نویسی” باشد اما در حقیقت منظور از این سوال این است که “آیا برنامه نویسی انجام شده است، داده های تستی ساخته شده، تست واقعی انجام شده، قابلیت پیاده سازی دارد، قابل مستنند سازی است و…
به عنوان مثال برای جواب به این سوال، میتوان سوال را اینگونه مطرح کرد: “من میدانم که تو کار را انجام داده ای اما آیا “کاملا انجام”[۹۲] شده است؟ (“کاملا آماده”[۹۳] است)
تاکید مستندسازی بر مستند نمودن تصمیمات به جای برنامه ریزی[۹۴]
مستند سازی در حوزه توسعه نرم افزار دامنه وسیعی را پوشش میدهد. در دیدگاه چابک، تاکید بر کم حجم بودن مستند سازی است. با توجه به این تغییر سیاست در حوزه مستندسازی لازم است که دقت مناسبی در این بخش صورت گیرد. لازم به ذکر است، شکی در تهیه مستندات مورد نیاز وجود ندارد و تاکید بر کم حجم بودن مستندات دلیلی بر نفی وجود مستندسازی نخواهد بود. هر چند توصیه هایی در این زمینه شده است، اما مهمترین مورد به جایی بر میگردد که نیازمند مستند سازی است[۷, ۵۳]. به دلیل نبود یک برنامه ریزی جامع پیش از شروع پروژه های چابک و همچنین به دلیل درصد تغییرات بالایی که برای کار در جریان متصور می شود (به دلیل آزادی مشتری در تغییر نیازمندی ها)، معمولا مهمترین بخشی که باید در مستند سازی مورد توجه باشد، تصمیماتی است که تیم توسعه در شرایط مختلف و در مواجهه با مشکلات اتخاذ می کند. در واقع به دلیل ماهیت متفاوت برنامه ریزی مستندسازی آن چندان مفید نبوده و به نوعی کار نامفید محسوب می شود که در دیدگاه چابک، نبایستی دنبال شود.
تکرارهای تثبیت کننده[۹۵]
تیم های توسعه در هر تکرار ویژگی هایی را برای عرضه آماده مینمایند. معمولا در پروژه های واقعی پس از هر چند تکرار (۴ الی ۶ تکرار توسعه نرم افزار) چند تکرار را برای ثبیت بخشیدن به افزایش هایی از محصول که تولید شده و به نوعی دستاورد تکرارهای توسعه بوده اند، اختصاص میدهند. در این تکرار ها عملا کد جدیدی تولید نمیشود و تنها به دغدغه ها و موارد مبهم پیشین پرداخته می شود[۱۷]. در این حالت کد منجمد شده[۹۶] و تنها به منظور رفع عیب و نقص بر روی آن تغییرات احتمالی صورت میگیرد. وجود چنین تکرارهایی به متخصصین کیفیت و توسعه دهندگان امکان بررسی بهتر کد و رفع مشکلات احتمالی آنها را می دهد. نکته قابل تامل در اینجا این است که تنهایی کد هایی که آماده تحویل هستند در این تکرار ها بررسی می شوند. شاید در مقام مقایسه با دیدگاه سنتی در توسعه نرم افزار این امر را به نوعی تست بتای محصول تولید شده بتوان در نظر گرفت.
ارتباطات همگام[۹۷]
یک تیم توسعه نیاز به ارتباط موثر هم بین اعضای تیم و هم بین سهامداران نیاز دارد. در برقراری ارتباطی قدرتمند، ارتباط شخصی بر ارتباط توزیع شده، ارتباط همگام بر ارتباط ناهمگام، ارتباطات با پهنای باند بالا بر ارتباطات با پهنای باند کم و ارتباطات چند حالته[۹۸] بر ارتباطات تک حالته[۹۹] برتری دارد[۱۷]. موثر ترین روش ارتباط قدرتمند، قرار دادن همه اعضا تیم در یک اتاق است تا آنها بتوانند هر روز و در بیشتر زمان کاری با یکدیگر کار کنند. ارتباط رو در رو[۱۰۰] موثر ترین نوع ارتباط همگام است. هر چه مکانیزم ارتباطی تیم به سمت انسانی شدن و رو در رو شدن پیش رود، تیم توانمندی بهتری در مسائل انسانی پروژه خواهد داشت.
تصویر درباره بازار سهام (بورس اوراق بهادار)
همه: تیم چند وظیفه ای با یک هدف[۱۰۱]
معنی عمومی تیم چند وظیفه ای تیمی است که متخصصین فیلدهای مختلف را به منظور دستیابی به هدف تیمی گردهم آورده است. در تیم های چابک نیز نه تنها بر گردهم آمدن تخصص های مختلف در یک تیم تاکید شده، بلکه به ترکیب شدن افراد در قالب تیم نیز تاکید میشود[۱۷]. در واقع در دیدگاه چابک، “همه”[۱۰۲] جایگزین فرد شده است. تیم متشکلی از همه افرادی با تخصص های متفاوت برای ساخت محصول است که هر عضو داوطلب انجام وظیفه ای بیش از آنچه بر عهده خود اوست نیز می باشد. اما سوال اینجاست که آیا برای این امر محدوده هم باید قائل شد؟ آیا طبیعی است که از یک کدنویس درخواست شود که نقش تست کننده را نیز بر عهده گیرد؟ پاسخ به چنین سوالی می تواند بر اساس ترکیب تیم و نفرات متفاوت باشد. در تیم های اسکرام هیچ فردی اختصاص به یک بخش کار توسعه ندارد، پس طبیعی است که بتواند نقش های متفاوتی اجرا کند. این امر در اکثر روش های دیگر چابک نیز به همین شکل است[۵].
تیم خود سازمان ده[۱۰۳]
تیم خود سازمان ده در محیط های چابک، به تیمی متشکل از افراد با انگیزه که با یکدیگر برای رسیدن به هدفی مشترک همکاری می نمایند و در این راه، اختیار و توانمندی مناسبی برای اخذ تصمیمات مورد نیاز را داشته و به شکلی مناسب می توانند با تغییرات احتمالی خود را تطبیق دهند. برخی از نکات حائز اهمیت در مورد چنین تیم هایی عبارتند از [۵۴]:

 

 

    • تیم خود سازمان ده، برای انجام کار خود معطل کسی نمی ماند تا کاری را به آنها واگذار نماید و خود راسا این کار را انجام میدهند. بدین ترتیب حس مالکیت و تعهد بیشتری در تیم ایجاد می شود.

 

    • آنها همه کارهای مربوط به خود را مانند یک تیم خود مدیریت می کنند. (تخصیص کار، تخمین، تخمین مجدد، واگذاری مجدد کار، تحویل و ….)

 

    • اگر چه این تیم ها کماکان نیازمند هدایت و آموزش هستند، اما نیازی به “کنترل و فرمان”[۱۰۴] ندارند.

 

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

 

    • آنها تلاش می کنند که نیازمندی مشتری را درک کنند و هراسی از سوال کردن در خصوص موارد مبهم ندارند.

 

  • آنها به طور پیوسته در حال بهبود مهارت خود و ارتقا توان فنی خود بوده و از ایده های خلاقانه استقبال می نمایند.

 

اجرای اتوماتیک تستها در هر ساخت[۱۰۵]
چنانچه پیشتر ذکر گردید لازم است که تیم بتواند در زمانی اندک ساخت جدیدی از سیستم را تهیه نماید (اتوماتیک). نکته مهم دیگر این است که در هر ساخت بایستی تست ها و موارد آزمون نیز به صورت اتوماتیک اجرا شوند[۴۵]. در واقع هر ساخت از سیستم منحصر به یکپارچگی و کامپایل نبوده و تست های مورد نیاز (فنی و پذیرش) نیز بایستی به صورت اتوماتیک قابل اجرا باشد. در واقع ساخت اتوماتیک سیستم (ساخت در ده دقیقه) توام با اجرای اتوماتیک موارد آزمون نیز بایستی باشد.
شرح و بسط به موقع نیازمندی ها[۱۰۶]
در هر تکرار در چرخه توسعه نرم افزار، صاحبان محصول، مشتری و یا افراد تحلیلگر تجاری تمرکز خود را بر تعریف نیازمندی ها و قرار دادن آنها در بک لاگ می نمایند. همزمان با اینکار لازم است که معیارهای پذیرش این آیتمها را نیز تدوین نمایند. چنین مدلی تحت عنوان گردآوری به موقع نیازمندیها شناخته می شود. در این تمرین، در ابتدای هر تکرار تنها نیازمندیهایی که قرار است در تکرار پیش رو توسعه پیدا کنند، مورد بحث و تجزیه و تحلیل قرار میگیرند. بحث و بررسی نیازمندیهایی که در تکرارهای بعدی قرار است توسعه یابند، منحصرا به همان زمان موکول می گردند[۱۰].
قرارداد محدوده مذاکره شده[۱۰۷]
قرارداد های کاری در پروژه های چابک با پروژه های متداول در شیوه های سنتی متفاوت است. اگر چه انواعی متفاوتی از قرارداد ها در این خصوص می توان تعریف کرد، اما تمرکز قرارداد بر امکان مذاکره و شفاف سازی و یا حتی تغییر در طول پروژه است. با این وضعیت نوشتن قراردادی با قیمت و مدت قطعی چندان معقول به نظر نمی رسد، هر چند میتوان چنین قراردادی را امضا کرد ولی به نحوی امکان تغییر در دامنه نیازمندی ها، زمان مورد نیاز اجرا و مبلغ قرارداد را در آن پیشبینی کرد. یک روش معمول در این خصوص نوشتن قرارداد اولیه ای با مبلغ پایین و محدوده عملیاتی متناسب با آن است که به مرور پیشرفت کار و تشخیص نیازهای واقعی می توان دامنه، مدت و مبلغ را متناسب با تغییرات مورد نیاز تغییر داد[۱۰]. به این طریق، هم تیم توسعه دهنده و هم مشتری می توانند انتظارات خود را در حوزه قراردادی با واقعیت تطبیق دهند. تدوین چنین قراردادهایی یکی از توصیه های دیدگاه چابک است که مانند مکانیزمی است که طرفین را برای دستیابی به هدف نهایی پروژه تشویق به مذاکره نموده و باعث می شود که با دیدی روشن و به دور از الزامات تعهد آور قراردادهای طولانی مبنی بر تهیه مواردی که شاید چندان هم مورد نیاز نباشند، محصول نهایی کاراتری را دنبال کنند.
انجام تست ویژگیهای “تکمیل شده” در هر تکرار[۱۰۸]
در هر تکرار تعدادی از ویژگی های مورد نیاز مشتری توسعه داده می شود. پس از پایان تکرار تعدادی و یا همه ویژگی های تحت توسعه، که به نوعی “تکمیل شده” تلقی میگردند، لازم است تست شوند[۵۵]. جدای از نحوه و چگونگی فرایند تست، انجام تست این ویژگی ها توسط توسعه دهندگان و مشتری یا صاحب محصول دارای اهمیت فراوانی است. در این خصوص توجه به مفهوم و توافق “تعریف انجام شده” که پیشتر نیز شرح داده شد، ضروری است.
مدیریت پیکربندی[۱۰۹]
توسعه نرم افزار چابک مبتنی بر تحویل زودهنگام بخش هایی از محصول نهایی است که آماده بهره برداری توسط مشتری می باشند. بهره برداری از بخش های آماده شده محصول در صورتی ریسک اندکی را در بر خواهد داشت که به نحوی در طول توسعه سیستم، نظارت و کنترل مناسبی برای تهیه آن شده باشد. چنین فعالیتی که مدیریت پیکربندی نامیده می شود، به کنترل محصول در حال توسعه، نظارت بر یکپارچه سازی بخش های مختلف آن و انجام تنظیمات خاص سیستم به منظور بهره برداری مشتری از سیستم بکار گرفته می شود[۵۲]. با توجه به اینکه محصول تولیدی در روش های چابک در چندین مرحله ممکن است تحویل مشتری گردد، این فعالیت در دیدگاه چابک جایگاه خاص تری نسبت به روش های سنتی دارد و توجه مناسب به آن منجر به تولید سیستمی با کیفیت مناسب تر خواهد گردید.
نوشتن نیازمندیها به شکل داستانهای غیر رسمی[۱۱۰]
نیازمندیهای مشتری در روش های چابک به شکل نوشتن داستانهای کاربر مستند می شوند. داستانهای کاربر چنانچه پیشتر بیان گردید، به صورت متن های ساده و کوتاه که بیان کننده ویژگیهای مورد نیاز مشتری هستند، مدون می گردند. غالبا نحوه تدوین این نیازمندیها به صورت متون غیر رسمی و غیر فنی می باشد. این ویژگی به ذی نفعان پروژه و مخصوصا مشتری امکان می دهد که فهم بهتری از کلیات سیستم داشته باشد و در مذاکرات آتی شفاف تر نیازمندی های خود را بیان کند. هر چند تیم توسعه در هنگام شروع به کار بر روی این داستانها، با اخذ جزئیات فنی و عملیاتی، آنها را به بخش های کوچک تر تقسیم می نماید. در برخی از روش های چابک، وجود این تمرین الزامی می باشد، اما در برخی دیگر به صورت مستتر مورد توجه است. با اینحال، وجود چنین تمرینی منافع متعددی بالاخص برای ایجاد فهم بهتر سیستم برای همه دست اندرکاران در پی خواهد داشت.
برنامه ریزی تحویل[۱۱۱]
هر گونه برنامه ریزی و تخمین در دنیای چابک تنها به یک کلید معیار بستگی دارد: سرعت تیم توسعه. این معیار چنانچه پیشتر ذکر شد، نشان دهنده میزان کاری است که تیم توسعه قادر به انجام آن در طی یک تکرار است. در صورت دانستن سرعت تیم توسعه (از پروژه های قبلی)، یک برنامه تحویل، نشان دهنده میزان حجم کاری است که تیم توسعه می تواند در یک محدوده زمانی به انجام برساند[۵۶].
ضرب العجل های تحویل معمولا ناشی از تعهدات قراردادی، مالی و یا ارائه محصول در یک نمایشگاه می باشند. اگر چه به دلیل اینکه اولویت اصلی رساندن محصول نهایی به دست کاربر اصلی و رفع نقص های احتمالی آن مطابق با نیاز مشتری است، تاکید بر تکرارهای کوتاه مدت است[۴۸]. هر برنامه تحویل متشکل از چندین تکرار با طول ثابت و یکسان تشکیل میشود که در انتهای همه این تکرار ها محصول نهایی در طی چند مرحله تحویل می گردد. برنامه ریزی تحویل یک روش ساده برنامه ریزی بالا-به پایین[۱۱۲] است[۵۲]. این برنامه ریزی در مقایسه با گانت چارت های متداول در پروژه های های سنتی سریعتر (و البته نه لزوما دقیقتر یا بهتر) می باشد.
۳-۴ مدل سازی
تدوین هر مدلی نیازمند شناخت مولفه های تشکیل دهنده آن می باشد. در مورد مدل اندازه گیری چابکی، چنانچه در فصل قبل ذکر گردید، مولفه های تشکیل دهنده مدل، تمرینات چابکی بودند. این تمرینات تا حد زیادی شکل استاندارد به خود گرفته و دارای مقبولیت مناسبی می باشند و چنانچه در بخش قبل ذکر گردید مشروعیت مناسبی برای بکارگیری در مدل مورد نظر ما دارند. در این فصل، با توجه به روش تحقیق مصوب، ارزش گذاری این مولفه ها انجام خواهد شد و به مدل اندازه گیری شکل خواهد گرفت.
۳-۵ جمع آوری اطلاعات
به منظور ارزش گذاری مولفه های مدل اندازه گیری، پرسشنامه ای تدوین گردید که در آن تمرینات چابکی که در فصل قبل معرفی گردید، مورد پرسش واقع گردند. در این پرسشنامه تمامی تمرینات بدون ترتیب خاصی لیست شده و از پاسخ دهندگان درخواست گردید که میزان اهمیت هر کدام از آنها را در چابکی سازمان بیان کنند. به منظور ساده سازی تحلیل داده ها، سوالات پرسشنامه در قالب سوالات با پاسخ بسته و از نوع مقیاس لیکرت[۱۱۳] ۵ تایی طراحی شدند. پاسخ دهندگان میتوانستند میزان اهمیت هر تمرین را با عددی در بازه ۱ الی ۵ مشخص نمایند. همچنین اطلاعات مختصری در مورد سابقه آنها در توسعه نرم افزار و شغل آنها نیز دریافت گردید. به دلیل عدم دسترسی به متخصصین مربوطه و دیدار حضوری با آنها و به علت اینکه هنوز این روش های توسعه در کشور رواج چندانی نیافته اند، پرسشنامه مزبور بر روی اینترنت قرار داده شد و از متخصصین مربوطه دعوت گردید که در این تحقیق مشارکت نمایند. لینک پرسشنامه مزبور در ادامه آمده است و تا لحظه تهیه این گزارش همچنان فعال نگه داشته شده است. همچنین متن پرسشنامه در پیوست شماره ۱ این گزارش، ارائه گردیده است.
http://tinyurl.com/Agile-Ass1
فرایند جمع آوری اطلاعات گرچه شاید ساده به نظر آید، اما فرایندی دشوار و زمان بر است، چرا که الزامی برای مشارکت افراد در چنین تحقیقاتی وجود ندارد. همچنین به دلیل عدم دسترسی مستقیم به مشارکت کنندگان در تحقیق امکان تشویق آنها به مشارکت، پیگیری نحوه و میزان مشارکت آنها و همچنین محدود کردن زمان جمع آوری اطلاعات وجود ندارد. از این روی این فرایند غالبا فرایندی خسته کننده بوده که محقق نقش زیادی در طول زمان آنها ندارد. با توجه به مصوبات تحقیق، عملیات جمع آوری داده تا دستیابی به حداقل تعداد مشارکت کنندگان ادامه داشت و تحلیل داده ها بلافاصله پس از دستیابی به این حداقل آغاز گردید. حداقل تعداد پاسخ ها در این تحقیق ۳۰ پاسخ لحاظ شده بود، هر چند تحلیل داده ها بر مبنای ۳۵ پاسخ دریافتی انجام گرفته است.
فصل چهارم : تجزیه و تحلیل داده ها
۴-۱ مقدمه
چنانچه در فصل قبل ذکر گردید، به منظور تدوین مدل اندازه گیری چابکی، معیارهای مدل در قالب تمرینات چابکی معرفی شدند و از طریق پرسشنامه الکترونیکی، اهمیت هر کدام از این تمرینات از پاسخ دهندگان مورد پرسش قرار گرفت. میزان اهمیت هر کدام از معیارها نشان دهنده وزن آن معیار در تعیین میزان چابکی سازمان خواهد بود. بنابر این به طور ساده، مدل اندازه گیری بر مینای وزن هر کدام از تمرینات چابک در سازمان های نرم افزار کاربرد خواهد داشت. در این بخش به تجزیه وتحلیل داده ها پرداخته و مدل اندازه گیری چابکی را بر اساس آنها خواهیم ساخت.
۴-۲ تحلیل داده ها
طی مدت فعال بودن لینک پرسشنامه و تا لحظه تدوین این گزارش ۳۵ پاسخ از مشارکت کنندگان در تحقیق دریافت گردیده است. داده های اولیه که در پیوست این گزارش نیز درج شده اند، نشان دهنده نظر متخصصین چابک در مورد ارزش هر یک از تمرینات چابک می باشند.
۴-۲-۱ جامعه آماری
حدود نیمی از پاسخ دهندگان پرسشنامه توسعه دهندگان بوده اند و همین امر به دلیل نزدیکی بیشتر آنها به تمرینات روزمره چابکی نقش مهمی در کیفیت داده های خام دارد. شکل ۱ نمایش دهنده توزیع مشاغل پاسخ دهندگان به پرسشنامه می باشد.

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

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *