چرا automation گاهی به ceremony جدید تبدیل می‌شود؟

Ceremony دقیقاً چه زمانی شکل می‌گیرد؟

هر رویداد تکرارشونده ceremony بدی نیست. بعضی eventها برای inspect، تصمیم، هماهنگی یا یادگیری لازم‌اند. مسئله زمانی شروع می‌شود که فعالیت تکرار می‌شود اما purpose، decision یا outcome روشنی ندارد و تیم فقط برای حفظ خود فرایند آن را انجام می‌دهد.

برای تشخیص، پنج سؤال بپرسید: چه triggerی این فعالیت را شروع می‌کند؟ چه تصمیمی باید گرفته شود؟ چه کسی owner آن تصمیم است؟ اگر تصمیمی لازم نیست، چرا خروجی تولید می‌شود؟ و اگر این activity یک هفته حذف شود، کدام outcome واقعاً آسیب می‌بیند؟ اگر پاسخ‌ها مبهم باشند، احتمالاً automation به جای حذف ceremony، آن را به شکل دیجیتال بازتولید کرده است.

تفاوت یک control لازم با ceremony اضافی در این است که control به یک failure mode و action وصل است. مثلاً alert نشت secret باید مسیر توقف و owner داشته باشد. اما alertی که هر روز می‌گوید چند item تغییر کرده و هیچ‌کس بر اساس آن تصمیم نمی‌گیرد، بیشتر notification است تا کنترل.

• Automation مفید: signal مشخص، owner روشن، action قابل‌ردگیری و نتیجهٔ قابل‌سنجش دارد.
• Ceremony اضافی: خروجی تکراری، audience نامشخص، approval مبهم و action بدون پیگیری دارد.
• Dashboard مفید: سؤال مشخصی را پاسخ می‌دهد و به تصمیم یا بازبینی منجر می‌شود.
• Dashboard تزئینی: فقط نشان می‌دهد داده جمع شده است.

AI چرا این مشکل را بزرگ‌تر می‌کند؟

automation سنتی معمولاً یک کار مشخص را با rule نسبتاً مشخص انجام می‌دهد. Agentهای AI می‌توانند context بیشتری بخوانند و خروجی انعطاف‌پذیرتری تولید کنند؛ همین flexibility باعث می‌شود تعداد خروجی‌های ممکن، سؤال‌های باز و پیشنهادهای نیازمند review هم زیاد شود.

مستندات رسمی GitHub دربارهٔ Copilot cloud agent توضیح می‌دهد که agent می‌تواند repository را research کند، plan بسازد، روی branch تغییر بدهد و پس از review و iteration به pull request برسد. همان مستندات از automationهایی صحبت می‌کند که می‌توانند در schedule یا response به eventهای repository اجرا شوند و برای issueهای triageشده rationale، confidence و approval داشته باشند.

این قابلیت‌ها می‌توانند زمان آماده‌سازی را کم کنند، اما خودشان تصمیم محصول نیستند. اگر هر agent run به یک approval دستی طولانی، جلسهٔ triage یا گزارش status جداگانه منجر شود، تیم به‌جای یک workflow سریع‌تر، صف جدیدی از خروجی‌های نیمه‌تمام ساخته است. باید بپرسیم agent کدام handoff یا waiting را حذف کرده و کدام را فقط از یک ابزار به ابزار دیگر منتقل کرده است.

مدل همچنین می‌تواند با زبان قانع‌کننده activity را به progress شبیه کند. یک خلاصهٔ زیبا ممکن است هیچ actionی نسازد. بنابراین معیار automation، تعداد خروجی یا کیفیت ظاهری متن نیست؛ باید اثر آن بر تصمیم و جریان کار را ببینیم.

چهار نوع automation را از هم جدا کنیم

قبل از افزودن automation، نوع ارزش مورد انتظار را مشخص کنید. همهٔ workflowها قرار نیست action را خودکار کنند؛ بعضی فقط باید visibility بسازند و بعضی باید کنترل safety باشند. اشتباه زمانی رخ می‌دهد که نوع اول با نوع چهارم سنجیده شود یا برای یک summary کم‌ریسک همان approval سنگین action بیرونی را بگذاریم.

