कार्य और टिकट — ये क्या हैं, ट्रैकिंग सिस्टम और कार्यों के साथ काम करना
कार्य और टिकट मोबाइल डेवलपमेंट ट्रैकिंग सिस्टम में काम की इकाइयाँ हैं। कार्य विवरण, प्राथमिकता, नियुक्त व्यक्ति और समय सीमा के साथ एक काम है। टिकट एक बदलाव अनुरोध, बग या सहायता पूछताछ है। मोबाइल प्रोजेक्ट्स में आमतौर पर Jira, Trello, Linear, Asana और YouGile का उपयोग किया जाता है। प्रत्येक कार्य की एक स्थिति (Open, In Progress, Review, Done), प्रकार (Feature, Bug, Tech Debt) होता है और यह एक महाकाव्य या उपयोगकर्ता कहानी से जुड़ा होता है। Atlassian 2025 के अनुसार, 78% मोबाइल डेवलपमेंट टीमें Jira का उपयोग करती हैं।
मुख्य बिंदु
- कार्य — विवरण, प्राथमिकता, नियुक्त व्यक्ति और पूर्णता स्थिति के साथ ट्रैकर में एक काम
- टिकट — बदलाव अनुरोध, बग रिपोर्ट या सहायता पूछताछ
- ट्रैकर — Jira, Linear, Trello, YouGile, Asana कार्य प्रबंधन के मुख्य उपकरण हैं
- स्थितियाँ — Open, In Progress, In Review, Done — मानक कार्य जीवनचक्र
- उचित कार्य प्रबंधन सीधे प्रक्रिया पारदर्शिता और डेवलपमेंट गति को प्रभावित करता है
कार्य और टिकट क्या हैं?
कार्य — ट्रैकिंग सिस्टम में दर्ज काम की एक इकाई। इसमें विवरण, प्राथमिकता (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 — डेवलपमेंट या परीक्षण के दौरान पाया गया दोष। बग टिकट की प्राथमिकता गंभीरता से निर्धारित होती है (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 — एक बड़ा विषय जो कई कहानियों को एकजुट करता है। उदाहरण: “ई-कॉमर्स: कार्ट और चेकआउट”।
| कार्य प्रकार | विवरण | प्राथमिकता निर्धारण | उदाहरण |
|---|---|---|---|
| Feature | नई कार्यक्षमता | उत्पाद मूल्य + व्यावसायिक प्राथमिकता | SBP के माध्यम से भुगतान के साथ ऑर्डर स्क्रीन जोड़ें |
| Bug | एप्लिकेशन दोष | गंभीरता (Critical → Minor) | Android 12 पर RecyclerView स्क्रॉल करते समय क्रैश |
| Tech Debt | तकनीकी रखरखाव और रिफैक्टरिंग | डेवलपमेंट गति पर प्रभाव | RxJava से Kotlin Coroutines में माइग्रेशन |
| Spike | अनुसंधान और प्रोटोटाइपिंग | अनिश्चितता बनाम महत्व | Compose Navigation और Cicerone की तुलना |
| Improvement | मौजूदा कार्यक्षमता में सुधार | उपयोगकर्ता प्रभाव + प्रयास | ऐप लॉन्च को 200ms तक अनुकूलित करें |
कार्य जीवनचक्र: निर्माण से समापन तक
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, प्रबंधक सभी एक ही सिस्टम में काम करते हैं।
| ट्रैकर | किसके लिए उपयुक्त | मूल्य (प्रति टीम) | मुख्य विशेषता |
|---|---|---|---|
| Jira | 10+ की टीमें, उद्यम | $7.50/उपयोगकर्ता/माह | लचीला वर्कफ़्लो, कस्टम फ़ील्ड, उन्नत ऑटोमेशन |
| Linear | उत्पाद टीमें, स्टार्टअप | $8/उपयोगकर्ता/माह | गति, Cycles, GitHub एकीकरण, कीबोर्ड शॉर्टकट |
| Trello | छोटी टीमें (2–5) | $5/उपयोगकर्ता/माह | सरलता, दृश्य कानबान बोर्ड, चेकलिस्ट |
| YouGile | रूसी टीमें | 10 लोगों तक मुफ़्त | अंतर्निहित चैट, वीडियो कॉल, कानबान बोर्ड |
| Asana | बहु-प्रोजेक्ट टीमें | $10.99/उपयोगकर्ता/माह | टाइमलाइन, Goals, Portfolios, दिनचर्या ऑटोमेशन |
कार्य प्रबंधन के लिए सर्वोत्तम अभ्यास
स्वीकृति मानदंड लिखें — स्वीकृति मानदंड विशिष्ट और सत्यापन योग्य होने चाहिए। बुरा: “लॉगिन स्क्रीन काम करती है”। अच्छा: “उपयोगकर्ता ईमेल और पासवर्ड दर्ज करता है, लॉग इन पर क्लिक करता है। यदि क्रेडेंशियल सही हैं — मुख्य स्क्रीन पर नेविगेट करें। यदि गलत हैं — त्रुटि दिखाएं “अमान्य ईमेल या पासवर्ड””। स्वीकृति मानदंड (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। यह तकनीकी ऋण संचय को रोकता है और डेवलपमेंट गति बनाए रखता है।
अक्सर पूछे जाने वाले प्रश्न
कार्य और टिकट में क्या अंतर है?
कार्य एक विशिष्ट काम है जिसमें नियुक्त व्यक्ति, अनुमान और समय सीमा होती है। टिकट एक व्यापक अवधारणा है: बग रिपोर्ट, फ़ीचर अनुरोध, सहायता पूछताछ। टिकट में ट्राइएज तक नियुक्त व्यक्ति नहीं हो सकता। Jira में, दोनों अवधारणाएँ Issue प्रकार में संयुक्त हैं, लेकिन Agile टीमों में अंतर करना आम है: कार्य = नियोजित काम, टिकट = आने वाला अनुरोध।
एक कार्य की कौन सी स्थितियाँ होती हैं?
मूल वर्कफ़्लो: Open → In Progress → In Review → QA → Done। अतिरिक्त: Blocked (दूसरी टीम पर निर्भरता), Deployed (कोड उत्पादन में), Reopened (बग ठीक नहीं हुआ)। प्रत्येक टीम अपनी प्रक्रियाओं के अनुसार स्थितियों को अनुकूलित कर सकती है। 7 से अधिक सक्रिय स्थितियों की अनुशंसा नहीं की जाती — अत्यधिक मात्रा ट्रैकिंग को धीमा करती है और टीम को भ्रमित करती है।
एक स्टार्टअप को कौन सा ट्रैकर चुनना चाहिए?
10 लोगों तक के स्टार्टअप के लिए, Linear (तेज़, उत्पाद-उन्मुख) या Trello (मुफ़्त, सरल) इष्टतम हैं। Linear बेहतर है यदि विकास और Scrum में संक्रमण की योजना है। Trello MVP चरण के लिए है जब आपको जल्दी से बुनियादी ट्रैकिंग सेट करने की आवश्यकता होती है। Jira एक स्टार्टअप के लिए अत्यधिक है: वर्कफ़्लो सेटअप में सप्ताह लगते हैं और बुनियादी कार्यक्षमता अतिभारित होती है।
कार्यों का सही अनुमान कैसे लगाएँ?
सापेक्ष अनुमान के लिए Story Points (1, 2, 3, 5, 8, 13) का उपयोग करें। स्टोरी पॉइंट्स को घंटों से न जोड़ें — यह जटिलता का एक सापेक्ष माप है। तकनीकें: Poker Planning (Planning Poker), T-Shirt Sizing (S/M/L/XL), Affinity Estimation। अनुमान में शामिल है: कोड + परीक्षण + दस्तावेज़ीकरण + समीक्षा। अधिक अनुमानित कार्य (8 SP से अधिक) को विघटन की आवश्यकता है। अनुमान सटीकता टीम के अनुभव के साथ सुधरती है: 3–4 स्प्रिंट के बाद, त्रुटि मार्जिन घटकर ±20% हो जाता है।
यदि कोई कार्य अवरुद्ध है तो क्या करें?
स्थिति को Blocked पर सेट करें जिसमें कारण बताने वाली टिप्पणी हो: “25 जुलाई तक Figma से स्क्रीन डिज़ाइन की प्रतीक्षा”, “कार्य APP-456 (API एंडपॉइंट) पर निर्भर”। डेवलपर निष्क्रिय नहीं बैठता — वह दूसरे कार्य पर स्विच करता है। सप्ताह में एक बार, प्रबंधक सभी अवरुद्ध कार्यों की समीक्षा करता है और अपने स्तर पर समस्या हल करता है। यदि कोई अवरोधक 2 सप्ताह से अधिक रहता है — उत्पाद टीम को एस्केलेट करें।
सारांश
- कार्य — नियुक्त व्यक्ति और समय सीमा के साथ काम की इकाई; टिकट एक अधिक सामान्य बदलाव अनुरोध या पूछताछ है
- कार्य प्रकार — Feature, Bug, Tech Debt, Spike, Improvement — प्रत्येक का अपना उद्देश्य और प्राथमिकता निर्धारण
- जीवनचक्र — Open → In Progress → Review → QA → Done अतिरिक्त Blocked और Deployed स्थितियों के साथ
- ट्रैकर — Jira (उद्यम), Linear (उत्पाद), Trello/YouGile (स्टार्टअप), चुनाव टीम के आकार पर निर्भर करता है
- विघटन — Epic → Story → Task → Sub-task INVEST नियम के साथ (Independent, Small, Testable)
- सर्वोत्तम अभ्यास — स्वीकृति मानदंड अनिवार्य, सभी आर्टिफैक्ट को कार्य से लिंक करें, 20% समय Tech Debt पर
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें