در طی این مقاله مروری بر اسکرام در دو بخش کلی خواهیم داشت.

بخش اول

اسکرام چیست ؟

اسکرام یک فریم وورک توسعه نرم افزار از سری متدهای تفکرAgile  می باشد .

اسکرام یک Framework یا فرآیند؟ مسئله این است

در این موضوع کاملا بین متخصصان اسکرام دوگانگی وجود دارد. اشخاصی مانند کن شوئبر (مبدع اسکرام) دائما از لفظ فریم ورک استفاده می کنند و تاکید می نمایند که همه باید این مورد را قبول داشته باشند ولی بعضی دیگر از دوستان از لفظ فرآیند و یا متدولوژی برای اسکرام استفاده می کنند .

با استناد به اصل اسکرام و تجربیات در این مورد می توان بیان کرد که فریم وورک عنوان مناسب تری برای اسکرام خواهد بود. شاید سوال پیش بیاید که خوب فریم ورک باشد , چه فرقی خواهد کرد ؟مایک کان می تواند تعریف خوبی برای شما ارائه دهد :

Scrum is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the team. This is done because the team will know best how to solve its problem.

Mike Cohn Blog

به معنی : اسکرام یک فریم وورک (چارچوب) می باشد. پس به جای اینکه اسکرام جزئیات دقیق و کاملی در مورد اینکه کارها در پروژه چگونه باید انجام شوند ,  بیشتر آن را به تیم واگذار می کند. این کار عملی خواهد بود زیرا تیم خواهد فهمید که چگونه به بهترین نحو مشکل خود را حل نماید .

برای مثال می توان جلسه Sprint Planning را درنظر گرفت : در اسکرام آمده است که خروجی این جلسه می تواند (بایدی در کار نیست ) تعدادی آیتم باشد که آن ها در اسپرینت بعدی پیاده سازی خواهند شد. اما در متدولوژی های دیگر, ضوابط ورودی , تعیین وظایف , ضوابط خروجی و دیگر مسائل جلسه توسط متدولوژی تعیین می شوند و همه آنها لازم الاجرا هستند .

به عبارت ساده تر , در فریم وورک نسخه پیچی نداریم ولی در متدولوژی نسخه های پیچیده شده لازم الاجرا می باشند.

پس قابل نتیجه گیری است که در فریم ورک اسکرام , کشف راه حل برای مشکلات به تیم واگذار می شود و از نسخه پیچی (ارائه حل ها) خبری نیست و بیشتر سعی اسکرام کشف و نمایان کردن مشکلات می باشد به جای اینکه مشکلات را حل نماید .

برای تکمیل تعریف اسکرام , در Scrum Guide کن شوئبر و جف سادرلند چنین می خوانیم :

Scrum employs an iterative, incremental approach to optimize predictability and control risk.

به این معنی که : اسکرام برای بهینه سازی پیش بینی و کنترل ریسک از یک روش تکرار نموی یا iterative incremental بهره می جوید .برای آشنایی با این مفهوم به این لینک مراجعه کنید .

تعریف اسکرام ما به اینجا رسیده است که: اسکرام یک چارچوب برای توسعه نرم افزار می باشد که از روش iterative incremental بهره می جوید. اما در تعریف اول مطلبی بود که در این یکی تعریف نیست : “از سری متدهای تفکر Agile”.

اسکرام یکی از فریم ورک های محبوب و پرکاربرد Agile محسوب می شود .

متد Agile چیست؟

متدهای Agile که از آن جمله می توان به اسکرام , XP , Kanban و… اشاره کرد , روشی برای دست یابی به تفکر Agile می باشند.  Agile یک تفکر در زمینه توسعه نرم افزار می باشد و اسکرام یک روش برای پیاده سازی این تفکر در پروژه های توسعه نرم افزاری می باشد [ادامه…]

پس برای کامل کردن تعریف می توان گفت : اسکرام یک چارچوب  توسعه نرم افزار Agile می باشد که از روش iterative incremental بهره می جوید .

گاها در مقالات اسکرام می خوانیم که از اسکرام به عنوان متدولوژی سبک یاد می کنند. البته این وزن کردن متد ها زیاد درست نمی باشد. درهمین باب می خوانیم :

Scrum is an agile framework for completing complex projects.

Scrum alliance

یا گاها می شنویم که بعضی از افراد می گویند که اسکرام فقط برای پروژه ها و یا شرکت های کوچک موثر است: در همین باب می توانیم به مثال های زیر رجوع کنیم :

پیاده سازی اسکرام در گوگل

استفاده یاهو از اسکرام

اسکرام در مایکروسافت

تجربه اسکرام در salesforce

به نظر می رسد که سبک و سنگین کردن اسکرام و یا محدود کردن آن به پروژه های کوچک کاری است غیر عادلانه و شاید کوته فکرانه. پس اسکرام چارچوبی است که در نرم افزار های پیچیده و بزرگ نیز طبق تجربه جهانی جواب خواهد داد.

نتیجه گیری بخش ۱