نوع اول visibility است: دادهٔ پراکنده را جمع می‌کند و وضعیت قابل‌فهم می‌سازد. نوع دوم decision support است: گزینه، impact یا سؤال باز ارائه می‌دهد. نوع سوم execution است: کار کم‌ریسک و قابل‌برگشت را انجام می‌دهد. نوع چهارم control است: failure یا ریسک مشخص را تشخیص می‌دهد و مسیر توقف، escalation یا rollback را فعال می‌کند.

هر نوع، DoD و metric خودش را دارد. visibility باید زمان پیدا کردن context را کم کند؛ decision support باید زمان رسیدن به تصمیم یا کیفیت آن را بهتر کند؛ execution باید lead time و rework را با حفظ quality بسنجد؛ control باید incident یا زمان واکنش را کاهش دهد. اگر همه را با «تعداد automation فعال» گزارش کنیم، ارزش واقعی پنهان می‌شود.

• Visibility: جمع‌آوری و خلاصه‌سازی context.
• Decision support: ساختن گزینه، impact، risk یا سؤال باز.
• Execution: انجام action محدود، قابل‌برگشت و کم‌ریسک.
• Control: تشخیص failure و فعال‌کردن guardrail، escalation یا rollback.

نشانه‌های تبدیل automation به ceremony

نشانهٔ اول، افزایش acknowledgement است. افراد باید پیام‌های bot را با emoji، comment یا status جداگانه تأیید کنند، اما این تأیید هیچ تصمیمی را عوض نمی‌کند. نشانهٔ دوم، تکرار گزارش است: همان داده در Slack، email، dashboard و جلسهٔ هفتگی بازخوانی می‌شود.

نشانهٔ سوم، alert بدون action است. اگر تیم alert را می‌بیند اما owner، threshold یا مسیر escalation ندارد، بعد از مدتی آن را نادیده می‌گیرد. نشانهٔ چهارم، approval برای outputهای بی‌ریسک است؛ مدل draftی می‌سازد که انسان فقط برای عبور از gate آن را تأیید می‌کند، نه برای اعمال judgment واقعی.

نشانهٔ پنجم، رشد work برای نگهداری automation است. اتصال‌ها، promptها، exceptionها و dashboardها آن‌قدر زیاد می‌شوند که تیم زمان بیشتری برای تعمیر سیستم گزارش‌سازی صرف می‌کند تا حل مسئلهٔ محصول. نشانهٔ آخر این است که کسی نمی‌تواند بگوید اگر automation فردا خاموش شود، کدام metric یا outcome بدتر می‌شود.

• notification و acknowledgement بیشتر شده اما تصمیم سریع‌تر نشده است.
• یک داده در چند کانال و چند جلسه تکرار می‌شود.
• alert زیاد است اما action، owner یا threshold روشن نیست.
• approval فقط برای ثبت تأیید انجام می‌شود، نه بررسی واقعی.
• هزینهٔ نگهداری automation از اصطکاک حذف‌شده بیشتر شده است.
• هیچ baseline قبل و بعدی برای ارزش workflow وجود ندارد.

Scrum قرار نیست با bot جلسهٔ بیشتری بسازد

Scrum Guide می‌گوید eventهای Scrum فرصت رسمی برای inspect و adapt کردن artifactها هستند و برای ایجاد regularity و کم‌کردن نیاز به meetingهای تعریف‌نشده طراحی شده‌اند. Daily Scrum هم برای inspect کردن progress نسبت به Sprint Goal و adapt کردن Sprint Backlog است، نه خواندن همهٔ updateهای تولیدشده.

این اصل به معنی حذف هر status یا dashboard نیست. اگر automation قبل از Daily Scrum اطلاعات را مرتب می‌کند و تیم در جلسه دربارهٔ blocker و برنامهٔ actionable تصمیم می‌گیرد، automation به هدف Scrum کمک کرده است. اگر تیم فقط گزارش bot را می‌خواند و دوباره همان داده را در یک meeting دیگر تأیید می‌کند، یک ceremony موازی ساخته‌ایم.

