कोडिंग से पहले कार्यक्षमता जानना कितना महत्वपूर्ण है?


9

मैं एक सॉफ्टवेयर डेवलपमेंट कंपनी के लिए काम करता हूँ, जहाँ पर विकास का काम बंद कर दिया गया है। किनारे टीम समर्थन संभालती है और ग्राहकों से सीधे बात करती है। हम कभी भी ग्राहकों से सीधे बात नहीं करते हैं हम सिर्फ किनारे की टीम के लोगों से बात करते हैं, जो ग्राहकों से सीधे बात करते हैं।

जब आवश्यकताएं आती हैं, तो किनारे टीम ग्राहकों से बात करती है और आवश्यकता दस्तावेज बनाती है और हमें सूचित करती है। हम आवश्यकताओं का अध्ययन करने के बाद डिजाइन दस्तावेज बनाते हैं (हम पारंपरिक जलप्रपात मॉडल का पालन करते हैं)।

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

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

मेरा प्रश्न यह है कि यदि आप ऐप की कार्यक्षमता को पूरी तरह से नहीं जानते हैं तो आप कैसे विकास कार्य करेंगे?

अपडेट करें

विकास पद्धति यह वास्तव में मेरी पसंद नहीं है और मैं अपनी टीम का नेतृत्व नहीं कर रहा हूं। यह जिस तरह से शुरू हुआ था। मैंने लोगों को फुर्तीले फायदों के बारे में बताने की कोशिश की लेकिन कोई फायदा नहीं हुआ। इसके अलावा मुझे नहीं लगता कि मेरी टीम में फुर्तीले माहौल में काम करने की आवश्यक मानसिकता है।



यह एक व्यक्तिगत राय है, लेकिन आप जिस पर्यावरण का वर्णन कर रहे हैं, उसके लिए आप बिल्कुल गलत सॉफ्टवेयर डेवलपमेंट मेथडोलॉजी (झरना) का उपयोग कर रहे हैं। राड, या चुस्त आप बेहतर सूट करेगा।
डैश

