ٹاسک اور ٹکٹ — یہ کیا ہیں، ٹریکنگ سسٹم اور کاموں کے ساتھ کام کرنا

ٹاسک اور ٹکٹ کیا ہیں؟

ٹاسک — ٹریکنگ سسٹم میں ریکارڈ کردہ کام کی اکائی۔ اس میں تفصیل، ترجیح (Critical, High, Medium, Low)، ذمہ دار شخص، آخری تاریخ اور حالت شامل ہے۔ موبائل ڈیولپمنٹ میں، ایک ٹاسک «ایک اوتار کے ساتھ پروفائل اسکرین شامل کریں»، «فیڈ پیجینیشن نافذ کریں» یا «targetSdk کو 35 میں اپ ڈیٹ کریں» ہو سکتا ہے۔ ہر ٹاسک ایک پروجیکٹ، سپرنٹ اور کسی خاص ڈیولپر یا ٹیم سے منسلک ہوتا ہے۔

ٹکٹ — ایک وسیع تر ہستی۔ ٹکٹ ایک بگ رپورٹ («Android 14 پر اسکرین گھمانے پر ایپ کریش ہو جاتی ہے»)، فیچر کی درخواست («ڈارک تھیم سپورٹ شامل کریں»)، تکنیکی معاونت کی پوچھ گچھ («پش نوٹیفکیشن نہیں آ رہا») یا مینیجر کا کام («مہینے کی کریش ریٹ رپورٹ تیار کریں») ہو سکتا ہے۔ ٹاسک اور ٹکٹ کے درمیان لائن دھندلی ہے: Jira میں، دونوں تصورات Issue میں یکجا ہیں۔ کلیدی فرق: ایک ٹاسک میں ہمیشہ ایک ذمہ دار شخص ہوتا ہے، جبکہ ٹکٹ ٹرائیج تک مخصوص ذمہ دار شخص کے بغیر ایک درخواست ہو سکتا ہے۔

Scrum اور Kanban میں، ٹاسک بیک لاگ کا بنیادی عنصر ہیں۔ ہر ٹاسک کو INVEST معیار (Independent, Negotiable, Valuable, Estimable, Small, Testable) پر پورا اترنا چاہیے۔ آزاد ٹاسک کسی بھی ترتیب میں لاگو کیے جا سکتے ہیں۔ قابل تخمینہ — ٹیم کوشش کا اندازہ لگا سکتی ہے۔ چھوٹے — ایک سپرنٹ میں فٹ ہوتے ہیں۔ قابل جانچ — واضح قبولیت کے معیار ہوتے ہیں۔ بڑے ٹاسک (ایپکس) چھوٹے ٹاسک میں تقسیم کیے جاتے ہیں جب تک تمام معیار پورے نہ ہو جائیں۔

موبائل ڈیولپمنٹ میں ٹاسک کی اقسام

Feature — نئی ایپلیکیشن فعالیت۔ مثال: «بایومیٹرک لاگ ان اسکرین (Face ID / Touch ID)»۔ Feature ٹاسک ہمیشہ یوزر اسٹوری سے منسلک ہوتے ہیں اور ان میں قبولیت کے معیار ہوتے ہیں۔ تخمینہ اسٹوری پوائنٹس (1, 2, 3, 5, 8, 13) میں ہوتا ہے۔ Bug — ڈیولپمنٹ یا ٹیسٹنگ کے دوران پایا گیا نقص۔ بگ ٹکٹ کی ترجیح شدت سے متعین ہوتی ہے (crash → Critical, UI بگ → Medium, ٹائپو → Low)۔ موبائل ڈیولپمنٹ میں، 0.1% سے اوپر کریش ریٹ ایک سنگین بگ ہے جسے فوری ٹھیک کرنے کی ضرورت ہے۔