در Sprint Review باید outcome و تغییر محیط را ببینیم، نه تعداد runهای automation را. در Retrospective هم از خودمان بپرسیم کدام automation واقعاً quality و effectiveness را بهتر کرده و کدام فقط پیچیدگی workflow را افزایش داده است.

• قبل از هر event، automation باید context را فشرده کند، نه جلسه را جایگزین تصمیم کند.
• هر خروجی باید به یک سؤال، تصمیم یا action وصل باشد.
• اگر bot گزارش می‌سازد، جلسه نباید همان گزارش را دوباره تولید کند.
• در retrospective، هزینهٔ توجه و نگهداری automation را هم بررسی کنید.

Automation را با outcome و flow بسنجیم، نه با تعداد dashboard

راهنمای رسمی DORA پنج metric delivery را به throughput و instability تقسیم می‌کند و تأکید دارد که metricها باید در context یک application یا service و در طول زمان خوانده شوند. همان راهنما دربارهٔ چند دام هشدار می‌دهد: metric را goal نکنیم، یک metric را بر همه‌چیز حاکم نکنیم، تیم‌های نامشابه را مقایسه نکنیم و measurement را جایگزین improvement نکنیم.

این چارچوب برای automation هم کاربرد دارد. اگر bot گزارش‌ساز ساخته‌ایم، زمان پیدا کردن context، زمان رسیدن به تصمیم و تعداد follow-upهای بی‌نتیجه را مقایسه کنیم. اگر agent کد تولید می‌کند، change lead time را کنار change fail rate و deployment rework ببینیم. اگر alert برای incident ساخته‌ایم، زمان تشخیص و recovery را بسنجیم، نه تعداد alertهای ارسال‌شده.

گاهی بهترین نتیجهٔ automation کمترشدن یک عدد نیست، بلکه بهترشدن کیفیت تصمیم است. برای این مورد باید نمونهٔ decision record، نرخ اصلاح، رضایت owner و ارتباط action با outcome را هم بررسی کنیم. metricها قطب‌نما هستند، نه verdict خودکار.

• Throughput: آیا change یا decision با زمان و batch کوچک‌تر به مقصد می‌رسد؟
• Stability: آیا failure، rework و rollback بیشتر نشده است؟
• Attention: چه مقدار زمان صرف خواندن، triage و acknowledgement می‌شود؟
• Decision: آیا actionها روشن‌تر، سریع‌تر و قابل‌پیگیری‌تر شده‌اند؟
• Learning: آیا failureها به بهبود workflow یا automation برمی‌گردند؟

الگوی چهارمرحله‌ای برای طراحی automation سالم

من برای هر automation یک حلقهٔ چهارمرحله‌ای می‌سازم: signal، decision، action و learning. Signal باید event یا threshold مشخصی داشته باشد. Decision باید معلوم کند چه کسی و بر اساس چه evidenceای انتخاب می‌کند. Action باید کوچک، bounded و تا حد ممکن قابل‌برگشت باشد. Learning باید نشان دهد نتیجه چه تغییری در baseline یا workflow ایجاد کرده است.

اگر یک automation فقط signal تولید می‌کند اما هیچ decision یا actionی ندارد، آن را به visibility محدود تبدیل کنید و از آن انتظار execution نداشته باشید. اگر action دارد اما learning ندارد، نمی‌دانیم بهبود ایجاد کرده یا فقط کار بیشتری تولید کرده است. اگر approval در مرحلهٔ decision فقط یک دکمهٔ تشریفاتی است، threshold و مسئولیت را دوباره طراحی کنید.

برای Agentهای AI، provenance و confidence را کنار output نگه دارید. انسان باید بتواند بفهمد agent چه چیزی دیده، چه چیزی را حدس زده و برای چه اقدامی approval می‌خواهد. این کار تعداد ceremony را کم می‌کند چون به جای جلسهٔ بازسازی context، evidence آماده است.

• Signal: چه event یا thresholdی automation را فعال می‌کند؟
• Decision: چه سؤال و چه ownerی باید پاسخ داده شود؟
• Action: کوچک‌ترین اقدام کم‌ریسک و قابل‌برگشت چیست؟
• Learning: چه metric یا evidenceای نشان می‌دهد workflow بهتر شده است؟
• Stop: چه زمانی automation باید خاموش، کوچک یا بازطراحی شود؟