1
यदि आप कुछ भी नहीं बदलते हैं, तो चीजें या तो एक ही रहेंगी, या कोई अन्य व्यक्ति कुछ बदलेगा और आपके पास या तो कम नियंत्रण होगा, या कोई नौकरी नहीं होगी :-( मैं बच्चे को बाहर फेंकने की वकालत नहीं कर रहा हूं डिशवॉटर, लेकिन आप वास्तव में वह विकसित करने पर नहीं जा सकते हैं जो आपको लगता है कि ग्राहक चाहते हैं। शायद आप किसी के साथ काम करने वाले ग्राहकों के आधार पर दिन-प्रतिदिन प्राप्त कर सकते हैं। रिश्ता आपको लाभ देने वाला है।
डैश

1
@MarkBannister "इस प्रश्न में निहित प्रतीत होता है कि एक बड़ा, मौजूदा एप्लिकेशन है जिसे खरोंच से बनाए जाने वाले नए एप्लिकेशन के बजाय संशोधित करने की आवश्यकता है - क्या यह सही है?" सही है।
माइनसइवेन

जवाबों:


6

लघु संस्करण:

अपने ग्राहक को जानने के लिए क्या करना चाहिए।

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


दीर्घ संस्करण:

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

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

दूसरी ओर, विशिष्ट डोमेन की समझ के बिना बनाया गया एक सॉफ्टवेयर उत्पाद सबसे अच्छा, अच्छा, थोड़ा बेकार होगा

इसलिए कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं को उन लोगों द्वारा लिखा जाना चाहिए जो डोमेन को पूरी तरह से समझते हैं। सामान्य तौर पर, आवश्यकताएं एक ही समय में शामिल होती हैं:

  1. तकनीशियनों (उदाहरण के लिए डेवलपर्स जो यह बताएंगे कि एक विशिष्ट सुविधा असंभव है, कि अगर इस तरह से किया जाए तो यह अन्य बहुत बेहतर हो सकता है, और इस पर हजारों डॉलर खर्च होंगे जबकि बहुत सस्ता विकल्प है)

  2. परियोजना प्रबंधन में विशेषज्ञता प्राप्त लोग,

  3. ग्राहक के क्षेत्र में विशिष्ट लोग , जिनके पास इस डोमेन की पूरी समझ और ग्राहक की सटीक ज़रूरतें हैं। बेशक, यह ग्राहक ही हो सकता है।

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


अपने विशिष्ट मामले के रूप में, आप समस्या का कारण स्वयं बताते हैं:

हम डिजाइन दस्तावेज के साथ संघर्ष करते हैं क्योंकि आवश्यकताएं स्पष्ट नहीं होंगी।

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

यह जानते हुए कि, आपको अलग तरह से कार्य करना होगा:

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

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

संभवतः आवश्यकताओं का दस्तावेज़ अभी अधूरा है। मैं यह हर समय देखता हूं: अनुभवहीन परियोजना प्रबंधकों को सिर्फ यह विश्वास है कि एक-पृष्ठ दस्तावेज़ पर्याप्त है, और समझ में नहीं आता कि वे कभी एक के बजाय तीन से चार सौ पृष्ठ क्यों लिखेंगे। यदि आपकी कंपनी में ऐसा है, तो बताएं कि आवश्यकताओं पर अधिक समय खर्च करने से लागत में कमी आएगी।


11

आप जिन समस्याओं का सामना कर रहे हैं, उनके लिए आप गलत विकास पद्धति का उपयोग कर रहे हैं।

झरना का उपयोग करके आप इसके लिए प्रतिबद्ध हैं:

  1. सही आवश्यकताओं को सामने लाना - यह स्पष्ट रूप से काम नहीं कर रहा है
  2. आवश्यकताओं को ग्राहक से दूर करना - आप आवश्यकताओं को विकसित करने के लिए प्रतिबद्ध ग्राहक के साथ समस्याओं की प्रभावी ढंग से जांच करने में सक्षम नहीं हैं
  3. ग्राहक को उनकी कार्यक्षमता देखने का पहला मौका परीक्षण के दौरान मिलता है - यह आपके द्वारा किए जा रहे मुद्दों को देखते हुए बहुत देर हो चुकी है

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

वाटरफॉल बनाम एजाइल की एक सभ्य तुलना कुछ समय पहले लिखी गई थी, इससे कुछ उद्धरणों को लिया जा सकता है जो आपकी समस्याओं को उजागर करते हैं:

मार्क गुम:

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

नीचे बांधा...

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

... और ले जाने में असमर्थ

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

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

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


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

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

जोड़ने के लिए, यह असंभव नहीं है, यहां तक ​​कि सार्थक बदलाव करने के लिए "सिर्फ एक प्रोग्रामर" के रूप में। jamesshore.com/Change-Diary
शौना

-1, यह चुस्त करने के लिए एक प्रेम पत्र है, न कि ग्राहकों की समस्या का समाधान जो एक विकास टीम के साथ काम करने को तैयार नहीं है। चंचल वैसे भी ठीक नहीं करता है।
रायथल

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

4

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

  • आप घर बनाने के लिए एक बिल्डिंग कंपनी को ऑर्डर करते हैं लेकिन आप नहीं जानते कि आप इसे कैसे देखना चाहते हैं। आप सिर्फ पहली मंजिल को अनुकूलित करते हैं, इसलिए टीम पहली मंजिल तक एक घर बनाती है। फिर आप चाहते हैं कि भूतल अलग तरीके से बिछाया जाए। ओह ...

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


-1

यहाँ कुछ चीजें हैं जो समस्याओं को दूर करने में मदद करेगी:

  1. दो टीमों के बीच संचार में सुधार । अन्य टीम को 3 शब्दों की आवश्यकता को संक्षिप्त करने के लिए कहें, और फिर प्रोग्रामर उन शब्दों को बिल्कुल लागू करेगा। शब्दों को सिर्फ सही होना चाहिए। उन शब्दों के बिना कुछ भी लागू नहीं किया जाएगा। हर शब्द आपको कोड की 2000 लाइनें देता है। कार्यान्वयन तब शुरू होता है जब कोई नया शब्द ज्ञात होता है।
  2. यदि आपके प्रोग्रामर को एक शब्द तुरंत स्पष्ट नहीं है, तो उन्हें एकल प्रश्न पूछने की अनुमति है । प्रश्न को फिर से सही करना होगा। इसे तत्काल उत्तर की आवश्यकता है - उत्तर दुनिया के दूसरी तरफ से एक राउंडट्रिप की प्रतीक्षा नहीं कर सकता है, लेकिन इसे पहले से जानने की आवश्यकता है। उत्तर प्राप्त करने के तुरंत बाद कार्यान्वयन शुरू हो जाता है और उत्तर पत्र का पालन किया जाएगा।
  3. यदि कार्यान्वयन के दौरान अस्पष्ट या अस्पष्ट आवश्यकताएं हैं, तो उन्हें हल करने का तरीका पहले (मौजूदा) 3 शब्दों को देखना है। यदि यह अभी भी अस्पष्ट है, तो प्रोग्रामर सबसे अच्छा अनुमान संभव बनाता है । इस प्रक्रिया में कोई भी देरी बिल्कुल मना है; और दूसरी टीम से मदद मांगना इसे हल करने का सही तरीका नहीं है - उनके पास पहले से ही सही 3 शब्द तय करके आवश्यकताओं को बदलने का मौका था।
  4. यदि इस सब के बाद, आवश्यकता अभी भी अस्पष्ट या असंभव है, तो संभाल करने का सही तरीका उन 3 शब्दों को अस्वीकार करना है जो परेशानी का कारण बने, और अगले शब्दों पर जाएं। किसी भी खारिज किए गए शब्दों को एकत्र किया जाएगा और दूसरी टीम को दिया जाएगा, और उन्हें सिस्टम में फिर से दर्ज करने से पहले शब्दों को संशोधित करना होगा। शब्दों को अस्वीकार करना हमेशा समय सीमा को आगे बढ़ाता है और कार्यान्वयन को फिर से योजना बनाने की आवश्यकता होगी।
  5. टीमों को इस बात का मूल्यांकन करना होगा कि उनके पास कितने अस्वीकृत शब्द हैं। आवश्यकता लागू होने के बाद, यह हमेशा के लिए तय हो गया है और अब इसे बदला नहीं जा सकता है । पहले से लागू सुविधाओं को बदलने के किसी भी प्रयास को अस्वीकार कर दिया जाएगा।
  6. प्रश्न के साथ वास्तविक समस्या यह है कि यह मानता है कि अधिक जानकारी कार्यान्वयन को आसान बनाती है। यह सच नहीं है। और अधिक स्वतंत्रता अपने प्रोग्रामर है, आसान कार्यान्वयन । आवश्यकताओं को संपीड़ित करने के लिए बड़ी मात्रा में जानकारी को संवाद किए बिना अनुमति देने से प्रोग्रामर को क्या करने की अनुमति मिलती है।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.