स्क्रम में, विकास के वातावरण की स्थापना और क्षमता विकास जैसे कार्यों को वास्तविक उपयोगकर्ता कहानियों के भीतर उप-मुखौटे के रूप में प्रबंधित किया जाना चाहिए?


23

कभी-कभी परियोजनाओं में हमें कार्यों पर समय बिताने की आवश्यकता होती है जैसे:

  1. वैकल्पिक रूपरेखा और उपकरण की खोज
  2. परियोजना के लिए चुने गए ढांचे और उपकरणों को सीखना
  3. सर्वर और प्रोजेक्ट इन्फ्रास्ट्रक्चर (संस्करण नियंत्रण, निर्माण वातावरण, डेटाबेस, आदि) की स्थापना

यदि हम उपयोगकर्ता कहानियों का उपयोग कर रहे हैं, तो यह सब काम कहाँ जाना चाहिए?

एक विकल्प यह है कि उन्हें पहले उपयोगकर्ता कहानी (उदाहरण के लिए आवेदन करने के लिए होमपेज) का हिस्सा बनाया जाए। एक अन्य विकल्प इन कार्यों के लिए एक स्पाइक करना है। एक तीसरा विकल्प एक का कार्य हिस्सा बनाने के लिए है जारी करना / बाधा (जैसे विकास के वातावरण अभी तक नहीं चुने गए) के बजाय एक उपयोगकर्ता कहानी।


मैंने इसे और अधिक स्पष्ट करने के लिए प्रश्न को थोड़ा बदल दिया है .. प्रश्न अब कहानियों के बजाय वास्तविक उपयोगकर्ता कहानियों के भीतर उपशीर्षक के रूप में है
असीम गफ्फार

जवाबों:


12

हमने पिछले एक साल में इस समस्या के बारे में काफी सोचा।

जबकि मैं मानता हूं कि परियोजना शुरू होने से पहले एक बुनियादी ढांचा मौजूद होना चाहिए, व्यावहारिक उपयोग में यह परियोजना का ही हिस्सा हो सकता है। इसलिए आपको किसी तरह मैनेज करना होगा।

उपयोगकर्ता कहानियों के साथ प्रोजेक्ट सेटअप को मिलाते समय यह समझ में आ सकता है कि कभी-कभी हम ऐसे सरल कार्यों पर बस गए हैं जो उत्पाद बैकलॉग में जोड़े जा सकते हैं और उपयोगकर्ता कहानियों के समान ध्यान आकर्षित कर सकते हैं। हम जानते हैं कि ये तकनीकी कार्य कभी-कभी आवश्यक होते हैं, लेकिन इन्हें किसी भी स्थिति में उचित ठहराया जाना चाहिए। यदि टीम को लगता है कि वे एक निश्चित लक्ष्य को प्राप्त करने के लिए बिल्कुल आवश्यक हैं, तो वे एक स्प्रिंट का हिस्सा होंगे।

यह कहना मुश्किल है कि आपके लिए सबसे अच्छा काम क्या है, इसलिए प्रयोग करें ! एक स्पाइक अब के लिए पर्याप्त हो सकता है, लेकिन मुझे लगता है कि आप बाद में उसी समस्या के साथ समाप्त करेंगे, इसलिए आगे की योजना बनाएं। क्या कार्य है कि इस तरह की गतिविधियों के लिए एक प्लेसहोल्डर है। कहानियों से कार्यों को अलग करने के लिए दो मैं उनके साथ अपने अनुभव के आधार पर उनकी तुलना जल्दी करूंगा।

कार्य: एक कार्य एक तकनीकी आवश्यकता है। यह कॉन्फ़िगरेशन प्रबंधन या सामान्य परियोजना सेटअप के लिए चीजें हो सकती हैं, जैसे कि कमिट के लिए एक रिपॉजिटरी स्थापित करना, या आपके द्वारा कभी भी विकास प्रक्रिया को देखे गए सबसे हॉट कोड समीक्षा टूल को जोड़ना। कार्य को योजना में माना जाना चाहिए, उपयोगकर्ता कहानी के समान। यदि टीम उत्पाद के मालिक को समझा सकती है कि नवीनतम और सबसे बड़ी कोड समीक्षा टूल होने से लंबे समय तक चलने वाले जोड़ी प्रोग्रामिंग सत्रों या इन-पर्सन कोड समीक्षाओं को समाप्त करके प्रदर्शन और अप टीम संचार बढ़ता है, तो यह उत्पाद के मालिक का ध्यान आकर्षित करेगा।

