स्क्रम टीम YAGNI सिद्धांत का पालन नहीं कर रही है

Question

SCRUM मीटिंग में उत्पाद टीम एक API पर एक फीचर के बारे में बहस कर रही थी जिसका उपभोग मोबाइल ऐप द्वारा किया जाएगा। हमारे पास एक मॉक अप था जिसने दिखाया कि स्क्रीन को कैसे दिखना चाहिए और इसमें कौन से प्रमुख तत्व होने चाहिए (एक "लेआउट")।

इसके आधार पर और उत्पाद स्वामी के साथ हुई चर्चा के आधार पर मैंने API प्रतिक्रिया (HAL + JSON) के लिए एक प्रोटोटाइप बनाया। यह बहुत सरल था, एचएएल-आज्ञाकारी जेन्सन ने मॉकअप पर उन चीजों का प्रतिनिधित्व करने से ज्यादा कुछ नहीं किया। मैं भविष्य के उन विचारों से प्रभावित नहीं हुआ जो व्यवसायिक लोगों द्वारा पूर्वापेक्षित थे क्योंकि उनमें अपने विचारों को अक्सर बदलने की प्रवृत्ति होती है और मैंने न्यूनतम दृष्टिकोण अपनाने का फैसला किया। मेरे प्रस्ताव को टीम ने खारिज कर दिया और मुझे 7 से 1 आउट किया गया।

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

अधिकांश समय हम उन चीजों के बारे में बहस कर रहे थे जो स्प्रिंट का हिस्सा नहीं थे और न ही मॉकअप पर उल्लेख किया गया था। वर्णित समस्याएं थीं "क्या होगा अगर भविष्य में विपणन होगा ...", "क्या होगा यदि व्यवसाय हमें चाहता है ..."।

मैं और उत्पाद स्वामी अनुभवी प्रोग्रामर हैं और हमने अतीत में इस तरह की समस्याएं देखी हैं। हम पालन करने की कोशिश YAGNI और KISS सिद्धांतों। टीम के बाकी सदस्य थोड़े कम अनुभवी हैं और हालाँकि वे इन सिद्धांतों को जानते हैं, वे उन्हें समझ नहीं पाते हैं।

हम उनके समाधान पर सहमत हुए क्योंकि टीम पूरी तरह से हमारे लिए महत्वपूर्ण है और हम उस चीज पर नहीं लड़ना चाहते जो कि महत्वपूर्ण नहीं है। लेकिन मुझे डर है कि क्या इस तरह की बात और अधिक जटिल बहस के लिए एक मिसाल बन सकती है? इस तरह के व्यवहार से कैसे निपटें? क्या ऐसा कुछ है जो मैं, एक टीम लीडर के रूप में बेहतर कर सकता हूं?

यह उल्लेख के लायक है कि उत्पाद एक प्रारंभिक चरण का एमवीपी है।

Comments

I'm afraid if such thing can become a precedence for upcoming, more complicated debates?- यह भी YAGNI का उल्लंघन करता है: भविष्य के बारे में चिंता करना जो कि नहीं हो सकता है। यदि आप अपनी जमीन पर खड़े होने जा रहे हैं, तो आपको पहले से ही ऐसा करना चाहिए था।

— रॉबर्ट हार्वे

@gnat: यह समय की कमी के बारे में प्रतीत नहीं होता है।

— रॉबर्ट हार्वे

क्या HAL-Compliant YAGNI के अधीन नहीं है?

— मैथ्यू

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

— जेसेक Kobus

लचीलापन जटिलता जोड़ता है। जब तक टीम समझती है कि, कोई आगे बढ़ सकता है।

— जॉन रेन्नोर

Answer 1

मुझे तुम्हारा दर्द महसूस हो रहा है। IMHO इस तरह की समस्याएं इस तथ्य के कारण होती हैं कि आपके पास 8 व्यक्तियों की एक टीम है, जो पहले से ही बहुत बड़ा है जो आपको हमेशा सर्वश्रेष्ठ रणनीतिक निर्णयों के लिए आने देता है।

8 या उससे अधिक संभावना वाले आकार की एक टीम में औसत दर्जे के प्रोग्रामर की संख्या अनुभवी लोगों की संख्या से अधिक होती है। इससे अक्सर उन स्थितियों का सामना करना पड़ेगा जहां बेहतर निर्णय औसत लोगों द्वारा किए जाते हैं। यह संतोषजनक नहीं लगता है, खासकर जब आप कर रहे हैं (या लगता है कि आप हैं) अधिक अनुभवी लोगों में से एक हैं, लेकिन कम से कम एक ही वास्तव में बुरे फैसलों के लिए सच है।

