اسکرامبان مدل کاری است که اخیراً رایج شده است و عموماً به ترکیب اسکرام و کانبان گفته می‌شود. در این اپیزود با ارد سمسارزاده، مدرس رسمی کانبان، در مورد خاستگاه این مدل کاری صحبت کردیم و به ناچار فلسفه پشت اسکرام و کانبان را نیز بررسی کردیم تا ببینیم این دو از چه جنبه هایی در راستای هم و چه جنبه هایی مغایر با هم هستند.
آیا شما هم از اسکرامبان استفاده می‌کنید؟ برای شما از چه جنبه‌هایی مفید بوده است؟
مهمان: اُرُد سمسارزاده، مدرس رسمی کانبان از استرالیا
اجرا: پدرام کشاورزی، اجایل کوچ و اسکرام مستر
تدوین: پانته‌آ شهریاری
طراح کاور: سید محمدحسین بطحایی
اسپانسر: بوم گردی نارتی‌تی
برای دیدن ویدئو کوری لاداس در مورد اسکرامبان اینجا را کلیک کنید.
اجایل گپ را می‌توانید از طریق شبکه‌های اجتماعی لینکدین، اینستاگرام و تلگرام دنبال کنید
سلام به همه‌ی شنوندگان عزیز. من پدرام کشاورزی هستم و شما در حال شنیدن یکی دیگر از قسمت‌های پادکست «اجایل‌گپ» هستید. امروز قرار است دوباره به سراغ یکی از دوستان آشنا برویم و درباره‌ی موضوعی گفت‌وگو کنیم که هم طرفداران خاص خود را دارد و هم مخالفانی جدی. من بسیار خوشحالم که بار دیگر فرصتی برای این گفت‌وگو فراهم شده است.
موضوع بحث امروز ما، مفهومی نسبتاً جدید در حوزه‌ی چابکی است که با عنوان Scrum-Ban (اسکرام‌بَن) شناخته می‌شود. پرسش اصلی این است که اسکرام‌بَن دقیقاً چیست، از کجا آمده و آیا واقعاً می‌تواند برای ما مفید و کاربردی باشد یا خیر.
با گذشت زمان، بازار این شرکت بزرگ‌تر شد و حجم کارهای آن‌ها نیز افزایش یافت. در نتیجه، اعضای تیم در طول اسپرینت‌ها با موانع زیادی مواجه می‌شدند. دلیل اصلی این مسئله آن بود که بازی‌هایی که طراحی می‌کردند باید توسط یک تیم خارجی تحت فرآیند کنترل کیفیت (QA) بررسی می‌شد تا اطمینان حاصل گردد که این محصولات با استانداردهای ایالات متحده برای بیماران آلزایمری مطابقت دارند. همین امر موجب می‌شد کارها در تیم به تعویق بیفتد و اغلب در پایان اسپرینت کامل نشود.
برای رفع این مشکل، تیم اقدام به افزایش طول اسپرینت‌ها کرد یا تلاش نمود کارها را خردتر کند تا در بازه‌های زمانی کوتاه‌تر قابل انجام باشند. با این حال، همچنان در تحویل به‌موقع دچار مشکل می‌شدند. علاوه بر آن، ارزش خروجی برخی از فعالیت‌ها چندان بالا نبود و تخمین‌زنی (Estimation) نیز برایشان به یک چالش جدی تبدیل شده بود؛ زیرا زمان زیادی صرف برآوردها می‌شد بی‌آنکه نتیجه‌ی مطلوب حاصل شود.
در این شرایط، خانم جنیس ری تصمیم گرفت فردی متخصص را دعوت کند. او از کوری لاداس (Corey Ladas)، که در آن زمان به‌عنوان مربی فرآیند (Process Coach) در مایکروسافت فعالیت داشت، درخواست همکاری نمود. لاداس پیش‌تر تجربه‌ی بهینه‌سازی فرآیندهای کاری در مایکروسافت را داشت. در همین دوره، جنیس همچنین مقالات و نوشته‌های دیوید اندرسون و سایر منابع مرتبط با کانبان را مطالعه کرد.
در آن زمان، یعنی حدود سال ۲۰۰۹، اسکرام بسیار رایج بود و تقریباً به‌عنوان روش غالب در بسیاری از سازمان‌ها به‌کار گرفته می‌شد. با این حال، در شرکت مذکور، با وجود آنکه از مشاوران متعددی دعوت می‌شد، همگی نظر مشابهی داشتند: «مشکل از اسکرام نیست، بلکه شما در اجرای آن ضعف دارید.» این موضوع سرانجام باعث شد مدیر شرکت بگوید: «اگر اسکرام برای ما کارآمد نیست، باید راه دیگری پیدا کنیم.»
به همین دلیل تصمیم گرفتند تغییراتی در رویکرد خود ایجاد کنند. جنیس ابتدا تصور می‌کرد اگر به تیم بگوید قصد دارند تخمین‌زنی را کنار بگذارند، اسپرینت‌ها را حذف کنند و به‌جای آن محدودیت کار در جریان (WIP Limit) داشته باشند، همه با استقبال مواجه می‌شود. اما برعکس، اعضای تیم به دلیل عادت به اسکرام و استفاده‌ی چندساله از آن، مقاومت نشان دادند و این تغییر را نپذیرفتند.
از همین رو، جنیس تغییرات را تدریجی آغاز کرد. برای نمونه، ابتدا از میزان جزئی‌نگری در تخمین‌زنی‌ها کاست، سپس به‌جای اسپرینت‌های دوهفته‌ای، چرخه‌های کوتاه‌تر هفتگی تعریف کرد. به مرور زمان، این تغییرات گسترش یافت و تیم از اجرای کامل اسکرام فاصله گرفت و کم‌کم به سمت کانبان حرکت کرد.
در سال ۲۰۱۴، کوری لاداس این فرآیند را به‌طور رسمی نام‌گذاری کرد و گفت: حرکت تدریجی یک تیم از اسکرام به سمت کانبان، همان چیزی است که ما آن را «اسکرام‌بَن (Scrumban)» می‌نامیم.
لاداس تأکید کرد که اسکرام‌بَن یک فریم‌ورک مستقل و از پیش تعریف‌شده نیست، بلکه یک مسیر انتقال است. این انتقال به‌صورت تدریجی و متناسب با نیاز تیم‌ها صورت می‌گیرد و با فلسفه‌ی کانبان نیز هماهنگی دارد؛ زیرا کانبان بر اصل «شروع از جایی که هستید» استوار است و تغییرات را به‌مرور و مرحله‌به‌مرحله اعمال می‌کند.
آنچه کوری لاداس تأکید می‌کند این است که اسکرام‌بَن (Scrumban) صرفاً یک مقصد نهایی نیست، بلکه یک مسیر تکاملی (Evolutionary Approach) است. به بیان دیگر، وقتی تیمی در حال اجرای اسکرام است و با محدودیت‌ها یا ناکارآمدی‌هایی مواجه می‌شود، می‌تواند به‌تدریج از تکنیک‌ها و اصول کانبان بهره بگیرد تا مشکلات را رفع کند. این دوره‌ی گذار همان چیزی است که اسکرام‌بَن نامیده می‌شود.
لاداس توضیح می‌دهد که هدف تیم‌ها «ماندن در اسکرام‌بَن» نیست؛ چرا که اسکرام‌بَن خود مقصد نهایی به شمار نمی‌آید. مقصد واقعی همان سازگاری کامل با کانبان یا یافتن چارچوبی است که برای شرایط خاص تیم بیشترین کارآمدی را داشته باشد. بنابراین، اگر تیمی در اسکرام موفق عمل می‌کند، دلیلی برای افزودن محدودیت کار در جریان (WIP Limit) یا استفاده از سایر ابزارهای کانبان وجود ندارد. اما اگر اسکرام پاسخ‌گوی شرایط نباشد، آن‌گاه بهره‌گیری از این ابزارها می‌تواند تیم را به سمت یک مدل بهینه‌تر سوق دهد.
در سال‌های اخیر، برخی ابزارهای نرم‌افزاری مدیریت پروژه، مانند جیرا (Jira)، امکاناتی برای تعریف بوردهای کانبان، اعمال WIP Limit، و ترکیب برخی قابلیت‌ها با اسکرام فراهم کرده‌اند. این موضوع ناخودآگاه موجب شده تا بسیاری تصور کنند اسکرام‌بَن یک چارچوب مشخص و رسمی است، در حالی که در اصل چنین نیست.
همچنین برخی نهادهای آموزشی و استانداردگذاری تلاش کرده‌اند برای اسکرام‌بَن مدارک و گواهینامه‌هایی عرضه کنند. این روند باعث ایجاد سوء‌تفاهم در جامعه‌ی چابک شده است؛ زیرا بسیاری می‌پندارند اسکرام‌بَن یک «فریم‌ورک ترکیبی» است که به‌طور رسمی طراحی و استانداردسازی شده است، حال آنکه در واقعیت، اسکرام‌بَن تنها یک رویکرد گذار و تکاملی است.
واقعیت این است که اسکرام طراحی شده تا در یک «حوزه‌ی فعالیت (Context)» خاص، با شرایطی مشخص، کارآمد باشد. اما ایجاد آن شرایط همیشه ممکن یا به‌صرفه نیست. در طی بیش از ۲۵ سال استفاده از اسکرام، هنوز بخش قابل توجهی از تیم‌ها نتوانسته‌اند آن شرایط را فراهم کنند و به همین دلیل است که توجه به روش‌های جایگزین و تکاملی مانند کانبان یا اسکرام‌بَن بیش از پیش ضرورت پیدا کرده است.
می‌توان اسکرام را همانند یک ابزار یا وسیله در نظر گرفت؛ ابزاری که در شرایطی خاص بسیار کارآمد است، اما نمی‌توان آن را بهترین گزینه برای تمام موقعیت‌ها دانست. همان‌طور که خودروی فرمول یک در پیست بهترین عملکرد را دارد، اما برای سفر در جاده‌های ناهموار باید از یک خودروی آفرود استفاده کرد، اسکرام نیز تنها در حوزه‌ی فعالیت مناسب خود بهترین نتیجه را خواهد داد. بنابراین، انتخاب ابزار و چارچوب باید بر اساس شرایط و نیاز واقعی تیم و سازمان صورت گیرد، نه صرفاً بر اساس شهرت یا توصیه‌های عمومی.
در سال‌های اخیر، بسیاری از تیم‌ها دیگر حتی از واژه‌ی «اسکرام» استفاده نمی‌کنند و نام‌های دیگری همچون اسکواد (Squad) یا اسکرام ارگ (Scrum Org) را به‌کار می‌برند. این تغییر نشان می‌دهد که رویکردهای جدیدی در حال شکل‌گیری است و تیم‌ها با آزمون و خطا در پی یافتن روش‌های متناسب‌تر با شرایط خود هستند. در این میان، ترکیب برخی اصول اجرایی (Practices) کانبان با اسکرام می‌تواند در کوتاه‌مدت مزایایی به همراه داشته باشد؛ برای مثال، استفاده از محدودیت کار در جریان (WIP Limit) ممکن است به تیم کمک کند متوجه شود که اعضا کارهای نیمه‌تمام زیادی را آغاز کرده‌اند یا بیش از توان خود تعهد پذیرفته‌اند.
با این حال، این سودمندی غالباً موقتی است. زیرا کانبان و اسکرام از اساس بر دو فلسفه‌ی بنیادین متفاوت استوارند. کانبان بر جریان کار (Flow of Work) تمرکز دارد؛ بدین معنا که نیاز مشتری وارد سیستم می‌شود و کار در طول زنجیره‌ای از فعالیت‌ها – مانند تحلیل، طراحی، توسعه و آزمون – به‌صورت پیوسته جریان پیدا می‌کند. در این رویکرد، هر مرحله به‌اندازه‌ی ظرفیت واقعی خود کار دریافت می‌کند و هیچ بخشی اجازه ندارد بیش از توان خود خروجی تولید کند. این همان جایی است که محدودیت کار در جریان معنا پیدا می‌کند و موجب هماهنگی کل سیستم می‌شود.
در مقابل، اسکرام رویکردی بر مبنای تکرارهای زمانی (Timeboxed Iterations) دارد و تمرکز اصلی آن بر بازرسی، انطباق و ایجاد محصول به‌صورت افزایشی در بازه‌های زمانی مشخص است. به همین دلیل، هرچند می‌توان برخی از تکنیک‌های کانبان را موقتاً در اسکرام به‌کار گرفت، اما در بلندمدت یا باید شرایط مناسب اسکرام به‌خوبی ایجاد شود یا تیم‌ها به‌سمت پذیرش کامل کانبان حرکت کنند.
به‌بیان دیگر، اسکرام‌بَن (Scrumban) نباید مقصد نهایی تلقی شود، بلکه تنها یک مسیر گذار است. این مسیر به تیم‌ها کمک می‌کند زمانی که اسکرام به‌تنهایی پاسخ‌گو نیست، به‌تدریج اصول کانبان را وارد کار کنند و در نهایت چارچوبی را برگزینند که با شرایط واقعی‌شان بیشترین همخوانی را دارد.
بنابراین، در رویکرد کانبان (Kanban) تمرکز اصلی بر روی جریان کار (Workflow) است. نخستین گام آن است که کار و جریان حرکت آن به‌درستی طراحی و روی برد (Board) بازنمایی شود تا سیگنال‌ها به‌وضوح قابل مشاهده باشند. سپس، معیارهایی اندازه‌گیری می‌شوند؛ از جمله زمان انجام کار (Lead Time) که نشان می‌دهد از لحظه ورود یک درخواست تا زمان تحویل به مشتری چه مدتی طول می‌کشد.
کانبان دو مرحله‌ی کلیدی برای افزایش چابکی (Agility) تعریف می‌کند:
پیش‌بینی‌پذیر کردن Lead Time: تیم باید بتواند به‌صورت شفاف پیش‌بینی کند که چه زمانی یک کار وارد سیستم می‌شود و چه زمانی خروجی خواهد داشت.
بهینه‌سازی و کاهش Lead Time: پس از پیش‌بینی‌پذیری، تلاش می‌شود این زمان کاهش یابد تا ارزش سریع‌تر به مشتری تحویل شود. هرچه Lead Time کوتاه‌تر باشد، میزان چابکی بیشتر خواهد بود.
برای این منظور ابزارهایی چون محدودیت کار در جریان (WIP Limit) به‌کار گرفته می‌شود. این محدودیت باعث می‌شود تمرکز تیم بر روی اتمام کارهای جاری باشد، از جابه‌جایی مکرر بین کارها جلوگیری شود و در نتیجه، تحویل کار به مشتری سریع‌تر انجام گیرد.
در مقابل، اسکرام (Scrum) نیز هدفش دستیابی به چابکی است، اما از رویکردی دیگر استفاده می‌کند. اسکرام بر پایه‌ی تکرارهای زمانی (Timeboxes) بنا شده است. در این روش، تیم یک بازه‌ی زمانی مشخص – معمولاً بین یک تا چهار هفته – تعریف می‌کند که در آن باید تعهدات خود را به مشتری تحویل دهد. این بازه‌ی زمانی همان اسپرینت (Sprint) است که می‌توان آن را نوعی Lead Time از پیش تعیین‌شده دانست.
برای رسیدن به این هدف، اسکرام تیمی چندمهارته (Cross-functional) تشکیل می‌دهد که تمامی مهارت‌های لازم برای تحویل محصول را داراست. سپس تأکید می‌کند که کارها باید به اندازه‌ای کوچک شوند تا در همان تایم‌باکس تعیین‌شده تکمیل گردند. در این چارچوب، روش انجام کار درون اسپرینت اهمیت کمتری دارد؛ آنچه اهمیت دارد نتیجه‌ی قابل تحویل در پایان اسپرینت است.
به این ترتیب، هرچند هر دو چارچوب به دنبال افزایش چابکی هستند، اما مسیرهای متفاوتی را انتخاب می‌کنند:
کانبان از طریق مدیریت جریان کار و بهینه‌سازی Lead Time.
اسکرام از طریق زمان‌بندی‌های مشخص و تیم‌های خودگردان در بازه‌های کوتاه.
یکی از تفاوت‌های بنیادین بین اسکرام (Scrum) و کانبان (Kanban) در نحوه‌ی مدیریت کارها و تغییرات است.
در اسکرام، چرخه‌ی کار به‌صورت وقفه‌دار (Stop–Start) پیش می‌رود. در ابتدای هر اسپرینت، تیم مجموعه‌ای از کارها را انتخاب کرده و به انجام آن‌ها متعهد می‌شود. سپس در طول اسپرینت بر همان کارها تمرکز می‌کند و در پایان بازه‌ی زمانی – معمولاً دو هفته – همه‌چیز متوقف می‌شود. پس از بازبینی (Review) و مرور (Retrospective)، تیم دوباره کارهای جدید را برای اسپرینت بعدی انتخاب می‌کند. این یعنی اسکرام به‌طور ذاتی بر پایه‌ی تکرارهای زمانی کوتاه و هدف‌گذاری مشخص بنا شده است.
در مقابل، کانبان مانند رودخانه‌ای پیوسته عمل می‌کند. جریان کار همواره در حرکت است و هیچ سدی در برابر ورود یا خروج کارها قرار داده نمی‌شود. هر زمان که تیم ظرفیت داشته باشد، کار جدیدی وارد سیستم می‌شود؛ و اگر ظرفیت وجود نداشته باشد، کار در صف می‌ماند. این پیوستگی باعث می‌شود که تمرکز بر بهینه‌سازی جریان (Flow Optimization) و کاهش زمان انجام کار (Lead Time) باشد، نه بر تقسیم کار به بازه‌های زمانی ثابت.
تفاوت مهم دیگر در مدیریت تغییرات (Change Management) است:
اسکرام انتظار دارد تیم از همان ابتدا قواعد مشخص چارچوب را بپذیرد و محیطی متناسب با آن ایجاد شود.
کانبان برعکس، تغییرات را به‌صورت تدریجی و تکاملی (Evolutionary Change) اعمال می‌کند. این روش می‌گوید: «کارهایی را که اکنون انجام می‌دهید ادامه دهید، اما بیایید آن‌ها را گام‌به‌گام بهبود دهیم.»
به همین دلیل است که ترکیب این دو چارچوب در قالب مفهومی چون «اسکرامبان (Scrumban)» اغلب منجر به ابهام و سردرگمی می‌شود. چراکه بنیادهای آن‌ها – یکی مبتنی بر تکرارهای زمان‌بندی‌شده و دیگری بر جریان مداوم – با هم همخوانی کامل ندارند. هرچند ممکن است استفاده از برخی اصول کانبان، مانند محدودیت کار در جریان (WIP Limit)، در یک تیم اسکرام موقتاً سودمند باشد، اما در درازمدت معمولاً تیم یا به سمت اجرای کامل اسکرام می‌رود یا به سمت کانبان.
یکی از اصول اساسی کانبان (Kanban) این است که هیچ نقش تثبیت‌شده و از پیش‌تعریف‌شده‌ای برای هدایت تغییرات در تیم وجود ندارد. برخلاف اسکرام (Scrum) که نقشی رسمی تحت عنوان اسکرام‌مستر (Scrum Master) تعریف می‌کند تا به‌عنوان «رهبر خدمت‌گزار» (Servant Leader) عمل کرده و شرایط لازم برای اجرای چارچوب را فراهم آورد، کانبان بر این باور است که رهبری می‌تواند از هر نقطه‌ای در سازمان ظهور کند.
در واقع، کانبان همه‌ی اعضای تیم را به‌عنوان «عاملان تغییر» تشویق می‌کند. هر فرد – چه توسعه‌دهنده، چه مدیر پروژه و چه هر نقش دیگری – می‌تواند آغازگر یک بهبود باشد. این بهبودها به‌صورت کوچک و تدریجی (Evolutionary Change) معرفی می‌شوند تا مقاومت در برابر تغییر به حداقل برسد.
با این حال، در عمل معمولاً در مراحل ابتدایی نیاز است فرد یا افرادی نقش تسهیل‌کننده تغییر را ایفا کنند. این فرد می‌تواند:
یک اسکرام‌مستر باشد که تیم را از اسکرام به کانبان هدایت می‌کند (در مسیر موسوم به Scrumban)،
یک مدیر پروژه یا رهبر تیم باشد که ایده‌های جدید را معرفی و پیگیری می‌کند،
یا حتی یک توسعه‌دهنده که علاقه‌مند به بهبود فرایندها است و با پیشنهادهای کوچک، جریان کار تیم را هدایت می‌کند.
در کانبان، برخلاف اسکرام، نقش‌ها ثابت و الزام‌آور نیستند؛ بلکه ارزش‌ها اهمیت دارند. از جمله‌ی این ارزش‌ها می‌توان به شفافیت (Transparency)، تمرکز بر جریان (Flow)، و توانمندسازی جمعی برای ایجاد تغییر اشاره کرد. به همین دلیل است که کانبان اغلب به‌عنوان یک رویکرد «فراگیر و بدون نقش رسمی» شناخته می‌شود که امکان مشارکت برابر برای همه‌ی اعضا در تغییر و بهبود فرایندها را فراهم می‌آورد.
در کانبان (Kanban) اصل بر این است که هر سازمان باید به کانتکست موجود خود احترام بگذارد؛ یعنی نقش‌ها، ساختارها و رویدادهای جاری الزاماً نباید تغییر داده شوند. اگر تیمی اکنون جلسات مشخصی دارد، همان جلسات می‌توانند ادامه پیدا کنند؛ تنها در صورت نیاز، پیشنهادهایی برای اضافه کردن رویدادها یا تغییر در تسهیلگری (Facilitation) ارائه می‌شود. نکته مهم آن است که هر فردی می‌تواند تسهیل‌کننده رویدادها باشد و این نقش محدود به شخص یا عنوان خاصی نیست.
با این حال، در عمل معمولاً وقتی سطح بلوغ (Maturity) تیم پایین است، نیاز به فرد یا گروهی وجود دارد که آغازگر و هدایتگر تغییر باشد. این نقش ممکن است به‌صورت موقت توسط یک مدیر تحویل (Delivery Manager)، مدیر پروژه (Project Manager) یا حتی یک مدیر محصول (Product Manager) ایفا شود تا تغییرات تدریجی در فرهنگ و شیوه کار تیم جا بیفتد. سپس، به‌مرور زمان، این تغییرات جزئی از عادت‌ها (Habits) و فرهنگ سازمان خواهند شد و دیگر نیازی به هدایت مستقیم وجود نخواهد داشت.
در اینجا می‌توان تفاوتی ظریف میان چارچوب‌ها مشاهده کرد:
اسکرام (Scrum) با معرفی نقش‌هایی چون اسکرام‌مستر و پراوداکت اونر، خود به‌طور مستقیم برای تغییرات سازمانی ساختار و مسئولیت تعیین می‌کند.
SAFe (Scaled Agile Framework) نیز با نام‌گذاری نقش‌ها و سطوح مدیریتی مشخص، توانست توجه کسب‌وکارها را جلب کند و از این طریق در بازار نفوذ پیدا کند.
اما کانبان برخلاف آن‌ها، هیچ‌گاه خود را با تبلیغات گسترده یا بازاریابی پررنگ معرفی نکرده است. همانند «قانون اول باشگاه مبارزه (Fight Club)» که می‌گوید: هیچ‌کس نباید درباره‌ی باشگاه مبارزه صحبت کند، در کانبان نیز در بسیاری از سازمان‌ها این تغییرات بی‌نام و نشان معرفی می‌شوند. یعنی گاهی اصلاً واژه‌ی "کانبان" به کار نمی‌رود تا مقاومت تیم‌ها و افراد در برابر تغییر به حداقل برسد.
در واقع، کانبان به‌جای اینکه بر برندسازی یا تبلیغ چارچوب تمرکز کند، تلاش می‌کند هر آنچه مانع تغییر می‌شود حذف گردد. اگر حتی استفاده از واژه‌ی «کانبان» باعث مقاومت شود، می‌توان نام دیگری بر آن گذاشت. هدف اصلی، ایجاد محیطی است که افراد در آن تمرکز بیشتری بر کار خود داشته باشند، کیفیت محصولات افزایش یابد و ارزش مورد انتظار سریع‌تر و بهتر به مشتری تحویل شود.
در حال حاضر، دوره‌های آموزشی کانبان (Kanban) به زبان فارسی در حال برگزاری است. این دوره‌ها در دو سطح مقدماتی و پیشرفته طراحی شده‌اند. تجربه نشان داده است که کیفیت آموزش در گروی تعداد محدود شرکت‌کنندگان است؛ به همین دلیل در دوره‌های مقدماتی حضور بیش از ۱۰ نفر توصیه نمی‌شود. دلیل این محدودیت آن است که در این کلاس‌ها از شبیه‌سازی (Simulation) و بازی‌های آموزشی (Educational Games) استفاده می‌شود و برای حفظ کیفیت و مشارکت مؤثر، تعداد کمتر شرکت‌کنندگان ضروری است.
در ماه مهر ظرفیت دوره‌ی پیشرفته تکمیل شده و به حد نصاب رسیده است. بنابراین، ثبت‌نام برای این دوره بسته شده و کلاس بعدی به احتمال زیاد در آذرماه برگزار خواهد شد. تلاش بر این است که به‌صورت منظم، هر یک یا دو ماه یک‌بار، کلاس‌های فارسی کانبان در هر دو سطح مقدماتی و پیشرفته برگزار شود تا علاقه‌مندان بتوانند مسیر یادگیری خود را پیوسته ادامه دهند.
برای اطلاع‌رسانی و ارتباط با مخاطبان، از دو کانال اصلی استفاده می‌شود:
لینکدین (LinkedIn): جهت اعلام رسمی دوره‌ها و ارتباط حرفه‌ای.
اینستاگرام (Instagram): برای اطلاع‌رسانی منظم‌تر، انتشار پست‌های آموزشی و ویدیوهای کوتاه درباره‌ی موضوعات کانبان، اسکرام و نیز معرفی دوره‌های آتی.
بنابراین، علاقه‌مندان می‌توانند از طریق هر دو بستر در جریان تازه‌ترین اخبار دوره‌ها و محتوای آموزشی قرار گیرند.