چطور approval را از تشریفات به judgment تبدیل کنیم؟

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

سطح approval را بر اساس reversibility و impact تنظیم کنید. draft داخلی و action قابل‌برگشت می‌تواند review سبک‌تری داشته باشد. تغییر دائمی داده، پیام بیرونی، merge حساس، تصمیم حقوقی یا تغییر در production نیازمند owner و evidence قوی‌تری است. یک approval boundary خوب، هم سرعت را حفظ می‌کند و هم مسئولیت را مبهم نمی‌گذارد.

AI می‌تواند خلاصهٔ diff، risk، source و سؤال‌های باز را آماده کند؛ reviewer باید امکان رد، اصلاح، درخواست evidence بیشتر یا انتقال به owner دیگر را داشته باشد. اگر خروجی مدل همیشه با یک کلیک approve می‌شود، احتمالاً gate را برای compliance نمایشی ساخته‌ایم، نه کنترل واقعی.

• ریسک و برگشت‌پذیری action را مشخص کنید.
• برای low-risk automation، review را نمونه‌ای یا rule-based کنید.
• برای high-impact action، evidence، owner و escalation لازم داشته باشید.
• ردکردن و درخواست اصلاح باید به‌اندازهٔ تأیید آسان باشد.
• تعداد approval را معیار امنیت یا کیفیت فرض نکنید.

هزینهٔ پنهان automation در پروژهٔ AI

در برآورد پروژه، فقط زمان ساخت integration را نبینیم. هزینهٔ واقعی شامل طراحی trigger، جمع‌آوری داده، مدیریت دسترسی، prompt و policy، تست و evaluation، review انسانی، نگهداری اتصال‌ها، monitoring، هزینهٔ API و رسیدگی به failure است. اگر automation ceremony بسازد، هزینهٔ توجه و context switching هم باید به آن اضافه شود.

این هزینه در پروژه‌های کوچک به‌راحتی پنهان می‌ماند. یک bot گزارش status شاید سریع ساخته شود، اما اگر هر روز افراد را به dashboard بکشاند و دادهٔ آن با ابزار اصلی ناسازگار باشد، مجموع زمان از دست‌رفته از status دستی بیشتر می‌شود. برای همین باید قبل از rollout baseline بگیریم و یک kill criterion داشته باشیم.

از نگاه تجاری حکیم، پیشنهاد خوب برای automation نباید با تعداد agent یا integration فروخته شود. باید بگوید کدام اصطکاک حذف می‌شود، چه کاری انسانی می‌ماند، چه ریسکی اضافه می‌شود و با چه metricی بعد از چند چرخه بررسی می‌کنیم که ادامه‌دادن منطقی است.

یک روش عملی برای تیم کوچک

برای یک تیم کوچک، از یک workflow دردناک شروع کنید؛ مثلاً جمع‌کردن status برای Daily Scrum یا triage کردن issueهای تکراری. پیش از automation، یک هفته baseline بگیرید: زمان کار دستی، تعداد handoff، زمان انتظار، خطا، follow-up و تصمیم‌های واقعی.

سپس automation را با کمترین دامنه فعال کنید. یک channel یا dashboard کافی است، یک owner برای action تعیین کنید و خروجی را با source و timestamp نشان دهید. بعد از دو یا سه چرخه، افراد را دور هم جمع کنید و بپرسید چه چیزی واقعاً حذف شد، چه کار جدیدی ساخته شد و کدام alertها نادیده گرفته شدند.

اگر outcome بهتر شده، دامنه را آهسته زیاد کنید. اگر فقط گزارش و جلسه بیشتر شده، automation را کوچک یا خاموش کنید. خاموش‌کردن یک automation کم‌ارزش شکست نیست؛ جلوگیری از تبدیل‌شدن آن به بدهی عملیاتی است.

• یک workflow و یک outcome انتخاب کنید.
• baseline توجه، زمان، waiting، error و rework بگیرید.
• automation را با یک trigger و یک owner شروع کنید.
• هر alert را به action، threshold و stop criterion وصل کنید.
• بعد از چند چرخه تصمیم بگیرید: scale، redesign یا retire.

چک‌لیست قبل از اضافه‌کردن automation جدید

• کدام اصطکاک یا failure mode مشخص قرار است حذف شود؟
• automation از چه signalی شروع می‌شود و چه چیزی را تغییر می‌دهد؟
• آیا خروجی آن به تصمیم یا action واقعی وصل است؟
• owner، audience و سطح approval مشخص هستند؟
• چه کاری هنوز انسانی می‌ماند و چرا؟
• آیا output، source، timestamp و uncertainty قابل‌مشاهده است؟
• آیا action کم‌ریسک، محدود و قابل‌برگشت است؟
• metric قبل و بعد برای زمان، waiting، quality و rework داریم؟
• هزینهٔ نگهداری، API، review و توجه را حساب کرده‌ایم؟
• معیار stop یا retire کردن automation چیست؟

جمع‌بندی

واقعیت عمومی: Scrum Guide، eventها را برای inspect و adapt و کاهش meetingهای تعریف‌نشده توضیح می‌دهد و DORA هم توصیه می‌کند performance delivery را با چند metric، در context یک application و با تمرکز بر بهبود بسنجیم؛ نه با هدف‌کردن یک عدد یا ساختن dashboard بیشتر. مستندات رسمی GitHub نشان می‌دهد Agentها و automationهای جدید می‌توانند research، plan، branch، pull request و اجرا بر اساس event یا schedule را پشتیبانی کنند.

تحلیل من: این قابلیت‌ها ظرفیت تولید و visibility را بالا می‌برند، اما ظرفیت توجه، review و تصمیم انسان را خودکار زیاد نمی‌کنند. اگر signal، report و approval بیشتری بسازیم ولی action و learning را بهبود ندهیم، automation به ceremony جدید تبدیل می‌شود. معیار درست، تعداد bot و dashboard نیست؛ کاهش زمان انتظار، تصمیم بهتر، rework کمتر، recovery سریع‌تر و outcome قابل‌مشاهده است.

پیشنهاد حکیم: هر automation را با signal، decision، action، learning و stop criterion طراحی کنید. یک workflow کوچک را baseline بگیرید، خروجی AI را با source و uncertainty نشان دهید و بعد از چند چرخه دربارهٔ scale یا retire تصمیم بگیرید. اتوماسیون خوب باید بخشی از توجه تیم را آزاد کند؛ اگر هر روز توجه بیشتری برای نگهداری خودش می‌خواهد، باید آن را دوباره طراحی کنیم.

منابع اولیه برای بررسی

Scrum Guide نسخهٔ HTML برای هدف eventهای Scrum، Daily Scrum، Sprint Goal، inspect و adapt و کاهش meetingهای تعریف‌نشده: https://scrumguides.org/scrum-guide.html — بررسی‌شده در 2026-09-15.

راهنمای رسمی DORA دربارهٔ پنج metric عملکرد delivery، throughput، instability، اهمیت context و دام‌های metricگذاری: https://dora.dev/guides/dora-metrics/ — آخرین به‌روزرسانی صفحه 2026-01-05 و بررسی‌شده در 2026-09-15.

مستندات رسمی GitHub دربارهٔ Copilot cloud agent، research، plan، branch، pull request و automation بر اساس schedule یا event: https://docs.github.com/en/copilot/concepts/agents/cloud-agent — بررسی‌شده در 2026-09-15.

مرز شواهد و تحلیل

تعریف‌های Scrum، چارچوب metricهای DORA و قابلیت‌های اعلام‌شدهٔ GitHub از منابع اولیهٔ بالا گرفته شده‌اند. این منابع تضمین نمی‌کنند automation یا Agent برای هر تیم سرعت، کیفیت یا outcome را بهتر کند. چارچوب تشخیص ceremony، چهار نوع automation، حلقهٔ signal تا learning، مدل approval و تحلیل هزینه و اثر AI بر Agile دیدگاه امین رضا سیدآبادی است و باید با context، ریسک و دادهٔ واقعی همان workflow تطبیق داده شود.