तथ्य यह है कि जब तक टीम नहीं बदलती है , तब तक आप इसके बारे में बहुत कुछ नहीं कर सकते , कम से कम अगर चीजें लोकतांत्रिक रहेंगी, तो

• इसके साथ जीना सीखो
• एक या दो साल के लिए टीम के साथ काम करते हैं, अपने स्वयं के विशेषज्ञता को साझा और आशा है कि वे समय के साथ YAGNI के मूल्य और KISS सीखना
• टीम को "बिक्री" डिजाइन या रणनीतिक निर्णयों के अपने कौशल पर काम करें
• एक अलग (शायद छोटी) टीम में जाने का प्रयास करें जहां आपकी अपनी विशेषज्ञता का स्तर पूरी टीम के औसत के करीब हो

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

Comments

ज्यादातर लोगों को यह गर्म है और इसे छूने के लिए नहीं जानने के लिए स्टोव को छूना होगा। सॉफ्टवेयर बहुत समान है। ++

— रबरडुक

इस तरह की चीज़ के लिए प्रोजेक्ट लॉग / डायरी रखना महत्वपूर्ण है। एक बार जब आपने विभिन्न चर्चाओं को रिकॉर्ड कर लिया है, तो वे कहीं अधिक ठोस हैं जो लोगों की बातचीत के महीनों या वर्षों के बाद याद करते हैं। यहां अभ्यास पर एक अच्छा सवाल है ।

— रॉबी डी

@RobbieDee: सुनिश्चित करें, अगर यह मदद करता है टीम YAGNI और KISS के बारे में जानने के लिए।

— डॉक्टर ब्राउन

तीसरी गोली (एक डिजाइन को "बेचने" में अपने स्वयं के कौशल पर काम करना) पर्याप्त ध्यान नहीं देता है। यही कारण है कि डेवलपर्स को अभी भी अच्छे संचार कौशल रखने (या काम करने) की आवश्यकता है।

— रान्डेल स्टीवर्ट

@ रैंडलस्टार्ट: बिल्कुल। लेकिन सबसे अच्छे संचार कौशल के बावजूद भी YAGNI को उन लोगों को बेचना मुश्किल हो सकता है जिन्होंने खुद से कुछ अनुभव नहीं किए हैं, या इसे "त्वरित और गंदे" के साथ भ्रमित करते हैं, या शिक्षित किया गया कि "अमूर्त (हमेशा) अच्छा है" और इसलिए प्रयास करें अमूर्त के लिए अमूर्त के बजाय अमूर्त चीजों के लिए। संचार में दो पक्षों की आवश्यकता होती है - एक जो चीजों को अच्छी तरह से समझा सकता है, और एक वह जो सुनने और समझने के लिए तैयार है।

— डॉक ब्राउन

Answer 2

आगे की संगतता एक वैध चिंता का विषय है

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

अन्य आवश्यकताओं की तरह, आपको स्वीकृति मानदंड की आवश्यकता है

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

यह एक निर्णय कॉल नहीं होना चाहिए

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

Comments

जहां सवाल में आप यह पढ़ते हैं कि ओपी की टीम ने वायएजीएनआई का रास्ता छोड़ दिया, क्योंकि आगे की अनुकूलता की आवश्यकता है?

— डॉक्टर ब्राउन

आगे की संगतता है कि Content-Typeहेडर किसके लिए है

— जैक

यदि आप चाहते हैं तो मैं इसे कुछ और कहने के लिए तैयार हूं, शायद यह एक्स्टेंसिबिलिटी है। बात वही है; यह अभी भी एक एनएफआर है।

— जॉन वू

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

— डॉक ब्राउन

... तो यह अधिक है कि एनएफआर के बारे में धारणा बनाने से कुछ रचनात्मक डेवलपर्स की एक टीम को कैसे पकड़ें और कुछ का आविष्कार करें।

— डॉक ब्राउन

Answer 3

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

अगर मैं उत्पाद का मालिक होता हूं तो मुझे यकीन है कि मैं एक विकास टीम के साथ बहुत खुश होऊंगा जो बाद के मुकाबले पहला दृष्टिकोण लेगी।

Comments

+1 पूर्वानुमान और परिवर्तन के लिए योजना बनाना पूर्ण वास्तुकला अंतरिक्ष यात्री के जाने और एक आंतरिक मंच बनाने जैसी ही बात नहीं है । अभी थोड़ा सा जमीनी काम भविष्य में बहुत सारे कामों को रोक सकता है। जबकि ओपी की टीम शायद काल्पनिकता की दिशा में बहुत अधिक झुकाव कर रही है, एक कट्टरपंथी YAGNI दृष्टिकोण निश्चित रूप से उपसमिति है।