कहानियां : केवल व्यावसायिक दृष्टिकोण पर केंद्रित, कहानियां हमेशा ग्राहक को दृश्यमान मूल्य प्रदान करती हैं। आंतरिक गुणवत्ता एक ऐसी चीज है जो व्यावसायिक मूल्य के उत्पादन के साथ-साथ चलती है।

हम कार्यों को कहानी के बिंदु भी देते हैं और कभी-कभी उनके साथ वही काम करते हैं जो हम कहानियों के साथ करते हैं।

अंत में मैं आपके मामले में इस समाधान के लिए जाऊंगा (जिसे सामान्य रूप में भी लागू किया जा सकता है):

  1. कार्यों में "सेटअप" और तकनीकी सामान को अलग करें (सामान जो सीधे उत्पाद स्वामी के लिए व्यावसायिक मूल्य का उत्पादन नहीं करता है)।
  2. हो सकता है कि सबसे महत्वपूर्ण उपकरण (SCM, dev टूल्स, प्रोसेस डिफिकेशन, कोडेशन मानकों आदि) को प्राप्त करने के लिए प्रोजेक्ट सेटअप से पहले एक स्पाइक करें।
  3. स्वीकार करें कि ये कार्य परियोजना की अवधि के दौरान पॉप अप करते हैं और कहानियों के अलावा गतिविधियों का एक अलग "प्रकार" होने से इसके लिए योजना बनाते हैं।

तो आप जिसे TASK कह रहे हैं, वह मूल रूप से उपयोगकर्ता की कहानी या बग जैसी कार्य वस्तु है? .. यह उपयोगकर्ता कहानियों जैसे कार्यों में कोड, परीक्षण, परिनियोजन आदि के रूप में TASK नहीं है
Asim Ghaffar

2
हाँ, उन लोगों के बीच अंतर पाने के लिए जिन्हें हम कहानियों के उप-कार्यों को "गतिविधियाँ" कहते हैं।
माल्ट

जिसे आप टास्क कहते हैं, वह मूल रूप से एजाइल 5.0 के लिए MSF के अनुसार एक मुद्दा है
असीम गफ्फार

यदि आप इस विवरण को यहाँ देखें: msdn.microsoft.com/en-us/library/dd997897.aspx - आप इसे एक समस्या कह सकते हैं क्योंकि यह वहाँ वर्णित था, जो मेरे विचार से उपयुक्त होगा। ताकि यह आपके विकल्प नंबर 3.
माल्ट

2
बिंदु 3 "स्वीकार करें कि ये कार्य परियोजना की अवधि के दौरान पॉप अप होते हैं" विशेष रूप से महत्वपूर्ण है। एजाइल यूनिफाइड प्रोसेस में एक शानदार चित्र है जो इसे प्रदर्शित करता है: i.stack.imgur.com/CUVFI.jpg । ध्यान दें कि वे "पर्यावरण" अनुशासन कभी गायब नहीं होता है। यह भी ध्यान रखें कि पर्यावरण कार्य का बड़ा हिस्सा सामने है। इसलिए यदि आपको अचानक पता चलता है कि आप बाद के चरण में बहुत सारे पर्यावरण कार्य कर रहे हैं तो कुछ गलत हो सकता है।
माइकल

4

जो कुछ भी आपकी कंपनी में सबसे अधिक समझ में आता है करो। कभी भी ऐसा न करें कि अन्य लोग कैसे चीजों को सामान्य ज्ञान में बाधा बनते हैं।

लेकिन मैं कहूंगा कि ये सभी कार्य कुछ ऐसे हैं जो विकास शुरू करने से बहुत पहले होने चाहिए। इसलिए मैं सवाल करता हूं कि क्या स्क्रैम इन कार्यों के लिए भी प्रासंगिक है। कुछ चल रहे रखरखाव और इस तरह के स्रोत नियंत्रण और डेटाबेस के लिए हैं, लेकिन ये निर्धारित नहीं किया जाना चाहिए, वे सिर्फ वे चीजें होनी चाहिए जो आपके वेग को प्रभावित करती हैं।

