اسکرام به زبان ساده

اسکرام چی هست و  به چه درد ما می خوره؟

خب! مثل تمام مستند‌های ایرانی همون اول میریم سراغ معنی لغوی اسکرام (Scrum): معنی لغوی نداره و خیالتون راحت، اما اصطلاحاً شروع دوباره تو بازی راگبی رو اسکرام میگن؛ یعنی هر وقت به هر دلیلی، مثل خطا یا بیرون افتادن توپ بازی متوقف بشه، با اسکرام بازی شروع میشه. شاید دیده باشید بازیکن ها دور هم جمع میشن، سرشونو میگیرن پایین. اسکرام یک فرایند مکرر و رو به جلوئه که شاخه‌ای از سیستم توسعه‌ی نرم‌افزار بصورت چابک (Agile) حساب میشه. اگه اسکرام رو گوگل کنیم، یه چیزی تو همین مایه‌ها رو برامون میاره، اما قطعاً من نمیخوام همین کارو برای شما تکرار کنم. خب! یه مسأله بنام اسکرام داشتیم یه مسأله‌ی جدید اضافه شد به‌نام سیستم چابک. همین روش رو ادامه بدیم میرسیم به شرکت‌های چابک، بعدشم چندتا تعریف دیگه و هرکدوم از اینا یه تاریخچه‌ای دارن و یکی دو نفر که احتمال قریب به یقین ژاپنی هم بودن رو معرفی میکنیم که لااقل شما حوصله خوندن همشو ندارید.
اسکرام یه جلسه ست که روزانه و معمولاً در اولین ساعت کاری بین یک گروه توسعه‌ی نرم‌افزار برگزار میشه. بچه‌ها میان کارهایی که روز گذشته انجام دادن و روز آینده میخوان انجام بدن رو خیلی سریع میگن و تموم.

خب چرا روزانه؟ صبر میکردیم تا کار به یه جای خوب و افتخارآمیز برسه تا بشه به بقیه هم توضیح داد؟

اینو همین اول بگم که نمیدونید که گزارش روزانه چه تأثیر شگرفی روی بهبود فعالیت ما داره. امتحانش مجانیه. کارهای روزانه‌ی خونه مثل مطالعه، دیدن فیلم و غیره رو گزارش‌گیری کنید، چند روز صبر کنید و این کار رو ادامه بدید. خود به خود ذهن شروع به مقایسه‌ی عملکرد روزها با هم میکنه و آدمی که وقتش کمه سعی میکنه این کارها رو بهتر و سریعتر انجام بده. (تجربه شخصی)

اینا بخش‌های اصلی‌ای هستند که در ۸ مرحله توضیح داده شده و اینجا هر مرحله رو دقیقتر توضیح میدم که اون دایره بالائی هم که داخلش ۱۵ دقیقه زده خود اسکرام هست. از توی این عکس مشخصه که از مجموع اسکرام‌ها یک اسپرینت (Sprint) بوجود میاد و از مجموع این اسپرینت‌ها هم کل فرایند توسعه‌ی نرم‌افزار یا بازی حاصل میشه. اسپرینت در واقع یک محدوده‌ی زمانی با هدف یا اهداف کوتاه مدت مشخصه.
حالا یک سناریو تعیین میکنیم و این سناریو رو از طریق اسکرام پیش میبریم. مثلاً میخوایم یه فروشگاه اینترنتی بسازیم و یه کارفرما یا صاحب سمج داریم که روزی چهار بار زنگ میزنه و میگه چه خبر و چهار روز یک بار هم یه چیز جدید به ذهنش میرسه و یه بخش کار رو عوض میکنه.

مرحله‌ی اول: تهیه‌ی Product Backlog

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

مرحله‌ی دوم: فازبندی

اولاً اینکه واسه این جور مشتری‌ها باید پروژه رو بصورت فاز به فاز، تحویل داد (این یکی از تعاریف سیستم چابکه: Early Delivery). پس باید کل کار رو به چند فاز تقسیم کنیم تا تحویل هم به همین صورت انجام بشه. تقسیم‌بندی به دو صورت رفتاری یا کیفی انجام میشه، به طور مثال، در پیاده‌سازی فروشگاه میتونیم فروشگاه رو به فازهای سیستم کاربران، بخش مالی و حسابداری، بخش انبارداری و زنجیره‌ی تأمین، بخش پنل اپراتوری و مدیریت و بخش ویترین فروشگاه تقسیم‌بندی کرد، یا میتونیم همه‌ی این بخش‌ها رو با هم شروع کنیم، اما با کیفیت و سطح خدمات پایینتر. اگه کار برای خودتون هست یا مشتری سمج ندارید، من روش اول رو پیشنهاد میکنم. دوباره‌کاری و تغییرات در روش اول خیلی کمتره اما فکر نکنید که میتونید با ارائه‌ی یک سیستم کاربری خالی صاخب کار سمج رو به ادامه‌ی کار دلگرم کنید.

مرحله‌ی سوم: جلسه‌ی برنامه‌ریزی اسپرینت

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

