اسکرام‌بان چیست؟ - متدولوژی اجایل فقط اسکرام نیست!

شاید برای بعضی از دوستان جمله‌ی دوم عنوان کمی عجیب به نظر برسه. مگه بجز اسکرام متدولوژی چابک (agile) دیگه‌ای هم وجود داره؟ بله. در واقع متدولوژی چابک رُ می‌شه فقط یک بیانیه‌ی دونست که از این لینک قابل مشاهده‌ست (حتما روی لینک ۱۲ اصل نرم‌افزار چابک کلیک کنین). شاید براتون جالب باشه که قبل از تب اسکرام توی ایران XP متولوژی چابکی بود که به قول معروف توی بورس بوده.

خب یه سوال دیگه‌ای که ممکنه پیش بیاد اینه که مگه اسکرام چشه؟ این همه تیم در دنیا دارن ازش استفاده می‌کنند، پس حتما بهترین متدولوژیه دیگه! این جمله به نظرم خطرناک‌ترین جمله‌ی دنیاست :). شرایط شما ممکنه با کل دنیا فرق کنه، پس باید دلایل استفاده از اون توسط کل دنیا رُ ببینین و بعد با بررسی شرایط خودتون بهترین کار رُ بکنین؛ به همین دلیله که ما توی تیم بیستون تا حالا ۳ متدولوژی مختلف (اسکرام، کنبان و اسکرام‌بان) رُ تست کردیم و الآن به اسکرام‌بان رسیدیم.

یکی از بزرگ‌ترین فواید استفاده از اسکرام‌بان برای ما این بوده که دیگه محدود به اسپرینت‌های ۲ هفته‌ای نیستیم و پس از بستن اسپرینت، تسک‌های فوری لازم نیست برای ۲ هفته منتظر بمانند یا اسپرینت را برهم بزنند. بدلیل پویایی فضایی که در آن کار می‌کنیم، این یکی از بزرگ‌ترین موهبت‌های این متدولوژی برایمان بوده است.

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

اول کار تیم محصول شروع به پر کردن ستونی به نام backlog می‌کنن و اون‌طوری که خودشون صلاح می‌دونن اولویت تسک‌ها رُ مشخص می‌کنن. البته مدیرفنی هم در این جلسات شرکت می‌کند تا به مدیران محصول دیدی در مورد میزان زمان تقریبی برای هر تسک بدهد تا اولویت‌بندی دقیق‌تری انجام شود و در صورت لزوم بعضی تسک‌ها بشکند. جلسات backlog refinement بطور منظم بنا به صلاح‌دید تیم محصول انجام می‌شود.

تیم فنی در جلسات planning تسک‌های بک‌لاگ رُ به ترتیب به ستون بعدی که ستون آماده (Ready) نام دارد منتقل می‌کنند. در این مرحله تمام تسک‌ها به تیم فنی یا مسئول تسک تفهیم می‌شود و در صورت لزوم شکستی در تسک انجام داده می‌شود. در این مرحله پس از این‌که تسک‌ها به افرادی از تیم فنی محول شد، افراد شرکت‌کننده در هر تسک ددلاینی برای تسک تعیین می‌کنند تا تیم محصول بداند در چه زمانی می‌تواند انتظار فیچر مورد نظر رُ بصورت دیپلوی شده داشته باشد. جلسات planning در دو صورت برگزار می‌شوند: ۱. وقتی ستون ready از یک حدی کم‌تر تسک داشته باشد. ۲. وقتی یک تسک با الویت خیلی بالا توسط تیم محصول پوش شود.

ستون بعدی جریان، ستون DEV یا کار در حال انجام است. زمانی که افراد در حال کار کردن روی یک تسک هستند کارت مورد نظر را به این ستون منتقل می‌کنند. در هر کارت می‌توان چک‌لیست‌هایی تعریف کرد و از آن به عنوان مکانی برای ذخیره‌ی sub-taskها استفاده کرد.

وقتی کار روی یک تسک تمام می‌شود، تسک به ستون code review منتقل می‌شود. پس از این‌که کد توسط همکاران فرد (حداقل یک فرد) بررسی شد، تسک به ستون بعدی یعنی functionality test منتقل می‌شود. در این ستون تستی در مورد این‌که آیا کد واقعا فیچر تسک را انجام می‌دهد یا خیر تست می‌شود و در نهایت به ستون done منتقل می‌شود.