ऐसे समय होंगे जब आपको किसी प्रोजेक्ट के दौरान या किसी फ्रेमवर्क का चयन करना होगा, लेकिन जब मैं कहता हूं कि मेरा मतलब एनएचबर्नेट की तरह है, न कि फ्रेमवर्क जैसा। उन मामलों में, अनुसंधान को नुकीला और समयावधि में रखा जाना चाहिए, न कि काफी संक्षिप्त रूप से। इसे प्रबंधित करने का प्रयास करें जैसे कि आप एक दो दिनों के लिए बीमार से विकासक थे।

ज्ञान हस्तांतरण एक और चल रही प्रक्रिया है जिसे सामान्य विकास वेग से बाहर प्रबंधित किया जाना चाहिए।


जब मैंने फ्रेमवर्क कहा .. तो ऐसा था कि हमें JSF या स्प्रिंग के लिए जाना चाहिए .. या जब मैंने टूल कहा .. तो ऐसा था कि क्या हमें Jboss या ग्लासफिश के लिए जाना चाहिए ..
असीम गफ्फार

1
मुझे पता नहीं है कि आपके द्वारा "विकास शुरू करने से पहले" का क्या मतलब है .. जब परियोजना शुरू होती है, तो 1 प्रारंभ ASAP को नहीं शुरू करना चाहिए जैसे कि परियोजना शुरू होने की तारीख के 2 सप्ताह के भीतर ... और स्प्रिंट 1 में वास्तविक कोडिंग है।
असीम गफ्फार

1
@AsimGhaffar: मुझे नहीं लगता कि यह चाहिए, नहीं। यदि आप कोडिंग शुरू करने से पहले यह भी तय कर लेते हैं कि किस एप्लिकेशन सर्वर का उपयोग करना है, तो आप कम से कम एक निर्णय लेने जा रहे हैं, जिसके लिए आपको उस कोड को फिर से लिखना होगा। और मैं बिना स्रोत नियंत्रण स्थापित किए आजकल एक परियोजना शुरू करने की कल्पना नहीं कर सकता। मेरा मतलब है ठीक है, अगर आपके पास डेवलपर्स बैठे हैं, तो उन्हें कुछ ऐसा करने के लिए उत्पादक खोजें, जैसे कि प्रोटोटाइप। जब तक आप महत्वपूर्ण निर्णय नहीं लेते हैं, तब तक परियोजना में न जाएं।
पीडीआर

"परियोजना प्रारंभ तिथि के 2 सप्ताह के भीतर 1 प्रारंभ ASAP को स्प्रिंट नहीं करना चाहिए"। सही बात। इसका मतलब है कि आपका पर्यावरण सभी तैयार है और जाने के लिए तैयार है। आप पहले से ही उपकरण का उपयोग करने, बिल्ड और तैनाती करने में कुशल हैं। यदि आप इन चीजों में पहले से ही कुशल नहीं हैं और वातावरण सेटअप नहीं है, तो आप शुरू करने के लिए तैयार नहीं हैं।
S.Lott

@ एस.लॉट हम्म मैंने सोचा था कि किसी को जोब पर आवश्यक कौशल प्राप्त होता है अर्थात प्रोजेक्ट पर काम करते समय और स्प्रिंट के लिए कोई लर्निंग-टूल आवश्यक नहीं है।
असीम गफ्फार

2

आपकी परियोजना की "आधिकारिक" शुरुआत से पहले संभव के रूप में कई डिजाइन निर्णय लेने के लिए एक नाम है। इसे झरना कहा जाता है। उपयोगकर्ता की कहानियों के साथ कुछ भी गलत नहीं है, "एक डेवलपर के रूप में, मुझे एक रूपरेखा का चयन करने की आवश्यकता है, इसलिए हमारे पास वेब साइट के लिए एक प्रारंभिक बिंदु है।" यदि यह एक चलना में फिट होने के लिए बहुत बड़ा है, तो इसे नीचे तोड़ने की कोशिश करें, जैसे "एक डेवलपर के रूप में, मुझे ड्रुपल में एक बुनियादी होम पेज को लागू करने की आवश्यकता है, इसलिए हमें पता चल जाएगा कि क्या यह हमारी आवश्यकताओं के अनुरूप है।"


1

एक विकल्प यह है कि पहले उपयोगकर्ता की कहानी के सभी हिस्से जैसे कि आवेदन के लिए मुखपृष्ठ बनाएं।

