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

تخمين بزند. اين تخمين بر اساس داستانهاي کاربر باقيمانده و با فرض اينکه سرعت تيم در تکرارهاي باقيمانده تغييري نخواهد کرد (رجوع به تمرين سرعت پايدار)، محاسبه خواهد شد. اين پيش بيني با وجودي که به ندرت دقيق است اما صحيح ميباشد.
تيم هاي چابک براي دو نوع رخداد يک علامت هشدار دهنده در نظر ميگيرند: شکست در تکميل يک داستان کاربر و يا ديدن نمودار الاکلنگي59 (بالا و پايين شده) در سرعت کار [49].
زمان-بسته60
يک زمان-بسته به زماني از پيش تعيين شده اطلاق ميشود که جهت تکميل برخي اهداف توسط يک شخص يا گروه در نظر گرفته ميشود. در زمان-بسته، بيشتر از اينکه ادامه کار تا اتمام آن و ارزيابي آنچه انجام شده مهم باشد، توقف کار در پايان زمان تخصيص داده شده و ارزيابي آنچه انجام شده اهميت دارد[5]. جعبه زمان ميتواند در مقياسهاي متفاوتي استفاده شود. روش ” Pomodoro”61 کارهاي شخصي را در حدود جعبه هاي زمان 25 دقيقه اي سازماندهي ميکند. در کاربرد هاي متفاوت ديگر مقياس هاي زماني مختلف از يک روز تا چند ماه استفاده شده است. چالش مهم جعبه زمان اين است که کار بايد در پايان زمان متوقف شود و پروسه مرور گردد: آيا دستيابي به هدف حاصل شده است و يا، در هدفهاي چند قسمتي، قسمتي از هدف حاصل شده است؟ چنين تمريني به مفيد بودن زمان اختصاص داده شده کمک ميکند و باعث ميشود از حساب کردن روي وقت اضافه و کشيده شدن کار به بعد از موعد مقرر جلوگيري شود. به اين ترتيب هم تاخيرات را کنترل ميکند و هم روي مفيد بودن تمرکز ميشود.

برنامه نويسي زوجي62
برنامه نويسي زوجي شامل دو برنامه نويس ميباشد که يک ايستگاه کاري مشترک ( يک مانيتور، کيبورد و ماوس) دارند. فردي که کيبورد را در اختيار دارد “راننده”63 و ديگري که در روند کدنويسي نقش دارد اما تمرکزش بر روي روند کلي ميباشد “هدايتگر”64 ناميده ميشود. انتظار ميرود که برنامه نويسان هر چند دقيقه يک بار نقشهايشان را با يکديگر عوض کنند[10]. چنين تمريني کمک ميکند که کد توليد شده داراي کيفيت بهتري بوده و در نهايت قابليت بهبود (دوباره سازي) را نيز داشته باشد[44].
کانبان65
در مبحث چابک وقتي صحبت از روش Kanban براي بهبود مستمر (يا برخي از مفاهيم آن) استفاده ميشود، معمولا موارد زير ديده ميشود[50]:
1- در اين نوع تيمها بر روي استفاده از تکرار، ارزيابي تلاش و سرعت به عنوان اندازه گيري هاي اوليه پروسه تاکيدي نميشود.
2- آنها به “زمان عرضه”66 به جاي سرعت تکيه ميکنند.
3- در بيشتر دگرگونيهاي قابل رويت، تخته کار با “تخته Kanban”67 جايگزين ميشود. برخلاف تخته کار، تخته Kanban در هر بار شروع هر تکرار پاک نميشود. ستونهاي آن نمايشگر وضعيتهاي متفاوت پروسه از هر “واحد ارزش”68 که عموما (و نه لزوما) مساوي با داستانهاي کاربر هستند و به علاوه هر ستون ممکن است با يک “محدوديت کار در جريان”69 در ارتباط باشد.[51]

