बैकएंड देवों को उपयोगकर्ता कहानियों द्वारा नीचे रखा गया है


10

मैंने बैकएंड विकास में उपयोगकर्ता कहानियों को लंबवत रूप से स्लाइस करने की योजना बनाई। लेकिन हमारी टीम के एक बैकेंड लड़के ने शिकायत करना शुरू कर दिया कि यह उनके काम को अदृश्य बनाता है।

मेरा जवाब था कि

  • स्प्रिंट योजना और समीक्षा बैठकों में हम हितधारकों के सामने बैकेंड कार्यों पर चर्चा करते हैं ताकि यह दिखाई दे, और

  • परियोजना के दौरान उच्च गुणवत्ता बनाए रखने से अन्य टीमों की तुलना में धीमी गति से गति होगी, लेकिन परियोजना के दौरान हमारे पास एक स्थिर वेग होगा। और हितधारकों के लिए वेग अत्यधिक दिखाई देता है।

वह अभी भी इस तरह की कहानियाँ रखने पर जोर देता है: "एक डेवलपर के रूप में मुझे एक डोमेन परत रखने की आवश्यकता है ताकि मैं व्यापार तर्क को समाप्‍त कर सकूं।"

टीम को प्रदूषित करने से पहले मैं इस मुद्दे को कैसे हल कर सकता हूं?

इस मुद्दे की जड़ यह है कि हमारा प्रबंधन व्यवस्थित रूप से बैकेंड के काम को अदृश्य मानता है और समर्थित डीईआर माइनर्स, या अन्य सहायक शर्तें कहता है।


7
मेरे पास बैकएंड की कहानियां नहीं हैं, उनका कोई मतलब नहीं है .. हालांकि, मैं उस तरह के प्रबंधकों को पसंद नहीं करूंगा .. मुझे लगा कि बैकेंड
देव

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

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

1
ऊर्ध्वाधर विषयों को स्लाइस करें, फिर परिणामी कहानियों को क्षैतिज कार्यों में स्लाइस करें।
जुवेंट

जवाबों:


5

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

तथ्य यह है कि टीम पर व्यक्तियों के एक समूह को काम से महिमा प्राप्त करने के लिए कई संभावित समस्याओं के स्मैक के लिए मामूली लगता है।

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

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

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


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

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

@AlanShutko - बिल्कुल। "एक व्यक्ति का फ्रंट एंड, दूसरे व्यक्ति का बैक एंड" सही है? यह एक कारण है कि मैं "बैक एंड" और "फ्रंट एंड" जैसे स्लैंग को नापसंद करता हूं, खासकर जब एक सिस्टम में कई घटकों के बारे में बात कर रहा हो। आपकी बात अत्यंत महत्वपूर्ण है! यहां तक ​​कि "फुल स्टैक" एक सापेक्ष शब्द है जिसका अर्थ सिस्टम के विभिन्न भागों में अलग-अलग चीजें हो सकती हैं!
माइकल

11

यह एक सामाजिक समस्या लगती है, इसलिए इसे सामाजिक समाधान की आवश्यकता होगी।

यदि (जैसा कि मैं आपको समझता हूं) बैकएंड डेवलपर्स अनदेखा और मामूली महसूस करते हैं, और महसूस करते हैं कि उनके काम को पर्याप्त महत्व नहीं दिया गया है, तो ऐसा बहुत कम है कि विकास प्रक्रिया इसे बदलने के लिए कर सकती है।

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

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


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

1
@Szili: क्या बैकेंड का काम इतना बुरा है कि वह किसी भी सम्मान के लायक नहीं है, या क्या वह सिर्फ इतना है कि वह पहचाना नहीं जा रहा है?
ब्लरफुल

उनका बैकएंड काम बेहतरीन है। उचित मान्यता और यहां तक ​​कि प्रबंधन बदमाशी समस्या है।
सिली जूल

4

इस मुद्दे की जड़ यह है कि हमारा प्रबंधन व्यवस्थित रूप से बैकेंड के काम को अदृश्य मानता है और समर्थित डीईआर माइनर्स, या अन्य सहायक शर्तें कहता है।

वास्तव में यही समस्या है। यह स्पष्ट है कि आप इसे कहानियों से हल नहीं करेंगे!

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

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

दूसरे शब्दों में: सभी को अपने अंतिम उपयोगकर्ताओं के लिए मूल्य दें।