एक अवधारणा के रूप में "उपयोगकर्ता कहानी" को तोड़ता है। उपयोगकर्ता इसमें क्या शामिल है? कोई नहीं। यह वह काम है जो आपको पहले ही कर लेना चाहिए था।

एक अन्य विकल्प इसके लिए एक स्पाइक करना है।

बुरा नहीं।

तीसरा विकल्प उपयोगकर्ता की कहानी के बजाय कार्य के मुद्दे (जैसे विकास वातावरण अभी तक चयनित नहीं) का हिस्सा बनाना है।

जहाँ तक योजना और ओवरहेड्स का सवाल है, स्पाइक के बारे में समान है।

सेटअप एक उपयोगकर्ता कहानी नहीं है।

आपके द्वारा इस परियोजना को शुरू करने से पहले यह आपके पास होना चाहिए

जब तक आपके पास ढांचा / उपकरण और सर्वर सेटअप नहीं है और जाने के लिए तैयार नहीं है तब तक आप वास्तव में परियोजना शुरू नहीं कर सकते।

मुझे अच्छी तरह पता है कि अनुबंध पर हस्ताक्षर होने के बाद तक कई संगठन वास्तव में मौजूद नहीं हैं । मैं यह भी अच्छी तरह से जानता हूं कि अनुबंध पर हस्ताक्षर होने के बाद तक कई संगठन एक तकनीक का चयन नहीं करते हैं । ये सभी अकुशल चीजें हैं जो किसी भी उपयोगकर्ता की कहानियों से बाहर हैं।


मुद्दा स्पाइक जैसा नहीं है। सामान्य स्प्रिंट में निर्धारित कार्य आइटम के रूप में समस्या के बारे में सोचें, लेकिन इसमें कहानी के बिंदु नहीं हैं .. उदाहरण का मुद्दा: एसवीएन का चयन नहीं किया गया है। मैं एमएसएफ से एजाइल 5.0 के लिए
असीम गफ्फार

"मुद्दा समान स्पाइक नहीं है"। शब्दों की परिभाषा के लिए, आप सही हैं। लेकिन जब आप स्प्रिंट 1 से पहले अतिरिक्त काम की योजना के बारे में सोचते हैं, तो इससे कोई फर्क नहीं पड़ता कि आप इसे एक मुद्दा या स्पाइक कहते हैं। एक चुनें। सिक्का उछालो। प्रमुखों।
S.Lott

फिर से मेरा मतलब था कि स्प्रिंट 1 के भीतर कहानियों के साथ शेड्यूलिंग मुद्दा - स्प्रिंट 1 से पहले नहीं। इसलिए स्प्रिंट 1 के लिए हम 2 उपयोगकर्ता कहानियों और 1 मुद्दे को लेने की अनुमति देते हैं। हालांकि अंक के लिए कोई कहानी नहीं। स्पाईक वास्तव में स्प्रिंट 1 से पहले होगा।
असीम गफ्फार

स्पाइक या इश्यू कोई मायने नहीं रखता। यह सब काम है जो एक उपयोगकर्ता कहानी का हिस्सा नहीं है । यह सब काम है कि किया जाना चाहिए है से पहले पहले स्प्रिंट। आप इसे स्पाइक या मुद्दा कह सकते हैं, जो भी आपको खुश करता है। लेकिन यह एक यूजर स्टोरी नहीं है।
S.Lott

1

काम पर हम पर्यावरण तैयार करने के लिए एक कार्य का उपयोग करते हैं। यह कुछ लोगों के लिए भ्रामक हो सकता है लेकिन हम जिस कार्य का उपयोग करते हैं वह उपयोगकर्ता की कहानी से कार्य के समान ही है। कार्य उपयोगकर्ता की कहानी से संबंधित नहीं है, लेकिन घंटों में अनुमान लगाया गया है और इसे उत्पाद स्वामी द्वारा किसी विशेष स्प्रिंट में पूरा करने के लिए सहमत होना है।

हम वास्तुशिल्प कार्य के लिए भी कार्य का उपयोग करते हैं, जिसमें "स्पष्ट" व्यावसायिक मूल्य नहीं है, लेकिन यह उत्पाद को विशेष रूप से एक बड़े कोड आधार के साथ मौजूदा उत्पाद के लिए गुणवत्ता जोड़ता है।

ये आपके काम के माहौल में लागू नहीं हो सकते हैं लेकिन इसने हमारे लिए अच्छा काम किया है।