طرح ارائه70
ارائه يک سطحي بالاتر از هر تکرار توسعه است. يکي از اهداف نهايي روشهاي چابک کوتاه کردن زمان ارائه است. طرح ارائه در واقع نقشه اي است که مسير توليد تا تحويل را نشان ميدهد[52]. زمان توليد و تحويل سيستم از نکات مهم اين طرح ميباشد. عوامل موثر در تهيه طرح ارائه عبارتند از: آيتم هاي بک لاگ محصول، کارهاي باقيمانده در بک لاگ، زمان و سرعت. طرح ارائه بايستي پس از تدوين اوليه بر اساس عوامل موثر فوق مورد بازنگري قرار گيرد و به روز رساني شود. جلسات بازبيني (مانند مرور اسپرينت در اسکرام) فرصتي براي به روز رساني اين طرح مي باشند[5].
استقبال از تغييرات مورد نياز71
يکي از شعارهاي پر رنگ روشهاي چابک، پذيرش تغييرات مورد نظر مشتري در همه مراحل (حتي در مراحل نهايي و نزديک تحويل) مي باشد. چنين تمريني منجر به توليد محصولي که مطابق نيازهاي مشتري است خواهد شد و در نهايت رضايت مشتري را به همراه خواهد داشت[7]. عدم توجه به تغييرات درخواستي يکي از دلايل ضعف هاي روشهاي سنتي و عاملي براي ظهور روشهاي چابک بود[31].
نمودار burn down72
تيم يک گراف بزرگ مربوط به حجم کار باقيمانده (روي محور افقي) و زمان سپري شده از آغاز پروژه (روي محور عمودي که زمان گذشته و آينده را نيز مشخص ميکند) را در جايي روي ديوار اتاق پروژه به نمايش ميگذارد]5[ . اين کار يک “رادياتور اطلاعات”73 تشکيل ميدهد که به طور منظم به روز ميشود. بسته به اينکه حجم کار باقيمانده در هر تکرار مد نظر باشد يا در کل پروژه، دو نوع گراف وجود دارد.
اين تمرين نه تنها وضعيت به روز شده پروژه را قابل مشاهده ميکند، بلکه در حقيقت اين وضعيت را در جلوي چشم همه افراد درگير در اين پروژه قرار ميدهد و اعضاي تيم را براي رويارويي با مشکلات در آينده نزديک آماده ميکند.
تاثير يک نمودار، بسته به محل مناسب براي نصب و سايز (به اندازه کافي بزرگ) آن است. اگرچه معمولا چنين نمودارهايي کمک فراواني در تحليل وضعيت موجود يا نشان دادن جزئيات پروژه نميکنند، اما ميتوانند آغاز کننده بحث فني و مديريتي در خصوص وقايع حادث شده باشند. نموداري در يک صفحه A4 و نصب شده در يک راهرو يا در زير يک رخت آويز نميتواند تاثير مناسبي داشته باشد. سادگي نمودارdown burn که ميتواند فقط بر پايه سوابق سرعت ايجاد شود فاکتور ديگري براي تاثير آن در روند پروژه است[17].
بازي کارتها (برنامه ريزي کارتها)74
يک روش بازي گرا براي ارزيابي ميباشد که توسط بسياري از تيم هاي چابک مورد استفاده قرار ميگيرد. هر يک از اعضاي تيم در حضور صاحب محصول و يا مشتري و دور يک ميز هستند و هر کدام داراي مجموعه اي از کارتهاي بازي ميباشند[5].
هر کارت حاوي يک عدد براي تخمين امتياز داستان کاربر ميباشد. صاحب محصول در مورد هدف و ارزش يک داستان توضيح مي دهد. هر يک از اعضا تيم توسعه در سکوت به داستان مربوطه يک عدد نسبت داده و کارت را برميگرداند. در واقع امتياز داده شده مبين ميزان نفر ساعت يا واحد هاي هزينه ديگر براي توسعه داستان کاربر مي باشد. وقتي همه کارتهاي خود را انتخاب و عدد مربوطه را مشخص کردند، کارتها برگردانده شده و تخمين ها به صورت بلند خوانده ميشود. دو ( و يا بيشتر) نفر از اعضاي تيم که بالاترين و کمترين عدد را در نظر گرفته اند در مورد علت آن توضيح خواهند داد. بعد از يک بحث کوتاه، تيم ممکن است با انجام دوباره و يا چندباره اين بازي به يک نظر جمعي در مورد ارزش آن داستان کاربر برسد[5, 17].
جلسات ايستاده روزانه (اسکرام روزانه)75
تيم توسعه ?ک تيم خود سازمانده76 است. جلسات ايستاده (اسکرام) در جهت اطمينان از نايل شدن به اهداف توسط تيم توسعه و به صورات روزانه برگزار ميگردد. اين جلسات هميشه در محل و زماني مشخص و به صورت روزانه برگزار ميگردند.
هر يک از اعضاي تيم توسعه سه دسته اطلاع را در اختيار ديگران قرار ميدهد[5].
1- چيزي که من از آخرين جلسه روزانه تا به حال انجام داده ام.
2- چيزي که تصميم دارم از امروز تا جلسه بعدي روزانه انجام بدهم.
3- مانعي که در مسير پيشرفت من است.
اگرچه در مورد اين سه مساله، پرسش و پاسخ مختصري انجام خواهد شد اما هيچ بحث و بررسي عميقي روي آن انجام نخواهد شد. با اين حال، بسياري از تيمها بعد از اتمام جلسه دور هم جمع شده و به بحث و بررسي پيرامون مواردي که در جلسه مطرح شده مي پردازند. گزارش اين جلسه به هيچ يک از مديران، صاحب محصول و يا مديران فني (مانند مدير اسکرام) داده نخواهد شد. اين جلسه، تنها يک جلسه بين اعضاي تيم توسعه ميباشد تا اين اطمينان حاصل شود که همه در يک سطح هستند. فقط اعضا تيم توسعه (شامل مدير اسکرام و صاحب محصول و يا نماينده مشتري) ميتوانند در طول اين جلسه صحبت کنند. ديگر علاقه مندان فقط ميتوانند در جلسه حضور داشته و شنونده باشند. بسته به نکاتي که در طول اين جلسه مطرح ميشود، اعضا تيم ميتوانند در صورت نياز کار خود را در جهت دستيابي به اهداف تکرار بعدي / اسپرينت مجددا برنامه ريزي کنند[49].
جلسات روزانه، عنصري کليدي در روشي مانند اسکرام است که موجب شفافيت، اعتماد و کارايي بهتر مي گردد. اين جلسات موجب تشخيص سريع مشکلات، تشويق تيم ها به خود سازماندهي و خود اتکايي مي شود. اين جلسه نيز مانند جلسات ديگر بايستي در يک زمان بسته انجام پذيرد. اين زمان معمولا ماکزيمم 15 دقيقه در نظر گرفته مي شود[5].
استاندارد کدنويسي77
استاندارد کدنويسي مجموعه اي از قواعد پذيرفته شده است که همه تيم توسعه در طول پروژه از آنها تبعيت مي کنند. اين استاندارد يک ساختار و قالب سازگار براي توليد کد منبع بر اساس زبان برنامه نويسي منتخب تيم ارائه ميکند. اين استاندارد همچنين ساختار ها و الگوهايي را که بايستي در طي توسعه از آنها پرهيز نمود را نيز به منظور کاهش بروز نقص معرفي مينمايد]42[. استانداردهاي برنامه نويسي ممکن است همان مواردي باشند که توسط تهيه کنندگان زبانهاي برنامه سازي پيشنهاد شده اند (مانند توصيه نامه جاوا که تهيه شرکت سان تهيه شده است) باشد يا اينکه توسط تيم توسعه راسا تهيه شده باشد.
طراحي غير رسمي78/ طراحي ساده پيش از شروع
تيم توسعه، “طراحي مختصر قبل از شروع” را با توجه به استراتژي طراحي نرم افزار خود و بر اساس اصول زير دنبال ميکند[40]:
* طراحي يک فعاليت در حال جريان است که شامل دوباره سازي وکشف راهکارهاي جديد مي باشد.
* کيفيت طراحي بر اساس قوانين سادگي کد ارزيابي ميشود.
* تمام عناصر طراحي مانند الگوهاي طراحي، معماري مبتني بر پلاگين، و غيره بايستي هم از لحاظ هزينه اي و منفعتي که خواهند داشت، نظر گرفته شوند، و در نهايت لازم است هزينه هاي طراحي توجيه پذير باشد.
* تصميمات طراحي را بايد تا آخرين لحظه مسئوليت به تعويق انداخت، تا با جمع آوري هر چه بيشتر اطلاعات در مورد مزاياي گزينه انتخاب شده، هزينه تحميلي را تا جاي ممکن کاهش دهد[50].
مرور تکرار79 /نمايش80
در پايان هر تکرار، جلسه مرور تکرار برگزار مي گردد. زمان اين جلسه متناسب با طول تکرار و تعداد نفراتي بايد باشد که در تکرار فعاليت داشته اند، اما اين زمان بيش از چهار ساعت توصيه نمي گردد. هدف اين جلسه نمايش ويژگي ها و کاربرد هاي توسعه يافته و تکميل شده در تکرار گذشته است[5]. اين جلسه در واقع فرصتي به مشتري، صاحب محصول، مديران، کاربران و ساير ذي نفعان پروژه ميدهد تا از ميزان واقعي پيشرفت پروژه آگاه گردند. اين جلسه براي همه طرفهاي درگير پروژه منافع ويژه اي دارد. در درجه اول با نمايش پيشرفت واقعي پروژه، مشتريان و يا سرمايه گذار اعتماد بيشتري به تيم پروژه پيدا ميکنند. همچنين صاحب محصول (مشتري) با ديدن آنچه در نهايت قرار است تحويل گيرد، بازخورد بهتر و دقيق تري مي تواند به تيم توسعه بدهد. مخصوصا در مواقعي که محصول ارائه شده مطابق نيازهاي درخواستي آنها نمي باشد. در واقع نبود اين جلسه، فرصت استثنايي تشريک مساعي در تهيه سيستمي ارزشمند را از همه ذي نفعان سلب خواهد کرد.

تست پذيرش توسعه آزمون رانده81
شبيه به TDD، اين تمرين نيز بر استفاده از تستهاي پذيرش خودکار اشاره دارد با اين تفاوت که اين تمرين يک محدوديت اضافه تر دارد و آن، نوشتن تست از قبل از اجراي قابليت مربوطه ميباشد.
در وضعيت ايده آل (هر چند در عمل به ندرت به دست آمده)، صاحب محصول، مشتري و يا متخصص دامنه قادر به مشخص کردن قابليتهاي جديد با نوشتن تستهاي پذيرش جديد و موارد آزمون82 بدون نياز به مشورت با توسعه دهندگان ميباشد. ATDD 83مخفف عبارت “توسعه آزمون پذيرش رانده” است که گاهاً به آن “توسعه آزمون داستان رانده”84 نيز ميگويند[45].
تکرارهاي کوتاه85
تکرار در ديدگاه چابک حاکي از بسته زماني اي است که مراحل توسعه نرم افزار طي آن صورت ميگيرد.

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