चुस्त तरीकों के साथ उत्कृष्ट सॉफ्टवेयर कैसे विकसित करें?


61

ग्राहक संतुष्टि का कानो मॉडल उत्पाद सुविधाओं के विभिन्न वर्गों को परिभाषित करता है। उनमें से हैं

  1. गुण होना चाहिए: यदि इन्हें लागू नहीं किया जाता है तो ग्राहक उत्पाद को स्वीकार नहीं करेगा।

  2. आकर्षक गुण (प्रसन्नता देने वाले): ऐसी विशेषताएं जो ग्राहक अक्सर पहली जगह में भी उम्मीद नहीं करते हैं लेकिन खोजे जाने पर उत्साह और खुशी का कारण बनते हैं।

आकर्षक गुणों का स्पष्ट रूप से बहुत अधिक व्यावसायिक मूल्य है। वे लोगों को 500.000 के लिए फेरारी खरीदते हैं जब 5.000 से कम के फिएट का इस्तेमाल सभी आवश्यकताओं को पूरा करता है।

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

मेरा मानना ​​है कि चुस्त प्रक्रियाएँ सॉफ्टवेयर विकास में बहुत उपयोगी हैं। लेकिन उन्हें खुशहाल उच्च गुणवत्ता वाले सॉफ्टवेयर उत्पादों को बनाने के लिए कैसे लागू किया जा सकता है और न केवल न्यूनतम न्यूनतम जो मुश्किल से आवश्यकताओं को पूरा करता है?

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


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

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

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

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

4
उत्कृष्ट सॉफ्टवेयर कैसे विकसित करें? उत्कृष्ट डेवलपर्स किराया। विकास पद्धति, विकास करने वाले लोगों की तुलना में बहुत कम महत्वपूर्ण है।
मार्क

जवाबों:


78

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

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

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

ऑटोमोबाइल का आविष्कार कभी नहीं हुआ होता अगर उस समय निर्माता "फुर्तीले" होते, क्योंकि सभी ग्राहक तेजी से घोड़ा बनाने के लिए कह रहे थे।

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

[संपादित करें]

Slebetman:

यह विडंबना है कि फुर्तीली वाहन उद्योग (अर्थात् टोयोटा) से विकसित हुआ।

स्वचालन का सुनहरा नियम याद है? "पहले व्यवस्थित करें, फिर स्वचालित करें"। यदि आप एक टूटी हुई प्रक्रिया को स्वचालित करते हैं, तो सबसे अच्छा यह हो सकता है कि आप हर उस चीज में तेजी लाएं जो गलत हो। टोयोटा में लोग बेवकूफ नहीं थे।

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

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

बिक्री, ग्राहक सेवा या दूसरी ओर मालिक इसे एक विभाग के इस ब्लैक बॉक्स पर लाभ (वापस) नियंत्रण के रूप में देख सकते हैं जो संभवतः आवश्यक सामान कर रहे हैं। वे यह नहीं देखते हैं कि वहां क्या हो रहा है, लेकिन उन्हें पूरा यकीन है कि समस्या का मूल वहाँ कहीं दफन है। इसलिए वे स्क्रैम को पेश करते हैं, अपनी पसंद के उत्पाद के मालिक को स्थापित करते हैं और अचानक उनके पास सभी नियंत्रण होते हैं, सभी तार उनके हाथ में होते हैं। अब क्या? ... एहर ...

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

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

तो चीजें बदतर हो जाती हैं और निष्कर्ष यह होगा कि एजाइल चूसता है।

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


4
यह विडंबना है कि फुर्तीली वाहन उद्योग (अर्थात् टोयोटा) से विकसित हुआ। मूल ने क्या किया: टोयोटा की "द टोयोटा वे" कार्यप्रणाली "ग्राहक" को कार खरीदने वाले व्यक्ति के रूप में परिभाषित नहीं करती है। इसके बजाय यह उत्पाद डिजाइन / विपणन विभाग है। यह उत्पाद या विपणन विभाग का काम है कि कानो जैसे उत्पाद डिजाइन मॉडल का पालन करें। एजाइल का काम उत्पाद का कार्यान्वयन और वास्तव में निर्माण करना है। यदि आप खुद को मिक्सिंग मेथडोलॉजी पाते हैं तो आपके बॉस को वास्तव में नौकरी की भूमिकाएं समझ में नहीं आती हैं। यदि आप एक स्टार्टअप हैं और आपके पास कोई विकल्प नहीं है, तो उन्हें अलग से करें।
स्लीवमैन

