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

اسکرام یه جلسه ست که روزانه و معمولاً در اولین ساعت کاری بین یک گروه توسعه‌ی نرم‌افزار برگزار میشه. بچه‌ها میان کارهایی که روز گذشته انجام دادن و روز آینده میخوان انجام بدن رو خیلی سریع میگن و تموم.

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

اول قبل از این که این مقاله را مطالعه کنید حتما حتما حتما این فیلم را ببینید تا متوجه شوید که اسکرام چقدر ساده و جالب است.

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

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

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

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

بک لاگ محصول به منزله قلب اسکرام است و نقطه­ شروع داستان توسعه نرم افزار است. بک لاگ محصول یک لیست اولویت بندی شده از نیاز ها، ویژگی­ها و داستان­های کاربره که  مشتری می­خواهد و با ادبیات بیزنس خود آنها را توصیف می­کند که به آنها، داستان­ها یا آیتم­های بک­لاگ گفته میشه. برای هر داستان مشخصات زیر را ثبت می­کنیم:

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

2-    نام: یک نام کوتاه و توصیف کننده برای داستان. مانند “مشاهده تراکنش های صاحب حساب” . این نام باید برای توسعه دهندگان و صاحب محصول قابل درک باشه.

3-    اهمیت: میزان اهمیت داستان از نظر صاحب محصول. این معیار به صورت عددی است و هر چه بیشتر باشد، نشان دهنده اهمیت بالاتره.

4-    برآورد اولیه: برآورد اولیه تیم از میزان کار مورد نیاز برای انجام داستان نسبت به سایر داستان­ها است. واحد این برآورد story point است که معمولا به میزان کار یک فرد در یک روز (نفر-روز)  اطلاق می­شود. نکته مهم اینه که لازم نیست حتما یک برآورد دقیق برای هر داستان داشته باشید بلکه باید برآورد­ها نسبت به یکدیگر متناسب باشند

5-    چگونگی دمو: یک توصیف کلی از نحوه دمو داستان در جلسه دمو را بیان می­کند که می­تواند شبیه به یک تست ساده باشه، مثلا این کار و آن کار را انجام دهید در این صورت این نتیجه حاصل می­گردد. اگر از شیوه TDD استفاده می­کنید، این توصیف به عنوان کد تست پذیرش شما خواهد بود.

6-    توضیحات: هر اطلاعات اضافی برای شفاف سازی داستان یا ارجاعات به سایر منابع به صورت خلاصه.

در شکل زیر نمونه ای از بک لاگ محصول را مشاهده می­کنید:

جدول بک­لاگ محصول را در یک فایل Excel نگهداری می کنیم و بین اعضای تیم به اشتراک می­گذاریم. معمولا صاحب محصول، مالک این فایل است ولی سایر اعضای تیم می­توانند آن را ویرایش کنند. به همین خاطر این فایل را در مخزن کنترل نسخه[1]  قرار نمی­دهیم بلکه آن را در یک درایو اشتراکی می­گذاریم. این ساده ترین راه برای ویرایش همزمان بدون مشکلات قفل شدن فایل است. به جز این آرتیفکت، بقیه در مخزن کنترل نسخه قرار می­گیرند.

به جای فایل Excel می­توان از روش­های دیگری برای نگهداری بک­لاگ استفاده نمود که برخی از آنها عبارتند از:

1-      استفاده از سیستم رهگیری باگ (مانند نرم افزار Jira). اشکال این روش آن است که معمولا صاحب محصول از کلیک­های زیاد در این نرم افزار خسته می­شود. کار با Excel راحت و سر راست است، زیرا به سادگی می­توان آیتم­ها را رنگی کرد، جابجا نمود و سطر و ستون­های جدیدی اضافه کرد.

2-      استفاده از ابزارهای حمایت از فرایندهای چابک مانند VersionOne, ScrumWorks و XPlanner.

3- و پیشنهاد بنده استفاده از تسکولو

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

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

قبل از اینکه روز برنامه ریزی اسپرینت فرا برسد باید بک­لاگ محصول مرتب و واضح باشد. منظور از مرتب و واضح بودن چیست؟ آیا باید همه آنها به طور کامل تعریف شده باشند؟ همه برآورد­ها درست باشند؟ همه اولویت ها تعیین شده باشند؟ نه، نه و نه. این بدان معنا است که:

1-      بک­لاگ محصول وجود داشته باشد.

2-      فقط یک بک­لاگ محصول و یک صاحب محصول برای هر محصول باشد.

3-      آیتم­های مهم بک­لاگ باید دارای اهمیت متفاوت باشند.

• در واقع اشکالی ندارد اگر آیتم­های کم اهمیت دارای رتبه یکسان باشند زیرا آنها در طول جلسه برنامه ریزی اسپرینت کنار گذاشته می­شوند.
• هر داستانی که صاحب محصول احتمال می­دهد در اسپرینت باشد باید دارای رتبه اهمیت یکتا باشد.
• رتبه اهمیت فقط برای مرتب سازی آیتم­ها بر اساس اهمیت است. یعنی اگر آیتم A دارای اهمیت 20 و آیتم B دارای اهمیت 100 باشد به این معنی است که B از A مهمتر است نه اینکه B پنج برابر مهمتر از A است.
• بهتر است که بین رتبه اهمیت آیتم­ها فاصله بگذارید تا بتوانید آیتم­هایی را بین آنها قرار دهید.

4-      صاحب محصول باید هر داستان را درک کند و علت حضور آنها در بک­لاگ را بداند. معمولا او داستان­ها را اضافه می­کند، اما گاهی اوقات سایر افراد مواردی را اضافه می­کنند تا او اولویت­بندی نماید.

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

جلسه برنامه ریزی اسپرینت یک جلسه بسیار مهم است و شاید مهمترین رویداد در اسکرام باشد. یک جلسه برنامه ریزی بد می­تواند کل اسپرینت را باد دهد.

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

1-      هدف اسپرینت

2-      اعضای تیم (و درصد همکاری آنها اگر 100% نیست.)

3-      بک­لاگ اسپرینت (داستان ­هایی که در اسپرینت باید انجام شوند)

4-      تاریخ دموی اسپرینت

5-      زمان و مکان برگزاری جلسات روزانه اسکرام

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

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

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

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

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

با تشکر از توسعه چابک و تاد