تسک و تیکت — چیست، سیستم‌های رهگیری و کار با وظایف

تسک و تیکت چیست؟

تسک (از انگلیسی task) — واحد کاری ثبت‌شده در سیستم رهگیری. شامل توضیحات، اولویت (Critical, High, Medium, Low)، مسئول، مهلت زمانی و وضعیت است. در توسعه موبایل، تسک می‌تواند «افزودن صفحه پروفایل با آواتار»، «پیاده‌سازی صفحه‌بندی فید» یا «به‌روزرسانی targetSdk به نسخه 35» باشد. هر تسک به پروژه، اسپرینت و توسعه‌دهنده یا تیم خاصی متصل است.

تیکت (از انگلیسی ticket) — موجودیت گسترده‌تری است. تیکت می‌تواند گزارش باگ («برنامه هنگام چرخش صفحه در Android 14 کرش می‌کند»)، درخواست ویژگی («افزودن پشتیبانی از تم تاریک»)، مراجعه به پشتیبانی فنی («اعلان push نمی‌رسد») یا وظیفه از مدیر («تهیه گزارش نرخ کرش ماهانه») باشد. تفاوت بین تسک و تیکت مبهم است: در Jira هر دو مفهوم در Issue ادغام شده‌اند. تفاوت کلیدی: تسک همیشه وظیفه‌ای با مسئول است، تیکت می‌تواند درخواستی بدون مسئول مشخص تا زمان تریاژ باشد.

در Scrum و Kanban، تسک‌ها عنصر اصلی بکلاگ هستند. هر تسک باید معیار INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) را برآورده کند. تسک‌های مستقل را می‌توان به هر ترتیبی پیاده‌سازی کرد. قابل برآورد — تیم می‌تواند میزان کار را تخمین بزند. کوچک — در یک اسپرینت جا می‌شود. قابل تست — معیارهای پذیرش مشخصی دارد. تسک‌های بزرگ (اپیک‌ها) تا برآورده شدن همه معیارها به بخش‌های کوچک‌تر تقسیم می‌شوند.

انواع وظایف در توسعه موبایل

Feature — قابلیت جدید برنامه. مثال: «صفحه ورود با بیومتریک (Face ID / Touch ID)». تسک‌های Feature همیشه به یوزر استوری متصل هستند و معیارهای پذیرش (Acceptance Criteria) دارند. برآورد — در استوری پوینت (1, 2, 3, 5, 8, 13). Bug — نقص یافت‌شده در فرآیند توسعه یا آزمایش. اولویت تیکت باگ بر اساس severity تعیین می‌شود (crash → Critical, UI-bug → Medium, اشتباه تایپی → Low). در توسعه موبایل، نرخ کرش بالای 0.1% یک باگ بحرانی است و نیاز به رفع فوری دارد.

Tech Debt / Chore — وظایف فنی بدون تأثیر قابل مشاهده برای کاربر: به‌روزرسانی کتابخانه‌ها (Dependency Bump)، بازآفرینی (مهاجرت از ViewPager به ViewPager2)، تنظیم CI/CD، نوشتن تست‌ها. تسک‌های Tech Debt اغلب دست‌کم گرفته می‌شوند، اگرچه بر اساس داده‌های Stripe 2025، تا 30% زمان تیم موبایل صرف نگهداری و پرداخت بدهی فنی می‌شود. نادیده گرفتن Tech Debt منجر به افزایش باگ‌ها و کندی توسعه قابلیت‌های جدید می‌شود.

انواع اضافی: Spike (وظیفه تحقیقاتی — بررسی فناوری جدید، نوشتن POC)، Task (هر کاری که به کد مربوط نمی‌شود — مستندات، بازبینی طراحی)، Improvement (بهبود قابلیت موجود — بهینه‌سازی زمان بارگذاری صفحه). در Jira، انواع issues برای هر پروژه قابل تنظیم است. مجموعه استاندارد برای تیم موبایل: Story, Bug, Task, Improvement, Epic. Epic — موضوع بزرگ چند داستان را ترکیب می‌کند. مثال: «تجارت الکترونیک: سبد خرید و ثبت سفارش».

چرخه حیات تسک: از ایجاد تا بسته شدن

Open (To Do) — تسک ایجاد شده اما شروع نشده. شامل توضیحات، معیارهای پذیرش، اولویت است. در این وضعیت، تسک باید قبل از ورود به اسپرینت، گروومینگ (شفاف‌سازی و برآورد) را طی کند. In Progress — توسعه‌دهنده کار را شروع کرده است. در توسعه موبایل، پیوند commit و pull request به تسک مهم است: در Jira از طریق Smart Commits (APP-123 #comment رفع باگ)، در GitHub/GitLab از طریق کلمات کلیدی در توضیحات PR (Closes APP-123).

In Review — کد برای بازبینی ارسال شده است. بررسی‌های خودکار: CI (Gradle build, lint, تست‌های واحد)، SonarQube (کیفیت کد)، Danger (changelog, تست‌ها). توسعه‌دهنده نمی‌تواند تسک بعدی را شروع کند تا زمانی که تسک فعلی در Review است — این کار از چندوظیفگی جلوگیری می‌کند. QA / Testing — تست‌کننده روی دستگاه‌های واقعی بررسی می‌کند (Android — نسخه‌های مختلف OS و اندازه صفحه، iOS — مدل‌های مختلف iPhone). اگر باگ‌هایی پیدا شود، تسک با توضیحات به In Progress بازگردانده می‌شود.

Done (Closed) — تسک تکمیل شده: کد در main/master ادغام شده، تست شده، آماده انتشار است. برخی تیم‌ها وضعیت Deployed را اضافه می‌کنند — تسک تنها پس از انتشار بیلد در فروشگاه‌ها به کاربر می‌رسد. بستن تسک‌ها با توضیح نتیجه مهم است: چه نسخه‌ای، چه PRای، چه معیارهایی تغییر کرده است. بر اساس داده‌های Linear (2025)، تیم‌هایی که تسک‌ها را با توضیح نتیجه می‌بندند، 40% کمتر به همان وظایف برمی‌گردند.

چرخه حیات می‌تواند وضعیت Blocked را شامل شود — تسک به دلیل وابستگی خارجی قابل انجام نیست (منتظر طراحی، پاسخ از بک‌اند، تأیید مدیر). تسک‌های Blocked باید دارای توضیح با دلیل و تاریخ بررسی بعدی باشند. بازبینی هفتگی تسک‌های Blocked به شناسایی تأخیرهای سیستمی در فرآیند توسعه کمک می‌کند. بلاکرهای بیش از 2 هفته نیاز به ارتقا به سطح مدیر محصول دارند.

سیستم‌های رهگیری وظایف

Jira — استاندارد صنعت برای تیم‌های از 10 نفر. از تابلوهای Scrum و Kanban، تنظیمات پیشرفته workflow، فیلدهای سفارشی، خودکارسازی‌ها، یکپارچه‌سازی با Bitbucket/GitHub پشتیبانی می‌کند. معایب: افزونگی برای تیم‌های کوچک، رابط کاربری کند، پیچیدگی تنظیمات. برای پروژه‌های موبایل، Jira با موارد زیر پیکربندی می‌شود: پلاگین Mobile-specific fields (Platform, OS version, Device model)، یکپارچه‌سازی با TestFlight و Firebase Test Lab، خودکارسازی ساخت بیلدهای انتشار. Jira — انتخاب پروژه‌های سازمانی با فرآیندهای بوروکراتیک.

Linear — رهگیر مدرن برای تیم‌های محصولی. رابط کاربری سریع، پشتیبانی درجه یک از میانبرهای صفحه کلید، Cycle داخلی (مشابه اسپرینت)، یکپارچه‌سازی با GitHub و Slack. مزایا: سرعت ایجاد وظایف از طریق CMD+K، توزیع خودکار در فازها (Triaged → Backlog → Upcoming → Current → Completed)، مستندات داخلی و نقشه راه. Linear را استارتاپ‌ها و تیم‌های محصولی انتخاب می‌کنند که به سرعت کار اهمیت می‌دهند. در سال 2025، 40% از پروژه‌های جدید موبایل از Linear استفاده می‌کنند.

Trello — تابلوی کانبان ساده برای تیم‌های کوچک (2-5 نفر). کارت‌هایی با چک‌لیست، برچسب، مهلت زمانی. نقص: بدون اسپرینت، تحلیل محدود، مقیاس‌پذیری دشوار. YouGile — معادل روسی Trello با تابلوهای کانبان، چت و تماس تصویری. Asana — رهگیر با تمرکز بر پروژه‌ها و جدول زمانی. انتخاب رهگیر به اندازه تیم، بودجه و ترجیحات بستگی دارد: Jira برای سازمانی، Linear برای تیم‌های محصولی، Trello/YouGile برای استارتاپ‌ها. مهم: ابزار باید برای کل تیم یکسان باشد — طراحان، توسعه‌دهندگان، تست‌کنندگان، مدیران در یک سیستم کار می‌کنند.

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

معیارهای پذیرش (Acceptance Criteria) را بنویسید — معیارهای پذیرش باید مشخص و قابل بررسی باشند. بد: «صفحه ورود کار می‌کند». خوب: «کاربر ایمیل و رمز عبور را وارد می‌کند، دکمه ورود را می‌زند. اگر داده‌ها درست باشد — انتقال به صفحه اصلی. اگر نادرست باشد — خطای «ایمیل یا رمز عبور اشتباه است» نمایش داده می‌شود». معیارهای پذیرش (AC) قراردادی بین توسعه‌دهنده، تست‌کننده و مدیر محصول است. بدون AC، تسک معیار Definition of Ready (DoR) را برآورده نمی‌کند و نباید وارد اسپرینت شود.

همه چیز را پیوند دهید. Commitها، PRها، موارد تست، طرح‌های طراحی (Figma)، بحث‌های Slack — همه باید به تسک متصل باشند. در Jira این کار از طریق لینک‌ها در نظرات، در Linear — از طریق پیوند خودکار PR انجام می‌شود. قاعده یک کلیک: از تسک تا طراحی/کد/تست — بیشتر از یک کلیک نباشد. توسعه‌دهنده تسک را باز می‌کند و بلافاصله طرح را در Figma، لینک PR و موارد تست را می‌بیند. این کار طبق داده‌های Linear (2025) باعث تسریع 30% در راه‌اندازی اعضای جدید تیم می‌شود.

تسک‌های روحی ایجاد نکنید. تسک بدون توضیحات، بدون AC و بدون اولویت — زباله است. اگر در استندآپ روزانه هیچ‌کس به خاطر نمی‌آورد که چرا تسک ایجاد شده — باید حذف یا شفاف‌سازی شود. قاعده 48 ساعت: اگر تسک به مدت 48 ساعت در وضعیت In Progress بدون فعالیت باقی بماند — توسعه‌دهنده باید در مورد دلایل تأخیر نظر بدهد. بر اساس داده‌های Jira (2025)، 60% از تسک‌هایی که بیش از 3 روز غیرفعال می‌مانند در نهایت بدون انجام بسته می‌شوند.

تجزیه وظایف: اپیک‌ها، یوزر استوری‌ها و زیروظایف

Epic — حوزه عملکردی بزرگ که داستان‌های متعددی را ترکیب می‌کند. مثال: «راه‌اندازی کاربر» شامل «صفحه خوش‌آمدگویی»، «انتخاب علایق»، «بارگذاری آواتار»، «تنظیم اعلان‌ها». User Story — وظیفه از دید کاربر. قالب: «به عنوان [نقش]، می‌خواهم [عمل] تا [ارزش]». مثال: «به عنوان کاربر، می‌خواهم با بیومتریک وارد شوم تا هر بار رمز عبور وارد نکنم». User Story توسط مدیر محصول یا مالک محصول نوشته می‌شود.

زیروظیفه (Sub-task) — تجزیه کار فنی درون Story / Task. مثال برای Story «صفحه پروفایل»: Sub-task 1: طراحی UI صفحه (XML / SwiftUI)، Sub-task 2: اتصال به ViewModel، Sub-task 3: نوشتن تست‌های واحد، Sub-task 4: تست‌های Snapshot، Sub-task 5: تست‌های UI (Espresso / XCUITest). قاعده تجزیه: هر زیروظیفه در 1-2 روز تکمیل می‌شود. اگر توسعه‌دهنده زیروظیفه را طولانی‌تر برآورد کند — بیشتر تقسیم می‌کنیم. زیروظایف تکنیک داخلی تیم هستند و در بکلاگ محصول قابل مشاهده نیستند. مجموع برآوردهای زیروظایف لزوماً برابر با برآورد Story والد نیست (بخشی از کار — ارتباطات، بازبینی کد، تست).

هرم تجزیه: Epic (سه‌ماهه / شش‌ماهه) → Feature / Story (Sprint) → Task (1-3 روز) → Sub-task (چند ساعت). تکنیک INVEST به بررسی کیفیت تجزیه کمک می‌کند. اگر تسک Independent نیست (به دیگران وابسته است) — این نشانه آن است که تجزیه نادرست است. اگر تسک Small نیست (بیش از 8 استوری پوینت) — باید بیشتر تقسیم کرد. الگوی رایج: Epic → 5-15 Stories → هر Story → 3-8 Sub-task. برآورد نهایی اپیک = مجموع برآورد Stories، اما اسپرینت اول معمولاً 20-30% خطا در برآوردها دارد.

اشتباهات رایج در کار با تسک‌ها

اشتباه 1: تسک‌های بیش از حد بزرگ. تسک 2 هفته کاری یک اپیک است که نیاز به تجزیه دارد. تسک‌های بزرگ برای رهگیری روزانه مناسب نیستند، هفته‌ها در In Progress می‌مانند. قاعده: حداکثر اندازه تسک — 2-3 روز کار. هر چیزی بزرگ‌تر — تجزیه کنید. عارضه جانبی: توسعه‌دهنده با بستن 2-3 تسک در هفته به جای یک تسک غول‌پیکر، پیشرفت را احساس می‌کند. این باعث افزایش انگیزه و قابلیت پیش‌بینی مهلت‌ها می‌شود.

اشتباه 2: فقدان معیارهای پذیرش. توسعه‌دهنده قابلیت را ساخت، تست‌کننده بررسی کرد — همه چیز خوب. مدیر: «دکمه ویرایش کجاست؟» — «در تسک نوشته نشده». بدون AC هر طرف وظیفه را به روش خود می‌فهمد. نتیجه: دوباره‌کاری، تعارضات، مهلت‌های از دست رفته. AC — قرارداد: اگر در تسک معیاری وجود ندارد — برای اسپرینت آماده نیست. در گروومینگ ابتدا وجود AC بررسی می‌شود. اگر AC وجود ندارد — تسک برای اصلاح به مدیر محصول بازگردانده می‌شود.

اشتباه 3: فراموش کردن Tech Debt. تیم فقط تسک‌های Feature را اسپرینت به اسپرینت انجام می‌دهد. پس از شش ماه: بیلد 15 دقیقه طول می‌کشد، Gradle 3 نسخه اصلی قدیمی شده، تست‌ها در CI به دلیل deprecation شکست می‌خورند. راه‌حل: 20% از زمان تیم را به Tech Debt اختصاص دهید (رویکرد Google SRE «بودجه خطای مبتنی بر SLO»). حداقل یک تسک Tech Debt برای هر اسپرینت Feature ثبت کنید. نسبت: به ازای هر 3 تسک Feature — 1 Tech Debt یا Bug. این کار از انباشت بدهی فنی جلوگیری می‌کند و سرعت توسعه را حفظ می‌کند.