اسکرام یک فرایند مکرر و رو به جلوئه که شاخه‌ای از سیستم توسعه‌ی نرم‌افزار بصورت چابک (Agile) حساب میشه.
در این موضوع کاملا بین متخصصان اسکرام دوگانگی وجود دارد. اشخاصی مانند کن شوئبر (مبدع اسکرام) دائما از لفظ فریم ورک استفاده می کنند و تاکید می نمایند که همه باید این مورد را قبول داشته باشند ولی بعضی دیگر از دوستان از لفظ فرآیند و یا متدولوژی برای اسکرام استفاده می کنند .
اساس اسکرام به صورت زیر می باشد:
در سمت چپ این عکس شاهد وجود کاربران , ذینفعان , مدیران و دیگرنقش های موجود هستیم. این نقش ها که شامل درخواست کنندگان محصول و یا ذینفعان محصول و یا استفاده کننده می باشد از طریق رابط خود یعنی مالک محصول یا Product Owner با تیم توسعه دهنده محصول ارتباط برقرار می کنند.
همانطور که اشاره شد PO یا Product Owner نماینده گروه ذینفعان محصول می باشد. PO به عنوان یکی از نقش های اصلی در محیط اسکرام به حساب می آید . که مسلما هر نقش باید یک سری وظیفه داشته باشد که وظایف PO به این شکل می باشند :
- تعیین هدف و چرایی هدف برای تیم؟ (او مقصد نهایی را نشان می دهد ولی به این کار نخواهد داشت که چگونه تیم می خواهد به آنجا دست یابد)
- اولویت بندی .
در این شکل، کل کار و فعالیت اسکرام به 8 مرحله تقسیم بندی شده است:
مرحله‌ی اول: تهیه‌ی Product Backlog
یک سند بالا دستی در پروژه‌ی ما به حساب میاد. در این سند تمام خواسته‌های صاحب کار رو باید بگنجونیم. معمولاً این سند در یکی دو جلسه با حضور مشتری یا نماینده‌ش و بخش مدیریت توسعه شکل میگیره. حالا اینکه به چه صورت میشه کفه‌ی ترازو رو به نفع تیم توسعه سوق داد به قدرت چانه‌زنی و اقناع بخش مدیریت برمیگرده.
مرحله‌ی دوم: فازبندی
اولاً اینکه واسه این جور مشتری‌ها باید پروژه رو بصورت فاز به فاز، تحویل داد (این یکی از تعاریف سیستم چابکه: Early Delivery). پس باید کل کار رو به چند فاز تقسیم کنیم تا تحویل هم به همین صورت انجام بشه. تقسیم‌بندی به دو صورت رفتاری یا کیفی انجام میشه، به طور مثال، در پیاده‌سازی فروشگاه میتونیم فروشگاه رو به فازهای سیستم کاربران، بخش مالی و حسابداری، بخش انبارداری و زنجیره‌ی تأمین، بخش پنل اپراتوری و مدیریت و بخش ویترین فروشگاه تقسیم‌بندی کرد، یا میتونیم همه‌ی این بخش‌ها رو با هم شروع کنیم، اما با کیفیت و سطح خدمات پایینتر. اگه کار برای خودتون هست یا مشتری سمج ندارید، من روش اول رو پیشنهاد میکنم. دوباره‌کاری و تغییرات در روش اول خیلی کمتره اما فکر نکنید که میتونید با ارائه‌ی یک سیستم کاربری خالی صاخب کار سمج رو به ادامه‌ی کار دلگرم کنید.
مرحله‌ی سوم: جلسه‌ی برنامه‌ریزی اسپرینت
چه اهدافی در این اسپرینت داریم؟ چطور به این اهداف برسیم؟ این دو سوال دلایل اصلی برگزاری جلسه‌های برنامه‌ریزی اسپرینت هستند. در سند اسپرینت برخلاف سند پروژه، مباحث بیشتر در مورد مسائل درون‌گروهی و نحوه‌ی اجرا، تعیین نفرات و زمان‌بندی کارها متمرکزه.
در این جلسه با حضور اعضای تیم، وظایف مشخص میشه و زمان‌بندی کل اسپرینت به دست میاد. توجه به قوانین زمانی بسیار مهمه. معمولاً وظائف بسیار خرد میشن و اونا رو از یک تا هشت ساعت زمان‌دهی میکنیم. بعضی از روش‌ها زمان‌دهی باینری رو توصیه میکنن، یعنی فقط مجاز به انتخاب یکی از زمان‌های ۱، ۲، ۴ یا ۸ ساعت هستیم. اما آنچه مهمه اینه که سعی بشه که بیشتر از ۸ ساعت (یعنی یک روز کاری) نشه تا پیگیری کارها آسونتر و به‌روزتر باشه؛ البته باز هم بستگی به نوع پروژه داره.
در جلسه‌ی برنامه‌ریزی اسپرینت یا بعد از اون، برگه ها یا برچسب‌هایی از کار بچه‌ها، با توجه به قوانین زمانی، توسط خودشون تهیه میشه، یعنی حاوی نام کارهاشون هست و زمانی که دارن بهش اختصاص میدن، که البته بهتره جا برای اصلاح و کم کردن زمان برای کارهای طولانی‌تر در طول اسپرینت داشته باشن. بهتره که هر فرد در هر تیم یک رنگ رو انتخاب کنه تا تشخیص اون برای همه میسر باشه. یک تخته اسکرام (Scrum Board) رو به سه بخش در صف انجام(To-Do)، در حال انجام(Doing) و انجام شده(Done) تقسیم می کنیم و برگ ها رو ابتدا در بخش در صف انجام قرار میدیم.
زمان هر جلسه‌ی اسپرینت معمولاً متناسب با زمان خود اسپرینته که به ازای هر هفته دو ساعت در نظر گرفته میشه. یعنی اگه اسپرینت ما ۲ هفته ای باشه، ۴ ساعت زمان جلسه ست. معمولاً اسپرینت‌ها کمتر از ۲ هفته و بیشتر از یک ماه در نظر گرفته نمیشن.
مرحله‌ی چهارم: تهیه‌ی سند اسپرینت (Sprint Backlog)
در این مرحله پروژه‌ی ما به چند فاز تقسیم شده، حالا میتونیم هر فاز رو به عنوان یک اسپرینت انتخاب کنیم یا یک فاز رو به چند اسپرینت. انتخاب اسپرینت میتونه در جلسه‌ی اولیه‌ی تهیه‌ی Product Backlog یا در هر جلسه‌ی برنامه‌ریزی اسپرینت صورت بگیره. سندی که در این جلسه تهیه میشه همون سند اسپرینته.
مرحله‌ی پنجم: اجرای اسکرام
بچه‌ها هر روز دور هم جمع میشن و به شرح مختصر فعالیت‌های گذشته و جاری میپردازن. بچه ها برگ هایی که مربوط به کار خودشون هست رو جابجا می کنن. یعنی برگ کارهایی امروز می خواهیم انجام بدیم رو از بخش To-Do به Doing و برگ کارهایی که دیروز انجام شده رو از Doing به Done انتثال میدن. اینجا چند تا نکته خیلی مهمه.
- اینجا محل ذکر عنوان کاره که نیازی به توضیح نیست. قرار نیست توضیح بدیم که چرا کارمون تموم نشده و از مشکلات یا نواقص حرف بزنیم.
- همه موقع جلسه ایستاده‌ن و وقتی داریم گزارش میدیم باید مخاطب ما هم‌تیمی‌های ما باشن نه مدیر پروژه یا مسئول اسکرام (Scrum Master)
- سعی کنیم ارائه‌ی گزارش خیلی جدی، دقیق و با اطلاعات درست همراه باشه. اگه کاری رو تموم نکردیم، کتمان کنیم و فکر کنیم که این کار رو روز بعد تکمیل میکنیم و کسی هم متوجه نمیشه. اولین کسی که ضربه‌ی این اشتباه رو می خوره خودمون هستیم. اسکرام برای بهبود و ارتقای سطح کیفی کار ماست و ارائه‌ی اطلاعات غلط میتونه برای ما و تیم بسیار مخرب باشه.
همون طور که قبلاً ذکر شد، زمان جلسه حداکثر ۱۵ دقیقه ست، که البته بسته به تعداد افراد تیم و نوع پروژه قابل تغییره. در پایان جلسه مسئول اسکرام میتونه یک گزارش کلی از وضعیت و مسائل موجود ارائه کنه.
مرحله‌ی ششم: تحویل اسپرینت
در این مرحله بخشی از فاز یا یک فاز از پروژه رو تحویل میدیم، این کار رو اصطلاحاً تحویل افزایشی و فازی پروژه مینامیم.
مرحله‌ی هفتم: بررسی اسپرینت
چه کارهایی انجام شده و چه کارهای ناقص مونده؟ پس از اجرای روزانه‌ی جلسات اسکرام، باید به بررسی روند تکمیل پروژه و مقایسه با سند اسپرینت، کارکرد افراد (اعم از اثر بخشی و بهره‌وری در انجام کار) که منجر به ارائه‌ی یک گزارش که به گزارش اسپرینت معروفه، بپردازیم. این گزارش به ما در ارائه‌ی یک نگاه روشن از نقاط ضعف و قوت ما کمک میکنه. زمان این جلسه معمولاً نصف جلسه‌ی برنامه‌ریزی اسپرینته.
مرحله‌ی هشتم: بازنگری اسپرینت (Sprint Retrospective)
حالا دیگه وقت تصمیم‌گیریه! رفع نقاط ضعف و بهبود نقاط قوت، تصمیم‌گیری در مورد بهبود عملکرد افراد، ارتباطات، فرآیندها و توسعه‌ی ابزارهای مورد نیاز و تعیین برنامه‌ای برای اجرای این تصمیمات در این جلسه انجام میشه. زمان این جلسه هم کمتر از جلسه‌ی بررسیه و معمولاً برای یک اسپرینت ۲ هفته‌ای ۳ ساعت وقت گذاشته میشه.
درج دیدگاه