कैसे तेजी से प्रोटोटाइप एक चुस्त कार्यप्रणाली में फिट बैठता है?

Question

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

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

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

हालाँकि, पायथन प्रोटोटाइप बनाने से हमें अपने हिरन के लिए बहुत धमाके मिलेंगे ताकि हम जल्दी से वास्तविक परिणाम दे सकें।

क्या आप तेजी से प्रोटोटाइप को शामिल करने में सक्षम हैं - उम्मीद है कि पायथन में - एक उद्यम वातावरण में एक ठोस चुस्त वर्कफ़्लो में?

Comments

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

— डेव हिलेयर

"बड़ी कंपनी, जो चुस्त का इस्तेमाल करती है" - " तानाशाही " और "चुस्त" शब्दों का मज़ेदार मिश्रण किसी तरह मुझे हाफ-एरेडेड एजाइल मेनिफेस्टो की याद दिलाता है । व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत ... और हमारे पास अनिवार्य प्रक्रियाएं और उपकरण हैं जो उन व्यक्तियों को नियंत्रित करने के लिए (हम 'संसाधनों' शब्द को पसंद करते हैं) बातचीत करते हैं

— gnat

Answer 1

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

ऐसे विभिन्न मामले हैं जिन्हें तलाशने की आवश्यकता है:

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

2. क्या प्रोटोटाइप कुछ ऐसा है जिसे समस्या स्थान को बेहतर ढंग से समझने के लिए निर्माण करने की आवश्यकता है? फिर इसे स्पाइक के रूप में कवर किया जाना चाहिए , और केवल इसके परिणाम रखे गए हैं (स्रोत कोड क्षणिक है)।

3. प्रोटोटाइप 0.x संस्करण है? एक mininimum व्यवहार्य उत्पाद ? फिर इसके लिए अपनी पसंद की चुस्त प्रक्रिया का उपयोग करें। यदि आपको इसे किसी अन्य भाषा में पुनर्निर्माण करने की आवश्यकता है, तो यदि आप एक अलग उत्पाद का इलाज करते हैं, तो आप बेहतर बंद होने की संभावना है। ध्यान दें कि कभी-कभी यह एक युक्ति लिखने के शॉर्टकट के रूप में माना जाता है ("इसे प्रोटोटाइप के समान ही करना चाहिए!")। यह एक उत्पाद के दस्तावेज़ीकरण का एक बहुत ही खराब तरीका है, लेकिन यह शायद एक अलग प्रश्न और उत्तर के रूप में बेहतर समझा जाता है :-)

Comments

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

— मार्टिन माट

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

— स्किलिविज़

Answer 2

नहीं है रैपिड प्रोटोटाइप (यानी पुनरावृत्ति और वृद्धिशील विकास) की तरह चंचल के पूरे मुद्दे?

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

और अजगर एक खिलौना भाषा नहीं है (अगर यह कभी था)। नासा और उसके ठेकेदार पायथन का उपयोग करते हैं , और यदि यह उनके लिए पर्याप्त है, तो यह मेरे लिए काफी अच्छा है।

Comments

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

— BobIsNotMyName

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

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

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

— जियोर्जियो

@ जियोर्जियो: यह ठीक है, लेकिन ग्राहकों को यह नहीं पता है कि वे क्या चाहते हैं जब तक कि आप इसे उन्हें नहीं दिखाते हैं और वे कहते हैं "नहीं, यह वह नहीं है जो मैं चाहता हूं, मैं यह चाहता हूं । आप चाहे कोड में करें या कागज के टुकड़े पर। मुझे इससे कोई फर्क नहीं पड़ता, इसलिए जब तक यह पहचान लेता है कि ग्राहक क्या चाहता है।

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

Answer 3

स्पाइक नामक एक्सट्रीम प्रोग्रामिंग में एक बहुत ही स्थापित अभ्यास है । इसका मतलब है कि यह फेक कोड है। इसमें कुछ खास नहीं है। यह सिर्फ एक स्प्रिंट है जिसमें अपेक्षित परिणाम थ्रोफेल कोड के बारे में ज्ञान है।

उपरोक्त लिंक में अच्छी प्रथाओं, स्पाइक्स के नुकसान के बारे में पर्याप्त जानकारी है।

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

1) सहायता संचार

2) समाधान साक्षात्कार में उपयोगकर्ताओं को प्राप्त करें और जल्दी प्रतिक्रिया प्राप्त करें

चेतावनी:

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

Answer 8

दूसरों ने पहले ही स्पाइक्स के सीखने के उद्देश्य का उल्लेख किया। जो चीज याद आ रही है वह इसका अंतर्निहित चुस्त सिद्धांत है जो तेजी से विफल है ।

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

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