اسکرام (Scrum) یا کانبان (Kanban) یک سوال پرتکرار در بین تیم‌های نرم افزاری است. شما کدام راه‌حل را برای مدیریت فرایند‌ها در تیم چابک خود انتخاب می‌کنید؟ آیا تیم شما چابک است؟ چه معیار‌هایی چابکی تیم شما را ملموس می‌کند؟

اسکرام یا کانبان؟

در این مقاله به مقایسه Scrum و Kanban می‌پردازیم و بدون در نظر گرفتن تعصبات رایج ویژگی‌های هریک از این رویکرد‌ها را بررسی می‌کنیم. هدف نهایی رسیدن به پاسخ این پرسش است:

اسکرام بهتر است یا کانبان؟ آیا نیاز به انتخاب تنها یک مورد است؟

پیش از پرداختن به موضوع اصلی مقاله، ببینیم عبارت پر تکرار چابک به چه معناست.

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

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

لغت نامه دهخدا چابکی را فرز، تند، زبر و زرنگ و چست و چالاک تعریف می‌کند. ولی زمانی که چابک را در تعریف Agile به کار می بریم منظور فرز بودن در هر کاری نیست!

این که شما یک شرکت بازاریابی باشید و به سرعت برای مشتریان راهکار تبلیغاتی ارائه دهید به معنای Agile بودن کسب و کار شما نیست. یا اگر یک سوپرمارکت دارید و پیک‌هایی زبر و زرنگ که در کسری از ثانیه سفارش مشتری را به او می‌رسانید: به شما تبریک می‌گوییم، نقطه تمایز برتری در این بازار دارید ولی Agile نیستید.

اجایل، Agie یا چابک، مجموعه ای از راهکارها برای بهینه کردن فرایند توسعه نرم افزار کارامد است که از سال ۲۰۰۱ در یک بیانیه مختصر به نام بیانیه چابک به صورت رسمی معرفی شد. Agile راهکارهای متفاوتی را برای کارامد کردن کارها معرفی کرد و بسیاری از این رویکردها مانند جلسات ایستاده روزانه یا استفاده از برگه‌های چسبان برای نوشتن کارها و چسباندن آن روی یک تخته، در بسیاری از شرکت‌ها استفاده می‌شوند.

استفاده از این راهکارها به معنای چابکی آن شرکت نیست و صرفا به معنای استفاده از راهکارهای چابک برای به انجام رساندن کارهاست.

بگوییم Agile (چابک) یا متدولوژی چابک؟

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

ولی متدولوژی چیست؟

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

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

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

پس بهترین تعریف برای چابکی شاید به این صورت باشد:

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

متن بیانیه توسعه نرم افزار چابک فارسی را می‌توانید در این جا بخوانید.

پس با این که چابکی خود یک متدولوژی نیست، مجموعه‌ای از متدولوژی‌ها با استفاده از رویکرد چابک برای توسعه نرم افزار به وجود آوردند. در این میان نام‌های Scrum، Kanban، Extreme Programming و Lean Development احتمالا آشنا باشند. که در این مقاله به دلیل محبوبیت نسبتا بیشتر اسکرام و کانبان به این دو می‌پردازیم.

فریمورک مدیریت فرایند Scrum یا اسکرام

اسکرام یک راه چابک برای مدیریت پروژه (توسعه نرم‌افزار) است.

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

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

یک نفر شیشه ها را تمیز کند و پرده ها را باز کند که شسته شوند، فرد دیگری مبلمان را جا به جا کند تا فرش را جمع کنیم که شسته شود و فرد دیگری جارو بزند و طی بکشد….

این برنامه ریزی و تقسیم یک فرایند پیچیده مثل خانه تکانی به بخش‌هایی قابل انجام و قابل تخصیص به چند نفر باعث می‌شود که کار خانه تکانی به صورت منظم و در بازه زمانی کوتاه‌تری انجام شود. همین کار که به طور معمول در زندگی روزمره زیاد آن را انجام می‌دهیم بخشی از فرایند روزمره تیم‌های چابک است.

Scrum، بهینگی را افزایش و هدررفت زمانی پروژه را کاهش می‌دهد. به دلیل شکست کارها به زیرمجموعه‌های کوچک‌تر، توانایی تطبیق تیم با تغییرات پیش‌بینی نشده بیشتر می‌شود و درنتیجه قدرت بهبود پروژه با مرور زمان در کنترل تیم نرم افزاری خواهد بود.

اسکرام بر مبنای تجربه‌گرایی و تفکر ناب ایجاد شد. تجربه‌گرایی تاکیدش بر ایجاد دانش از طریق تجربه و تصمیم گیری بر مبنای شواهد است. و تفکر ناب هدررفت را کاهش می‌دهد و تمرکز خود را بر موارد حیاتی می گذارد.

اسکرام با نگاه تکرارشونده (چرخشی)‌ و افزایشی به تسک‌ها نگاه می‌کند تا ریسک توسعه را کاهش دهد.