در این جلسه با حضور اعضای تیم، وظایف مشخص میشه و زمان‌بندی کل اسپرینت به دست میاد. توجه به قوانین زمانی بسیار مهمه. معمولاً وظائف بسیار خرد میشن و اونا رو از یک تا هشت ساعت زمان‌دهی میکنیم. بعضی از روش‌ها زمان‌دهی باینری رو توصیه میکنن، یعنی فقط مجاز به انتخاب یکی از زمان‌های ۱، ۲،‌ ۴ یا ۸ ساعت هستیم. اما آنچه مهمه اینه که سعی بشه که بیشتر از ۸ ساعت (یعنی یک روز کاری) نشه تا پیگیری کارها آسونتر و به‌روزتر باشه؛ البته باز هم بستگی به نوع پروژه داره.

در جلسه‌ی برنامه‌ریزی اسپرینت یا بعد از اون، برگه ها یا برچسب‌هایی از کار بچه‌ها، با توجه به قوانین زمانی، توسط خودشون تهیه میشه، یعنی حاوی نام کارهاشون هست و زمانی که دارن بهش اختصاص میدن، که البته بهتره جا برای اصلاح و کم کردن زمان برای کارهای طولانی‌تر در طول اسپرینت داشته باشن. بهتره که هر فرد در هر تیم یک رنگ رو انتخاب کنه تا تشخیص اون برای همه میسر باشه. یک تخته اسکرام (Scrum Board) رو به سه بخش در صف انجام(To-Do)، در حال انجام(Doing) و انجام شده(Done) تقسیم می کنیم و برگ ها رو ابتدا در بخش در صف انجام قرار میدیم.

زمان هر جلسه‌ی اسپرینت معمولاً متناسب با زمان خود اسپرینته که به ازای هر هفته دو ساعت در نظر گرفته میشه. یعنی اگه اسپرینت ما ۲ هفته ای باشه، ۴ ساعت زمان جلسه ست. معمولاً اسپرینت‌ها کمتر از ۲ هفته و بیشتر از یک ماه در نظر گرفته نمیشن.

مرحله‌ی چهارم: تهیه‌ی سند اسپرینت (Sprint Backlog)

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

مرحله‌ی پنجم: اجرای اسکرام

بچه‌ها هر روز دور هم جمع میشن و به شرح مختصر فعالیت‌های گذشته و جاری میپردازن. بچه ها برگ هایی که مربوط به کار خودشون هست رو جابجا می کنن. یعنی برگ کارهایی امروز می خواهیم انجام بدیم رو از بخش To-Do به Doing و برگ کارهایی که دیروز انجام شده رو از Doing به Done انتثال میدن. اینجا چند تا نکته خیلی مهمه.

1. اینجا محل ذکر عنوان کاره که نیازی به توضیح نیست. قرار نیست توضیح بدیم که چرا کارمون تموم نشده و از مشکلات یا نواقص حرف بزنیم.
2. همه موقع جلسه ایستاده‌ن و وقتی داریم گزارش میدیم باید مخاطب ما هم‌تیمی‌های ما باشن نه مدیر پروژه یا مسئول اسکرام (Scrum Master)
3. سعی کنیم ارائه‌ی گزارش خیلی جدی، دقیق و با اطلاعات درست همراه باشه. اگه کاری رو تموم نکردیم، کتمان کنیم و فکر کنیم که این کار رو روز بعد تکمیل میکنیم و کسی هم متوجه نمیشه. اولین کسی که ضربه‌ی این اشتباه رو می خوره خودمون هستیم. اسکرام برای بهبود و ارتقای سطح کیفی کار ماست و ارائه‌ی اطلاعات غلط میتونه برای ما و تیم بسیار مخرب باشه.

همون طور که قبلاً ذکر شد، زمان جلسه حداکثر ۱۵ دقیقه ست، که البته بسته به تعداد افراد تیم و نوع پروژه قابل تغییره. در پایان جلسه مسئول اسکرام میتونه یک گزارش کلی از وضعیت و مسائل موجود ارائه کنه.

TOD Scrum Board

 مرحله‌ی ششم: تحویل اسپرینت

در این مرحله بخشی از فاز یا یک فاز از پروژه رو تحویل میدیم، این کار رو اصطلاحاً تحویل افزایشی و فازی پروژه مینامیم.

مرحله‌ی هفتم: بررسی اسپرینت

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

مرحله‌ی هشتم: بازنگری اسپرینت (Sprint Retrospective)

حالا دیگه وقت تصمیم‌گیریه! رفع نقاط ضعف و بهبود نقاط قوت، تصمیم‌گیری در مورد بهبود عملکرد افراد، ارتباطات، فرآیندها و توسعه‌ی ابزارهای مورد نیاز و تعیین برنامه‌ای برای اجرای این تصمیمات در این جلسه انجام میشه. زمان این جلسه هم کمتر از جلسه‌ی بررسیه و معمولاً برای یک اسپرینت ۲ هفته‌ای ۳ ساعت وقت گذاشته میشه.

اینجا اسپرینت ما بسته شده و باید یک اسپرینت جدید رو شروع کنیم پس برمیگردیم به مرحله‌ی سوم و این تناوب تا اتمام پروژه (و حتی برای همیشه و در زمان نگهداری یک پروژه) ادامه میدیم.