قوانین Automation در جیرا که بیشترین کار دستی را حذف می‌کنند

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

تفاوت این دو، در ساختار قانون نیست — در باریک‌بودن محرک و روشن‌بودن مالک است.

ساختار یک قانون

هر قانون از چهار جزء ساخته می‌شود و ترتیبشان مهم است:

• Trigger — چه اتفاقی قانون را بیدار می‌کند. ساخت Issue، تغییر وضعیت، تغییر مقدار فیلد، رسیدن یک زمان مشخص.
• Condition — بعد از بیدار شدن، آیا واقعاً باید ادامه بدهد. اینجا جایی است که مصرف را کنترل می‌کنید.
• Branch — روی چه چیزی کار کند: خود Issue، والدش، فرزندانش، یا Issueهای لینک‌شده.
• Action — کاری که انجام می‌شود: انتقال، تخصیص، کامنت، ویرایش فیلد، اعلان.

هشت قانونی که تقریباً همیشه ارزش دارند

۱. تخصیص خودکار بر اساس نوع درخواست

محرک: ساخت Issue. شرط: Request Type برابر «درخواست دسترسی». اقدام: تخصیص به گروه IT و افزودن Component مربوطه. این ساده‌ترین قانون ممکن است و بیشترین وقت را برمی‌گرداند، چون کار تریاژ دستی را حذف می‌کند.

۲. بستن خودکار کارهای منتظر پاسخ

محرک: زمان‌بندی‌شده، روزی یک بار. شرط: وضعیت برابر Waiting for Customer و بیش از هفت روز بدون به‌روزرسانی. اقدام: کامنت توضیحی، انتقال به Closed، ست‌کردن resolution روی Incomplete.

۳. همگام‌سازی والد با فرزندان

محرک: تغییر وضعیت Sub-task. شرط: همهٔ Sub-taskهای والد در دستهٔ Done هستند. اقدام: Branch روی والد و انتقالش به In Review. این قانون تنهایی جلسات وضعیت را کوتاه می‌کند.

۴. هشدار SLA قبل از نقض، نه بعدش

محرک: زمان‌بندی‌شده، هر ساعت. شرط: زمان باقی‌ماندهٔ SLA کمتر از دو ساعت و Issue هنوز باز است. اقدام: اعلان به مسئول و مدیر تیم. اعلانی که بعد از نقض می‌آید فقط یک گزارش شکست است.

۵. برگرداندن Issue ناقص به سازنده

محرک: ساخت Issue. شرط: فیلد Description خالی یا Component تعیین‌نشده. اقدام: کامنت با ذکر دقیق چیزی که کم است و تخصیص به Reporter. کیفیت ورودی را بدون هیچ بحثی بالا می‌برد.

۶. ساخت Sub-task استاندارد

محرک: تغییر وضعیت به Ready for Dev. شرط: Issue Type برابر Story. اقدام: ساخت سه Sub-task ثابت — پیاده‌سازی، تست، مستندسازی. جلوی «یادمان رفت تست بنویسیم» را می‌گیرد.

۷. اعلان انتخابی به کانال تیم

محرک: ساخت Issue. شرط: Priority برابر Highest. اقدام: ارسال پیام به وب‌هوک کانال تیم. نکتهٔ مهم شرط است: اعلان برای همهٔ Issueها یعنی اعلان برای هیچ‌کدام.

۸. به‌روزرسانی Epic از روی فرزندان

محرک: زمان‌بندی‌شده، شبانه. اقدام: Branch روی Epicها، شمردن فرزندان تمام‌شده، و نوشتن درصد پیشرفت در یک فیلد سفارشی. مدیر بدون باز کردن هیچ Boardی وضعیت را می‌بیند.

smart value؛ جایی که قوانین از ساده به مفید می‌روند

smart value به شما اجازه می‌دهد داخل متن و شرط‌ها به مقادیر Issue ارجاع بدهید. چندتایی که بیشترین کاربرد را دارند:

{{issue.key}}                     -- issue key, e.g. OPS-142
{{issue.summary}}                 -- title
{{issue.status.name}}             -- current status name
{{issue.assignee.displayName}}    -- assignee name
{{issue.parent.key}}              -- parent key
{{triggerIssue.key}}              -- the triggering issue, inside a branch
{{now.plusDays(3)}}               -- date maths, e.g. for Due Date
{{#if}} ... {{/if}}               -- conditional text inside a message

سه اشتباهی که قانون خوب را خراب می‌کنند

حلقه بین قوانین

قانون A فیلدی را عوض می‌کند، قانون B به آن تغییر واکنش نشان می‌دهد و چیزی را عوض می‌کند که دوباره A را بیدار می‌کند. Jira یک محافظ دارد و بعد از چند دور حلقه را قطع می‌کند، ولی تا آنجا تاریخچهٔ Issue پر از تغییرات بی‌معنی شده است.

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

اجرا با کاربر ادمین

هر قانون یک «کاربر اجراکننده» دارد. اگر ادمین سیستم باشد، قانون از همهٔ Permissionها عبور می‌کند و می‌تواند کاری کند که هیچ آدمی مجاز به انجامش نیست. علاوه بر ریسک امنیتی، تاریخچهٔ Issue پر می‌شود از تغییراتی به نام کسی که آن‌ها را انجام نداده.

راه درست: یک اکانت اختصاصی برای اتوماسیون با حداقل دسترسی لازم، تا در تاریخچه هم مشخص باشد که این کار را یک قانون انجام داده.

قانون بی‌مالک

قانونی که کسی مالکش نیست، شش ماه بعد کار اشتباه می‌کند و هیچ‌کس جرئت خاموش‌کردنش را ندارد. در هر پیاده‌سازی، فهرست قوانین با نام مالک هر کدام مستند می‌شود — معمولاً در یک صفحهٔ Confluence کنار خود پروژه.

سقف مصرف را جدی بگیرید

در Jira Cloud تعداد اجرای قوانین محدود است و پلن شما تعیین می‌کند چقدر. نکتهٔ مهم این است که این سقف معمولاً فقط شامل قوانینی می‌شود که چند پروژه را پوشش می‌دهند؛ قوانین محدود به یک پروژه سخاوتمندانه‌تر حساب می‌شوند.

خطرناک‌ترین الگو، محرک «تغییر مقدار فیلد» بدون تعیین فیلد مشخص است. چنین قانونی با هر ویرایش کوچکی روی هر Issueی بیدار می‌شود و می‌تواند تنهایی سهم کل سازمان را مصرف کند. دو کار ساده جلویش را می‌گیرد:

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

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

عیب‌یابی و تست

هر قانون یک Audit Log دارد که نشان می‌دهد کِی اجرا شده، چه شرطی رد شده و چه خطایی خورده. نود درصد سؤال «چرا قانونم کار نمی‌کند؟» با خواندن همین لاگ جواب می‌گیرد — و جواب معمولاً «شرط برقرار نبود» است، نه «قانون خراب است».

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

جمع‌بندی

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

اگر می‌خواهید این قوانین روی محیط خودتان نوشته، تست و مستند شوند، Automation و حذف کار دستی همین کار است.