منظور چیست؟

باید در نظر بگیریم که ماهیت پروژه‌های نرم افزاری ثابت نیست. مشتری یک اپلیکیشن سفارش آنلاین غذا می‌خواهد، ولی این تمام داستان نیست. در طول اجرای پروژه، نیاز مشتری و یا نیازهای کاربران نهایی تغییر پیدا می‌کند و یک اپلیکیشن سفارش غذا ممکن است به اپلیکیشنی برای رزرو غذا تبدیل شود.

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

دو سوال مطرح می‌شود:

1.  آیا ما محصول درستی را می‌سازیم؟
2. آیا ما محصول را به شیوه درستی می‌سازیم؟

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

اگر اسکرام را با شیوه آبشاری مقایسه کنیم، بهینگی این مدل را برای توسعه بهتر می‌بینیم

نحوه کار اسکرام

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

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

در انتهای هر اسپرینت یک ریلیز وجود دارد که به صورت Incremental (افزایشی) تا انتهای پروژه، محصول را تکمیل می‌کند.

تغییرات لازم در جلسات بازبینی اسپرینت که معمولا روزانه انجام می‌شوند لحاظ می‌شوند.

فریمورک مدیریت جریان کار Kanban، کنبن، کنبان یا کانبان

کنبن یک اصطلاح ژاپنی به معنای تابلوی تصویری یا Visual Board است و از دهه ۱۹۵۰ میلادی در حال استفاده است. ابتدا تویوتا استفاده از سیستم زمان‌بندی کنبن را برای تولیدات خود استفاده کرد و سپس به عنوان متدی در سایر کارها نیز استفاده شد.

متد کانبان یا کنبن چیست؟

اگر با ابزارهایی مانند ترلو کار کرده باشید، تصویر زیر برایتان آشنا است. تقریبا مشابه همان بخش بندی‌هایی که در دفتر‌های رنگی‌رنگی Daily Planner نیز می‌بینید.

کنبن به تیم‌ها ابزاری برای تصویری کردن کار‌هایشان، کاهش کار-در حال-اجرا یا WIP و حرکت سریع از فاز Doing به Done می‌دهد.

هدف کنبان، تقسیم کار به چند مرحله است. حال این مراحل می‌تواند در پروژه‌ها و یا شرکت های متفاوت نام‌های خلاقانه‌ای داشته باشد. ساده ترین تقسیم بندی : Tasks – In progress – Done هستند.

یا ممکن است در یک پروژه نرم افزاری تسک‌ها : Design – Front Dev. – Back Dev – Release باشند.

در هر صورت، kanban برای تیم‌هایی که ورودی کار زیادی با اولویت بندی و لود زمانی متفاوت دارند، بسیار به صرفه است.

مدل کار کانبان یا Kanban

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

برای هر ستون کنبان با توجه به ظرفیت تیم‌ها یک محدودیت در نظر گرفته می‌شود و بر همان اساس کارها از بک لاگ وارد لیست To Do یا Working می‌شود.

زمانی که کار بر روی یک آیتم آغاز می‌شود این کار به ستون (در حال اجرا یا In progress) منتقل می‌شود. که در تصویر زیر ستون In-Progress خود مجموعه ای از ۳ ستون دیگر به نام Working, Waiting و Review است.

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

در هر دو صورت Kanban نیازمند مشخص کردن یک Limit یا محدودیت برای کارها است. یکی از مهم‌ترین وظایف کنبان ایجاد یک سیستم برای منطقی تخصیص دادن کار‌هاست: نمی‌توان بیشتر از لود منطقی کاری را پذیرفت به خصوص اگر توانایی مدیریت تعداد کارها را نداشته باشیم.

به عنوان مثال وقتی تیم فنی شامل چهار دولوپر است، بهتر است بیش از ۸ کار از بک لاگ به ستون In-progress وارد نشود. زمانی که یک کار از این ستون به ستون Done انتقال یافت، تسک دیگری می‌تواند وارد ستون In progress شود.

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

همانند جلسات اسپرینتی، در شرکت‌هایی که متد کنبن را پیاده سازی می‌کنند جلسات کنبن وجود دارد. این جلسات در سطح تیم برگزار می‌شوند به هدف بازبینی کارها و ایجاد یک Feedback-Loop کارامد است. در این جلسات، ظرفیت تیم‌ها و پتانسیل اجرایی افراد بازبینی می‌شود و با بررسی دقیق سرعت تحویل هر تیم، فرایند تخصیصی کارها بهینه می‌شود.

سیستم Kanban امروزی که پیاده‌سازی می‌شود شاید شباهت زیادی به تخته بالا داشته باشد ولی ماهیتی بسیار عمیق تر از این بورد ساده دارد.
فلسفه نهفته در تصویری کردن کارها و انجام طبقه‌بندی شده ‌آن‌ها نه تنها در توسعه نرم‌افزار بلکه در بسیاری فرایندهای دیگر نیز کاربرد دارد.