1
एक अच्छा सवाल होगा। कैसे हम (डेवलपर्स) ग्राहक को यह समझने के लिए फुसला सकते हैं कि वे शोध करें, केवल कार्यक्षमता पर्याप्त नहीं है। मेरे पास कुछ कठिन परिस्थितियों को प्रभावित करने की कोशिश कर रहा है, जो कि गलत साबित हुए या वास्तविक जीविका के अभाव में प्रभावित हुए।
Laiv

5
+1 वास्तविक दुनिया में फुर्तीले का सबसे अच्छा विवरण जो मैंने लंबे समय में देखा है।
पॉल स्मिथ

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

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

74

फुर्तीले में आकर्षक गुणों के लिए एक जगह भी नहीं लगती है।

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

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

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


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

21
और फुर्तीले के साथ आप अपने फिएट प्रोजेक्ट का विस्तार करने में सक्षम हो सकते हैं और एक फेरारी प्राप्त कर सकते हैं, या एक फेरारी परियोजना के साथ, अभी भी एक फिएट प्राप्त कर सकते हैं (नॉनजेरो मूल्य के साथ) भले ही परियोजना विफल हो जाए।
user253751

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

13
@MartinMaat मैं इस तथ्य पर आपसे सहमत हूं कि एक खराब पीओ एक खराब परिणाम के लिए बनाता है, लेकिन मैंने झरने में बहुत सारी खराब आवश्यकताओं के दस्तावेजों को देखा है, मैं सहमत नहीं हो सकता कि यह एक चुस्त बात है। एक बुरा काम एक बुरा काम है ... किसी भी प्रक्रिया में।
नवगीत

28

हालांकि, सभी चुस्त प्रक्रियाएं मुझे पता है कि आवश्यकताओं का दृढ़ता से पक्ष लेना चाहिए। इन्हें हमेशा सर्वोच्च प्राथमिकता मिलती है।

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

फुर्तीले में आकर्षक गुणों के लिए एक जगह भी नहीं लगती है।

सच्चाई से आगे कुछ भी नहीं हो सकता है।

फुर्तीली प्रक्रियाएं आमतौर पर इन बिंदुओं पर जोर देती हैं:

  • किसी कार्यशील उत्पाद की बार-बार डिलीवरी जिससे आपको फीडबैक मिल सके।
  • छोटे भागों में सुविधाओं को विभाजित करें जिन्हें थोड़े समय में पूरा किया जा सकता है।
  • प्राथमिकता के क्रम में उन भागों को लागू करें।

कुछ भी आपको "प्रसन्नता" देने से रोकता है एक उच्च प्राथमिकता है। यह पूरी तरह से उन लोगों पर निर्भर करता है जो प्राथमिकताएं निर्धारित करने के प्रभारी हैं।

अब यह सच है कि ऐसे कई लोग जोखिम नहीं लेना पसंद करते हैं और इस तरह "प्रसन्नता" को उच्च प्राथमिकता नहीं दे सकते हैं। लेकिन एक गैर-चुस्त परियोजना में जो अभी भी मामला होगा।


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

9

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

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

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

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

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


9

उत्कृष्ट सॉफ्टवेयर दो चीजों से आता है:

  • ग्राहक को वे देते हैं जिनकी उन्हें आवश्यकता होती है

  • एक पेशेवर होने के नाते

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

हमारी नौकरी का हिस्सा मानकों को बनाए रखना है जो ग्राहक को कभी भी अनुभव नहीं होता है जब तक कि चीजें बहुत गलत न हों।

