اسکرام یک چارچوب چابک است که با آن میتوانید مسئله های پیچیده را حل نمایید. مسئله پیچیده به مواردی گفته می شود، دانش ما نسبت به مسئله ناقص است و به مرور این دانش پدیدار خواهد شد. مثلا ترافیک، پیش بینی آب و هوا، یا ساختن واکسن کرونا.

کاربرد اسکرام کجاست؟

چرا توسعه نرم افزار در این رده “پیچیده” دسته بندی می شود؟ شاید دیده باشید ما با یک سری نیازمندی ابتدایی پروژه را شروع می‌کنیم، و در ادامه مشتری با دیدن خروجی کار، نظرات جدید یا متفاوتی پیدا میکند. انگار تازه پدیدار می شود که که نیاز اصلی چه بوده است. این پدیداری شاخص اصلی پروژه های پیچیده است.

اسکرام یک چارچوب یا متدلوژی؟ مسئله این است

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

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

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

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

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

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

یکی از پایه های اصلی اسکرام ایجاد شفافیت در تمامی ارکان پروژه است. این باعث می شود که ما انحرافات و کج روی ها را زودتر مشاهده کنیم و سریعتر بر اساس وضعیت و شرایط خودمان تصمیم درست را بگیریم.

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

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

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

اسکرام با استفاده از یک روش چرخشی افزایشی باعث کاهش ریسک و افزایش میزان پیش بینی پذیری می شود.

آیا ما “محصول درستی” می سازیم؟
آیا ما محصول را به “شیوه درستی” میسازیم؟

برخی پروژه ها هستند، جواب این سوالها از اول مشخص هست، پس نگرانی نداریم و فقط می‌سازیم و یکباره تحویل میدهیم. اما برخی پروژه ها هستند، ما در انتها یا اواخر پروژه می‌فهمیم که مشتری اشتباه کرده یا ما.اسکرام در چنین مواردی کاربرد دارد که ما سریعتر و در چرخش های ابتدایی این مسئله برای ما پدیدار شود.تعریف اسکرام ما به اینجا رسیده است که: اسکرام یک چارچوب برای توسعه نرم افزار می باشد که از روش iterative incremental بهره می جوید. اما در تعریف اول مطلبی بود که در این یکی تعریف نیست : “از سری متدهای تفکر Agile”.

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

Agile یا چابک چیست؟

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

پس برای کامل کردن تعریف می توان گفت : اسکرام یک چارچوب  حل مسئله های پیچیده چابک است که از روش چرخشی-افزایشی استفاده می‌کند.

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

(پیاده سازی اسکرام در گوگل)، (اسکرام در مایکروسافت) (تجربه اسکرام در salesforce)

یا مثال ایرانی: بام چگونه روش برنامه‌ریزی خود را تغییر داد؟

بخش دوم – اجزا و نحوه کار اسکرام

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

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

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

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

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

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

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

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

تیم های اسکرام بر خلاف دیگر تیم ها دو ویژگی اساسی دارند :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

در ادامه چه بخوانیم؟

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

توضیحات بیشتر و دریافت کتابچه

در وبلاگ دنیای چابک بیش از ۳۰۰ نوشته کاربردی وجود دارد که می توانید از بخش اسکرام آن شروع کنید.

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

اطلاعات بیشتر در مورد این کتاب

بدنبال دوره آموزشی و گرفتن مدرک اسکرام هم هستم

گروه تلگرامی برای ارتباط با دیگران

برای راحتی ارتباط با دیگر متخصصین چابکی از راههای ارتباطی زیر میتوانید استفاده کنید: