با اینکه اسکرام در واقع یک روش برای کل فرآیند تولید نرم افزار در پروژه‌ها به شمار می‌رود اما مشخصا” برای کنترل پروژه نرم افزار استفاده می‌گردد، همچنین امکان استفاده از این روش در نگهداری و پشتیبانی نرم افزار به عنوان برنامه و خط مشی عمومی وجود دارد. اسکرام دربردارنده مجموعه‌ای از روش ها (Practices) و نقش‌های از قبل تعریف شده است اما سه ویژگی است که پایه‌های اصلی اسکرام هستند:
نمایی کلی از اسکرام و بخش های آن
جهت مشاهده تصویر بزرگتر روی آن کلیک نمایید.
۱- شفافیت Transparency: یعنی اینکه تمام جنبه‌های مختلف فرآیند که بر خروجی آن اثر می‌گذارد بایستی برای آنهایی که فرآیند را کنترل می‌کنند مشهود و قابل دید باشد. نه فقط این جنبه‌ها باید شفاف باشد بلکه بایستی مشخص و معلوم هم باشند یعنی اگر کسی که فرآیند را ممیزی می‌کند تشخیص دهد که چه چیزی انجام شده، این باید مطابق با تعریف انجام شده (Done) از دید تمام افراد درگیر در پروژه باشد. اگر توافقی بین همه طرف‌های درگیر در پروژه بر سر معانی و مفاهیم نباشد، مشهود بودن اینکه یک قابلیت یا ویژگی انجام شده یا خیر، مشکل و غیر قابل اطمینان خواهد بود.
۲- ممیزی و وارسی Inspection: جنبه‌های مختلف فرآیند تولید نرم افزار بایستی همواره به اندازه‌ای در حال وارسی و آزمایش باشند که انحرافات فرآیند قابل تشخیص باشد.
۳- تطابق پذیری Adaption: اگر بازرس و ممیز فرآیند پس از بازرسی فرآیند، تشخیص داد که یک یا چند جنبه از فرآیند خارج از حدود قابل قبول است و باعث غیر قابل پذیرش شدن محصول تولیدی می‌شود، آن شخص باید فرآیند یا آنچه که فرآیند بر روی آن انجام می‌شود را تنظیم و تعدیل کند. این کار باید در سریعترین زمان ممکنه انجام شود تا از انحرافات بیشتر جلوگیری شود.
نقش ها
نقش‌های اصلی در اسکرام عبارتند از:
- Scrum Master که وظیفه نگهداری و حفظ فرآیند را برعهده دارد.
- Product Owner که نماینده ذینفعان (Stakeholders)های پروژه و Business است.
- Team Member عضوی از یک گروه Cross-Function است که معمولا بیش از ۷ نفر نیستند. این افراد عملیات تحلیل٫ طراحی٫ پیاده سازی، تست و… را انجام می‌دهند.
تعریف هر نوع نقش یا سمت به جز سه نقش گفته شده در اسکرام ممنوع است. به عنوان مثال اعضای تیم نمی‌توانند سمت‌های متفاوتی داشته باشند.
روند کار اسکرام
مثل تمام متدولوژی های Incremental و Iterative ادر اینجا هم دوره‌های زمانی یا Iteration وجود دارد که طی آنها محصول نهایی پروژه بتدریج تکمیل می‌شود. این دوره‌های زمانی در اسکرام اصطلاحا” Sprint نامیده می‌شوند.
روند کار اسکرام در تولید نرم افزار
جهت مشاهده تصویر بزرگتر روی آن کلیک نمایید.
در طی یک Sprint که معمولا” یک دوره دو تا چهار هفته ای است (طول دوره را تیم مشخص می‌کند) اعضاء تیم یک محصول بالقوه قابل ارائه و قابل استفاده را تدریجا” تولید می‌کنند. بطور رسمی دوره هر Sprint را یک ماه در نظر می‌گیرند.
مجموعه ویژگی‌هایی از محصول نهایی پروژه که در یک Sprint محقق می‌شود از یک Requirements Repository بنام Sprint 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 و سایر ذینفعان پروژه نشان می‌دهند که چکار کرده‌اند و چطور از نسخه جاری نرم افزار می‌شود استفاده کرد.
در ساده‌ترین روش معمولاْ از نرم افزارهای صفحه گسترده (Spread Sheet) همچون LibreOffice Calc یا Microsoft Excel برای ساختن و نگهداری Product Backlog و Sprint Backlog استفاده می‌شود، اما می‌توان از طیف وسیعی از ابزارهای نرم افزاری که برای استفاده در تیمهای Agile نوشته شده‌اند نیز استفاده کرد.
