پایان مأموریت اسکرام‌مستر؛ گذار به مدل مهندسی مبتنی بر جریان

دوران «اسکرامِ کتابی» رسماً تمام شده است.

این روزها یک الگوی تکراری می‌بینم. وقتی به تیم‌های فنی مشاوره می‌دهم، اولین سوالشان معمولاً این است: «کدوم فریم‌ورک اجایل (Agile) رو پیاده کنیم؟ اسکرام؟ SAFe؟ LeSS؟»

انتظار دارند من، به عنوان کسی که از فضای Big Tech می‌آید، یک کتاب قانون پیچیده و پر از نمودار جلویشان بگذارم. جواب من معمولاً شوکه‌شان می‌کند: «هیچکدوم.»

در دنیای مهندسیِ سطح بالا (High-performance) در سال ۲۰۲۶، ما داریم مرگ فریم‌ورک‌های خشک و دست‌وپاشکستنِ نقش‌های سنتی را می‌بینیم. دنیا دارد به سمت چیزی خیلی عمل‌گراتر می‌رود: مهندسی مبتنی بر جریان (Flow-Based Engineering).

مالیاتِ جلسات و فرسودگیِ دولوپرها

برای یک دهه، با مهندسان نرم‌افزار مثل کارگران خط تولید رفتار کردیم که باید در بسته‌های دو هفته‌ای مدیریت شوند. تقویمشان را پر کردیم از «مراسم» (Ceremonies). استندآپ، پلنینگ، ریفاینمنت، رترو…

ما اسم این کار را گذاشتیم «اجایل»، اما برای مهندسی که دارد سعی می‌کند یک Race Condition پیچیده را در کرنل حل کند، این‌ها فقط نویز (Noise) هستند.

هر جلسه یعنی یک Context Switch. و هر سوئیچ یعنی مالیاتی سنگین روی بارِ شناختی (Cognitive Load) مغز. ما فهمیدیم با اجبار کردن این مراسم، عملاً داریم جلوی مهم‌ترین کار مهندس‌ها را می‌گیریم: فکر کردن.

نظم بدون بوروکراسی: مدل Async

حالا سوال اصلی اینجاست: «اگه جلسات رو حذف کنیم، چطور برنامه‌ریزی کنیم؟»

حذف جلسات اسکرام به معنی حذف دیسیپلین نیست. به معنی تغییر دیسیپلین از «همگام» (جلسه) به «ناهمگام» (نوشتن) است. تیم‌های پیشرو اینطور مراسم را جایگزین می‌کنند:

۱. جایگزینی Sprint Planning با RFC:

به جای اینکه ۲ ساعت در اتاق جلسه حبس شویم و برای استوری پوینت‌ها شیر یا خط بیندازیم، مهندس یک داکیومنت ۱ صفحه‌ای (Design Doc/RFC) می‌نویسد. تیم در زمانِ مرده‌ی خودش آن را می‌خواند و کامنت می‌گذارد. وقتی نوشتن کد شروع می‌شود، نقشه راه مشخص است. خواندن همیشه سریع‌تر از شنیدن است.

۲. جایگزینی Stand-up با سیگنال‌های خودکار:

نیازی نیست بپرسیم «دیروز چه کردی؟». کامیت‌لاگ‌های گیت (Git Log) به ما می‌گویند. نیازی نیست بپرسیم «بلاکی؟». باتِ اسلک (Slack Bot) ساعت ۹ صبح می‌پرسد و اگر جواب «نه» باشد، جلسه‌ای در کار نیست. ما فقط وقتی حرف می‌زنیم که جایی آتش گرفته باشد.

۳. جایگزینی «اسپرینت» با «اولویت‌های شناور»:

ما منتظر پایان دو هفته نمی‌مانیم تا ولیو (Value) ریلیز کنیم. ما از مدل کانبان استفاده می‌کنیم. لحظه‌ای که فیچر آماده شد، دیپلوی می‌شود. لحظه‌ای که دولوپر آزاد شد، تسکِ بعدی را برمی‌دارد.

منسوخ شدنِ «پلیسِ پروسه»

اینجا به یک نکته جنجالی می‌رسیم: نقش «اسکرام مستر تمام‌وقت» دارد منسوخ می‌شود.

در گذشته، ما به کسی نیاز داشتیم که کارها را تسهیل کند چون ابزارها ضعیف بودند. اما در سال ۲۰۲۶، ابزارهایی مثل Linear و AI تمام کارهای ادمینی را انجام می‌دهند.

تیمی که برای برگزاری یک جلسه ۱۵ دقیقه ای به یک پرستار بچه (Babysitter) نیاز دارد، مشکلِ پروسه ندارد؛ مشکلِ استخدام (Hiring Problem) دارد.

حرف آخر به لیدرها

نصیحت من به همکارانم و تیم‌هایی که مشاوره می‌دهم: دست از پرستش فریم‌ورک بردارید.

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

آینده‌ی مهندسی نرم‌افزار درباره‌ی «استیکی‌نوت»های بیشتر نیست؛ درباره‌ی «فلو» (Flow) بیشتر است.

به تیمتان اعتماد کنید تا ریتم خودش را پیدا کند. به آن‌ها مسئله بدهید تا حل کنند، نه جلسه تا شرکت کنند.