مقاله رایگان درباره نرم افزار، بهبود مهارت

اين مدت زمان ميتواند بين 1 تا 4 هفته، بسته به نوع پروژه، طول بکشد[5]. در اکثر موارد براي يک پروژه مدت زمان مشخص و ثابتي در نظر گرفته ميشود. يک ويژگي کليدي در روشهاي چابک، وجود دنباله اي از تکرارها است.
عموماً تکرارها طبق هفته هاي تقويم، شروع از دوشنبه و اتمام در جمعه، تراز ميشوند. اين کار به نسبت قرار گرفتن در يک زمانبندي صريح آسان تر به نظر ميرسد و تيمهاي بيشتري با گروه هاي متفاوت تطبيق ميشوند. مدت زمان مشخص براي تکرارها موجب هماهنگ شدن اعضا تيم ميشود و بر اساس سرعت تيم و حجم کار باقيمانده، امکان تخمين مدت زمان مورد نياز براي اتمام پروژه فراهم ميشود. در اين ميان توجه ويژه اي به حداقل در نظر گرفتن اين تکرار هاي مي شود. کوتاه در نظر گرفتن تکرار ها موجب مي شود که توسعه دهندگان با شکست داستانهاي کاربر به ويژگيهاي کوچکتر ضمن کاهش پيچيدگي آنها، در تخمين بهتر و دقيق تر هزينه انجام آنها و همچنين اعتبار سنجي آنها نيز مفيد است. اين امر موجب مي شود که تيم توسعه زمان طولاني را صرف توسعه بخشي از سيستم که تا انتهاي آن نيز فرصت ارزيابي آن وجود ندارد نيز ننمايد و در زمان کمتري موفق به توليد ارزشي تجاري براي مشتري گردد.

