आवश्यकताओं के अभाव में सॉफ्टवेयर लिखना क्या मेरे पास एक ऐसी स्थिति है जिसके लिए मुझे बचना चाहिए?

Question

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

Comments

बचने की स्थिति। केवल एक चीज है, आप नहीं कर सकते। और मैं इसके बारे में कुछ हफ्ते पहले शेख़ी हूँ ...

— yannis

यह एक आग बुझाने की मशीन के संचालन की तरह दोनों है।

— बेन ब्रोका

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

— गॉर्डन

अप्रचलित दिलबर्ट: dilbert.com/strips/comic/2006-01-29

— Dan Neely

कभी-कभी, ग्राहक को पता नहीं होता है कि वे क्या चाहते हैं। वे चाहते हैं कि आप "प्रयोगों" को निर्धारित करें कि वे क्या चाहते हैं। मैंने एक बार एक कमीशन प्रणाली लिखी थी जहाँ केवल कमीशन का भुगतान करना था। प्रयोगात्मक कमीशन प्रणाली के साथ अनुभव के आधार पर कमीशन का भुगतान करने के लिए प्रतिशत और आइटम निर्धारित किए जाने थे।

— गिल्बर्ट ले ब्लैंक

Answer 1

कौशल आवश्यकताओं के बिना सॉफ्टवेयर लिखने के लिए नहीं है। इसके बजाय परियोजना के मालिक से आवश्यकताओं की परवाह किए बिना कि क्या कोई औपचारिक आवश्यकता दस्तावेज है या नहीं।

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

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

Comments

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

@BrianReindel कभी-कभी ग्राहक के विचारों के संयोजन माइंड-मैप / बाइनरी-ट्री के साथ शुरू होता है। मैं पूछता हूं "विचार क्या है?", फिर शब्द संघ का उपयोग करके देखें कि प्रत्येक विचार ग्राहक के दिमाग में क्या लाता है। वहां से मैं एक तस्वीर बनाता हूं जो ग्राहक सोच रहा है, और मैं वहां से आवश्यकताओं को परिभाषित करना शुरू करता हूं। प्रत्येक आवश्यकता उन प्रश्नों को उद्घाटित करती है जिन्हें पूछे जाने की आवश्यकता है। आमतौर पर "क्यों" सवालों से मुझे "व्हाट / हाउ" सवालों से बेहतर प्रतिक्रिया मिलती है, क्योंकि वे ग्राहक को मूल बातों से परे सोचने का मौका देते हैं। यह मूल रूप से मनोविज्ञान का उपयोग करने में एक कला है जिससे ग्राहक को ज़रूरत का पता चलता है।

— रॉबिन्स

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

— डेविड श्वार्ट्ज

आवश्यकताओं को पूरा करने का एक तरीका उन्हें कुछ बुनियादी देना है, और देखें कि वे किन हिस्सों के बारे में शिकायत करते हैं। उदाहरण के लिए, एक पेपर प्रोटोटाइप ( amazon.co.uk/… ) बनाएं और उनके साथ बातचीत के माध्यम से चलाएं।

— डेवार्ड

Answer 2

यह बहुत अस्पष्ट है ...

दो बातें मैं कह सकता हूं:

1. बहुत सारे गिफ्ट किए हुए तकनीकी लोग हैं जिनका करियर रुका हुआ है क्योंकि वे सही आवश्यकताओं की प्रतीक्षा करते हैं। या वे खेलते हैं, "क्षमा करें, यह नहीं कर सकता, आवश्यकताओं में नहीं था।" वास्तविकता है आवश्यकताओं को लिखना बहुत मुश्किल है। अच्छी आवश्यकताओं के लिए आवश्यक सटीकता कुछ भी सबसे अधिक व्यापार लोगों द्वारा बनाई गई के विपरीत है। प्रौद्योगिकी और व्यवसाय के बीच एक सेतु है, और जो लोग दूसरों को बनाते हैं, उनसे मिलने का 100% तरीका आमतौर पर खो जाता है।