اسکرام یک چارچوب توسعه نرم افزار Agile می باشد که برای توسعه نرم افزار از روش Iterative Incremental بهره می جوید. این چارچوب توانایی اداره پروژه های کوچک و هم پروژه های بزرگ را دارا می باشد.

بخش دوم

در بخش اول مقاله تعریفی از اسکرام ارائه شد. در بخش دوم سعی خواهد شد که مبانی و اصول اسکرام تشریح گردند.

اساس و کل اسکرام به صورت شکل زیر می باشد :

از طرف چپ شکل بالا شروع می کنیم :

در سمت چپ این عکس شاهد وجود کاربران , ذینفعان , مدیران و دیگرنقش های موجود هستیم. این نقش ها {که شامل درخواست کنندگان محصول و یا ذینفعان محصول و یا استفاده کننده می باشد} از طریق رابط خود یعنی مالک محصول یا Product Owner  با تیم توسعه دهنده محصول ارتباط برقرار می کنند.

همانطور که اشاره شد PO یا Product Owner نماینده گروه ذینفعان محصول می باشد. PO  به عنوان یکی از نقش های اصلی در محیط اسکرام به حساب می آید . که مسلما هر نقش باید یک سری وظیفه داشته باشد که وظایف PO به این شکل می باشند :

• تعیین هدف و چرایی هدف برای تیم؟ (او مقصد نهایی را نشان می دهد ولی به این کار نخواهد داشت که چگونه تیم می خواهد به آنجا دست یابد)
• اولویت بندی .

اهداف و خواسته های مالک محصول در یک لیست به نام Product Backlog جمع آوری می شوند. به عبارت ساده تر Product Backlog شامل تمام خواسته و ویژگی های مورد نظر مالک محصول  برای گنجاندن در محصول مورد نظر می باشد.اما این لیست باید مرتب شود ولی بر چه اساسی ؟ اینکار نیز به مالک محصول محول شده است تا او درخواست های خود را بر اساس اولویت های تجارت خود و یا ذینفعان خود تعیین کند. شاید سوال مطرح شود که چه نیازی به اولویت بندی است؟

از آنجایی که فقط ۲۰% از ویژگی های ارائه شده در قالب محصول برای مشتری با اهمیت و با ارزش می باشند چرا نباید این ویژگی ها را قبل از دیگر ویژگی های غیر ضروری ارائه داد. به این عمل در واقع تضمین بازگشت سرمایه می گویند . هر چقدر زودتر نیازهای اصلی مشتری را رفع کنید برگشت سرمایه زودتر انجام خواهد شد.

اما علاوه بر مالک محصول نقشی به نام تیم وجود دارد که کار او توسعه محصول مورد نظر خواهد بود . این تیم می تواند شامل تمام نقش های توسعه نرم افزار مانند برنامه نویس , تحلیل گر و طراح  DBA, و … باشد. تیم در صورت وجود نفرات زیاد می تواند به چندین تیم مجزا نیز تقسیم شود. تعداد ۵-۹ نفر برای هر تیم ترجیح داده می شوند. تیم های اسکرام بر خلاف دیگر تیم ها دو ویژگی اساسی دارند :

• Self-Organize یا خود سازمانده هستند.  از متد مدیریت Micromanagement   یا مدیریت دستور-کنترل برای این تیم ها استفاده نمی شود و این تیم ها خود-سازمانده می باشند . در واقع به این تیم ها فقط گفته می شود که می خواهیم چه کاری انجام دهیم و نه اینکه بگوییم این کار را انجام بده و اینگونه هم انجام بده.
• Cross-Functional کار می کنند . اعضای هر تیم به صورت Incremental در فکر پیاده سازی یک واحد کوچک به نام Story می باشند . هر Story در واقع می تواند یک عملیات محصول در نظر گرفته شود. این تیم ها بر خلاف تیم های دیگر که معمولا به صورت Component کار می کنند و هدفشان تکمیل جزئی از محصول هست می باشند.

از جمله وظایف این نقش می توان به موارد زیر اشاره کرد :

• تعیین کردن اینکه چه مقدار کار می توانند در طی یک اسپرینت (۲-۴ هفته) انجام دهند .
• چگونه باید کارها را انجام دهند .

اسپرینت در اسکرام همان Iterative هایی هستند که در بالا عرض شد . این تکرارها معمولا در اسکرام بین ۲-۴ هفته یکبار انجام می شود . در شروع هر اسپرینت مقداری درخواست مشتری (User Story) با توجه به ظرفیت تیم (سرعت تیم یا  Velocity) انتخاب می شوند و در لیست Sprint Backlog قرار می گیرند. این لیست شامل تمام درخواست های مشتری می شود که تیم متعهد شده است  که در این اسپرینت پیاده سازی نماید.

درخواست های مشتری چه در Product Backlog و چه در Sprint Backlog در قالبی به نام User Story نگه داری می شوند و به عبارتی به هر آیتم Backlog یک User Story گفته می شود. نکته مهم در مورد User Story این می باشد که این توضیحات باید به صورت علائم تجاری و مشتری فهم باشند و نه اختصارات فنی. معمولا بهتر است خود مالک محصول این توضیحات را در حضور تیم آماده کند.