यदि आप इसे सही कर रहे हैं तो फुर्तीलापन केवल तब होता है जब ग्राहक वास्तव में चाहता है। ऐसा नहीं है कि जब वे आंकड़ा है कि वे के लिए व्यवस्थित करने के लिए है।

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

आज भी कई दुकानों में झरना उपयोग में है। ये दुकानें सफल हैं क्योंकि उनकी आवश्यकताएं एक वर्ष में 2% से कम बदलती हैं।

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

कोई भी बेवकूफ एक असीमित बजट के साथ एक पुल का निर्माण कर सकता है। एक पेशेवर एक पुल का निर्माण करता है, जो कि मुश्किल से कभी नीचे गिरता है।

इसलिए मेरा मानना ​​है कि किसी को भी आवश्यक आवश्यकताओं पर ध्यान केंद्रित नहीं करना चाहिए।

ज़रूर चाहिए। सिवाय जब आपके समय का अनुमान लगाए। क्योंकि उन आवश्यकताओं को केवल विचार नहीं होना चाहिए।


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

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

4

ठीक,

फुर्तीली में प्रोग्रामर सॉफ्टवेयर बना सकता है, लेकिन अंत में यह उत्पाद बनाने वाला है जो उत्पाद बनाता है। (सॉफ्टवेयर डेवलपर्स का उपयोग करके।)

तो "आकर्षक गुणों" के बारे में, वह उत्पाद निर्माता तक है।

यदि उत्पाद निर्माता "सेक्सी डिजाइन" को अनिवार्य करता है, तो इसे एक आवश्यकता बना दिया जा सकता है। डेवलपर को इन विकल्पों के बारे में चिंता नहीं करनी चाहिए।

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


3

