नए संकलक बैकएंड को लागू करते समय क्या स्क्रम का कोई मतलब है?


15

मेरी एक मौजूदा भाषा है जिसे मुझे एक नए प्लेटफ़ॉर्म पर पोर्ट करने की आवश्यकता है। मैं शायद मौजूदा कंपाइलर के बैकएंड को बदलकर यह कोशिश करूँगा।

बैकएंड को फिर से लिखने के लिए यह एक महत्वपूर्ण राशि है। मैं एक ऐसा रास्ता नहीं देख सकता हूँ जिससे निवेश योग्य मानदंडों का उल्लंघन किए बिना इसे समझदार कहानियों में तोड़ दिया जा सके।

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

मेरे द्वारा कार्यान्वित किए जा रहे सॉफ़्टवेयर के कुछ हिस्से हैं जो दूसरों की तुलना में कम प्राथमिकता वाले हैं और मैं देख सकता हूं कि हम उस वृद्धिशीलता को वितरित कर सकते हैं। हालाँकि, एक महत्वपूर्ण कोर है जो अवश्य है

मैं स्क्रम का अनुसरण करने की कोशिश कर रहा हूं, लेकिन क्या मैं सिर्फ गतियों से गुजर रहा हूं?

क्या इस तरह की परियोजना के लिए अनुशंसित अभ्यास हैं?


1
@Sklivvz अपडेट अधिक समझ में आता है?
डेव हिलियर

1
स्क्रैम के विकल्प के रूप में, केबान पर एक नज़र डालें। वे दोनों चुस्त हैं, लेकिन AFAIK kanban आपके द्वारा किए जा रहे काम के प्रकार के लिए बेहतर है, जबकि स्क्रैम काम के लिए बेहतर है जिसे विभिन्न प्राथमिकताओं में विभाजित किया जा सकता है।
इज़काता

@ इज़काता कानबन को अभी भी एक प्राथमिकता वाली इनपुट कतार की उम्मीद है, या तो मूल्य या आगमन समय से। किसी भी प्रकार के पुनरावृत्त विकास मॉडल पर विचार करते समय ऑल-एंड-नथिंग वैल्यू प्रस्ताव मौलिक अवरोधक है।
CodeGnome

@CodeGnome Hm .. मैं कबन न करने की बात स्वीकार करता हूं, लेकिन मैंने इस बात का वर्णन करने के लिए बहुत सारी चीजों को करना अच्छा समझा, जैसा कि इस प्रश्न में वर्णित है: यदि आप अपनी स्वयं की शाखा में प्रत्येक कार्ड के लिए काम करते हैं तो ट्रंक में विलीन हो जाते हैं। पूरा, यह एक "पुनरावृत्ति" / रिलीज है। वे सिर्फ एक दूसरे के साथ ओवरलैप कर सकते हैं, स्क्रैम में स्प्रिंट के विपरीत।
इज़्काता

2
आवश्यकताएं नहीं बदलेंगी। तुम बस अब और विश्वास नहीं कर सकते।
जेएफओ

जवाबों:


22

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

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

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


1
आवश्यकताएँ हमेशा शिफ्ट होती हैं और लगता है कि जब तक कोड लिखा और स्वीकृत नहीं किया जाता है (यह मानते हुए कि प्रभारी नियमों का पालन करते हैं) केवल इनकार में है।
जेएफओ

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

1
@ जेफ़ो यदि आप नाइटपिक करना चाहते हैं, तो आवश्यकताएँ हमेशा बदलती नहीं हैं, वे लगभग हमेशा करते हैं। मैं परवाह किए बिना अपना शब्द बदल दूंगा।
vaughandroid

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

10

बेशक स्क्रेम उपयोगी है। यह एक पद्धति है जो आपके लिए दो काम करती है:

  1. यह आपकी परियोजना को बदलने और
  2. यह आपको प्रगति को ट्रैक करने की अनुमति देता है, और यह समाप्त होने पर विचार प्राप्त करेगा

तो, इसका उपयोग करने में कुछ मूल्य है।

मुझे लगता है कि आपके कुछ पूर्व शर्त सही नहीं हैं और यहीं आप खो रहे हैं।

मैं यह नहीं देख सकता कि प्रत्येक कहानी कैसे परक्राम्य हो सकती है - वे सभी एक काम करने वाले कंपाइलर के लिए आवश्यक हैं

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

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

