اسکرام (توسعه نرم‌افزار) - ویکی‌پدیا، دانشنامهٔ آزاد

چارچوب مدل اسکرام یک چارچوب تکرارپذیر و افزایشی برای کنترل پروژه (مدیریت نرم‌افزار) است که معمولاً در زیر شاخه مدل فرایند تولید نرم‌افزار چابک و سریع است؛ و یک نوع مدل تولید نرم‌افزار در مهندسی نرم‌افزار به شمار می‌آید.

اسکرام یک چارچوب تولید نرم‌افزار از سری روشهای تفکر چابک (Agile) می‌باشد.

اسکرام یک چارچوب یا فرایند؟ مسئله این است، دراین موضوع کاملاً بین متخصصان اسکرام دوگانگی وجود دارد. اشخاصی مانند کن شوئبر (مبدع اسکرام) دائماً از لفظ چارچوب (framework) استفاده می‌کنند و تأکید می‌نمایند که همه باید این مورد را قبول داشته باشند ولی بعضی دیگر از متخصصان از لفظ فرایند یا متدولوژی برای اسکرام استفاده می‌کنند.

تاریخچه[ویرایش]

این روش در سال ۱۹۸۶ توسط هیروتاکا تاکوچی و ایکوجیرو نوناکا به عنوان یک خط مشی جدید برای تولید نرم‌افزارهای تجاری که باید قابلیت سرعت در تولید و انعطاف‌پذیری را داشته باشند، عرضه گردید. اسم اسکرام از یک نوع بازی در فوتبال راگبی آمده است.

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

مشخصات[ویرایش]

با اینکه روش اسکرام در واقع یک روش برای کل فرایند تولید نرم‌افزار در پروژه‌ها به شمار می‌رود اما اختصاصاً برای کنترل پروژه نرم‌افزار استفاده می‌گردد، همچنین امکان استفاده از این روش در نگهداری و پشتیبانی نرم‌افزار به عنوان برنامه و خط مشی عمومی وجود دارد.

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

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

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

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

نقشها[ویرایش]

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

1. Scrum Master یک تسهیل گر می‌باشد که وظیفه نگهداری و حفظ فرایند را برعهده دارد.
2. Product Owner که نماینده ذینفعان (Stakeholders) پروژه و business است.
3. Team Member عضوی از یک گروه cross-function است که معمولاً بین 3 تا 9 نفر هستند. این افراد عملیات تحلیل٫ طراحی٫ پیاده‌سازی، تست و... را انجام می‌دهند.

تعریف هر نوع نقش یا سمت به جز سه نقش گفته شده در اسکرام ممنوع است. به عنوان مثال اعضای تیم نمی‌توانند سمت‌های متفاوتی داشته باشند.

روند کار اسکرام[ویرایش]

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

در طی یک Sprint که معمولاً یک دوره دو تا چهار هفته است (طول دوره را تیم مشخص می‌کند) اعضاء یک محصول بالقوه قابل ارائه و قابل استفاده را تدریجاً تولید می‌کنند.

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

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

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

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

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

در ساده‌ترین روش معمولاً از نرم‌افزارهای صفحه گسترده (Spread Sheet) همچون LibreOffice Calc یا Microsoft Excel برای ساختن و نگهداری Product Backlog و Sprint Backlog استفاده می‌شود، اما می‌توان از طیف وسیعی از ابزارهای نرم‌افزاری که برای استفاده در تیمهای Agile نوشته شده‌اند^[۱] نیز استفاده کرد.

منابع[ویرایش]

• [۱]
• [۲]
• [۳] کتاب اسکرام و اکس پی ساده شده