Tech Debt / Chore — صارف پر کسی ظاہری اثر کے بغیر تکنیکی کام: لائبریری اپ ڈیٹس (Dependency Bump)، ری فیکٹرنگ (ViewPager سے ViewPager2 میں منتقلی)، CI/CD سیٹ اپ، ٹیسٹ لکھنا۔ Tech Debt ٹاسک اکثر کم اندازے جاتے ہیں، حالانکہ Stripe 2025 کے مطابق، موبائل ٹیم کے 30% وقت تک دیکھ بھال اور تکنیکی قرض کی ادائیگی میں صرف ہوتا ہے۔ تکنیکی قرض کو نظر انداز کرنے سے بگ بڑھتے ہیں اور نئی خصوصیات کی ترقی سست ہو جاتی ہے۔

اضافی اقسام: Spike (تحقیقی کام — نئی ٹیکنالوجی دریافت کرنا، POC لکھنا)، Task (کوئی بھی غیر کوڈ کام — دستاویزات، ڈیزائن جائزہ)، Improvement (موجودہ فعالیت کو بہتر بنانا — اسکرین لوڈ ٹائم کو بہتر بنانا)۔ Jira میں، issue کی اقسام پروجیکٹ کے مطابق حسب ضرورت ہوتی ہیں۔ موبائل ٹیم کے لیے معیاری سیٹ: Story, Bug, Task, Improvement, Epic۔ Epic — ایک بڑا موضوع جو متعدد کہانیوں کو یکجا کرتا ہے۔ مثال: «ای کامرس: کارٹ اور چیک آؤٹ»۔

ٹاسک لائف سائیکل: تخلیق سے اختتام تک