कहानियाँ सभी समान प्राथमिकता की हैं और इससे कोई फर्क नहीं पड़ता कि मैं उन्हें किस क्रम में पहुँचाती हूँ।

यह सही नहीं है, जैसा कि आप नीचे कहते हैं कि कुछ कहानियां "नहीं" होनी चाहिए, इसलिए निश्चित रूप से कुछ कम मूल्यवान हैं। लेकिन यहां तक ​​कि "होना चाहिए" श्रेणी में: कुछ भाषा सुविधाएँ दूसरों की तुलना में बहुत अधिक मौलिक हैं, और औसतन ऐसा है।

इसे मापने का एक तरीका यह है कि "कोड की कितनी अधिक पंक्तियाँ हम किसी मौजूदा कोडबेस पर संकलित कर सकते हैं" या "कितने अधिक परीक्षण पास करते हैं" यदि आपके पास परीक्षणों का पूर्वनिर्धारित सूट है।

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

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

निष्कर्ष में, अपने प्रश्न का अधिक सीधे जवाब देने के लिए: क्या आपकी आवश्यकताओं के अपरिवर्तनीय होने पर आपको चुस्त प्रक्रियाओं की आवश्यकता है? निश्चित रूप से नहीं! क्या वे प्रयोग करने योग्य हैं? शायद हाँ! क्या वे आपके समय के लायक हैं? शायद नहीं - लेकिन क्या आपकी आवश्यकताएं अपरिवर्तनीय हैं? मेरे पिछले अनुभवों में, "अपरिवर्तनीय आवश्यकताओं" => "आलसी उत्पाद के मालिक" - एक नियम नहीं है, लेकिन ध्यान में रखने योग्य है।


3
+1 के लिए " यह सच नहीं है। आप भाषा के सबसेट का समर्थन कर सकते हैं और फिर भी एक संकलक है जो कुछ शर्तों के तहत काम करता है। निश्चित रूप से एक पूर्ण संकलक की तुलना में कम मूल्यवान, लेकिन अभी भी मूल्यवान है। " क्योंकि इससे पहले एक परीक्षण योग्य और प्रयोग करने योग्य इकाई बनाता है विकास का अंत।
रॉस पैटरसन

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

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

@DocBrown आवश्यकताएं निश्चित रूप से क्षैतिज हो सकती हैं, लेकिन कहानियों को ऊर्ध्वाधर होने की आवश्यकता है।
स्किलिविज़

"कंपाइलर के उपयोगकर्ता के रूप में, मैं प्रवेश करना चाहता हूं DavesCompiler -O9 program.c, और आउटपुट को प्रोग्राम-सी का एक अत्यधिक-अनुकूलित संस्करण होना चाहिए (जो कि अत्यधिक-अनुकूलित साधनों का अधिक औपचारिक परिभाषा है)" - मेरे लिए एक उचित उपयोगकर्ता कहानी की तरह लगता है।
डॉक ब्राउन

4

टी एल; डॉ

सभी परियोजना प्रबंधन नियंत्रण ओवरहेड जोड़ते हैं। जरूरत से ज्यादा सिर न जोड़ें।

स्क्रैम यहाँ गलत हैमर (एक कील मत बनो)

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

इसके अलावा, जब आप कहते हैं:

कहानियाँ सभी समान प्राथमिकता की हैं और इससे कोई फर्क नहीं पड़ता कि मैं उन्हें किस क्रम में पहुँचाती हूँ। मुझे ये सब करने की जरूरत है।

आप कुछ चीजों को लागू कर रहे हैं:

  1. जब तक सभी कहानियाँ 100% पूर्ण नहीं होतीं, परियोजना का शून्य मान है।
  2. कहानियाँ एक-दूसरे पर निर्भर नहीं हैं।

यदि ये दोनों कथन सत्य हैं, तो मूल्य या निर्भरता-क्रम द्वारा कार्य को प्राथमिकता देने के लिए डिज़ाइन किए गए ढांचे या अभ्यास का उपयोग करने का वास्तव में कोई मतलब नहीं है।

