क्या एजाइल सॉफ्टवेयर डेवलपमेंट का उपयोग अनुबंध द्वारा परिभाषित परियोजनाओं में किया जा सकता है?


14

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

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

यदि एजाइल सॉफ्टवेयर डेवलपमेंट बदलती जरूरतों को गले लगाता है तो आप कैसे जानते हैं कि यह कहां समाप्त होता है? जब आप अंतिम परिणाम हमेशा बदल रहे हैं, तो आप किसी परियोजना के लिए बजट कैसे दे सकते हैं?

फुर्तीली सॉफ्टवेयर विकास एक चुस्त उत्पाद की तुलना में एक चुस्त प्रक्रिया के बारे में अधिक है?


यह तब समाप्त होता है जब आपको वास्तव में कुछ काम करने की आवश्यकता होती है, बजाय कि टिंकर के। उस बिंदु पर आपको संरचना, योजना, आवश्यकताओं और समय सीमा को निर्धारित करना शुरू करना होगा और चारों ओर बेवकूफ बनाने के बजाय काम करना शुरू करना होगा।
जुंटिंग

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

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

@ वीरैक्स: परिवर्तनों को प्रबंधित करने के लिए फुर्तीला घोषणापत्र बनाया गया था। यदि आपकी परियोजना में कोई बदलाव नहीं हुआ है, तो चुस्त आपके लिए नहीं है। कहानी का अंत।
मार्टिन विकमन

2
@ वेरैक्स: आपको अपने प्रश्न को स्पष्ट करना चाहिए और इसमें और अधिक संदर्भ जोड़ना चाहिए। आपकी टिप्पणियों से पता चलता है कि प्रश्न अधिक है। यह भी जवाब पर वोट की गिनती से स्पष्ट है और यह कि स्वीकृत उत्तर वास्तविक प्रश्न पाठ से असंबंधित है (और यहां तक ​​कि "ओपी टिप्पणियों से ...") भी कहता है।
मार्टिन विकमैन

जवाबों:


7

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

चुस्त सॉफ्टवेयर विकास के साथ असंगत है जो एक अनुबंध द्वारा परिभाषित किया गया है।

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

कई कंसल्टिंग शॉप्स एजाइल का दावा करते हैं, वे झूठ बोल रहे हैं। वे सिर्फ इतना कहते हैं कि चंचल को बज़ शब्द का दर्जा मिला है।

फुर्तीली आंतरिक विकास के लिए सबसे अच्छा काम करता है जहां प्रोग्रामर पूर्णकालिक होते हैं, और बजट की बहुत कम बात होती है। सिर्फ टाइम फ्रेम्स और फीचर्स।


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

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

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

यह असंगत नहीं है यदि अनुबंध सेवा (लेखन कोड) के लिए है जैसा कि उत्पाद (तैयार सॉफ्टवेयर) के विपरीत है। चंचल यह अनुमान लगाने की अनुमति देता है कि क्या बजट के तहत किया जाएगा, यदि आवश्यकता होती है, तो बजट को भी बदलना होगा। आप एक और सुविधा चाहते हैं? आपको एक और 500 मानव-घंटे का अनुबंध करना चाहिए। फीचर रेंगना भी मूल्य रेंगना है, जो डेवलपर्स के लिए पूरी तरह से संतोषजनक है, और यदि ग्राहक भुगतान करने के लिए तैयार है, तो हम कौन हैं?
एसएफ।

2
हैं चुस्त अनुबंध है, तो जाहिर है इस जवाब परिभाषा से गलत है।
मार्टिन विकमैन

20

यदि आप सबसे महत्वपूर्ण चीजें पहले करने पर ध्यान केंद्रित कर रहे हैं (जो आपको विश्वास है कि) है, तो परियोजना तब पूरी होगी जब:

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

5
1. अधिक पैसा नहीं - ग्राहक ने अपना सारा पैसा एक अधूरे बेकार उत्पाद पर खर्च किया। 2. अधिक समय नहीं - ग्राहक के पास अभी भी एक बेकार उत्पाद है। 3. जोड़ने के लिए कुछ भी नहीं - हाँ ठीक है! 4. इसके लायक नहीं - ग्राहक ने सिर्फ परियोजना पर ध्यान दिया। --- मुझे किसकी याद आ रही है? इससे मुझे कोई मतलब नहीं है।
वेरैक्स

