টাস্ক এবং টিকিট — কী এগুলো, ট্র্যাকিং সিস্টেম এবং টাস্ক নিয়ে কাজ করা

টাস্ক এবং টিকিট কী?

টাস্ক — ট্র্যাকিং সিস্টেমে রেকর্ড করা কাজের একটি একক। এতে বিবরণ, অগ্রাধিকার (Critical, High, Medium, Low), দায়িত্বপ্রাপ্ত ব্যক্তি, সময়সীমা এবং অবস্থা থাকে। মোবাইল ডেভেলপমেন্টে, একটি টাস্ক হতে পারে “অ্যাভাটারসহ প্রোফাইল স্ক্রিন যোগ করুন”, “ফিড পেজিনেশন বাস্তবায়ন করুন” বা “targetSdk 35-এ আপডেট করুন”। প্রতিটি টাস্ক একটি প্রকল্প, স্প্রিন্ট এবং নির্দিষ্ট ডেভেলপার বা টিমের সাথে সংযুক্ত।

টিকিট — একটি বিস্তৃত সত্তা। টিকিট একটি বাগ রিপোর্ট (“Android 14-এ স্ক্রিন ঘোরালে অ্যাপ ক্র্যাশ হয়”), ফিচার অনুরোধ (“ডার্ক থিম সমর্থন যোগ করুন”), টেকনিক্যাল সাপোর্ট জিজ্ঞাসা (“পুশ নোটিফিকেশন আসছে না”) বা ম্যানেজারের কাজ (“মাসের ক্র্যাশ রেট রিপোর্ট প্রস্তুত করুন”) হতে পারে। টাস্ক এবং টিকিটের মধ্যে রেখা অস্পষ্ট: Jira-তে, উভয় ধারণা Issue-তে একত্রিত। মূল পার্থক্য: একটি টাস্কে সবসময় একজন দায়িত্বপ্রাপ্ত ব্যক্তি থাকে, যেখানে টিকিট ট্রায়াজ পর্যন্ত নির্দিষ্ট দায়িত্বপ্রাপ্ত ব্যক্তি ছাড়া একটি অনুরোধ হতে পারে।

Scrum এবং Kanban-এ, টাস্ক ব্যাকলগের প্রধান উপাদান। প্রতিটি টাস্ককে INVEST মানদণ্ড (Independent, Negotiable, Valuable, Estimable, Small, Testable) পূরণ করতে হবে। স্বাধীন টাস্ক যেকোনো ক্রমে বাস্তবায়ন করা যেতে পারে। অনুমানযোগ্য — টিম প্রচেষ্টা অনুমান করতে পারে। ছোট — একটি স্প্রিন্টে ফিট করে। পরীক্ষণযোগ্য — স্পষ্ট গ্রহণযোগ্যতার মানদণ্ড রয়েছে। বড় টাস্ক (এপিক) ছোট টাস্কে ভাগ করা হয় যতক্ষণ না সব মানদণ্ড পূরণ হয়।

মোবাইল ডেভেলপমেন্টে টাস্কের ধরন

Feature — নতুন অ্যাপ্লিকেশন কার্যকারিতা। উদাহরণ: “বায়োমেট্রিক লগইন স্ক্রিন (Face ID / Touch ID)”। ফিচার টাস্ক সবসময় ইউজার স্টোরির সাথে সংযুক্ত থাকে এবং গ্রহণযোগ্যতার মানদণ্ড থাকে। অনুমান স্টোরি পয়েন্টে (1, 2, 3, 5, 8, 13) হয়। Bug — ডেভেলপমেন্ট বা টেস্টিংয়ের সময় পাওয়া ত্রুটি। বাগ টিকিটের অগ্রাধিকার গুরুত্বতার (severity) দ্বারা নির্ধারিত হয় (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: Snapshot Tests, সাব-টাস্ক 5: UI Tests (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। এটি প্রযুক্তিগত ঋণ জমা হওয়া প্রতিরোধ করে এবং ডেভেলপমেন্ট গতি বজায় রাখে।