اسکرام یک چارچوب مدیریت پروژه چابک است که به تیمها کمک میکند تا کار خود را از طریق مجموعهای از ارزشها، اصول و شیوهها، ساختاردهی و مدیریت کنند. هدف اولیه اسکرام ارضای نیاز مشتری از طریق محیطی شفاف در ارتباطات، مسئولیت جمعی و پیشرفت مستمر است. توسعهی این امر از یک ایده کلی در مورد آنچه باید ساخته شود شروع میشود و به فهرستی از ویژگیهای مرتب شده بر اساس اولویت (حقوق محصول) که صاحب محصول میخواهد میرسد.
تاریخچه مختصری در مورد اسکرام
تاریخچه اسکرام را میتوان به سال 1986 در مقاله هاروارد بیزینس ریویو (HBR) با عنوان “بازی توسعه محصول جدید” توسط هیروتاکا تاکوچی و ایکوجیرو نوناکا مرتبط دانست. این مقاله توضیح میدهد که چگونه شرکتهایی مانند هوندا، کانن، و فوجی زیراکس با استفاده از رویکردی مقیاسپذیر و مبتنی بر تیم برای توسعه محصول، محصولات جدیدی را در سراسر جهان تولید میکنند. این رویکرد بر اهمیت توانمندسازی تیم های خودساخته تاکید میکند. مقالهی مورد بحث تأثیر بسیار زیادی بر توسعه بسیاری از مفاهیمی داشت که باعث پیدایش چیزی شد که ما اکنون اسکرام مینامیم. اسکرام اصطلاحی است که از راگبی گرفته شده است و به نحوه شروع مجدد بازی پس از خطا یا زمانی که توپ از بازی خارج می شود اشاره دارد.
در سال 1993، جف ساترلند و تیمش در شرکت Easel با ترکیب مفاهیم مقاله 1986 با مفاهیم توسعه شیگرا، کنترل فرآیند تجربی، توسعه تکراری و افزایشی و فرآیندهای نرم افزاری، اسکرام را برای استفاده در فرآیندهای توسعه نرم افزار ایجاد کردند.
روش و فرآیند اسکرام
اسکرام دقیقاً نسخهی تکامل یافته مدیریت چابک است. متدولوژی اسکرام مبتنی بر مجموعهای از اقدامات و نقشهای بسیار تعریف شده است که باید در طول فرآیند توسعه نرم افزار درگیر شوند. این یک روش منعطف است که به استفاده از 12 اصل چابک در زمینه مورد توافق همه اعضای تیم محصول، میپردازد.
اسکرام در بلوکهای موقت کوتاه و دورهای به نام Sprint اجرا میشود که مدت زمان اختصاص داده شده به هرکدام معمولاً بین 2 تا 4 هفته است. هر اسپرینت به خودی خود یک موجودیت است، یعنی یک نتیجه کامل را ارائه میکند. در واقع تنوعی از محصول نهایی است که باید بتواند در صورت درخواست با کمترین تلاش ممکن به مشتری تحویل داده شود.
فرآیند به عنوان نقطه شروع، فهرستی از اهداف و یا نیازهایی است که طرح پروژه را تشکیل میدهند. این مشتری پروژه است که این اهداف را با در نظر گرفتن تعادل ارزش و هزینه آن اولویتبندی میکند، به این ترتیب تکرارها و تحویلهای متعاقب آن تعیین میشوند. از طرف دیگر بازار خواستار کیفیت و تحویل سریع با هزینههای کمتر است که برای این منظور یک شرکت باید در توسعه محصولات بسیار چابک و انعطاف پذیر باشد تا بتواند به چرخههای توسعه کوتاهی دست یابد که تقاضای مشتریان را بدون تضعیف کیفیت نتیجه برآورده کنند.
این یک روش بسیار آسان برای پیاده سازی است و نتایج سریعی که از آن خواهید گرفت بسیار محبوب است. متدولوژی اسکرام عمدتاً برای توسعه نرمافزار استفاده میشود، اما سایر بخشها نیز با پیادهسازی این متدولوژی در مدلهای سازمانی خود مانند تیمهای فروش، بازاریابی و منابع انسانی و غیره از مزایای آن استفاده میکنند.
نقشهای مختلف در اسکرام
در اسکرام، تیم بر ساخت نرمافزار با کیفیت بالا تمرکز میکند. مالک یک پروژه اسکرام بر تعیین ویژگیهایی که محصول باید برای ساختن داشته باشد و برای غلبه بر هر مشکلی که میتواند مانع از کار تیم توسعه شود، تمرکز میکند.
تیم اسکرام از نقشهای زیر تشکیل شده است:
اسکرام مستر: شخصی که تیم را هدایت و افراد را برای رعایت قوانین و فرآیندهای متدولوژی راهنمایی میکند. اسکرام مستر کاهش موانع پروژه را مدیریت کرده و با مالک محصول برای به حداکثر رساندن ROI همکاری میکند. اسکرام مستر مسئول به روز نگهداشتن اسکرام، ارائه مربیگری، راهنمایی و آموزش به تیمها در صورت نیاز است.
مالک محصول (PO): نماینده ذینفعان و مشتریانی است که از نرمافزار استفاده میکنند. آنها روی بخش تجاری تمرکز میکنند و مسئولیت بازگشت سرمایه (ROI) پروژه را بر عهده دارند. آنها چشم انداز پروژه را به تیم ارائه داده و مزایای موجود در فعالیت پیش رو را بررسی میکنند.
تیم: گروهی از متخصصان با دانش فنی لازم است که پروژه را به طور مشترک توسعه میدهند و به یک سری از قوانین پایبند هستند.
مزایای روش اسکرام
اسکرام مزایای زیادی نسبت به سایر متدولوژیهای توسعه چابک دارد. در حال حاضر پرکاربردترین و قابل اعتمادترین چارچوب مرجع در صنعت نرمافزار است.
در ادامه برخی از مزایای شناخته شده اسکرام آورده شده است:
مقیاس پذیری آسان: فرآیندهای اسکرام تکراری هستند و در دورههای کاری خاص انجام میشوند، که تمرکز تیم را بر روی عملکردهای مشخص برای هر دوره آسان تر میکند. این نه تنها مزیت دستیابی به نتایج بهتر را مطابق با نیازهای کاربر دارد، بلکه به تیمها این توانایی را میدهد که ماژولها را از نظر عملکرد، طراحی، دامنه و ویژگیها به صورت منظم، شفاف و ساده مقیاس بندی کنند.
انطباق انتظارات: مشتری انتظارات خود را مشخص کرده و با توجه به این موضوع، تیم شما نسبت به برآورده کردن آن نیاز اقداماتی را انجام میدهد.
انعطاف پذیر در برابر تغییرات: واکنش سریع به تغییرات در نیازهای ایجاد شده توسط نیازهای مشتری یا تحولات بازار. این روش برای انطباق با الزامات متغیری که پروژههای پیچیده مستلزم آن هستند طراحی شده است.
کاهش زمان تا بازار: مشتری میتواند قبل از آماده شدن کامل محصول، استفاده از مهمترین قابلیتهای پروژه را شروع کند.
کیفیت بالاتر نرمافزار: روش کار و نیاز به دریافت نسخه کاربردی پس از هر بار تکرار، به دستیابی به نرم افزار با کیفیت بالاتر کمک میکند.
پیشبینی به موقع: با استفاده از این متدولوژی، میانگین سرعت تیم را با سرعت (نقاط داستانی) میدانیم، که در نتیجه، میتوان تخمین زد که چه زمانی یک عملکرد خاص که هنوز کامل انجام نشده، در دسترس خواهد بود.
کاهش خطرات: آگاهی از سرعت پیشرفت تیم در پروژه، امکان پاکسازی موثر ریسکها را از قبل فراهم میکند.
رویدادها در اسکرام
هر یک از رویدادهای اسکرام انطباق برخی از جنبههای فرآیند، محصول، پیشرفت یا روابط را تسهیل میکند.
اسپرینت: اسپرینت واحد اصلی کار برای تیم اسکرام است. این ویژگی اصلی است که تفاوت بین Scrum و سایر مدلها را برای توسعه چابک نشان میدهد.
برنامه ریزی اسپرینت: هدف برنامه ریزی اسپرینت این است که مشخص کند چه کاری قرار است در اسپرینت انجام شود و چگونه انجام شود. این جلسه در ابتدای هر اسپرینت برگزار میشود و نحوه رویکرد آن در طول پروژه به مراحل و مهلتهای Backlog محصول بستگی دارد. هر اسپرینت از ویژگیهای مختلفی تشکیل شده است.
اسکرام روزانه: هدف از اسکرام روزانه ارزیابی پیشرفت و روند تا پایان اسپرینت، همگامسازی فعالیتها و ایجاد یک برنامه برای 24 ساعت آینده است. این یک جلسه کوتاه است که هر روز در طول دوره اسپرینت برگزار میشود. به سه سوال به صورت جداگانه پاسخ داده میشود: دیروز چه کار کردم؟ امروز قرار است چه کار کنم؟ به چه کمکی نیاز دارم؟ اسکرام مستر باید سعی کند مشکلات یا موانعی که پیش میآید را به بهترین شکل ممکن حل کند.
بررسی اسپرینت: هدف از بررسی اسپرینت این است که نشان دهد چه کارهایی در رابطه با کالاهای عقب افتاده برای تحویلهای آینده تکمیل شده است. اسپرینت تمام شده بررسی میشود و از قبل باید یک پیشرفت واضح و ملموس در محصول برای ارائه به مشتری وجود داشته باشد.
اسپرینت گذشته نگر: تیم، اهداف اسپرینت تمام شده را بررسی و خوب و بد را یادداشت میکند تا دوباره اشتباهات تکرار نشود. این مرحله در خدمت اجرای بهبودها از نقطه نظر فرآیند توسعه است. هدف از اسپرینت گذشته نگر شناسایی بهبودهای احتمالی فرآیند و ایجاد طرحی برای اجرای آنها در اسپرینت بعدی است.
مصنوعات اسکرام
Scrum Artifacts برای تضمین شفافیت اطلاعات کلیدی در تصمیم گیری طراحی شدهاند.
بک لاگ محصول (PB): بک لاگ محصول لیستی است که هر چیزی را که محصول برای جلب رضایت مشتریان بالقوه نیاز دارد جمع آوری میکند. بک باگ توسط صاحب محصول تهیه میشود و عملکردها با توجه به آنچه که برای کسب و کار بیشتر و کمتر اهمیت دارد اولویت بندی خواهند شد. هدف این است که صاحب محصول به سؤال «چه باید کرد» پاسخ دهد.
بک لاگ اسپرینت (SB): زیرمجموعهای از آیتمهای بک لاگ محصول است که توسط تیم انتخاب میشود تا در طول سرعتی که قرار است روی آن کار کنند انجام دهند. تیم مدت زمان هر اسپرینت را تعیین میکند. معمولاً بک لاگ اسپرینت، بر روی بردهای فیزیکی به نام برد اسکرام نمایش داده میشود تا فرآیند توسعه برای همه افرادی که وارد منطقه توسعه میشوند قابل مشاهده باشد.
Increment: افزایش عبارت است از مجموع تمام وظایف، موارد استفاده، داستانهای کاربر، بک لاگهای محصول و هر عنصری که در طول اسپرینت توسعه یافته و به صورت نرم افزار در اختیار کاربر نهایی قرار میگیرد.
برنامه ریزی در اسکرام
جلسه برنامه ریزی اسپرینت در ابتدای هر اسپرینت برگزار میشود. همه اعضای تیم، یعنی مالک محصول، اسکرام مستر و تمام تیم توسعه در جلسه شرکت میکنند. کل تیم اسکرام باید بفهمد و تعریف کند که چه هدفی باید در آن اسپرینت به دست آید. در این نقطه، تیم توسعه باید یک برنامه کاری برای دستیابی به هدف طراحی کند. این برنامه ریزی باید به شما این امکان را بدهد که ببینید آیا هدف اسپرینت با توجه به مدت زمان تعیین شده برای اسپرینت ها (که 2 تا 4 هفته است) شامل حجم کاری است یا خیر.
پس از آن مشتری نتیجهای را که باید در آن اسپرینت به دست آورد و الزامات محصول قابل تحویل را نشان میدهد. در اینجا شما باید بحثی را انجام دهید که در آن تیم توسعه ارزیابی میکند که چه عناصری از لیست قابل ارائه هستند.
هم اسکرام مستر و هم مالک محصول باید برای روشن کردن هر جنبهای از الزامات همکاری کنند. در نهایت، تیم توسعه باید توضیح دهد که چگونه کار تیم را برای دستیابی به هدف اسپرینت سازماندهی خواهد کرد.