Open (To Do) — ٹاسک تخلیق ہوا لیکن شروع نہیں ہوا۔ اس میں تفصیل، قبولیت کے معیار، ترجیح شامل ہے۔ اس حالت میں، ٹاسک کو سپرنٹ میں داخل ہونے سے پہلے گرومنگ (ریفائنمنٹ اور تخمینہ) سے گزرنا ہوگا۔ In Progress — ڈیولپر نے کام شروع کر دیا۔ موبائل ڈیولپمنٹ میں، کمٹ اور پل ریکوسٹ کو ٹاسک سے منسلک کرنا ضروری ہے: Jira میں Smart Commits (APP-123 #comment fix bug) کے ذریعے، GitHub/GitLab میں PR کی تفصیل میں کلیدی الفاظ کے ذریعے (Closes APP-123)۔

In Review — کوڈ جائزہ کے لیے بھیجا گیا۔ خودکار جانچ: CI (Gradle build, lint, unit tests)، SonarQube (کوڈ کوالٹی)، Danger (changelog, tests)۔ ڈیولپر اگلا ٹاسک نہیں لے سکتا جب تک موجودہ Review میں ہے — یہ ملٹی ٹاسکنگ کو روکتا ہے۔ QA / Testing — ٹیسٹر اصلی آلات پر تصدیق کرتا ہے (Android — مختلف OS ورژن اور اسکرین سائز، iOS — مختلف iPhone ماڈلز)۔ اگر بگ پائے جاتے ہیں تو ٹاسک تبصرے کے ساتھ In Progress میں واپس آ جاتا ہے۔

Done (Closed) — ٹاسک مکمل: کوڈ main/master میں ضم، جانچ شدہ، ریلیز کے لیے تیار۔ کچھ ٹیمیں Deployed حالت شامل کرتی ہیں — ٹاسک صارف تک صرف اس وقت پہنچتا ہے جب بلڈ اسٹورز میں جاری کیا جائے۔ نتیجے کے تبصرے کے ساتھ ٹاسک بند کرنا ضروری ہے: کون سا ورژن، کون سا PR، کون سے میٹرکس بدلے۔ Linear (2025) کے مطابق، جو ٹیمیں نتیجے کی تفصیل کے ساتھ ٹاسک بند کرتی ہیں، ان کے اسی ٹاسک پر واپس آنے کا امکان 40% کم ہوتا ہے۔

لائف سائیکل میں Blocked حالت شامل ہو سکتی ہے — بیرونی انحصار کی وجہ سے ٹاسک مکمل نہیں کیا جا سکتا (ڈیزائن کا انتظار، بیک اینڈ جواب، مینیجر کی منظوری)۔ مسدود ٹاسک میں وجہ اور اگلے معائنہ کی تاریخ کے ساتھ تبصرہ ہونا چاہیے۔ مسدود ٹاسک کا ہفتہ وار جائزہ ڈیولپمنٹ کے عمل میں نظامی تاخیر کی نشاندہی کرنے میں مدد کرتا ہے۔ 2 ہفتوں سے زیادہ دیرپا رکاوٹوں کو پروڈکٹ مینیجر کی سطح تک بڑھانے کی ضرورت ہے۔

ٹاسک ٹریکنگ سسٹم

Jira — 10 یا اس سے زیادہ کی ٹیموں کے لیے صنعتی معیار۔ Scrum اور Kanban بورڈز، جدید ورک فلو حسب ضرورت، حسب ضرورت فیلڈز، آٹومیشن اور Bitbucket/GitHub انضمام کو سپورٹ کرتا ہے۔ خامیاں: چھوٹی ٹیموں کے لیے ضرورت سے زیادہ، سست UI، پیچیدہ ترتیب۔ موبائل پروجیکٹس کے لیے، Jira کو حسب ضرورت بنایا جاتا ہے: Mobile-specific fields پلگ ان (Platform, OS version, Device model)، TestFlight اور Firebase Test Lab انضمام، اور ریلیز بلڈ آٹومیشن۔ Jira بیوروکریٹک عمل والے انٹرپرائز پروجیکٹس کا انتخاب ہے۔

Linear — پروڈکٹ ٹیموں کے لیے ایک جدید ٹریکر۔ تیز UI، فرسٹ کلاس کی بورڈ شارٹ کٹ سپورٹ، بلٹ ان Cycle (سپرنٹ اینالاگ)، GitHub اور Slack انضمام۔ فوائد: CMD+K کے ذریعے فوری ٹاسک تخلیق، خودکار مرحلہ تقسیم (Triaged → Backlog → Upcoming → Current → Completed)، بلٹ ان دستاویزات اور روڈ میپ۔ Linear کو سٹارٹ اپ اور پروڈکٹ ٹیمیں منتخب کرتی ہیں جو رفتار کو اہمیت دیتی ہیں۔ 2025 میں، 40% نئے موبائل پروجیکٹس Linear استعمال کرتے ہیں۔

Trello — چھوٹی ٹیموں (2–5 افراد) کے لیے ایک سادہ کانبان بورڈ۔ چیک لسٹ، لیبلز، آخری تاریخوں والے کارڈ۔ خامی: کوئی سپرنٹ نہیں، محدود تجزیہ، پھیلانا مشکل۔ YouGile — کانبان بورڈز، چیٹ اور ویڈیو کالز کے ساتھ Trello کا روسی متبادل۔ Asana — پروجیکٹس اور ٹائم لائنز پر مرکوز ایک ٹریکر۔ ٹریکر کا انتخاب ٹیم کے سائز، بجٹ اور ترجیحات پر منحصر ہے: انٹرپرائز کے لیے Jira، پروڈکٹ ٹیموں کے لیے Linear، سٹارٹ اپ کے لیے Trello/YouGile۔ اہم: آلہ پوری ٹیم کے لیے یکساں ہونا چاہیے — ڈیزائنرز، ڈیولپرز، QA، مینیجرز سب ایک ہی سسٹم میں کام کرتے ہیں۔

ٹاسک مینجمنٹ کے بہترین طریقے

قبولیت کے معیار لکھیں — قبولیت کے معیار مخصوص اور قابل تصدیق ہونے چاہئیں۔ برا: «لاگ ان اسکرین کام کرتی ہے»۔ اچھا: «صارف ای میل اور پاس ورڈ درج کرتا ہے، لاگ ان پر کلک کرتا ہے۔ اگر ڈیٹا درست ہے تو مرکزی اسکرین پر جائیں۔ اگر غلط ہے تو «غلط ای میل یا پاس ورڈ» کی خرابی دکھائیں»۔ قبولیت کے معیار (AC) ڈیولپر، ٹیسٹر اور پروڈکٹ مینیجر کے درمیان معاہدہ ہے۔ AC کے بغیر، ٹاسک Definition of Ready (DoR) کو پورا نہیں کرتا اور سپرنٹ میں داخل نہیں ہونا چاہیے۔

سب کچھ منسلک کریں۔ کمٹ، PR، ٹیسٹ کیسز، ڈیزائن موک اپ (Figma)، Slack بحثیں — سب کچھ ٹاسک سے منسلک ہونا چاہیے۔ Jira میں، یہ تبصروں میں لنکس کے ذریعے کیا جاتا ہے؛ Linear میں، خودکار PR منسلک کرنے کے ذریعے۔ ایک کلک کا اصول: ٹاسک سے ڈیزائن/کوڈ/ٹیسٹ تک — ایک کلک سے زیادہ نہیں۔ ڈیولپر ٹاسک کھولتا ہے اور فوراً Figma موک اپ، PR لنک اور ٹیسٹ کیسز دیکھتا ہے۔ یہ Linear (2025) کے مطابق، نئے ٹیم ممبران کی شمولیت کو 30% تیز کرتا ہے۔

بھوت ٹاسک نہ بنائیں۔ بغیر تفصیل، بغیر AC اور بغیر ترجیح کے ٹاسک کوڑا ہے۔ اگر روزانہ اسٹینڈ اپ پر کسی کو یاد نہ ہو کہ ٹاسک کیوں بنایا گیا — اسے حذف یا واضح کر دینا چاہیے۔ 48 گھنٹے کا اصول: اگر کوئی ٹاسک 48 گھنٹے تک بغیر سرگرمی کے In Progress حالت میں ہے، تو ڈیولپر کو تاخیر کی وجوہات کے بارے میں تبصرہ چھوڑنا چاہیے۔ Jira (2025) کے مطابق، 3 دن سے زیادہ غیر فعال 60% ٹاسک آخر کار بغیر تکمیل کے بند ہو جاتے ہیں۔

ٹاسک کی تقسیم: ایپکس، یوزر اسٹوریز اور ذیلی ٹاسک

ایپک (Epic) — ایک بڑا فعال علاقہ جو متعدد کہانیوں کو یکجا کرتا ہے۔ مثال: «صارف کی رہنمائی» میں «خوش آمدید اسکرین»، «دلچسپی کا انتخاب»، «اوتار اپ لوڈ»، «اطلاعات کی ترتیبات» شامل ہیں۔ یوزر اسٹوری (User Story) — صارف کے نقطہ نظر سے ایک کام۔ فارمیٹ: «ایک [کردار] کے طور پر، میں [قدر] کے لیے [عمل] کرنا چاہتا ہوں»۔ مثال: «ایک صارف کے طور پر، میں بایومیٹرک سے لاگ ان کرنا چاہتا ہوں تاکہ ہر بار پاس ورڈ درج نہ کرنا پڑے»۔ یوزر اسٹوریز پروڈکٹ مینیجر یا پروڈکٹ اونر لکھتا ہے۔

ذیلی ٹاسک (Sub-task) — Story / Task کے اندر تکنیکی کام کی تقسیم۔ Story «پروفائل اسکرین» کی مثال: ذیلی ٹاسک 1: UI بنانا (XML / SwiftUI)، ذیلی ٹاسک 2: ViewModel سے منسلک کرنا، ذیلی ٹاسک 3: یونٹ ٹیسٹ لکھنا، ذیلی ٹاسک 4: سنیپ شاٹ ٹیسٹ، ذیلی ٹاسک 5: UI ٹیسٹ (Espresso / XCUITest)۔ تقسیم کا اصول: ہر ذیلی ٹاسک 1–2 دنوں میں مکمل ہوتا ہے۔ اگر ڈیولپر ذیلی ٹاسک کو لمبا اندازے لگائے تو مزید تقسیم کریں۔ ذیلی ٹاسک ایک اندرونی ٹیم تکنیک ہیں، وہ پروڈکٹ بیک لاگ میں نظر نہیں آتے۔ ذیلی ٹاسک کے اندازوں کا مجموعہ ضروری نہیں کہ والد Story کے اندازے کے برابر ہو (کچھ کام مواصلات، کوڈ جائزہ، ٹیسٹنگ ہے)۔

تقسیم کا ہرم: Epic (سہ ماہی / نصف سال) → Feature / Story (Sprint) → Task (1–3 دن) → Sub-task (کئی گھنٹے)۔ INVEST تکنیک تقسیم کے معیار کو جانچنے میں مدد کرتی ہے۔ اگر ٹاسک آزاد نہیں ہے (دوسروں پر منحصر) — یہ غلط تقسیم کی نشاندہی کرتا ہے۔ اگر ٹاسک چھوٹا نہیں ہے (8 اسٹوری پوائنٹس سے زیادہ) — مزید تقسیم کی ضرورت ہے۔ عام نمونہ: Epic → 5–15 Stories → ہر Story → 3–8 Sub-tasks۔ حتمی ایپک اندازہ = Story اندازوں کا مجموعہ، لیکن پہلا سپرنٹ عام طور پر اندازوں میں 20–30% کی خرابی کا مارجن دیتا ہے۔

ٹاسک کے ساتھ کام کرتے وقت عام غلطیاں

غلطی 1: ٹاسک بہت بڑے ہیں۔ 2 ہفتے کا ٹاسک ایک ایپک ہے جسے تقسیم کی ضرورت ہے۔ بڑے ٹاسک کو روزانہ ٹریکنگ میں ضم نہیں کیا جا سکتا؛ وہ ہفتوں تک In Progress میں رہتے ہیں۔ اصول: زیادہ سے زیادہ ٹاسک سائز — 2–3 دن کا کام۔ اس سے بڑی کوئی بھی چیز تقسیم کی جانی چاہیے۔ ضمنی اثر: ڈیولپر ایک بڑے ٹاسک کے بجائے ہفتے میں 2–3 ٹاسک بند کر کے پیشرفت محسوس کرتا ہے۔ یہ حوصلہ افزائی اور شیڈول کی پیش گوئی کو بڑھاتا ہے۔

غلطی 2: قبولیت کے معیار کی کمی۔ ڈیولپر نے فیچر لاگو کیا، ٹیسٹر نے تصدیق کی — سب ٹھیک۔ مینیجر: «ترمیم کا بٹن کہاں ہے؟» — «ٹاسک میں نہیں تھا»۔ AC کے بغیر، ہر فریق ٹاسک کو مختلف طریقے سے سمجھتا ہے۔ نتیجہ: دوبارہ کام، تنازعات، چھوٹ گئی آخری تاریخیں۔ AC ایک معاہدہ ہے: اگر ٹاسک میں کوئی معیار نہیں، تو یہ سپرنٹ کے لیے تیار نہیں۔ گرومنگ میں، سب سے پہلے AC کی موجودگی چیک کی جاتی ہے۔ اگر AC غائب ہے، تو ٹاسک ریفائنمنٹ کے لیے پروڈکٹ مینیجر کو واپس بھیج دیا جاتا ہے۔

غلطی 3: تکنیکی قرض بھول جانا۔ ٹیم سپرنٹ کے بعد سپرنٹ صرف Feature ٹاسک کرتی ہے۔ چھ ماہ بعد: بلڈ 15 منٹ لیتا ہے، Gradle 3 بڑے ورژن پیچھے ہے، ڈیپریکیشن کی وجہ سے CI پر ٹیسٹ ناکام ہوتے ہیں۔ حل: Tech Debt کے لیے ٹیم کا 20% وقت مختص کریں (Google SRE پریکٹس «SLO پر مبنی خرابی کا بجٹ»)۔ ہر Feature سپرنٹ کے لیے کم از کم ایک Tech Debt ٹاسک بنائیں۔ تناسب: ہر 3 Feature ٹاسک پر — 1 Tech Debt یا Bug۔ یہ تکنیکی قرض کے جمع ہونے کو روکتا ہے اور ڈیولپمنٹ کی رفتار برقرار رکھتا ہے۔