همه چیز پیرامون اسکرام

همه چیز پیرامون اسکرام

همه چیز پیرامون اسکرام

اسکرام چیست؟

اسکرام (Scurm) یک متدولوژی افزایشی (Incremental) برای مدیریت پروژه های نرم افزاری است و از رده متدولوژی های Agile محسوب می شود. این متدولوژی اولین بار در ژاپن اختراع شد و بعد ها در سال ۱۹۹۱ توسط Stahl و Degrace توسعه داده شد. درسال ۱۹۹۵ این متدولوژی توسط Ken Schwober و Jeff Stherland به عنوان یک متدولوژی رسمی برای تولید نرم افزار بکار گرفته شد. فرق بین Iterative بودن یک فرآیند و Incremental بودن یک فرآیند در این سایت بخوبی مشخص شده است.

ویژگی های اسکرام

اسکرام دربردارنده مجموعه ای از روش (Practice) ها و نقش های از قبل تعریف شده است اما سه ویژگی است که پایه های وجودی اسکرام هستند:

۱- شفافیت Transparency: یعنی اینکه باید تمام جنبه های مختلف فرآیند که بر خروجی آن اثر می گذارد بایستی برای آنهایی که فرآیند را کنترل می کنند مشهود و قابل دید باشد. نه فقط این جنبه ها باید شفاف باشد بلکه بایستی مشخص و معلوم هم باشند یعنی اگر کسی که فرآیند را ممیزی می کند تشخیص داده که چیزی انجام شده این باید مطابق با تعریف انجام شده Done از دید تمام افراد درگیر در پروژه باشد. اگر توافقی بین همه طرف های درگیر در پروژه بر سر معانی و مفاهیم نباشد٬ مشهود بودن اینکه یک قابلیت یا ویژگی انجام شده یا خیر٬ دیگر محلی از اعراب ندارند.

۲- ممیزی و وارسی Inspection:  جنبه های مختلف فرآیند تولید نرم افزار بایستی مدام به اندازه ای  در حال وارسی و چک باشند که انحرافات فرآیند قابل تشخیص باشد.

۳- تطابق پذیری Adaption: اگر بازرس و ممیز فرآیند پس از بازرسی فرآیند٬ تشخیص داد که یک یا چند جنبه از فرآیند خارج از حدود قابل قبول است و باعث غیر قابل پذیرش شدن محصول تولیدی  می شود٬ آن شخص باید فرآیند یا آنچه که فرآیند بر روی آن انجام می شود را تنظیم و تعدیل کند. این کار باید در سریعترین زمان ممکنه انجام شود تا از انحرافات بیشتر جلوگیری شود.

نقش های عمده در اسکرام عبارتند از:

Scrum Master که وظیفه نگهداریُ و حفظ فرآیند را برعهده دارد

Product Owner که نماینده ذینفعان (Stakeholders) های پروژه و business است.

Team یک گروه cross-function متشکل از حداکثر ۷ نفر برنامه نویس است که عملیات تحلیل٫ طراحی٫ پیاده سازی و … را انجام می دهند.

مثل تمام متدولوژی های Incremental و Iterative اینجا هم ما دوره های زمانی یا iteration داریم که در طی آنها محصول نهایی پروژه بتدریج تکمیل می شود. این دوره های زمانی را در اسکرام اصطلاحاْ sprint نامیده می شوند.

در طی یک اسکرام که معمولاْ یک دوره دو تا چهار هفته است(طول دوره را تیم مشخص می کند) اعضاء تیم یک محصول بالقوه قابل ارائه و قابل استفاده را تدریجاْ تولید می کنند. بطور رسمی دوره هر sprint یک ماه یا سی روز در نظر می گیرند.

مجموعه ویژگی هایی از محصول نهایی پروژه که در یک sprint محقق می شود از یک Requirements Repository بنام ‌Backlog استخراج می شود.

اصطلاح Product Backlog نامی است که به بانک اطلاعاتی نیازمندهای عملیاتی و غیر عملیاتی یک پروژه اطلاق می شود و در حقیقت مجموعه ای اولویت بندی شده از نیازمندی های سطح بالای سیستمی است که بایستی تحویل داده شود.

Sprint Planning Meeting

مواردی از Product Backlog که در طی یک sprint باییستی انجام شود در طول جلسه برنامه ریزی sprint  مشخص می شود. اصطلاحاْ این جلسه را Sprint Planning Meeting می نامند.

در طول این جلسه٫ Product Owner اعضاء تیم را درباره مواردی از Product Backlog محصولی که می خواهند تکمیل شود٬ آگاه می کند. سپس اعضاء تیم مشخص می کنند که چه مقدار از موارد مشخص شده توسط Product Owner را می توانند در این sprint انجام دهند و چه میزان از آنرا در sprint های بعدی.

مواردی از Product Backlog که قرار است در یک Sprint انجام شود را اصطلاحاْ Sprint Backlog می نامند. مفاد Sprint Backlog   در واقع توافقی است بین اعضاء تیم و Product Owner برای انجام بخشی از نیازمندی های پروژه در طول sprint جاری و بهرحال طبیعی است که بعد از تصویب شدن مفاد یک sprint ٬ هیچکس نمی تواند آنرا در طول sprint تغییر دهد. در طول دوره٬ نیازمندی های لحاظ شده در Sprint Backlog از Product Backlog بر داشته می شوند . اما امکان دارد به دلایلی که در ادامه می آید این نیازمندی های دوباره به Product Backlog برگردد.

مانند تمام متدولوژی های iterative توسعه نرم افزار در اسکرام نیز Time Boxed است٬ به این معنی که sprint بایستی دقیقاْ سر وقت تمام شود و اگر نیازمندی های اشاره شده در Spring Backlog به هر علتی تکمیل نشده باشند آنها را کنار گذاشته و دوباره وارد Product Backlog می کنند.

بعد از خاتمه یک sprint ٬ اعضاء تیم طی جلسه ای به Product Owner و سایر ذینفعان پروژه نشان می دهند که چکار کرده اند و چطور از نسخه جاری نرم افزار می شود استفاده کرد.

در ساده ترین روش معمولاْ از Mircosoft Excel برای ساختن و نگهداری Product Backlog و Sprint Backlog استفاده می شود اما شرکت Atlassian امکاناتی در این زمینه در محصول JIRA خود گنجانده است که از جمله اینها می تواند به ابزار GreenHopper اشاره کرد.

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

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