برای اینکه بتوان میزان ظرفیت تیم و میزان بهره وری آن ها را سنجید باید به هر داستان کاربر یک وزن اطلاق شود . واحد این وزن Story Point  می باشد. اما در باره نحوه وزن دادن هر داستان : ساده ترین درخواست مشتری را انتخاب کنید . به آن   Story Point 2 بدهید.  موارد دیگر باید بر اساس رابطه سختی آن ها با این داستان وزن دهی شوند. مورد بعدی را انتخاب کنید اگر دو برابر سخت تر از این داستان بود به آن ۴ و اگر کمی سخت بود به آن ۳ و اگر به سختی این داستان بود به آن ۱ بدهید .

همانطور که در بالا ذکر شد “در شروع هر اسپرینت مقداری درخواست مشتری (User Story) با توجه به ظرفیت تیم (سرعت تیم یا Velocity) انتخاب می شوند” . ظرفیت تیم همان سرعت تیم خوانده می شود . به عبارت ساده تر تیم در طی اسپرینت ۴ هفته ای چند Story point می تواند انجام بدهد؟ تعیین این میزان برای هر تیم به دو روش امکان دارد :

• تعیین ظرفیت اسپرینت با توجه به عملکرد تیم در اسپرینت های قبلی
• تعیین ظرفیت تیم بر اساس توان نیروی کار موجود و میزان توجه آن ها به کار

به طور خلاصه تیم بر اساس ظرفیت و یا سرعت خود و رعایت اولویت های مالک محصول تعدادی User Story  را از داخل Product Backlog انتخاب و به داخل Sprint Backlog کپی می کند. این فعالیت در طی جلسه برنامه ریزی اسپرینت و یا Sprint Planning انجام می شود . این جلسه در ابتدای هر اسپرینت برگزار می شود.

در گام بعدی تیم شروع به پیاده سازی هر یک از User Story های موجود در Sprint Backlog خواهد کرد . برای اینکه اعضای تیم اعلام کنند که چه کاری را انجام داده اند و چه کاری را می خواهند انجام بدهند جلسه ای با عنوان جلسه روزانه اسکرام و یا جلسه سرپایی روزانه در هر روز معمولا در شروع روز کاری به مدت حداکثر ۱۵ دقیقه برگزار می شود . در این جلسه هر کس ۳ سوال اصلی مطرح و به آن ها جواب می دهد :

• دیروز چه کاری انجام دادم
• امروز چه کاری می خواهم انجام بدهم
• چه موانعی در پیش رو دارم و با چه موارد پیش بینی نشده ای برخورد کرده ام ؟

طرح این سوالات برای ایجاد شفافیت و وضوح عملکرد تیم می باشد . این عمل باعث ژل شدن بیشتر تیم می شود.

در نهایت در زمان اتمام زمان اسپرینت , تیم اقدام به آماده سازی یک دمو از موارد تکمیل شده طی اسپرینت می کند . این دمو طی یک جلسه با عنوان Sprint Review به دیدگان مشتری  دیگر تیم ها گذاشته می شود . هدف این جلسه دریافت بازخوردهای مالک محصول و دیگر نفرات حاضر درجلسه می باشد. تیم بازخورد های دریافتی را مغتنم شمرده و آن ها را در Product Backlog اعمال می نماید و این راهی برای دریافت و کنترل تغییرات می باشد .

آخرین جلسه بعد از اتمام هر اسپرینت , جلسه Scrum Retrospective یا بازبینی عملکرد می باشد . این جلسه فرصتی با ارزش برای بهبود عملکرد تیم می باشد و معمولا فقط تیم در این جلسه حاضر می شود . در این جلسه عملکرد های اسپرینت بررسی و برای آینده یک راه حلی طرح می شود . در این جلسه سوال هایی مانند این ها مطرح می شود :

• کدامیک از عملکردهای ما درست بود
• کدامیک از عملکردهای ما نیاز به اصلاح دارد
• چه بهبودهایی را می توان برای آینده در نظر گرفت

بهبود ها و راه حل های کشف شده در این جلسه ۲ ساعته به مرور در اسپرینت های بعدی اعمال می شوند.

علاوه بر خود تیم نقشی به نام Scrum master یا مدیر اسکرام در داخل تیم وجود دارد . همانطور که از عنوان این نقش قابل ملاحظه  است کار این نقش مدیریت پروسه اسکرام می باشد . اولا او پروسه اسکرام را در سازمان کلید می زند و ثانیا او کنترل می کند که آیا تیم و مالک محصول ,اسکرام را درست انجام می دهند ؟ علاوه بر این ها وظیفه حذف موانع از سر تیم در راه فرآیند اسکرام نیز بر عهده SM می باشد .برای هر تیم باید یک SM و یک PO مجزا وجود داشته باشد .