7
1 और 2 के लिए: यदि आप सबसे महत्वपूर्ण सामान पहले करते हैं, तो जब आप पैसे से बाहर निकलते हैं, तो आपके पास सबसे महत्वपूर्ण सामान होगा जो आपको पैसे के लिए मिल सकता है। समय के लिए समान। मैं मानता हूं 3 दुर्लभ है। 4 के लिए: रोकना जरूरी नहीं है कि ग्राहक ने अभी-अभी दिया है। इसका मतलब यह हो सकता है कि उनके पास सबसे महत्वपूर्ण सामान है जो वे इससे चाहते थे, और अब अपने पैसे के साथ अन्य चीजें करेंगे। अन्य परियोजनाओं को समाप्त करने के लिए आप कैसे निर्णय लेते हैं? अब आप जो भी मानदंड उपयोग करते हैं, वे अभी भी चुस्त परियोजनाओं पर उपलब्ध हैं।
डेल एमरी

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

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

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

14

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

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


5

कभी नहीं, और यही इसकी खूबसूरती है।

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

इस तकनीक का अक्सर उल्लेखित व्यवसाय विशेषता नहीं है, क्या यह है?


2
जलप्रपात परियोजनाएं कभी भी पूरी तरह से समाप्त नहीं हुई हैं, बस ले जाने की संभावना है कि इसे ले जाना-या-छोड़ना महत्वपूर्ण सुविधाओं के साथ गायब है, जिससे एक नई, महंगी परियोजना आवश्यक हो जाती है।
माइकल बॉर्गवर्ड

4

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

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

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

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

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


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

1
इसके अलावा, आप इसे एक अच्छी बात की तरह आवाज़ देते हैं जिसे मालिक किसी भी बिंदु पर कॉल कर सकता है और आपके पास जो कुछ भी है वह समाप्त हो जाता है। IME, आम तौर पर ग्राहक जानना चाहते हैं कि उनका X डॉलर कैश में डुबकी लगाने से पहले एक निश्चित सुविधा प्रदान करने वाला है। मैं इसे एक लाभ के रूप में नहीं देखता हूं कि ग्राहक ने नकदी का ढेर खर्च किया और उन्हें केवल आधी सुविधाएं मिलीं। मैं विचार है कि भले ही वे कुछ वे काम कर कॉल वितरित हो सकता है विकसित करने के लिए कंपनियों हिस्से पर एक विफलता होगी ....
डंक

2
क्या होगा यदि एक ग्राहक एक घर के लिए अनुबंधित हो, लेकिन छत पर डालने से पहले पैसा बाहर चला गया था? फुर्तीला शिविर अभी भी एक सफलता कहेगा। कोई और नहीं होगा; विशेष रूप से ग्राहक
डंक

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

1
अगर यह एक झरने SLDC में ही किया है तो क्या होगा? या तो विकास बंद हो जाएगा और ग्राहक को गंभीर कार्यक्षमता छेद के साथ एक कोडबेस मिल सकता है, या पैसे / समय की कमी की आशंका होगी, शेष समय में शेष शेड्यूल को रद्द कर दिया जाएगा। यह हमेशा गुणवत्ता का बलिदान करता है, और ऐसी परियोजना के अंत में विकास टीम तला हुआ है। इसके अलावा, बहुत अधिक लागत हो जाती है क्योंकि एक पारंपरिक झरना उत्पाद का उत्पादन नहीं करता है जब तक कि विकास पूरा नहीं होता है; ग्राहक की यह कहने की क्षमता को सीमित करता है कि "वह नहीं है जो मैं चाहता था"।
कीथ्स

1

सभी सुविधाएँ लागू होने के बाद यह समाप्त हो जाती है और सभी बग्स ठीक हो जाते हैं।

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

निश्चित मूल्य भाग 1, इतना बुरा क्या है?

निश्चित मूल्य भाग 2, इसे चुस्त के साथ ठीक करें!


यह जानना मुश्किल है कि सभी कीड़े कब ठीक किए जाते हैं।
मार्टिन विकमैन

शायद "जब सभी ज्ञात कीड़े जो फिक्सिंग के लायक हैं, तय हो गए हैं"?
डैन रे

@CharithJ, आपके लिंक टूट गए हैं। क्या वे अब भी कहीं उपलब्ध हैं? धन्यवाद।
ट्वेनज

1

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

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


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