0

मुझे लगता है कि आप दो स्वतंत्र चीजों को मिला रहे हैं। एक उपयोगकर्ता कहानी में कोई तकनीकी विवरण शामिल नहीं होना चाहिए।

फ्रेमवर्क का विकल्प, रिपॉजिटरी और सर्वर स्थापित करना और अन्य कार्य, प्रारंभिक पुनरावृत्ति में जाना चाहिए।


आप सही हैं और मैं उन्हें कहानी विवरण में रखने का सुझाव नहीं दे रहा हूँ .. मेरा मतलब था कि "वास्तविक MySQL" के भाग के रूप में "MySQL स्थापित करें", "रूपरेखा का मूल्यांकन" जैसे कार्य हैं .. अर्थात एक उपयोगकर्ता के रूप में जो मैं चाहता हूं। एक मुखपृष्ठ ताकि मेरे पास आवश्यक सुविधाओं तक त्वरित पहुँच हो।
असीम गफ्फार

@AsimGhaffar प्रारंभिक पुनरावृत्ति में किया जा सकता है। उपयोगकर्ता की कहानी के रूप में नहीं, क्योंकि उपयोगकर्ताओं को यह जानने की आवश्यकता नहीं है (और न ही उन्हें परवाह करनी चाहिए) कि आप किस तकनीक का उपयोग उनकी जरूरतों को पूरा करने के लिए करते हैं।
B

0

मैं हाल ही में एक स्क्रम कोर्स पर गया था और प्रशिक्षक ने सुझाव दिया कि स्प्रिंट 0 नामक एक विशेष स्प्रिंट का उपयोग इस तरह की समस्याओं को ठीक करने के लिए किया जाना चाहिए। कोर्स में लोग अलग-अलग डिग्री के थे, जो कि स्क्रम में काफी अनुभवी थे और सभी अनुभवी लोग इस बात से सहमत थे कि उन्होंने भी यही काम किया है। कुछ मामलों में, कंपनियों ने परियोजना का मूल्यांकन करने के लिए स्प्रिंट 0 का इस्तेमाल किया और तय किया कि यह संभव है या नहीं।

खुद की तरह स्क्रम पद्धति के लिए किसी नए व्यक्ति के लिए, यह एक शानदार समाधान की तरह लगता है क्योंकि यह आपको उपयोगकर्ता की कहानियों और सामान्य स्प्रिंट के अन्य सभी पहलुओं जैसे उपयोगकर्ता प्रतिक्रिया से मुक्त रखता है।

जैसा कि स्प्रिंट 0 आपके अन्य स्प्रिंट के समान समय है, यह सुनिश्चित करने के एक तरीके के रूप में कार्य करता है कि आप चीजों को स्थापित करने में बहुत अधिक समय खर्च न करें क्योंकि वे हमेशा बाद में ट्विक किए जा सकते हैं। मुख्य बिंदु अपने आप को एक ऐसी स्थिति में लाना है जहां आप वास्तव में उत्पाद विकसित करना शुरू कर सकते हैं।


3
एलिस्टेयर कॉकबर्न का हवाला देते हुए मुझे यह महसूस होता है कि किसी ने स्क्रम के उपयोग के बारे में दबाया था जब उसने कुछ ऐसा किया था जिसका शुरू में कोई स्पष्ट व्यावसायिक मूल्य नहीं था, और उसने "ओह, द स्प्रिंट जीरो!" का आविष्कार किया। किसानों को अपने घर के दरवाजे से पिकैक्स के साथ पाने के लिए।
असीम गफ्फार

0

2-3 वैकल्पिक ढांचे / उपकरण की खोज पर

कभी-कभी ऐसा हो सकता है यदि आपके पास विशेष आवश्यकता है तो आपको आवश्यकता को हल करने के लिए सबसे अच्छा उपकरण चुनने के लिए कुछ POC करनी होगी। यह स्पाइक इसलिए है क्योंकि यह जानने के बिना कि आप किस फ्रेमवर्क का उपयोग करेंगे, संभवत: कहानी का अनुमान नहीं लगा सकते हैं और बिना अनुमान के स्टोर को योजनाबद्ध और कार्यों में विभाजित नहीं किया जा सकता है।

तब परियोजना के लिए हमारे द्वारा चुने गए ढांचे को सीखने पर