मेरा अनुभव उपरोक्त टिप्पणियों से सहमत है - एजाइल में कुछ भी अंतर्निहित नहीं है जो उत्कृष्ट सॉफ्टवेयर के विकास को रोकता है - हालांकि इस बात के कई पहलू हैं कि कैसे एजाइल अक्सर (mal-) अभ्यास किया जाता है जो सॉफ्टवेयर का नेतृत्व करता है जो केवल "अच्छा-पर्याप्त" है । "

  • चंचल ASAP कुछ काम करने पर जोर देता है ; हालांकि इसका अर्थ है कि मान्यताओं को सरल बनाना और कोनों को काटना, विशेष रूप से उपयोगकर्ता-दृश्यमान अवसंरचना में। इस बारे में कुछ भी गलत नहीं है, अगर सरलीकृत मान्यताओं को सही करने की लागत कम है; हालांकि सभी-बहुत-अक्सर यह "तकनीकी ऋण" किसी उत्पाद के उत्पादन में जाने से पहले हटाया नहीं जाता है;
  • फुर्तीली ने कहा कि एक स्प्रिंट के अंत में, आपके पास हमेशा कुछ ऐसा होना चाहिए जो कि आपके द्वारा बनाए जा सकने वाले shippable के करीब हो, ताकि हितधारक और परियोजना प्रबंधक यह तय कर सकें कि "उनके पास क्या है" उत्पादन। फिर, स्वाभाविक रूप से कुछ भी गलत नहीं है, अगरआपने अपने सभी "तकनीकी ऋण" को मंजूरी दे दी है (या आपके पास आपकी शांति है कि आपके पास कितना है और यह कहां है।) हालांकि, मेरे अनुभव में, बहुत अधिक तकनीकी ऋण एक प्रबंधक द्वारा एक वादा के साथ उत्पादन में जाता है कि "हम जहाज पर दबाव पड़ने के बाद "इसे साफ कर देंगे", जो तेजी से "उत्पादन में बदल जाता है, हमें अब जो हम बदलते हैं उसके बारे में बहुत सावधान रहना होगा", जो अंततः "आप मुझे बताएंगे कि हमने कभी उस जोखिम को नहीं बताया था" हमें अगली बार एक बेहतर काम करना है! " "कम कीमत की मिठास भूल जाने के बाद खराब गुणवत्ता की कड़वाहट लंबे समय तक बनी रहती है" के बारे में बेन फ्रेंकिन का सबक कभी नहीं सीखा गया लगता है;
  • हालांकि, यहां तक ​​कि भरोसेमंद प्रबंधकों और अच्छी तरह से अनुशासित डेवलपर्स के साथ, आम समस्या है कि स्प्रिंट की शुरुआत से पहले बहुत कम उचित विश्लेषण, डिजाइन और डिजाइन की समीक्षा होती है जिसमें कार्यान्वयन शुरू होने और पूरा होने की उम्मीद है। वैकल्पिक रूप से विचार करने में विफलतायूआई रूपकों और डिजाइन बड़े हैं - यह आमतौर पर एक परियोजना शुरू होने के बाद काफी महंगा है; जूनियर टीमों की विफलता उनकी प्रतिस्पर्धा के उत्पादों का सावधानीपूर्वक अध्ययन करने के लिए, या I18N, अधिसूचना ढांचे, लॉगिंग, सुरक्षा और एपीआई वर्जनिंग रणनीतियों (उदाहरण के लिए) के रूप में बुनियादी ढांचे प्रौद्योगिकियों के परिभाषा और कार्यान्वयन को प्राथमिकता देने के लिए है, जिसका अर्थ है कि वे अंततः उच्च बग, कम उत्पादकता, और अधिक तकनीकी ऋण को अर्जित करेगा, यदि उन्होंने पहले 2-5 स्प्रिंट अप-फ्रंट को अपेक्षित प्रशिक्षण, विश्लेषण, डिजाइन और प्रोटोटाइप बनाने में खर्च किया था। संक्षेप में, फुर्तीली टीमों को हैक करने के लिए लाइसेंस का विरोध करना चाहिए;
  • मेरे पास एक दूसरे-स्तर के प्रबंधक (100 से अधिक डेवलपर्स में से) हैं, जिन्होंने अपने डेवलपर्स को अपने नियोजित डिजाइन लिखने के लिए समय निकालने से हतोत्साहित किया, यहां तक ​​कि सबसे बुनियादी स्तर पर भी। उनका तर्क - "मैं चाहता हूं कि लोग एक-दूसरे के साथ बात करें" - जो कि विडंबना थी क्योंकि वे 5 अलग-अलग समय क्षेत्रों और 3 देशों में थे। कहने की जरूरत नहीं, वहाँ उंगली का एक बहुत के बारे में जो टीम परियोजना में देर रात और सप्ताहांत के बहुत सारे काम करने के लिए एक बार वे पता लगा हर किसी ने सोचा कि करने जा रहा था अन्य पुरुष कुछ कार्यक्षमता को लागू करने के लिए जिम्मेदार था (या फिर से लागू करना क्योंकि आपूर्तिकर्ता और उपभोक्ता के डिजाइनों में केवल जाली नहीं थी।)

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


1

टी एल; डॉ

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

पारंपरिक प्रक्रियाओं में कई सॉफ्टवेयर परियोजनाओं का सामना करने वाली समस्याओं को दूर करने के लिए कुछ स्मार्ट लोगों द्वारा चुस्त विकास पेश किया गया था।

फुर्तीली घोषणा (1) द्वारा परिभाषित चुस्त विकास के प्रमुख मूल्य हैं,

  • व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत
  • व्यापक प्रलेखन पर कार्य सॉफ्टवेयर
  • अनुबंध वार्ता पर ग्राहक सहयोग
  • किसी योजना का पालन करने पर परिवर्तन का जवाब देना

इसलिए, फुर्तीली विकास आपको उच्च गुणवत्ता वाले सॉफ़्टवेयर बनाने से नहीं रोकता है। चंचल विकास आपको उच्च गुणवत्ता वाले सॉफ़्टवेयर वितरित करने के लिए समर्थन करता है।

लेकिन क्या हम (और ग्राहक) वास्तव में हमेशा अग्रिम में जानते हैं कि क्या आवश्यकताएं होनी चाहिए।

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

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