— अमन

ऐसा लगता है कि आप ओपी को आगे बढ़ाएंगे और बाकी टीम की तुलना में "क्या होगा अगर भविष्य में मार्केटिंग करें .." के लिए योजना बनाने की वही गलतियाँ करें । जब लोग एप्लिकेशन सॉफ़्टवेयर बनाने के बजाय एप्लिकेशन सॉफ़्टवेयर के बजाय फ्रेमवर्क बनाना शुरू करते हैं, तो वे लगभग हमेशा गलत कर रहे हैं।

— डॉक ब्राउन

@DocBrown तकनीकी रूप से मैं सहमत होगा। हालांकि यह मामला व्यक्तिगत सम्मान की मांग करने की सुविधा के लिए तत्परता के बारे में है। एक ओर "सही" होना बनाम दूसरी ओर उपयोगी या सहायक होना। मैंने लाइनों के बीच जो पढ़ा है वह यह है कि ओपी जमीन खो रहा है और अपने अनुभव को ऑनलाइन दर्शकों तक पहुंचाने के बजाय अपने अहंकार को पंप करने का विकल्प चुनता है, एक ऐसे माहौल में योगदान करने के बजाय जो वह अब सहज महसूस नहीं करता है। यह गतिशील स्क्रम की शुरूआत के लिए विशिष्ट है।

— मार्टिन माट

@MartinMaat मैं इस तथ्य से थोड़ा निराश था कि वे मुझसे असहमत थे। मुझे समझ नहीं आया कि ऐसा क्यों हुआ। रोजमर्रा के काम के दौरान मैं उनकी कोड समीक्षा आदि में मदद करता हूं। हम अक्सर बहस करते हैं लेकिन मुझे यह पसंद है, क्योंकि अंतिम परिणाम बेहतर है; मुझे पता है कि वे मेरी राय का सम्मान करते हैं; मैं हमेशा मान्य सिद्धांतों का उपयोग करने की कोशिश करता हूं जो मेरे सिद्धांतों का समर्थन करते हैं। अंत में वे सबसे अच्छा विकल्प चुनते हैं और इसकी जिम्मेदारी भी लेते हैं। टीम ने वही किया जो वह करने वाली थी - उन्होंने समस्या को हल किया। यह मेरी और उत्पाद स्वामी की गलती थी, कि यह मामला शुरू से बहुत व्यापक और खराब था।

— जेसेक कोबस

Answer 4

खैर, मेरी राय है कि लोकतंत्र ठीक से काम नहीं कर रहा है - न तो राजनीतिक प्रणाली में, न ही ऐसी टीम में, जहां अधिकांश प्रोग्रामर जूनियर या औसत दर्जे के हैं।

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

आखिरकार, आपकी जिम्मेदारी अन्य लोगों के लिए अधिक है। यह न केवल कोड लिखना है, बल्कि लोगों का मार्गदर्शन करना भी है।

Comments

लोकतंत्र शायद यहां समस्या का कारण है, लेकिन लोकतांत्रिक नहीं होना आईएमएचओ कोई समाधान नहीं है, क्योंकि यह प्रश्न में वर्णित लोगों की तुलना में बड़ी समस्याओं को आसानी से पेश कर सकता है - यह वास्तव में टीम को बर्बाद कर सकता है।

— डॉक ब्राउन

@DocBrown आप बस एक ही वाक्य में खुद का विरोधाभास करते हैं। आईएमओ कुछ निर्णय लोगों पर निर्णय लेने के लिए नहीं होते हैं। ओपी ने जो समझाया वह उनमें से एक है। YAGNI का उपयोग नहीं करने वाले लोगों के लिए आर्मस्ट्रांग को उद्धृत करने के लिए: आप एक केला चाहते थे लेकिन आपको जो मिला वह एक गोरिल्ला था जो केले और पूरे जंगल को पकड़ रहा था

— BЈовић

नहीं, यह कोई विरोधाभास नहीं है (शायद मैंने अपनी बात अच्छी तरह से व्यक्त नहीं की)। चीजें हमेशा "काले और सफेद" नहीं होती हैं। सिर्फ इसलिए कि लोकतंत्र कुछ स्थितियों में अच्छा काम नहीं करता है, लोकतांत्रिक नहीं होना स्थिति में सुधार और चीजों को बेहतर बनाने की गारंटी नहीं है। यह अक्सर इतना आसान नहीं होता है।

— डॉक्टर ब्राउन

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

— oopexpert

@upexpert समस्या यह है: आपको उनकी आवश्यकता हो सकती है। इंजीनियरिंग के खिलाफ YAGNI की बातचीत उचित अमूर्तता एक चीज है, सामान जोड़ना जो आपको ज़रूरत नहीं हो सकता है अलग-अलग मामले हैं।

— B23овиЈ

Answer 5

ऐसा लगता है कि YAGNI को लेकर थोड़ा भ्रम है।

डेवलपर्स अक्सर सोचते हैं कि वे YAGNI का अनुसरण करते हैं जब वे अमूर्तता को छोड़ देते हैं जो सिस्टम को "संशोधन के लिए बंद कर देगा और विस्तार के लिए खुला रहेगा"।

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

मेरी व्यक्तिगत राय है कि डोमेन का केवल एक गहरा ज्ञान अमूर्तता के निर्णय लेने में मदद करेगा और इसे कहां खोजना होगा।

Answer 6

YAGNI और किस के साथ दिक्कत यह है कि वे पूरी तरह से व्यक्तिपरक और अस्पष्ट हो रहा है।

json ?? YAGNI! बस एक सीएसवी स्ट्रिंग भेजें!

वस्तुओं ?? KISSTUPID !!! बस गोटो का उपयोग करें !!

'टीम लीडर' की भूमिका अच्छी तरह से परिभाषित नहीं है, लेकिन मैं आपको सुझाव दूंगा कि आप अपनी टीमों की तकनीकी पसंद पर व्यक्तिपरक राय व्यक्त करने से दूरी बनाएं। भले ही आपको लगे कि वे गलत हैं। अच्छी तरह से परिभाषित आवश्यकताओं की एक छोटी सूची के लिए छड़ी।

• कोड के लिए इकाई परीक्षण
• एपिस के लिए एकीकरण परीक्षण
• अंतिम उत्पाद के लिए स्वचालित UI परीक्षण
• प्रदर्शन और स्केलिंग आवश्यकताओं

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

उसके बाद बस उसी को करने के लिए धक्का लेकिन तेजी से

Answer 7

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

इसके ऊपर और ऊपर दिया गया कुछ भी बैकलॉग पर होना चाहिए जो कि स्वयं की भी अपनी परिभाषा होगी।

प्राथमिकताओं के लिए, MoSCoW विधि ने हमेशा हमें अच्छी तरह से सेवा दी है - YMMV।

Answer 8

इसके बारे में मेरा पहला विचार है ... टीम को बदलावों की चिंता क्यों है? क्या उनके पास उत्पाद स्वामी की कुछ ऐतिहासिक समझ है जो उन्हें ऐसा महसूस कराती है कि भविष्य के संवर्द्धन को आसान बनाने के लिए उन्हें थोड़ा और अधिक विन्यास करने के लिए पहला समाधान बनाने की आवश्यकता है? यदि आपके समाधान में 2 दिन लगेंगे, और उनका 5 दिन, हाँ, यह दो बार लंबा है। लेकिन अगर आपकी योजना में फेरबदल करने में हर बार 2 दिन लगेंगे, लेकिन उनकी वृद्धि में 1 दिन लगेगा, तो उनकी योजना लंबी दौड़ में अधिक कुशल लगती है। मुझे नहीं लगता कि इस प्रश्न में कोई सही या गलत निर्णय है। यह अन्य कारकों पर निर्भर करता है, IMHO। हालांकि, आप इस मानसिकता के बारे में सही हैं यदि अन्य समाधानों पर वे ऐसा करने के लिए किसी भी प्रत्यक्ष मार्गदर्शन के बिना LOE को दोगुना करते हैं (कुछ सबूत हैं कि अतिरिक्त जटिलता स्केलेबिलिटी, मजबूती आदि के लिए आवश्यक है)। मेरा सुझाव उत्पाद स्वामी को इन वार्तालापों में लाना होगा, क्योंकि उन्हें प्राथमिकता के साथ मदद करने की आवश्यकता है। यदि आपका समाधान 5 अंक है, और यह अभी की जरूरत को पूरा करेगा, लेकिन वे जो करना चाहते हैं, उसके लिए 50 अंक और दो स्प्रिंट या अधिक की आवश्यकता होगी, पीओ कह सकते हैं "पकड़ पर, हमारे पास इस एमवीपी योजना की एक उच्च प्राथमिकता जारी है और रोडमैप पर नहीं है कि कार्यक्षमता के निर्माण में 2 सप्ताह खर्च नहीं कर सकते हैं!