14 दिस॰ 2025·7 मिनट
Claude Code टास्क स्कोपिंग: अस्पष्ट अनुरोधों से कमिट्स तक
Claude Code टास्क स्कोपिंग सीखें ताकि अव्यवस्थित फीचर अनुरोधों को स्पष्ट स्वीकृति मानदंड, एक न्यूनतम UI/API योजना और कुछ छोटे कमिट्स में बदला जा सके।
अस्पष्ट फीचर अनुरोध क्यों समय बर्बाद करते हैं
एक अस्पष्ट अनुरोध मासूम लग सकता है: “बेहतर सर्च जोड़ो”, “ऑनबोर्डिंग को सहज बनाओ”, “यूज़र्स को नोटिफिकेशन चाहिए।” वास्तविक टीमों में यह अक्सर एक-लाइन की चैट, तीरों के साथ एक स्क्रीनशॉट, या आधा-याद किया हुआ कस्टमर कॉल के रूप में आता है। हर कोई सहमत होता है, पर हर किसी के दिमाग में कुछ अलग होता है।
लागत बाद में दिखती है। जब स्कोप अस्पष्ट होता है, तो लोग अनुमान पर काम बनाते हैं। पहला डेमो एक और राउंड ऑफ़ क्लैरिफिकेशन बन जाता है: “यह वही नहीं था जो मैंने माना।” काम दोबारा किया जाता है, और बदलाव धीरे-धीरे बढ़ता चला जाता है। डिज़ाइन के छोटे बदलाव कोड परिवर्तन ट्रिगर करते हैं, जो और अधिक टेस्टिंग को बुलाते हैं। रिव्यू धीमे पड़ जाते हैं क्योंकि एक धुँधला परिवर्तन सत्यापित करना मुश्किल होता है। अगर कोई यह परिभाषित नहीं कर सकता कि “सही” क्या दिखता है, तो समीक्षक व्यवहार पर बहस करते हुए गुणवत्ता की जाँच करने के बजाय बहस में फँस जाते हैं।
आप आम तौर पर एक अस्पष्ट टास्क को जल्दी पहचान सकते हैं:
- उपयोगकर्ता क्या कर पाएगा इसका चरण-दर-चरण उदाहरण नहीं है
- एज केस (खाली राज्य, अनुमतियाँ, त्रुटियाँ) शामिल नहीं हैं
- “सुरक्षित रहने के लिए” कार्य जो एक विशाल PR में बदल जाता है
- रिव्यू कमेंट्स व्यवहार पर बहस कर रहे हैं, न कि इम्प्लीमेंटेशन पर
- “हम चलते-चलते ठीक कर लेंगे” बन जाता है योजना
एक अच्छी तरह स्कोप्ड टास्क टीम को एक अंतिम लक्ष्य देता है: स्पष्ट स्वीकृति मानदंड, एक न्यूनतम UI और API योजना, और स्पष्ट सीमाएँ कि क्या शामिल नहीं है। यही फर्क है “सर्च सुधारें” और एक छोटे बदलाव के बीच जिसे बनाना और रिव्यू करना आसान हो।
एक व्यावहारिक आदत: “Definition of done” को “nice-to-have” से अलग रखें। “Done” उन अल्पसूची जाँचों की एक छोटी सूची है जिन्हें आप चला कर सत्यापित कर सकते हैं (उदा.: “Search शीर्षक द्वारा परिणाम लौटाए, खाली होने पर ‘No results’ दिखे, और क्वेरी URL में बनी रहे”)। “Nice-to-have” वे चीज़ें हैं जो बाद में हो सकती हैं (साइनोनिम्स, रैंकिंग ट्वीक, हाइलाइटिंग, analytics)। पहले से इन्हें लेबल करना आकस्मिक स्कोप वृद्धि को रोकता है।
परिणाम से शुरू करें, समाधान से नहीं
अस्पष्ट अनुरोध अक्सर सुझाए गए फिक्स के रूप में आते हैं: “एक बटन जोड़ो”, “नया फ्लो बदलो”, “एक अलग मॉडल उपयोग करो।” रुकें और सुझाव को पहले एक परिणाम में अनुवादित करें।
एक सरल फॉर्मेट मदद करता है: “As a [user], I want to [do something], so I can [reach a goal].” इसे सादा रखें। अगर आप इसे एक साँस में नहीं कह सकते, तो यह अभी भी बहुत धुँधला है।
इसके बाद लिखें कि पूरा होने पर उपयोगकर्ता के लिए क्या बदलता है। दृश्य व्यवहार पर फोकस रखें, इम्प्लीमेंटेशन विवरण पर नहीं। उदाहरण: “फॉर्म सबमिट करने के बाद, मुझे एक कन्फर्मेशन दिखता है और मैं नई रिकॉर्ड को सूची में ढूँढ सकता हूँ।” यह एक स्पष्ट फिनिश लाइन बनाता है और “एक और छोटा ट्वीक” के बीच घुसपैठ को मुश्किल बनाता है।
यह भी लिखें कि क्या वही रहेगा। नॉन-गोल आपकी स्कोप की रक्षा करते हैं। अगर अनुरोध “ऑनबोर्डिंग सुधारें” है, तो एक नॉन-गोल हो सकता है “कोई डैशबोर्ड रीडिज़ाइन नहीं” या “कोई प्राइसिंग-टियर लॉजिक परिवर्तन नहीं।”
अंत में, पहले एक प्राथमिक पाथ चुनें: वेब-एंड-टू-एंड स्लाइस जो साबित करे कि फीचर काम करता है।
उदाहरण: “हर जगह snapshots जोड़ने” के बजाय लिखें: “As a project owner, I can restore the latest snapshot of my app, so I can undo a bad change.” नॉन-गोल: “कोई bulk restore नहीं, कोई UI redesign नहीं।”
Ambiguity हटाने वाले कुछ सवाल पूछें
एक अस्पष्ट अनुरोध अक्सर मेहनत की कमी नहीं, बल्कि निर्णयों की कमी होती है।
शुरू करें उन प्रतिबंधों से जो चुपके से स्कोप बदलते हैं। डेडलाइन मायने रखती है, पर साथ ही एक्सेस रूल्स और कंप्लायंस जरूरतें भी। अगर आप प्लेटफ़ॉर्म पर बना रहे हैं जिसमें टियर और रोल्स हैं, तो जल्दी तय करें किसे फीचर मिलेगा और किस प्लान पर।
फिर एक ठोस उदाहरण माँगें। एक स्क्रीनशॉट, प्रतियोगी का व्यवहार, या पिछला टिकट यह दिखा देता है कि “बेहतर” का आशय क्या है। अगर अनुरोधकर्ता के पास कुछ नहीं है, तो उनसे पूछें कि आख़िरी बार दर्द कब महसूस हुआ: वे किस स्क्रीन पर थे, क्या क्लिक किया और क्या उम्मीद थी?
एज केस वही जगह है जहाँ स्कोप बढ़ता है, इसलिए बड़े मामलों का जल्दी नाम लें: खाली डेटा, वैलिडेशन त्रुटियाँ, धीमा/फेल नेटवर्क कॉल, और “undo” का वास्तव में क्या मतलब है।
अंत में तय करें कि आप सफलता कैसे सत्यापित करेंगे। बिना टेस्टेबल परिणाम के, टास्क रायों में बदल जाता है।
ये पाँच सवाल अक्सर अधिकांश अस्पष्टता दूर कर देते हैं:
- किसे एक्सेस मिलेगा (टियर और रोल्स)?
- डेडलाइन क्या है, और सबसे छोटा स्वीकार्य वर्शन क्या है?
- अपेक्षित व्यवहार का एक उदाहरण क्या है?
- खाली राज्यों, त्रुटियों और धीमे कनेक्शनों में क्या होना चाहिए?
- हम कैसे पुष्टि करेंगे कि यह काम करता है (विशिष्ट मानदंड या मेट्रिक)?
उदाहरण: “Add custom domains for clients” तब अधिक स्पष्ट हो जाता है जब आप तय कर लें कि यह किस टियर का है, कौन इसे सेट कर सकता है, होस्टिंग लोकेशन कंप्लायंस के लिए मायने रखता है या नहीं, invalid DNS पर कौन सी त्रुटि दिखेगी, और “done” का मतलब क्या है (डोमेन verified, HTTPS active, और सुरक्षित rollback योजना)।
गंदे नोट्स को स्वीकृति मानदंडों में बदलें
गंदे अनुरोध लक्ष्य, अनुमान और आधा-याद एज केस मिलाते हैं। काम यह है कि उसे ऐसे कथनों में बदलना जो कोई भी आपकी दिमाग पढ़े बिना टेस्ट कर सके। वही मानदंड डिज़ाइन, कोडिंग, रिव्यू और QA को निर्देशित करने चाहिए।
एक सरल पैटर्न इसे साफ रखता है। आप Given/When/Then का प्रयोग कर सकते हैं, या छोटे बुलेट्स जो वही अर्थ रखते हैं।
एक त्वरित स्वीकृति-मानदंड टेम्पलेट
प्रत्येक मानदंड को एक ऐसे टेस्ट के रूप में लिखें जिसे कोई चला सके:
- Given एक प्रारंभिक स्थिति, when उपयोगकर्ता X करता है, then Y होता है।
- वैलिडेशन नियम शामिल करें (कौन से इनपुट स्वीकार्य हैं)।
- कम से कम एक फ़ेलियर केस शामिल करें (उपयोगकर्ता कौन सी त्रुटि देखेगा)।
- “Done signal” परिभाषित करें (QA क्या जाँचेगा, समीक्षक क्या उम्मीद करेंगे)।
अब इसे लागू करें। मान लीजिए नोट कहता है: “Snapshots को आसान बनाओ। मैं रोलबैक करना चाहता हूँ अगर आख़िरी बदलाव बिगाड़ दे।” इसे टेस्टेबल स्टेटमेंट्स में बदलें:
- Given एक प्रोजेक्ट में 2 snapshots हैं, जब मैं Snapshots खोलता हूँ, तब मुझे दोनों समय और एक छोटा लेबल के साथ दिखते हैं।
- Given एक snapshot है, जब मैं Roll back पर क्लिक कर के confirm करता हूँ, तब प्रोजेक्ट उस snapshot पर लौटता है और ऐप सफलतापूर्वक build होता है।
- Given मैं प्रोजेक्ट का मालिक नहीं हूँ, जब मैं rollback करने की कोशिश करता हूँ, तब मुझे एक त्रुटि दिखती है और कुछ भी बदलता नहीं है।
- Given एक rollback प्रगति में है, जब मैं पेज रिफ्रेश करता हूँ, तब भी मैं स्थिति और अंतिम परिणाम देख पाता हूँ।
- Given rollback फेल होता है, जब यह रुकता है, तब मुझे एक स्पष्ट संदेश दिखे और वर्तमान वर्शन सक्रिय बना रहे।
अगर QA इन चेक्स को चला सके और समीक्षक UI और लॉग्स में इन्हें सत्यापित कर सकें, तो आप UI और API कार्य की योजना बना कर उसे छोटे कमिट्स में विभाजित कर सकते हैं।
एक न्यूनतम UI योजना ड्राफ्ट करें
एक न्यूनतम UI प्लान एक वादा है: सबसे छोटा दृश्य परिवर्तन जो साबित करे कि फीचर काम करता है।
शुरू करें यह नामित करके कि कौन-कौन सी स्क्रीन बदलेगी और 10 सेकंड में उपयोगकर्ता क्या नोटिस करेगा। अगर अनुरोध कहता है “इसे आसान बनाओ” या “साफ़ करें”, तो उसे एक सुस्पष्ट परिवर्तन में बदलें जिसे आप इंगित कर सकें।
इसे एक छोटे नक्शे के रूप में लिखें, redesign के बजाय। उदाहरण: “Orders पृष्ठ: टेबल के ऊपर एक filter bar जोड़ें”, या “Settings: Notifications के अंतर्गत एक नया toggle जोड़ें।” यदि आप स्क्रीन और सटीक एलिमेंट का नाम नहीं बता सकते, तो स्कोप अभी भी अस्पष्ट है।
मुख्य UI अवस्थाएँ परिभाषित करें
अधिकतर UI बदलावों को कुछ प्रत्याशित अवस्थाएँ चाहिए। केवल वही लिखें जो लागू हों:
- Loading
- Empty
- Error (और क्या retry है)
- Success (toast, inline संदेश, अपडेटेड सूची)
उपयोगकर्ताओं को दिखने वाले शब्दों की पुष्टि करें
UI कॉपी भी स्कोप का हिस्सा है। उन लेबल्स और संदेशों को कैप्चर करें जिन्हें अनुमोदित करना ज़रूरी है: बटन टेक्स्ट, फ़ील्ड लेबल, हेल्पर टेक्स्ट, और त्रुटि संदेश। अगर शब्दावली अभी खुली है, तो उसे placeholder के रूप में चिन्हित करें और नोट करें कि कौन पुष्टि करेगा।
जो भी उपयोग करने के लिए आवश्यक नहीं है (responsive polish, advanced sorting, animations, नए आइकन) उसे “not now” सूची में रखें।
एक न्यूनतम API और डेटा योजना ड्राफ्ट करें
बनाएँ और क्रेडिट कमाएँ
Koder.ai साझा करके या दूसरों को आमंत्रित कर के क्रेडिट अर्जित करें।
एक स्कोप्ड टास्क के लिए UI, बैकएंड और डेटा के बीच एक छोटा, स्पष्ट कॉन्ट्रैक्ट चाहिए। लक्ष्य पूरा सिस्टम डिजाइन करना नहीं, बल्कि उन न्यूनतम रिक्वेस्ट्स और फ़ील्ड्स को परिभाषित करना है जो फीचर को साबित करें।
शुरू करें यह सूची बनाकर कि आपको कौन सा डेटा चाहिए और यह कहाँ से आता है: मौजूदा फ़ील्ड जो आप पढ़ सकते हैं, नए फ़ील्ड जिन्हें आपको सहेजना होगा, और मूल्य जो आप compute कर सकते हैं। अगर आप हर फ़ील्ड का स्रोत नहीं बता सकते, तो आपके पास अभी योजना नहीं है।
API सरफेस छोटा रखें। कई फीचरों के लिए एक read और एक write काफी होते हैं:
GET /items/{id}स्क्रीन render करने के लिए आवश्यक स्थिति लौटाता हैPOST /items/{id}/updateकेवल वही स्वीकार करता है जिसे उपयोगकर्ता बदल सकता है और अपडेटेड स्थिति लौटाता है
इनपुट और आउटपुट को साधारण ऑब्जेक्ट्स की तरह लिखें, न कि पैराग्राफ्स की तरह। आवश्यक बनाम वैकल्पिक फ़ील्ड शामिल करें, और सामान्य त्रुटियों पर क्या होता है (not found, validation failed)।
डेटाबेस छेड़ने से पहले एक त्वरित auth पास करें। तय करें कौन पढ़ सके और कौन लिख सके, और नियम एक वाक्य में लिखें (उदा.: “किसी भी साइन-इन उपयोगकर्ता पढ़ सकता है, केवल admins लिख सकते हैं”)। इसे छोड़ने से अक्सर रीवर्क होता है।
अंत में, तय करें क्या स्टोर करना है और क्या compute किया जा सकता है। एक सरल नियम: तथ्य स्टोर करें, व्यूज़ compute करें।
Claude Code का उपयोग करके एक स्कोप्ड टास्क बनाएं
Claude Code सबसे अच्छा तब काम करता है जब आप उसे एक स्पष्ट लक्ष्य और एक तंग बॉक्स दें। गंदे अनुरोध और कोई भी प्रतिबंध (डेडलाइन, प्रभावित उपयोगकर्ता, डेटा नियम) पेस्ट करके शुरू करें। फिर स्कोप्ड आउटपुट माँगें जिसमें शामिल हो:
- स्कोप की सादा भाषा में पुनर्लेखन और एक छोटा स्वीकृति-मानदंड चेकलिस्ट।
- 3–7 छोटे कमिट्स की एक श्रृंखला, हर एक का स्पष्ट आउटकम।
- हर कमिट के लिए संभावित फ़ाइलें या फ़ोल्डर और उनमें क्या बदलाव होंगे।
- हर कमिट के लिए एक त्वरित टेस्ट प्लान (एक हैप्पी पाथ और एक एज केस)।
- स्पष्ट रूप से आउट-ऑफ़-स्कोप नोट्स।
जवाब आने के बाद, उसे एक समीक्षक की तरह पढ़ें। अगर आप “improve performance” या “make it cleaner” जैसे वाक्य देखें, तो मापनीय शब्द माँगें।
छोटा उदाहरण (क्या “अच्छा” दिखता है)
Request: “Add a way to pause a subscription.”
एक स्कोप्ड वर्शन कह सकता है: “User 1 से 3 महीनों के लिए pause कर सकता है; अगला बिलिंग डेट अपडेट होता है; admin pause स्टेटस देख सकता है,” और out of scope: “कोई proration परिवर्तन नहीं।”
वहां से, कमिट प्लान व्यावहारिक बन जाता है: एक कमिट DB और API शपेश के लिए, एक UI कंट्रोल्स के लिए, एक वैलिडेशन और एरर स्टेट्स के लिए, और एक end-to-end टेस्ट के लिए।
काम को छोटे, रिव्यू करने योग्य कमिट्स में बाँटें
आउटपुट का मालिक बनें
जब आवश्यक हो तो स्रोत कोड निर्यात करके अपने विकल्प खुले रखें।
बड़े बदलाव बग्स छिपाते हैं। छोटे कमिट्स रिव्यूज़ तेज बनाते हैं, रॉलबैक सुरक्षित करते हैं, और आपको नोटिस करने में मदद करते हैं जब आप स्वीकृति मानदंड से भटक रहे हों।
एक उपयोगी नियम: हर कमिट को एक नया व्यवहार अनलॉक करना चाहिए, और उसे प्रमाणित करने का एक त्वरित तरीका शामिल होना चाहिए।
एक सामान्य अनुक्रम ऐसा दिखता है:
- डेटा मॉडल या migration (यदि आवश्यक) साथ में टेस्ट
- API व्यवहार और वैलिडेशन
- UI वायरिंग with empty और error states
- केवल यदि आवश्यक हो तो logging या analytics और फिर छोटा polish
हर कमिट को केंद्रित रखें। “While I’m here” रिफैक्टर्स से बचें। ऐप को end-to-end काम करते हुए रखें, भले UI बेसिक ही क्यों न हो। माईग्रेशन्स, व्यवहार और UI को एक ही कमिट में बैच में न रखें जब तक मजबूर वजह न हो।
Walkthrough: “Export reports”
एक स्टेकहोल्डर कहता है: “क्या हम Export reports जोड़ सकते हैं?” इसमें बहुत सी चुनौतियाँ छिपी होती हैं: कौन सा रिपोर्ट, कौनसा फ़ॉर्मेट, कौन एक्सपोर्ट कर सकता है, और डिलीवरी कैसे होगी।
सिर्फ़ उन सवालों को पूछें जो डिजाइन बदलते हैं:
- v1 के लिए कौन सा रिपोर्ट टाइप स्कोप में है?
- v1 के लिए कौन सा फ़ॉर्मेट चाहिए (CSV, PDF)?
- कौन एक्सपोर्ट कर सकता है (admins, specific roles)?
- क्या यह डायरेक्ट डाउनलोड है या ईमेल्ड एक्सपोर्ट?
- क्या लिमिट्स हैं (डेट रेंज मैक्स, row count cap, timeouts)?
मान लीजिए उत्तर हैं: “Sales Summary report, केवल CSV, manager role, डायरेक्ट डाउनलोड, पिछले 90 दिनों तक मैक्स।” अब v1 स्वीकृति मानदंड ठोस बन जाते हैं: मैनेजर्स Sales Summary पेज पर Export पर क्लिक कर सकते हैं; CSV ऑन-स्क्रीन टेबल कॉलम से मेल खाता है; एक्सपोर्ट करंट फ़िल्टर्स का पालन करता है; 90 दिनों से अधिक पर एक स्पष्ट त्रुटि दिखती है; 50k रो तक 30 सेकंड में डाउनलोड पूरा होता है।
न्यूनतम UI प्लान: टेबल एक्शंस के पास एक Export बटन, जेनरेट करते समय एक लोडिंग स्टेट, और एक त्रुटि संदेश जो उपयोगकर्ता को सुधार का तरीका बताये (जैसे “90 दिन या कम चुनें”)।
न्यूनतम API प्लान: एक endpoint जो फिल्टर्स लेता है और जनरेट किया गया CSV फ़ाइल रिस्पॉन्स के रूप में लौटाता है, टेबल जैसी ही क्वेरी को पुन: उपयोग करते हुए और 90-दिन नियम सर्वर-साइड लागू करते हुए।
फिर इसे कुछ तंग कमिट्स में भेजें: पहले फिक्स्ड हैप्पी-पाथ के लिए endpoint, फिर UI वायरिंग, फिर वैलिडेशन और यूज़र-फेसिंग त्रुटियाँ, फिर टेस्ट और डॉक्यूमेंटेशन।
सामान्य स्कोपिंग खामियाँ (और उनसे कैसे बचें)
छिपे हुए आवश्यकताएँ आ जाती हैं
“add team roles” जैसे अनुरोध अक्सर इंसान जोड़ने, संपादित करने, और मौजूदा उपयोगकर्ताओं के साथ क्या होता है, के नियम छिपाते हैं। अगर आप अनुमान लगा रहे हैं, तो वह मान्यता लिख दें और उसे सवाल या स्पष्ट नियम में बदल दें।
UI पॉलिश को मूल व्यवहार के साथ मिला दिया जाता है
जब एक ही टास्क में “काम कराओ” और “खूबसूरत बनाओ” दोनों शामिल होते हैं, टीम दिन गँवा देती है। पहला टास्क व्यवहार और डेटा पर केन्द्रित रखें। स्टाइलिंग, एनिमेशन और स्पेसिंग को फ़ॉलो-अप टास्क में रखें जब तक वे उपयोग के लिए ज़रूरी न हों।
आप v1 में हर एज केस हल करने की कोशिश करते हैं
एज केस महत्वपूर्ण हैं, पर सभी को तुरंत हल करने की जरूरत नहीं। वे जिन्हें भरोसा तोड़ने का खतरा हो (double submits, conflicting edits) उन्हीं को संभालें और बाकी को स्पष्ट नोट्स के साथ टाल दें।
त्रुटि स्थितियाँ और अनुमतियाँ बाद में डाल दी जाती हैं
अगर आप उन्हें लिखते नहीं हैं, तो आप उन्हें भूल जाएंगे। अपने स्वीकृति मानदंड में कम से कम एक unhappy path और एक permission नियम शामिल करें।
ऐसे मानदंड जिन्हें आप सत्यापित नहीं कर सकते
“Fast” या “intuitive” जैसे शब्दों से बचें जब तक आप उन पर संख्या या ठोस चेक न जोड़ें। उन्हें ऐसे शब्दों से बदलें जिन्हें आप रिव्यू में प्रमाणित कर सकें।
कोडिंग शुरू करने से पहले त्वरित चेकलिस्ट
UI अवस्थाएँ स्पष्ट करें
परिणामों को वास्तविक UI अवस्थाओं में अनुवादित करें: loading, empty, error, और success।
टास्क को पिन करें ताकि एक साथी बिना माइंड-रीडिंग के रिव्यू और टेस्ट कर सके:
- परिणाम और नॉन-गोल: परिणाम के लिए एक वाक्य और 1–3 स्पष्ट नॉन-गोल्स।
- स्वीकृति मानदंड: 5–10 टेस्टेबल चेक्स सादा भाषा में।
- UI अवस्थाएँ: न्यूनतम loading, empty, error, और success।
- API और डेटा नोट्स: सबसे छोटा endpoint आकार और कोई डेटा परिवर्तन, साथ में कौन पढ़/लिख सकता है और कौन लिख सकता है।
- कमिट प्लान और टेस्ट: 3–7 कमिट, हर एक के साथ एक त्वरित प्रूफ।
उदाहरण: “Add saved searches” बन जाता है “Users एक फ़िल्टर सेव कर सकते हैं और बाद में उसे फिर से लागू कर सकते हैं,” नॉन-गोल्स जैसे “कोई sharing नहीं” और “कोई sorting परिवर्तन नहीं।”
अगले कदम: बनाते समय स्कोप स्थिर रखें
एक बार जब आपके पास स्कोप्ड टास्क हो, तो इसे संरक्षित करें। कोडिंग से पहले, उनसे एक त्वरित सैनीटी रिव्यू कराएं जिनसे आपने परिवर्तन माँगा था:
- स्वीकृति मानदंड पढ़ें और पुष्टि करें कि यह परिणाम से मेल खाता है।
- अनुमतियाँ, खाली राज्य और फ़ेलियर व्यवहार की पुष्टि करें।
- क्या आउट ऑफ़ स्कोप है उसे फिर से पुष्टि करें।
- तय करें कि सबसे छोटी UI और API बदल क्या होंगे जो मानदंड को पूरा करें।
- तय करें कि आप इसे कैसे डेमो करेंगे और “done” क्या दिखता है।
फिर मानदंड को उस जगह स्टोर करें जहाँ काम हो रहा है: टिकट में, PR विवरण में, और जहाँ आपकी टीम वास्तव में देखती है वहाँ।
अगर आप Koder.ai (koder.ai) में बना रहे हैं, तो पहले योजना लॉक करना मददगार होता है और फिर उससे कोड जनरेट करें। Planning Mode इस वर्कफ़्लो के लिए उपयुक्त है, और snapshots और rollback प्रयोगों को सुरक्षित रख सकते हैं जब आपको किसी तरीके को आज़माना और वापस लेना पड़े।
जब निर्माण के दौरान नए आइडियाज़ आते हैं, तो स्कोप को स्थिर रखें: उन्हें फ़ॉलो-अप सूची में लिखें, यदि वे स्वीकृति मानदंड बदलते हैं तो रि-स्कोप के लिए रुकें, और कमिट्स को एक-एक मानदंड से बाँधे रखें।
अक्सर पूछे जाने वाले प्रश्न
कैसे पता चले कि फीचर अनुरोध निर्माण शुरू करने के लिए बहुत अस्पष्ट है?
एक वाक्य में परिणाम लिखकर शुरू करें (जब यह पूरा हो, उपयोगकर्ता क्या कर पाएगा), फिर 3–7 स्वीकृति मानदंड जोड़ें जिन्हें परीक्षणकर्ता सत्यापित कर सके।
यदि आप बिना बहस किए “सही” व्यवहार का वर्णन नहीं कर पा रहे हैं, तो कार्य अभी भी अस्पष्ट है।
“X को बेहतर बनाएं” को स्पष्ट परिणाम में सबसे तेज़ कैसे बदलें?
तेज़ तरीका यह है:
- As a [user]
- I want to [action]
- So I can [goal]
फिर अपेक्षित व्यवहार का एक ठोस उदाहरण जोड़ें। अगर आप उदाहरण नहीं दे सकते, तो आख़िरी बार जब समस्या आई थी उसे दोहराएँ: उपयोगकर्ता किस स्क्रीन पर था, किसपर क्लिक किया और क्या उम्मीद थी।
“Done” और “Nice-to-have” को बिना लंबी बहस के कैसे अलग रखें?
पहले एक छोटा "Definition of done" लिखें (वे चेक जो पास होने चाहिए), फिर अलग से "Nice-to-have" सूची बनाएं。
डिफ़ॉल्ट नियम: अगर वह फीचर end-to-end काम साबित करने के लिए ज़रूरी नहीं है, तो वह nice-to-have में रखा जाए।
कौन से प्रश्न शुरुआती अस्पष्टता को सबसे अधिक दूर करते हैं?
उन कुछ सवालों को पूछें जो स्कोप बदलते हैं:
- किसे एक्सेस मिलेगा (tier और roles)?
- डेडलाइन क्या है, और सबसे छोटी स्वीकार्य वर्ज़न क्या है?
- अपेक्षित व्यवहार का एक उदाहरण क्या है?
- खाली राज्यों, त्रुटियों और धीमे कनेक्शनों में क्या होगा?
- हम कैसे पुष्टि करेंगे कि यह काम करता है (मानदंड या मेट्रिक)?
ये निर्णय अक्सर छिपी-अनिश्चितताओं को बाहर ला देते हैं।
कौन से एज केस v1 स्वीकृति मानदंड में शामिल होने चाहिए?
इन्हें व1 में स्कोप आइटम की तरह संभालें, न कि आश्चर्यजनक मामलों के तौर पर। v1 में वे कवरेज दें जो भरोसा तोड़ सकते हैं:
- Empty state
- Validation errors
- Permission denied
- Network/API failures
- “Undo” या rollback व्यवहार (यदि लागू)
बाकी चीज़ें स्पष्ट रूप से out-of-scope के रूप में टाल दी जा सकती हैं।
अच्छे स्वीकृति मानदंड व्यवहार में कैसे दिखते हैं?
किसी भी व्यक्ति द्वारा चलाए जा सकने वाले टेस्टेबल स्टेटमेंट्स का उपयोग करें:
- Given प्रारंभिक स्थिति
- When उपयोगकर्ता X करता है
- Then Y होता है
कम से कम एक फ़ेलियर केस और एक अनुमति नियम शामिल करें। अगर कोई क्राइटेरियन टेस्ट नहीं किया जा सकता, तो उसे तब तक पुनर्लिखें जब तक वह टेस्टेबल न हो।
एक स्कोप्ड टास्क के लिए UI प्लान कितना न्यूनतम होना चाहिए?
सटीक स्क्रीन और प्रति स्क्रीन एक ही दृश्य परिवर्तन नामित करें।
साथ ही आवश्यक UI अवस्थाएँ लिखें:
- Loading
- Empty
- Error (क्या retry है)
- Success (toast/inline संदेश/अपडेटेड सूची)
कॉपी (बटन टेक्स्ट, त्रुटियाँ) को भी स्कोप में रखें, भले वह placeholder ही क्यों न हो।
ओवर-डिजाइन किए बिना API/डेटा प्लान सबसे सरल कैसे बनाएं?
कॉन्ट्रैक्ट छोटा रखें: v1 के लिए अक्सर एक read और एक write पर्याप्त होते हैं।
परिभाषित करें:
- इनपुट/आउटपुट साधारण ऑब्जेक्ट्स के रूप में (required vs optional)
- सामान्य त्रुटियाँ (not found, validation failed)
- एक वाक्य में auth नियम (कौन पढ़/लिख सकता है)
फैक्ट्स को स्टोर करें; व्यूज़ को संभव हो तो कंप्यूट करें।
Claude Code से स्कोप्ड टास्क और कमिट प्लान प्रोड्यूस करवाने के लिए कैसे प्रॉम्प्ट करें?
एक बॉक्स्ड डिलिवरेबल माँगें:
- पुनर्लिखित स्कोप + स्वीकृति चेकलिस्ट
- 3–7 कमिट्स, हर एक एक व्यवहार खोलता है
- हर कमिट के लिए संभावित फ़ाइलें
- त्वरित टेस्ट प्लान (happy path + एक edge)
- स्पष्ट out-of-scope सूची
फिर किसी भी अस्पष्ट शब्दों जैसे “make it cleaner” को मापनीय शब्दों में बदलने के लिए पुनःप्रॉम्प्ट करें।
फीचर को छोटे, रिव्यू करने योग्य कमिट्स में कैसे बाँटें?
डिफ़ॉल्ट अनुक्रम:
- डेटा/मॉडल परिवर्तन (यदि आवश्यक) + टेस्ट
- API व्यवहार + वैलिडेशन
- UI वायरिंग with empty/error states
- केवल आवश्यक होने पर अंतिम पॉलिश
नियम: एक कमिट = एक नया उपयोगकर्ता-दृश्य व्यवहार + उसे साबित करने का त्वरित तरीका। “While I’m here” रिफैक्टर्स फीचर कमिट्स में न जोड़ें।