2. ऐसे सॉफ्टवेयर लोग हैं जो डोमेन को अपने ग्राहकों से अच्छा या बेहतर मानते हैं। ये लोग सोने में अपने वजन के लायक हैं, भले ही वे 100% सर्वश्रेष्ठ डेवलपर्स न हों। मैंने सॉफ्टवेयर लोगों को देश के सर्वश्रेष्ठ ब्रांड प्रबंधकों की मात्रात्मक विपणन आवश्यकताओं का अनुमान लगाया है। वे सभी समाधानों को कोड करने में सर्वश्रेष्ठ नहीं थे, लेकिन वे नायक थे क्योंकि वे पुल को पार कर सकते थे।

हालांकि काले और गोरे के बारे में जीवन नहीं है। यदि आप अपने चारों ओर एक संकीर्ण बॉक्स बनाते हैं, तो आप अपने आप को सीमित कर लेंगे। दूसरी तरफ, एक संगठन जो तकनीक को बनाने के लिए आवश्यक चीजों को खारिज करता है, वह भी सीमित है। आपको यह देखना होगा कि आप किस ग्रे में रहना पसंद करते हैं।

Answer 3

आवश्यकताएँ यात्रा में कदम हैं, एक दृष्टि दिशा है

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

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

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

इसलिए, दृष्टि के खिलाफ कोड करना सीखें, लेकिन समय आने पर उन आवश्यकताओं के लिए तैयार रहें।

Comments

+1 के लिए "आवश्यकताएं यात्रा में कदम हैं, एक दृष्टि दिशा है"

— उपयोगकर्ता

Answer 4

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

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

चश्मा अच्छा है, लेकिन वे कभी भी परिपूर्ण नहीं होते हैं। उस बारे में एक प्रमेय मौजूद है। आप यह साबित नहीं कर सकते कि युक्ति पूरी है और आप यह साबित नहीं कर सकते कि उपकरण में कोई बग नहीं है या यह रुक जाएगा :)

फिर भी, सॉफ्टवेयर कंपनियां इस प्रक्रिया में इन खामियों के बावजूद हर समय जहाज सॉफ्टवेयर करती हैं। कल्पना कभी भी परिपूर्ण नहीं होगी। युक्ति भी UNNATURAL और पुरानी है। एक प्रोटोटाइप के लिए एक युक्ति है जैसे कि लघुगणक तालिका एक ग्राफ के लिए है - एक युक्ति अनिवार्य रूप से एक उबाऊ विवरणिका है जिसका अर्थ है मुद्रित करना जबकि आप इसके बजाय एक उपकरण / ग्राफ के साथ बातचीत कर सकते थे। प्रेरणा के लिए http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html देखें ।

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

Comments

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

— रॉबिन्स

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

— रॉबिन्स

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

— जॉब

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

— रॉबिन्स

Answer 5

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

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

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

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

Answer 6

यदि आप एक स्टार्टअप में एक सॉफ्टवेयर डेवलपर के रूप में काम करना चाहते हैं, तो यह एक कौशल के अधिकारी हैं।

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

यदि आप अपने खाली समय में मनोरंजन के लिए कोडिंग कर रहे हैं, तो यह आपकी कॉल है। यदि आप अपने खाली समय की परियोजनाओं के लिए कॉल करने के लिए योग्य महसूस नहीं करते हैं, तो एक-एक तरीका आजमाएं और देखें कि क्या काम करता है। इसके अलावा यह जरूरी नहीं है कि एक आकार-फिट-सभी चीज हो, कुछ परियोजनाएं एक या दूसरे प्रकार के दृष्टिकोण के लिए कॉल करती हैं। आमतौर पर अगर आप इनमें से किसी एक प्रोजेक्ट पर गलत चुनते हैं, तो आप इसे बहुत तेजी से समझेंगे।

Answer 7

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

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

Answer 8

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