सुझाए गए विकल्प

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

  1. सुनिश्चित करें कि आपकी सभी कहानियों में "की गई परिभाषा" है जिसमें इकाई- और स्वीकृति-परीक्षण शामिल हैं।
  2. अक्सर एकीकृत और रिफ्लेक्टर; परियोजना के अंत में एक विशाल एकीकरण कार्य के साथ अपने आप को मत छोड़ो।

इसके अलावा, यहां तक ​​कि अगर आपके उत्पाद का वास्तविक मूल्य शून्य है जब तक कि सभी कहानियां पूरी नहीं होती हैं, मैं कुछ समय कहानियों में उन विषयों को समूहीकृत करने में बिताऊंगा जिन्हें आप पूर्ण मील के पत्थर के रूप में मान सकते हैं। "मैंने foo फीचर पूरा कर लिया है" कहने में सक्षम होने के नाते यह कहने की तुलना में अधिक उपयोगी है कि "मुझे 23/117 यादृच्छिक कहानियाँ मिली हैं।" YMMV।


1
मैंने व्यक्तिगत डेवलपर होने का दावा नहीं किया।
डेव हिलियर

@DaveHillier "मेरे पास एक मौजूदा भाषा है ... मैं संभवतः इसके द्वारा प्रयास करूंगा ... मैं स्क्रेमम का अनुसरण करने की कोशिश कर रहा हूं।" कोई भी टीम, अन्य लोगों या औपचारिक परियोजना प्रबंधन की आवश्यकता के बारे में कुछ नहीं कहता है। यहां तक ​​कि अगर आप में से 347 परियोजना पर काम कर रहे हैं, तो जवाब अभी भी मान्य है यदि आपका आधार वैध है। यदि नहीं, तो अपने प्रश्न को अपडेट करें और मैं उत्तर को अद्यतन करने के लिए अपनी पूरी कोशिश करूंगा।
कोडग्निमे

1
किसी और ने ऐसी धारणा नहीं बनाई। आपने जो कुछ लिखा है, मैं उससे सहमत हूँ।
डेव हिलियर

4
@DaveHillier मैंने आपके प्रश्न को CodeGnome की तरह ही पढ़ा, कि आप इस परियोजना पर एक एकल डेवलपर होंगे। के Iबजाय अति प्रयोग Weशायद यही कारण है।
इज़्काता

गलत उपकरण, गलत हथौड़ा नहीं। एक हथौड़ा एक हथौड़ा है, सभी समस्याएं नाखून नहीं हैं :-)
स्किलिविज़

2

मैं आपकी चिंताओं को समझता हूं, लेकिन मेरा मानना ​​है कि स्क्रैम का उपयोग करने में आपके लिए अभी भी मूल्य है।

माना जाता है कि उपभोक्ता कहानियों का सामना उपभोक्ता कहानियों की तुलना में अधिक होता है। ताकि स्क्रैम का पहलू कम मूल्य प्रदान करेगा।

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

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

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

(कृपया ध्यान दें, मैंने कंपाइलर प्रोजेक्ट पर कभी भी स्क्रैम नहीं किया है; नमक के एक दाने के साथ मेरी सलाह लें।)


0

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

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


Scrum is not a set of strict rules to follow- मुझे लगा कि यह दूसरे तरीके से सटीक है। क्या ऐसा नहीं है कि इसमें केवल कुछ नियम हैं, लेकिन आपको उनसे चिपके रहना होगा (जैसे डेली स्टैंडअप, डेफिनिशन ऑफ डन, स्टोरी पॉइंट्स)?
ऊऊओ

क्या आप ScrumBut की वकालत कर रहे हैं ?
डेव हिलियर

@ केवल आपके द्वारा उल्लिखित तीनों में से पहला है स्क्रैम, बाकी सिर्फ अच्छे अभ्यास हैं, लेकिन कड़ाई से मौलिक नहीं हैं।
स्किलिविज़

@Sklivvz यही कारण है कि कई परियोजना प्रबंधक सोचते हैं कि "हम दैनिक स्टैंडअप कर रहे हैं, इसलिए हम घोटाला कर रहे हैं" ? स्क्रम केवल दैनिक स्टैंडअप से अधिक है।
ऊऊओ

1
@Sklivvz ठीक है, अब मुझे लगता है कि आपको इससे क्या मतलब है :-) मुझे लगा कि आपका मतलब केवल स्टैंडअप होना है।
ऊऊओ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.