از سوی دیگر به دلیل ماهیت انطباق پذیری بیشتر کانبان نسبت به اسکرام در هرجایی از این مسیر می‌توان تغییرات پروژه را اعمال کرد…کافیست کارتی از ستون Doing دوباره منتقل به todo شود، مشخصات آن تغییر پیدا کند و دوباره در ستون Doing قرار بگیرد.

اولویت کنبان، بهینه سازی جریان کار و انطباق آن با محدودیت‌های تیم‌ها است. به همین دلیل در تیم‌هایی که اولویت‌های آن‌ها دائما در حال تغییر است، وابسته به محدودیت‌های زمانی نیستند و کار‌ها به صورت سیال و درحال تغییر در تیم تعریف می‌شوند، متد Kanban ارزش افزوده بیشتری برای تیم دارد.

بالاخره کدام؟ کنبان kanban یا اسکرام Scrum؟

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

شاید این دو متد بسیار متفاوت به نظر برسند ولی در تیم‌های چابک لزوم به انتخاب تنها یک گزینه نیست. می‌توانید تارنتینو را انتخاب کنید: هم اسکرام باشید، هم کانبان.

فراموش نکنید که دلیل استفاده از این دو ابزار استفاده از رویکرد چابکی است.  از رویکرد چابکی استفاده می‌کنید تا سرعت عمل توسعه خود را بیشتر کنید و پاسخ‌گویی بهتری در مقابل تغییرات داشته باشید.

اما اگر به دنبال جوابی مشخص هستید شاید پاسخ خود را بتوانید از لیست زیر پیدا کنید:

راهنمایی برای انتخاب بین کنبان و اسکرام:

۱- ماهیت کار تیم شما چیست؟

اگر کارهای شما پیچیده، با ریسک بالا و یا Feature-oriented است: Scrum می‌تواند گزینه بهتری باشد.

اگر کار‌های شما تعریف مشخصی ندارند، در حال تغییر و سیال هستند و بیشتر بر محوریت خدمات قرار دارند: احتمالا Kanban گزینه بهتری است.

۲- اولویت‌های کار در تیم شما چگونه تغییر می‌کنند؟

آیا ماهیت کاری شما در بازه‌های زمانی مشخص ۱ تا ۲ هفته‌ای نمیگنجد و ممکن است تسک‌های جدید با اولویت بالاتر وارد اسکوپ کاری شما شود؟ در این صورت کنبان را انتخاب کنید و تیم‌تان را محدود به بازه‌های زمانی خشک نکنید.

۳- آیا تیم شما ترجیح می‌دهد کارها به زیرمجموعه‌های کوچکتر شکسته شوند تا سرعت بیشتری در به پایان رسیدن تسک ها داشته باشد؟

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

۴- آیا کاری که پیش روی تیم‌ شماست توانایی شکست به زیرمجموعه‌هایی کوچک و هم اندازه (از نظر حجم کار و زمان اجر) دارد؟

در این صورت به سراغ Kanban بروید چرا که یک سربار دیگر به نام تخمین زمان را از فرایند کاری شما حذف می‌کند و به دلیل هم اندازه بودن زیر بخش‌های کار، به صورت اتوماتیک چرخه کاری حفظ می‌شود.

۵- ایا اولویت شما در کار، بهینه کردن پاسخگویی به نیازهای در حال تغییر مشتری است؟

در این حالت چاره‌ای جز استفاده از Kanban ندارید. البته در نظر بگیرید که می‌توانید بورد کنبن را در کنار اسکرام نیز استفاده کنید.

۶- آیا تمرکز شما بر پیش بینی آینده بر اساس شواهد و دیتای موجود و بالا بردن بهره‌وری در پروژه‌های بزرگ است؟

در این صورت بی‌شک به سرغ Scrum بروید. با این‌که بهره‌وری را در هر دو متدولوژی می‌توان به دست آورد ولی به خصوص در تیم‌هایی که در ابتدای کار خود هستند، اسکرام مثل یک کتابچه راهنما است که گام به گام آن‌ها را در مسیر رسیدن به بهره وری راهنمایی می‌کند.

احتمالا بر اساس سوالات بالا متوجه شده‌اید که هرجا صحبت از انعطاف است Kanban مطرح می‌شود و هرجا صحبت به بهره‌وری بیشتر و سرعت می‌رسد، اسکرام به میان می‌آید.

در نهایت هر دو متدولوژی نیازمند پیگیری و پیاده‌سازی اصولی است. استفاده از اسکرام در تیمی که نظم ذاتی ندارد و یا اسکرام مستر پیگیری نداشته باشد خود باعث بی‌نظمی می‌شود و ممکن است سربار پروژه را زیاد کند. و در تیم هایی که انعطاف در آن‌ها به معنای بی‌نظمی نزدیک شده است، استفاده از کنبان به معنای به پایان نرساندن کارها است.

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