दिनों में वापस - आज के लिए यह अभी भी सच है - पारंपरिक दृष्टिकोणों में विकसित कई सॉफ्टवेयर परियोजनाएं सफल नहीं हुईं, या ग्राहकों को नाराजगी का कारण नहीं होना चाहिए क्योंकि आवश्यक गुणवत्ता तक नहीं पहुंचा गया था।

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

मैं रिवर्स क्वालिटी - उन विशेषताओं का भी उल्लेख करना चाहता हूं, जो कानो मॉडल के असंतोष की ओर ले जाती हैं।

हर परियोजना में आवश्यकताएं होती हैं जो परियोजना की शुरुआत में अच्छे विचार प्रतीत होते हैं। थोड़ी देर बाद वे विपरीत में बदल जाते हैं और निराशा पैदा करते हैं।

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

फुर्तीली विकास आपको गैर-कामकाजी या असंतोषजनक आवश्यकताओं को जल्दी पहचानने और परियोजना के दौरान उन्हें बदलने में मदद करता है।

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


1

मुझे इस पार्टी के लिए देर हो रही है, लेकिन मैं इस विषय पर एक और कोण साझा करना चाहता हूं:

लेकिन उन्हें खुशहाल उच्च गुणवत्ता वाले सॉफ्टवेयर उत्पादों को बनाने के लिए कैसे लागू किया जा सकता है और न केवल न्यूनतम न्यूनतम जो मुश्किल से आवश्यकताओं को पूरा करता है?

फुर्तीली सॉफ्टवेयर विकास में एक अस्थायी पहलू है जो पुनरावृत्त दृष्टिकोण और ग्राहक प्रतिक्रिया पर विचार करने के परिणामस्वरूप होता है , जो चुस्त कार्यप्रणाली के दो महत्वपूर्ण तत्व हैं। उदाहरण: वे विशेषताएँ जिन्हें iteration t में आकर्षक गुणवत्ता के रूप में पहचाना जाता है , वे अगले पुनरावृत्ति t + 1 में अवश्य ही गुणवत्ता वाली हो सकती हैं

चुस्त तरीकों को लागू करने से किसी विशेषता की गुणवत्ता श्रेणी बदल सकती है। यदि आप पुनरावृति की नियोजित सुविधाओं की तुलना कुछ बाद के पुनरावृत्ति t + n की सुविधाओं के साथ करते हैं, तो आप अनुभव करेंगे कि आपने क्या उल्लेख किया है:

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

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

निष्कर्ष

चुस्त तरीकों के साथ उत्कृष्ट सॉफ्टवेयर कैसे विकसित करें?

पुनरावृत्त दृष्टिकोण लागू करें और ग्राहकों की प्रतिक्रिया सुनें । इन तत्वों में से एक को खोदो और आपको चुस्त सॉफ्टवेयर विकास का एक कम सफल रूप मिलेगा।


1
   > How to develop excellent software with agile methods?
  • ग्राहक विशिष्ट व्यक्तिगत सॉफ़्टवेयर का निर्माण करते समय :
    • एक ग्राहक खोजें जहां लागत के मामले में कोई फर्क नहीं पड़ता क्योंकि "रमणीय" सुविधा के लिए अतिरिक्त पैसे खर्च होते हैं और ग्राहक को यह तय करना होता है कि क्या वह इसके लिए भुगतान करना चाहता है।
  • Softwareproducts का उत्पादन करते समय :
    • "रमणीय" विशेषताएं नए ग्राहकों को आकर्षित करने के लिए अच्छी हैं और "रमणीय" सुविधा को लागू करने की लागत इतनी महत्वपूर्ण नहीं है यदि उत्पाद 1000 से अधिक बार बेचा जाता है।
  • ऐसे वातावरण में जहां "अच्छा पर्याप्त (सबसे सस्ता) सबसे अच्छा है" आपको "रमणीय" सुविधाओं को लागू करने के लिए पैसा नहीं मिलेगा

एक स्क्रैम टीम में उत्पाद-मालिक को चुनना है कि कौन सी सुविधाओं को लागू करना है। तो यह उसके ऊपर है (और उसके बजट तक) "अच्छा पर्याप्त" या "उत्कृष्ट" सॉफ़्टवेयर को परिभाषित करने के लिए


