طراحی و کانفیگ Workflow و Board در جیرا (Jira)
وضعیتها و Transitionها را مطابق فرایند واقعی تیم میسازم و Board را طوری تنظیم میکنم که گلوگاه را نشان بدهد، نه پنهان کند.
Deliverables
چیزی که در پایان تحویل میگیرید:
- دیاگرام Workflow پیش و پس از بازطراحی
- Condition، Validator و Post Function روی Transitionهای حساس
- Board با ستونهای نقشهشده، Swimlane و Quick Filter
- WIP Limit و تعریف روشن Definition of Done
Workflow تنها جایی در Jira است که فرایند شما بهشکل اجرایی نوشته میشود. اگر آن را جدی نگیرید، هر گزارشی که بعداً از Jira بگیرید بیمعنی است — چون دادهای که گزارش روی آن ساخته میشود، از همین وضعیتها میآید.
نشانههای یک Workflow خراب
- وضعیتهایی که هیچکس عوض نمیکند. اگر یک وضعیت در سه ماه گذشته صفر بار استفاده شده، وجود ندارد — فقط شلوغی است.
- وضعیتهایی که بهجای وضعیت، مسئول را نشان میدهند.
Waiting for Aliوضعیت نیست؛ Assignee است. - همه میتوانند همهچیز را به هر جا ببرند. بدون Condition روی Transition، فرایند شما یک پیشنهاد است نه یک قاعده.
- فیلد اجباری در وضعیت اشتباه. پرسیدن «علت رد شدن» موقع ساخت Issue، کاربر را وادار به نوشتن چیز بیمعنی میکند. جایش Validator روی Transition است.
- Resolution دستی پر میشود یا خالی میماند. این تکفیلد، تفاوت بین «کار تمام شد» و «کارت را کشیدم آنطرف» است و بیشتر گزارشهای Jira به آن وابستهاند.
روش بازطراحی
با داده شروع میکنم، نه با وایتبورد. اول از Jira خودتان درمیآورم که در عمل چه Transitionهایی استفاده میشوند، هر Issue چند بار عقب برمیگردد، و کارها در کدام وضعیت میمانند. بعد فرایند را به کوچکترین حالتی که همان اطلاعات را میدهد کوتاه میکنم.
قاعدهٔ عملی من: هر وضعیت باید به یک سؤال مدیریتی جواب بدهد. اگر نمیتوانید بگویید چه تصمیمی با دیدن آن وضعیت گرفته میشود، حذفش کنید.
Board؛ جایی که Workflow دیده میشود
ستونهای Board به وضعیتها نقشه میشوند و همینجا رایجترین اشتباه اتفاق میافتد: وضعیتی که در ستون Done است ولی Resolution ندارد. نتیجه این میشود که Burndown و Velocity عدد اشتباه میدهند و کسی نمیفهمد چرا. ریشهٔ این مشکل و تفاوت status با resolution را در طراحی Workflow در Jira باز کردهام. موقع کانفیگ Board اینها را کنترل میکنم:
- نقشهٔ ستون به وضعیت، و اینکه هیچ وضعیتی بیستون نمانده باشد
- Board Filter با JQL دقیق — نه
project = Xخالی - Swimlane بر اساس چیزی که واقعاً تصمیم عوض میکند: Epic، اولویت، یا مسئول
- WIP Limit روی ستونهای میانی تا گلوگاه دیده شود
- Quick Filterهای کم و کاربردی بهجای ده فیلتر که کسی نمیزند
Scrum یا Kanban
| Scrum | Kanban | |
|---|---|---|
| مناسب وقتی | کار در بازههای ثابت برنامهریزی میشود | کار پیوسته و بر اساس اولویت لحظهای میآید |
| معیار موفقیت | تعهد اسپرینت محقق شود | زمان چرخه کوتاه و پایدار بماند |
| گزارش کلیدی | Burndown و Velocity | Control Chart و Cumulative Flow |
| خطر رایج | اسپرینت به لیست آرزو تبدیل میشود | بکلاگ بینهایت رشد میکند |
تیمهای پشتیبانی و IT تقریباً همیشه Kanban میخواهند و تیم محصول معمولاً Scrum. انتخاب اشتباه، بیشتر از هر تنظیم دیگری باعث میشود تیم Jira را رها کند.
میخواهید این را روی محیط خودتان ببینید؟
جلسهٔ اول ۳۰ دقیقه است و هزینهای ندارد. اگر مسئلهٔ شما در حوزهٔ من نباشد، همانجا میگویم.
خدمات مرتبط
پیادهسازی و راهاندازی جیرا
ساختار پروژه، Issue Type، فیلد، Screen و دسترسیها را از صفر طراحی میکنم — بر اساس فرایند شما، نه قالب پیشفرض Jira.
خواندناتوماسیون جیرا و حذف کار دستی
قوانین خودکار مینویسم که پیگیری دستی، اعلانهای فراموششده و بهروزرسانی تکراری را حذف کنند — با کنترل مصرف و لاگ.
خواندنداشبورد و گزارش مدیریتی جیرا
داشبوردی میسازم که مدیر بدون توضیح شما بفهمد — با JQL دقیق و شاخصهایی که رفتار تیم را خراب نمیکنند.
خواندن