(*) नोट: सभी कहानियों में फ्रंट-एंड कंपोनेंट या बैक-एंड कंपोनेंट होने की आवश्यकता नहीं है। यूआई तत्वों को अतिरिक्त बैक-एंड काम के बिना फेरबदल किया जा सकता है, और प्रदर्शन एक विशेषता है


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

1
No @JimmyHoffa मैं बैक-एंड डेवलपमेंट से काफी परिचित हूं। मेरा जवाब बहुत ज्यादा पाठ्यपुस्तक चुस्त है। जैसा कि आप देख सकते हैं, मैं केवल सामने वाले लोगों के होने की वकालत नहीं करता। यदि आप फुर्तीले पसंद नहीं करते हैं, तो इसका उपयोग न करें, लेकिन मैं केवल यह बता रहा हूं कि एक कार्यप्रणाली कैसे काम करती है, इसलिए मेरे बारे में सामान, या जो कुछ भी हो, उसे ग्रहण न करें।
स्किलिव्ज

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

1
@JimmyHoffa लेकिन वे अंतिम उपयोगकर्ता को कोई मूल्य नहीं दे रहे हैं । यदि यह केवल बैक एंड डेवलपर्स की टीम थी तो उपयोगकर्ता फ्रंट एंड डेवलपर्स होंगे। उस स्थिति में आपका तर्क समझ में आता है, लेकिन ऐसा प्रतीत नहीं होता है।
स्कालिवज़

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

1

आपकी समस्याएं हैं:

  • आपके पास अपने व्यवसाय में प्रबंधन की परतें हैं जहां वे बिना किसी उद्देश्य के सेवा करते हैं। स्क्रेम, फुर्तीली, मुझे परवाह नहीं है। प्रबंधन और विकास को उत्पाद प्रबंधक द्वारा नियंत्रित व्यावसायिक चिंताओं से अलग किया जाना चाहिए, जिनके पास प्रौद्योगिकी के बारे में @ $ $ सुराग है। हो सकता है कि इसने स्टीव जॉब्स के लिए काम किया हो, लेकिन मैं कभी भी ऐसी स्थिति में नहीं रहा, जहां गैर-तकनीकी-निपुण प्रबंधक देव के करीब हों, एक स्वस्थ चीज थी या अंततः एक बेहतरीन गुणवत्ता वाला उत्पाद तैयार करने के लिए परोसा जा सकता था जिसे एक टीम बना सकती थी।

  • आपके पास देवता हैं जो दिखावे के बारे में अधिक चिंतित हैं क्योंकि वे समस्याओं को हल कर रहे हैं। यह या तो एक बहुत ही गंभीर संस्कृति समस्या है (लगता है कि यह पूरी तरह से "खनन" घटना दी गई है) और / या आपके पास एक देव गुणवत्ता का मुद्दा है, जो मुझे विश्वास की कमी को देखते हुए झटका नहीं देगा।

उन लोगों को प्राप्त करें जिनकी योजना और स्टैंडअप से बाहर होने की आवश्यकता नहीं है। जिस किसी के पास बैक-एंड के बारे में कोई धारणा नहीं है, वह फ्रंट-एंड से कम महत्वपूर्ण है, कोई ऐसा व्यक्ति है जिसे वहां होने की आवश्यकता नहीं है और वास्तव में वहां होने से प्रक्रिया में बाधा आ रही है।

खाई कहानियाँ। हाँ मैं गंभीर हूँ। यदि वे इस प्रकार के मुद्दों का कारण बन रहे हैं, तो एयरलॉक से बाहर टॉस करें। मेरी वर्तमान नौकरी में हम किसी दिए गए कार्य के लिए "किए गए" मानदंड से चिपके रहते हैं, जो आम तौर पर उस उपयोगकर्ता की तुलना में ऐप पर अधिक केंद्रित रहता है जो उन लोगों को अपमानित कर सकता है जो सोचते हैं कि (जो 20 साल से लगातार बदल रहा है) जीता ' यदि आप पत्र का पालन नहीं करते हैं, तो t काम करें, लेकिन वास्तव में यदि हम अभियोग लगाते हैं, तो हमें किसी ऐसी चीज की आवश्यकता नहीं है, जो हमारे लिए समस्या पैदा कर रही हो। क्रम्पल उन्हें ऊपर उठाएं, उन्हें अपने कंधे पर रखें।

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


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

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

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

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