ويژگيهاي قابل تحويل در پايان هر تکرار86
يکي از مواردي که در ديدگاه چابک مورد توجه است، تمرکز بر قابل تحويل بودن بخشي از محصول نهايي بودن به کاربر (مشتري) در پايان هر تکرار مي باشد. اين بخش از محصول شامل ويژگيها يا کارکردهايي از محصول است که در تکرار پشت سر گذاشته شده توسعه داده شده، تکميل شده و همه تست هاي مورد نياز بر روي آن انجام گرفته است. چنين بخشي از محصول در واقع بخشي از ارزشي است که صاحب محصول در پي آن بوده است. هر چه ويژگيهاي بيشتري قابل تحويل باشد، ارزش تجاري قابل ارائه به مشتري بيشتري خواهد شد. نکته قابل توجه، اين است که شايد به هر دليلي مشتري يا صاحب محصول بخش آماده شده را تحويل نگيرد و يا تحويل را به تکميل شدن آن در تکرار هاي آتي منوط کند، اما از ديدگاه چابک، صرف قابليت تحويل داشتن ويژگيهايي از محصول در پايان تکرار (و نه لزوما تحويل آنها) کفايت ميکند. چرا که اين توانمندي در تامين منافعي چون، امکان دريافت بازخورد، لزوم يکپارچه سازي هاي مکرر ويژگيهاي توليدي، افزايش دقت برآورد اتمام کار (تحويل نهايي)، تسهيل تحويل نهايي سيستم، افزايش سرعت بازگشت سرمايه و مواردي از اين قبيل را به همراه خواهد داشت.
قابل ديدن بودن و ارزشمند بودن ويژگي ها براي مشتري در يک تکرار87
اين تمرين که مکمل تمرين قبل مي باشد، توجه خاصي به ارزشمند بودن ويژگيهاي در حال توسعه در هر تکرار دارد. تيم توسعه در هر تکرار تعدادي از داستانهاي کاربر را بر اساس اولويت مشخص شده توسط صاحب محصول يا مشتري انتخاب و بر روي آنها فعاليت مي نمايد. از آنجا که غالبا نيازمندي مشتري يا داستانهاي کاربر بياني سطح بالاتر از مباحث فني دارند، لازم است که عليرغم شکست احتمالي اين موارد به ويژگيهاي کوچک تر، همچنان قابل ديده شدن براي مشتري را داشته باشند و ضمنا ارزش تجاري مناسبي را براي مشتري تامين نمايند. توجه به اين تمرين، در توفيق تيم توسعه در انجام تمرين پيشين نيز موثر خواهد بود.
مشارکت روزانه مشتري/مدير يا صاحب محصول88
مشتري يا صاحب محصول و يا مدير محصول که جنبه هاي تجاري محصول نرم افزاري در حال توليد را بر عهده دارند، در تيم هاي چابک جايگاه ويژه اي دارند. در بسياري از اين روشها، چنين نقشي به عنوان يک نقش کليدي در تيم توسعه (ويا درکنار تيم) ايفا ميکند که وظايف مهمي بر عهده آن است. وظايفي چون کمک به فهم جنبه هاي تجاري محصول، عملکرد محصول، تعريف دقيق نيازمندي ها، تعريف تست هاي مختلف و انجام اين تست ها و …. بخشي از وظايف مشتري يا صاحب محصول است[5]. در تيم هاي چابک، حضور چنين فردي به صورت روزانه و در کنار افراد تيم بسيار حائز اهميت است، چنانچه اين امر در مواردي الزامي است. انجام وظايف محوله فوق الذکر و نقش تعيين کننده چنين فردي در انجام موفقيت آميز پروژه، نيازمندي حضور دائم اين فرد در محل استقرار تيم توسعه و مشارکت او با تيم توسعه است. چنين امکاني مستقيما در توفيق پروژه و توسعه محصولي با کيفيت موثر است.
ساخت 10 دقيقه اي89
در اين تمرين تلاش تيم بر پياده سازي مکانيزمي براي تسريع در ساخت يک نسخه اجرايي سيستم در زماني اندک است. در يک محيط واقعي تيم توسعه به محض اتمام ساخت يک ويژگي يا عملکرد سيستم و انجام تست هاي لازم بر روي آن، نيازمند يکپارچه سازي تمام سيستم، آماده سازي سرورها، اجراي کامپايلرها، تست سيستم با داده هاي مناسب و آماده سازي آخرين نسخه براي بررسي عملکرد آن مي باشند. اين حالت در طي روز ممکن است چندين بار رخ دهد و تيم نيازمند ساخت سيستم به فرم گفته شده داشته باشد. روشن است که چنانچه اين فرايند زمان زيادي را نياز داشته باشد، عملا زمان زيادي از تيم توسعه به هدر خواهد رفت. لذا تاکيد روشهاي چابک بر استقرار محيط ساخت سريع سيستم مي باشد.
* تعريف “انجام شده”90
تيم در مورد يک ليست از معيارهايي که بايد قبل از افزايش محصول به عنوان “انجام شده”91 در نظر گرفته شود توافق و آنرا در جايي در اتاق تيم به معرض نمايش ميگذارد. چنانچه کار انجام شده در پايان تکرار مطابق با معيارهاي تعريف شده نباشد، آن کار نميتواند جزء سرعت آن تکرار حساب شود. توسعه دهندگان نرم افزار معمولا به پاسخ سوال “آيا اين ويژگي انجام شده است؟” توجهي نمي کنند. در واقع، ريشه اين سوال مبهم است چون ميتواند فقط به معني “انجام برنامه نويسي” باشد اما در حقيقت منظور از اين سوال اين است که “آيا برنامه نويسي انجام شده است، داده هاي تستي ساخته شده، تست واقعي انجام شده، قابليت پياده سازي دارد، قابل مستنند سازي است و…
به عنوان مثال براي جواب به اين سوال، ميتوان سوال را اينگونه مطرح کرد: “من ميدانم که تو کار را انجام داده اي اما آيا “کاملا انجام”92 شده است؟ (“کاملا آماده”93 است)
تاکيد مستندسازي بر مستند نمودن تصميمات به جاي برنامه ريزي94
مستند سازي در حوزه توسعه نرم افزار دامنه وسيعي را پوشش ميدهد. در ديدگاه چابک، تاکيد بر کم حجم بودن مستند سازي است. با توجه به اين تغيير سياست در حوزه مستندسازي لازم است که دقت مناسبي در اين بخش صورت گيرد. لازم به ذکر است، شکي در تهيه مستندات مورد نياز وجود ندارد و تاکيد بر کم حجم بودن مستندات دليلي بر نفي وجود مستندسازي نخواهد بود. هر چند توصيه هايي در اين زمينه شده است، اما مهمترين مورد به جايي بر ميگردد که نيازمند مستند سازي است[7, 53]. به دليل نبود يک برنامه ريزي جامع پيش از شروع پروژه هاي چابک و همچنين به دليل درصد تغييرات بالايي که براي کار در جريان متصور مي شود (به دليل آزادي مشتري در تغيير نيازمندي ها)، معمولا مهمترين بخشي که بايد در مستند سازي مورد توجه باشد، تصميماتي است که تيم توسعه در شرايط مختلف و در مواجهه با مشکلات اتخاذ مي کند. در واقع به دليل ماهيت متفاوت برنامه ريزي مستندسازي آن چندان مفيد نبوده و به نوعي کار نامفيد محسوب مي شود که در ديدگاه چابک، نبايستي دنبال شود.
تکرارهاي تثبيت کننده95
تيم هاي توسعه در هر تکرار ويژگي هايي را براي عرضه آماده مينمايند. معمولا در پروژه هاي واقعي پس از هر چند تکرار (4 الي 6 تکرار توسعه نرم افزار) چند تکرار را براي ثبيت بخشيدن به افزايش هايي از محصول که توليد شده و به نوعي دستاورد تکرارهاي توسعه بوده اند، اختصاص ميدهند. در اين تکرار ها عملا کد جديدي توليد نميشود و تنها به دغدغه ها و موارد مبهم پيشين پرداخته مي شود[17]. در اين حالت کد منجمد شده96 و تنها به منظور رفع عيب و نقص بر روي آن تغييرات احتمالي صورت ميگيرد. وجود چنين تکرارهايي به متخصصين کيفيت و توسعه دهندگان امکان بررسي بهتر کد و رفع مشکلات احتمالي آنها را مي دهد. نکته قابل تامل در اينجا اين است که تنهايي کد هايي که آماده تحويل هستند در اين تکرار ها بررسي مي شوند. شايد در مقام مقايسه با ديدگاه سنتي در توسعه نرم افزار اين امر را به نوعي تست بتاي محصول توليد شده بتوان در نظر گرفت.
ارتباطات همگام97
يک تيم توسعه نياز به ارتباط موثر هم بين اعضاي تيم و هم بين سهامداران نياز دارد. در برقراري ارتباطي قدرتمند، ارتباط شخصي بر ارتباط توزيع شده، ارتباط همگام بر ارتباط ناهمگام، ارتباطات با پهناي باند بالا بر ارتباطات با پهناي باند کم و ارتباطات چند حالته98 بر ارتباطات تک حالته99 برتري دارد[17]. موثر ترين روش ارتباط قدرتمند، قرار دادن همه اعضا تيم در يک اتاق است تا آنها بتوانند هر روز و در بيشتر زمان کاري با يکديگر کار کنند. ارتباط رو در رو100 موثر ترين نوع ارتباط همگام است. هر چه مکانيزم ارتباطي تيم به سمت انساني شدن و رو در رو شدن پيش رود، تيم توانمندي بهتري در مسائل انساني پروژه خواهد داشت.
همه: تيم چند وظيفه اي با يک هدف101
معني عمومي تيم چند وظيفه اي تيمي است که متخصصين فيلدهاي مختلف را به منظور دستيابي به هدف تيمي گردهم آورده است. در تيم هاي چابک نيز نه تنها بر گردهم آمدن تخصص هاي مختلف در يک تيم تاکيد شده، بلکه به ترکيب شدن افراد در قالب تيم نيز تاکيد ميشود[17]. در واقع در ديدگاه چابک، “همه”102 جايگزين فرد شده است. تيم متشکلي از همه افرادي با تخصص هاي متفاوت براي ساخت محصول است که هر عضو داوطلب انجام وظيفه اي بيش از آنچه بر عهده خود اوست نيز مي باشد. اما سوال اينجاست که آيا براي اين امر محدوده هم بايد قائل شد؟ آيا طبيعي است که از يک کدنويس درخواست شود که نقش تست کننده را نيز بر عهده گيرد؟ پاسخ به چنين سوالي مي تواند بر اساس ترکيب تيم و نفرات متفاوت باشد. در تيم هاي اسکرام هيچ فردي اختصاص به يک بخش کار توسعه ندارد، پس طبيعي است که بتواند نقش هاي متفاوتي اجرا کند. اين امر در اکثر روشهاي ديگر چابک نيز به همين شکل است[5].
تيم خود سازمان ده103
تيم خود سازمان ده در محيط هاي چابک، به تيمي متشکل از افراد با انگيزه که با يکديگر براي رسيدن به هدفي مشترک همکاري مي نمايند و در اين راه، اختيار و توانمندي مناسبي براي اخذ تصميمات مورد نياز را داشته و به شکلي مناسب مي توانند با تغييرات احتمالي خود را تطبيق دهند. برخي از نکات حائز اهميت در مورد چنين تيم هايي عبارتند از [54]:
* تيم خود سازمان ده، براي انجام کار خود معطل کسي نمي ماند تا کاري را به آنها واگذار نمايد و خود راسا اين کار را انجام ميدهند. بدين ترتيب حس مالکيت و تعهد بيشتري در تيم ايجاد مي شود.
* آنها همه کارهاي مربوط به خود را مانند يک تيم خود مديريت مي کنند. (تخصيص کار، تخمين، تخمين مجدد، واگذاري مجدد کار، تحويل و ….)
* اگر چه اين تيم ها کماکان نيازمند هدايت و آموزش هستند، اما نيازي به “کنترل و فرمان”104 ندارند.
* اعضا تيم مرتبا با يکديگر در ارتباط بوده و توافقات صورت گرفته بيشتر از آنکه بين آنها و افراد خارج از تيم مانند مديران پروژه و … باشد، بين خود اعضا تيم با يکديگر است.
* آنها تلاش مي کنند که نيازمندي مشتري را درک کنند و هراسي از سوال کردن در خصوص موارد مبهم ندارند.
* آنها به طور پيوسته در حال بهبود مهارت خود و ارتقا توان فني خود بوده و از ايده هاي خلاقانه استقبال مي نمايند.
اجراي اتوماتيک تستها در هر ساخت105
چنانچه پيشتر ذکر گرديد لازم است که تيم بتواند در زماني اندک ساخت جديدي از سيستم را تهيه نمايد (اتوماتيک). نکته مهم ديگر اين است که در هر ساخت بايستي تست ها و موارد آزمون نيز به صورت اتوماتيک اجرا شوند[45]. در واقع هر ساخت از سيستم منحصر به يکپارچگي و

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