कुंआ। यह काफी खतरनाक है। जब ग्राहक आपको एक एसडब्ल्यू के लिए भुगतान करता है तो वह उम्मीद करता है कि आप पेशेवर हैं जो पहले से ही जानते हैं कि अपने उपकरणों का उपयोग कैसे करें। ग्राहक आपको सीखने या परीक्षण / असफल विकास दृष्टिकोण के लिए भुगतान नहीं करता है। यह डेवलपर की जिम्मेदारी है कि वह अपने खाली समय में या ग्राहक द्वारा नहीं कर्मचारी द्वारा भुगतान किए गए विशेष आवंटित समय में नए उपकरण सीखे । ग्राहक को सूचित किए बिना सीखने के लिए ग्राहक के पैसे खर्च करना अव्यवसायिक है।

यदि आपको वास्तव में कुछ विशेष का उपयोग करना है (उदाहरण के लिए कुछ ग्राहक का एपीआई या उपकरण ग्राहक चयनित), जिसका उपयोग आपने पहले कभी नहीं किया था तो आपको ग्राहक को सूचित करना चाहिए कि एपीआई का उपयोग करने के तरीके को जानने के लिए समय की आवश्यकता से कीमत बढ़ जाएगी। शायद ग्राहक अपने मन को बदल देंगे अगर मूल्य वृद्धि बहुत बड़ी होगी।

निश्चित रूप से, मुझे ऐसी स्थिति से कोई मतलब नहीं है जहाँ आपको कई बार उपयोग की गई रूपरेखा में कुछ विशेष नई समस्या को देखना होगा। मेरा मतलब है कि ऐसी स्थिति जहां आप सीखने के लिए कुछ महत्वपूर्ण समय (परियोजना के बाहर) खर्च किए बिना नए एपीआई या ढांचे का उपयोग करना शुरू करते हैं।

यदि आप इसका उल्लंघन करते हैं तो यह आपके वेग में वैसे भी दिखाई देगा क्योंकि आप प्रति चलना बहुत कम मात्रा में व्यापार मूल्य वितरित करेंगे। यदि ग्राहक को इस कारण के बारे में पता नहीं है तो वह परियोजना को संभवतः रद्द कर देगा।

आंतरिक परियोजनाओं के मामले में यह अभी भी मान्य है - आपको अपने प्रबंधक / व्यवसाय को नए एपीआई या उपकरण सीखने के लिए आवश्यक समय के बारे में सूचित करना चाहिए। आमतौर पर इसके बहुत बुरे परिणाम होते हैं यदि प्रबंधक आपकी सामान्य उत्पादकता के साथ गिना जाता है और आपके कार्य के दौरान सीखने की कोशिश कर रहे नए एपीआई की वजह से आपकी उत्पादकता केवल कुछ अंश है। यह स्पष्ट रूप से और भी बुरा है अगर कुछ बिक्री वाले लोग ग्राहक के साथ अनुबंधित होने पर सामान्य उत्पादकता के साथ गणना करते हैं।

सर्वर स्थापित करने पर (SVN, डेटाबेस, आदि)

यह आपकी बुनियादी संरचना और आंतरिक लागत हैं। जब आप परियोजना शुरू करते हैं, तो यह उम्मीद की जाती है कि आपके पास आपका बुनियादी ढांचा तैयार है। अपने विकास के माहौल को स्थापित करने का ग्राहक के लिए कोई मूल्य नहीं है और यह किसी भी परियोजना से संबंधित संकेतकों का हिस्सा नहीं होना चाहिए - उदाहरण के लिए स्क्रैम में वेग। मैंने इसे विशेष पूर्व-परियोजना पुनरावृत्ति के रूप में लागू किया, जिसका उपयोग केवल पर्यावरण की स्थापना, बुनियादी ढांचा तैयार करने आदि के लिए किया गया था।


हम उत्पाद विकास में हैं न कि ग्राहक परियोजनाएं :)।
असीम गफ्फार

ठीक है। ऐसे मामले में आपको अभी भी सीखने और बुनियादी ढांचे पर खर्च करने के लिए अलग से ट्रैक करना चाहिए कि आपके पास क्या ओवरहेड है। इस समय को कार्य के अंदर छुपाने से आपकी विकास प्रक्रिया की दृश्यता खराब हो जाएगी।
लादिस्लाव मृका
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.