1) जिन लोगों को औपचारिक आवश्यकताओं की आवश्यकता होती है। उन्हें ठीक से बताया जाना चाहिए कि क्या करना है, और कैसे करना है। वे वाक्यों से प्यार करते हैं जैसे कि प्रक्रिया ए तर्क ले रही है बी उत्पादन करेगी , और वे उन लोगों से नफरत करते हैं: कार्यक्रम को हमारे चित्रण के काम को अधिक प्रभावी बनाना चाहिए । वे आमतौर पर कॉर्पोरेट जानवर हैं।

2) जो लोग ओपोसिट हैं 1. वे यह बताने के लिए नफरत करते हैं कि क्या करना है और कैसे करना है, उन्हें बताया जाना चाहिए कि उन्हें क्या हासिल करना चाहिए। वे क्लाइंट से बात करना पसंद करते हैं, वे जो कहते हैं उसका विश्लेषण करते हैं और फिर अपना समाधान विकसित करते हैं। वे आमतौर पर फ्रीलांसर हैं और निगम के लिए अच्छा नहीं है।

मैं यह नहीं कहूंगा कि उनमें से कौन बेहतर है। दोनों के अपने नियम और अंतर्विरोध हैं। वे अन्य स्थितियों के लिए सरल पर्याप्त हैं।

Answer 9

आप आवश्यकताओं को जाने बिना परिचालन सॉफ्टवेयर विकसित नहीं कर सकते हैं ; लेकिन, आप को विकसित करने के लिए क्या अपने अनुभव आपको बताता है कि आवश्यकताओं हैं पर एक हंसमुख अच्छा चाकू हो सकता है की संभावनाहोने के लिए। फुर्तीली विकास 'सहज' तकनीकों के संयोजन का उपयोग करता है, जिसमें 80:20 नियम और प्रोटोटाइप द्वारा आवश्यकताओं की 'खोज' शामिल है। दूसरे शब्दों में, एक अनुभवी विकास टीम सॉफ़्टवेयर की एक प्रोटोटाइप का निर्माण करने की आवश्यकता पर सबसे अच्छा अनुमान लगाती है। 80:20 नियम कहता है कि वे 80% सही होंगे। परियोजना हितधारक तब मूर्त प्रोटोटाइप की समीक्षा करते हैं। हमारी प्रतिक्रिया आवश्यकताओं की हमारी समझ में 20% अंतर को भरना शुरू कर देती है। तो, वास्तव में, एजाइल बिना किसी आवश्यकता के सॉफ्टवेयर लिखने के बारे में नहीं है, बल्कि, यह कहने के लिए अपने पूर्व अनुभव का उपयोग करने के बारे में है, "क्या आप ऐसा कुछ चाह रहे हैं?" जो, 80% मामलों में, आपको आगे छलांग लगाने और यह पुष्टि करने की अनुमति देगा कि पारंपरिक आवश्यकताओं प्रक्रियाओं के माध्यम से प्लोडिंग की तुलना में वास्तव में क्या जल्दी की आवश्यकता है।

Comments

चंचलता अंतर्ज्ञान के बारे में नहीं है, यह संचार के बारे में है। प्रतिक्रिया प्राप्त करने के लिए अक्सर काम करने वाले सॉफ़्टवेयर को वितरित करना अक्सर संचार को प्रोत्साहित करना और ग्राहक की ज़रूरत की चीज़ों के वितरण का मूल्यांकन करना होता है। हां, अनुभव खेलने में आता है, लेकिन आपको यह विकसित करने की अधिक संभावना है कि ग्राहक को क्या चाहिए अगर आप पहले पूछें कि ग्राहक को क्या चाहिए। तथाकथित 80:20 नियम वास्तव में लागू नहीं होता है जब तक कि आप ग्राहक के व्यापार डोमेन से बहुत परिचित नहीं होते हैं, और तब भी मैं एक बड़े चम्मच नमक के साथ उस 'स्टेटिस्टिक' को ले जाऊंगा।

— रॉबिंस

Answer 10

किसने कहा कि चुस्त आवश्यकताओं के अभाव में कोडाइल लिख रहा था? मुझे पता है कि मैनिफेस्टो की व्याख्या कुछ इस तरह से की गई है ... लेकिन यह सही नहीं है।

Comments

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

— रॉबिन्स