1

आप कुछ अच्छे अंक जुटाएं। लेकिन मैं नहीं मानता कि ये समस्याएं चुस्त प्रक्रियाओं / कार्यप्रणालियों तक ही सीमित हैं।


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

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

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

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


चुस्त क्या कर सकते हैं (मदद) इन मुद्दों में से कुछ सतह पर लाना है।

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

यदि आप अपने आप को ऐसी स्थिति में पाते हैं, जहाँ अधिकांश वितरित कार्यक्षमता में आवश्यक विशेषताओं के बजाय हैप्पीर्स होते हैं, तो उस मुद्दे को उठाना बहुत आसान होता है (और कारण को निर्धारित करना बहुत आसान होता है) जब आप काम कर रहे हों या पास में काम कर रहे सॉफ़्टवेयर को वितरित कर रहे हों 2-3 सप्ताह की तुलना में जब प्रसव के महीने या वर्ष अलग होते हैं।

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

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

कुछ प्लानिंग करें, जिससे आप व्यवसाय की जरूरतों में बदलाव का जवाब दे सकें। "आप जानते हैं कि आप जिस वेब साइट का निर्माण कर रहे हैं, हमें वास्तव में एक मोबाइल ऐप की आवश्यकता है, जो डिस्कनेक्ट किए गए ऑपरेशन में सक्षम है।" यह कुछ ऐसा नहीं है जो विशेष रूप से के बारे में पूछा गया था ... लेकिन क्या आप अपनी प्रक्रिया को व्यवसाय के परिदृश्य (कम से कम सिद्धांत में) में परिवर्तन का जवाब देने में सक्षम नहीं चाहेंगे?


एजाइल यह नहीं कहता है कि "गैर-आवश्यक सुविधाओं का निर्माण न करें"। यह कहता है कि "व्यवसाय को यह तय करने की अनुमति दें कि कौन सी सुविधाओं का निर्माण करना है (नहीं)"।
... और (समान रूप से महत्वपूर्ण) "तकनीशियनों को यह बताने की अनुमति दें कि आप कितनी देर तक एक सुविधा का निर्माण करने जा रहे हैं"।


1
  1. Must-be qualitiesअक्सर निर्धारित करना कठिन होता है। लोग उन्हें अवचेतन में हैं। फुर्तीली पुनरावृत्तियों और ग्राहक भागीदारी से अधिकांश को खोजने में मदद मिलती है। यही फुर्ती की शक्ति है और इसे नजरअंदाज करना मूर्खता है
  2. One-dimensional qualitiesइसका मतलब है कि वादे जो पूरे होने चाहिए, झरने के समर्थन से ठीक हैं, जब तक कि वे बदल नहीं रहे हैं। यहाँ चुस्त होना ही मदद करता है, लेकिन इतना शक्तिशाली नहीं।
  3. Attractive qualitiesअच्छी विशेषताएं हैं। वे अगली पीढ़ी में जरूर बन सकते हैं। लेकिन वर्तमान पीढ़ी में वे समझौते में भी नहीं हैं - या वे एक-आयामी गुण होंगे। उन चुस्त तरीके जो मान लेते हैं कि ग्राहक प्रतिनिधि भागीदारी इन गुणों का बहुत अच्छी तरह से समर्थन करते हैं। काम के दौरान हम गुंजाइश को हल्के से बदल सकते हैं। हम दूसरे में कुछ मुआवजे के लिए एक जगह सुधार पर मोलभाव कर सकते हैं। झरने में यह व्यावहारिक रूप से असंभव है। एक महान संगठनात्मक देरी के बिना हम केवल मुफ्त में ADD सुविधाएँ प्रदान कर सकते हैं। यह संभव है, अगर कुछ अतिरिक्त समय पहले से बजट में डाला जाता है।

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

अपनी समझ में इसे करने के लिए आपको एक जिम्मेदार ग्राहक प्रतिनिधि प्रतिभागी के साथ चुस्त प्रक्रियाएँ निर्धारित करनी चाहिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.