مدیریت تسک‌ها به سبک کد؛ انتقال تیکت‌ها از جیرا به مخزن گیت

عصر هوش مصنوعی و ایجنت‌های کدنویسی، شیوه‌های سنتی توسعه نرم‌افزار را به چالش کشیده است. ایجنت‌های هوش مصنوعی زمانی بهترین عملکرد را دارند که تمامی اطلاعات مورد نیازشان به‌صورت متمرکز درون مخزن (Repository) پروژه قرار داشته باشد؛ چرا که سورس‌کد، منبع اصلی حقیقت برای آن‌هاست. با این حال، بیشتر تیم‌های توسعه هنوز از ابزارهایی مانند Jira یا Redmine برای مدیریت تسک‌ها و نیازمندی‌ها استفاده می‌کنند که کاملاً خارج از مخزن کد قرار دارند. انتقال تسک‌ها به فایل‌های ساده‌ی Markdown دقیقاً همین نقطه ضعف را هدف می‌گیرد.

از Docs as Code تا Tasks as Code

همان‌طور که مستندات نرم‌افزار پیش‌تر مسیر خود را از نرم‌افزارهای مجزا به سمت فایل‌های Markdown درون پوشه‌ی /docs در مخزن گیت تغییر دادند (رویکردی که به آن Docs as Code یا Docs Like Code می‌گویند)، اکنون نوبت تسک‌ها است. با این روش، ایجنت هوش مصنوعی می‌تواند مستندات و تسک‌ها را بخواند، تغییرات کد را اعمال کند و حتی مستندات را در یک روند کاری واحد به‌روزرسانی نماید.

این ایده بسیار به Spec-Driven Development یا همان SDD نزدیک است. در این روش، مشخصاتِ فنیِ رفتارِ مورد انتظار قبل از پیاده‌سازی توسط ایجنت، به زبان Markdown تعریف می‌شود. فایل تسک می‌تواند شامل یک توضیح کوتاه برای یک تغییر کوچک، یا معیارهای پذیرش (Acceptance Criteria)، تصمیمات فنی، وابستگی‌ها و نیازمندی‌های تستی برای یک فیچر پیچیده باشد.

چرخه کاری پنج مرحله‌ای

برای پیاده‌سازی این رویکرد به ابزار خاصی نیاز نیست و می‌توان با همان گیت و یک ایجنت محلی کار را شروع کرد. یک چرخه کاری استاندارد شامل مراحل زیر است:

• توصیف تسک: نوشتن شرح کوتاهی از تغییر یا فیچر جدید.
• تحلیل نیازمندی‌ها: خواندن تسک توسط ایجنت و بررسی کدهای مربوطه.
• تهیه برنامه پیاده‌سازی: اضافه کردن راه حل پیشنهادی توسط ایجنت و شناسایی تغییرات لازم.
• بررسی و تأیید: بررسی برنامه توسط توسعه‌دهنده پیش از شروع کدنویسی (برای حفظ کنترل انسانی).
• پیاده‌سازی و گزارش: تغییر کد، به‌روزرسانی مستندات و ثبت گزارش نهایی در انتهای فایل تسک.

ساختار پیشنهادی برای مخازن

دلیل اینکه نویسنده پیشنهاد می‌کند مخزن تسک‌ها از مخزن کد جدا باشد، مسائل امنیتی و دسترسی است (مانند وصله‌های امنیتی منتشرنشده یا برنامه‌ریزی‌های داخلی). یک توسعه‌دهنده می‌تواند مخزن تسک‌ها و مستندات را به صورت پوشه‌های مجزا درون مخزن کد کلون کند، در حالی که هر دو در فایل .gitignore مخزن اصلی نادیده گرفته می‌شوند تا تاریخچه گیت مستقل خود را حفظ کنند.

دستیارهای محلی مانند Claude Code یا OpenCode می‌توانند مستقیماً به این فایل‌ها دسترسی داشته باشند. پس از پایان کار، با ارجاع دادن به نام فایل تسک در کامیت گیت، ارتباط بین نیازمندی‌ها و کد تغییریافته حفظ می‌شود.

ابزارها و رابط‌های کاربری

اگرچه گیت و ایجنت برای این کار کافی هستند، اما استفاده از ابزارهایی مثل Typemill (به عنوان یک CMS مبتنی بر فایل) این امکان را فراهم می‌کند که افراد غیرفنی مثل مدیران محصول یا نویسندگان فنی هم بدون نیاز به دستورات گیت، تسک‌ها و مستندات را از طریق مرورگر مدیریت کنند.

دیدگاه جامعه توسعه‌دهندگان (Hacker News)

بحث‌های داغی پیرامون این مقاله در هکرنیوز شکل گرفت که به جنبه‌های مختلف این ایده اشاره داشتند:

• نگرانی از بوروکراسی: برخی کاربران مانند jurgenburgen اشاره کردند که تیکت‌ها بسیار سریع‌تر از کد تغییر می‌کنند و ایجاد یک Pull Request صرفاً برای ویرایش یک تیکت می‌تواند کابوسی از کارهای اداری بسازد.
• چالش ذینفعان: کاربر godzillafarts یادآور شد که در سازمان‌های بزرگ، بسیاری از ذینفعان به مخزن کد دسترسی ندارند و همچنان به ابزاری مثل جیرا برای پیگیری و اولویت‌بندی نیازمندند.
• ارتباطات رابطه‌ای: نظراتی وجود داشت مبنی بر اینکه تسک‌ها دارای روابط وابستگی، والد و فرزند هستند و پایگاه‌های داده ذاتاً برای این ساختارها مناسب‌ترند، هرچند ابزارهای فعلی مثل جیرا نقطه ضعف‌های بزرگی دارند.