ऊर्ध्वाधर उपयोगकर्ता कहानियों का नुकसान


9

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

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

  • एक डेवलपर शुरू में एक सुविधा को लागू करने में धीमा हो सकता है क्योंकि उसे कहानी विकसित करने के लिए आवश्यक सभी तकनीकों (यूआई + सेवा परत + डेटा एक्सेस + नेटवर्किंग, आदि ...) को समझना चाहिए
  • कुल मिलाकर वास्तुकला डिजाइन (अनुप्रयोग की रीढ़ की हड्डी का आकार) वास्तव में इस मंत्र को फिट नहीं करता है (हालांकि कुछ लोग तर्क दे सकते हैं कि यह समग्र वास्तुकला को विकसित करने / बदलने के लिए एक उपयोगकर्ता कहानी का हिस्सा है)

वर्टिकल स्लाइसिंग यूजर स्टोरीज की कुछ और कमियां क्या हैं?

नोट: मैं अब यह सवाल इसलिए पूछ रहा हूं क्योंकि मैं एक टीम को समझाने की कोशिश करने जा रहा हूं ताकि कहानी को 'वर्टिकल तरीके' से लिखना शुरू कर सकूं और मैं समय से पहले संभावित ट्रेड-ऑफ लाने में सक्षम होना चाहता हूं ताकि वे जीते जब वे कमियों का सामना करते हैं, तो वे दृष्टिकोण को असफल मानते हैं।


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

@DaveHillier: यह इस तरह से बनाया गया है जहाँ यह एक नुकसान है। उदाहरण के लिए, व्यवसाय सोच सकता है कि 'धीमा' कार्यान्वयन समय एक नुकसान है।
c_maker

क्या आप यह कहना चाह रहे हैं कि व्यवसाय इसे धीमा मानता है?
डेव हिलियर

क्या "वर्टिकल स्लाइस" अनिवार्य रूप से "क्रॉस-कटिंग चिंता" के समान है?
रॉबर्ट हार्वे

1
क्षैतिज और लंबवत उपयोगकर्ता कहानियों के बारे में एक बहुत अच्छा लेख है जो प्रत्येक के फायदे और नुकसान के बारे में बहुत विस्तार से बताता है: deltamatrix.com/-
रॉबर्ट हार्वे

जवाबों:


7

मुझे किसी दीर्घकालिक नुकसान का पता नहीं है। अल्पावधि में, और इस तरह के विकास के लिए नई टीम के लिए, मुख्य नुकसान यह है कि इसमें कुछ सीखने की आदत होती है और कुछ सीखने की।

लंबवत रूप से काम करने का सबसे कुशल तरीका पूर्ण-स्टैक डेवलपर्स है: इस तरह से एक कहानी को आम तौर पर एक व्यक्ति द्वारा निष्पादित किया जा सकता है (या एक से अधिक लेकिन पाइपलाइन कार्यों के बिना ) । स्पष्ट रूप से यह आवश्यक है कि डेवलपर्स स्टैक के पार लंबवत काम करें (वेब ​​एप्लिकेशन के मामले में html से डेटाबेस तक)।

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

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

मैं दूसरे जवाब से सहमत नहीं हूं कि यह दृष्टिकोण तकनीकी ऋण लाता है। यह कर सकते हैं, लेकिन किसी भी अन्य दृष्टिकोण कर सकते हैं।


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

7

मैं इस सटीक प्रश्न के बारे में बहुत सोच रहा हूँ।

मुझे लगता है कि व्यक्तिगत जिम्मेदारियों बनाम टीम की जिम्मेदारियों द्वारा टुकड़ा करने की क्रिया के बीच अंतर करना महत्वपूर्ण है। मैं इस उत्तर को मुख्य रूप से स्लाइसिंग टीमों पर केंद्रित करूँगा।

कुछ पृष्ठभूमि के लिए: मैंने पूर्ण-स्टैक डेवलपर्स, एकल-स्तरीय डेवलपर्स, ऊर्ध्वाधर (पूर्ण-स्टैक) टीमों, क्षैतिज (एकल-स्तरीय) टीमों और विकर्ण टीमों के साथ काम किया है। विकर्ण टीम द्वारा मेरा मतलब है कि एक कहानी के लिए आवश्यक सभी स्तरों में शामिल हैं, लेकिन जरूरी नहीं कि सिस्टम के सभी स्तरों में, और संभवतः एक ही स्तरीय (ओं) पर ध्यान केंद्रित करने वाले कई डेवलपर्स भी हों; दूसरे शब्दों में वर्टिकल इन स्पिरिट लेकिन शायद दिखने में कुछ क्षैतिज या कार्यान्वयन विस्तार से।

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

मैं निम्नलिखित सारांश तुलना के साथ अब तक अपनी राय गोल करूँगा:

क्षैतिज टीमें

लाभ:

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

नुकसान:

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

कार्यक्षेत्र / विकर्ण टीमें

लाभ:

  • एक टीम में एक उपयोगकर्ता कहानी के सभी भाग ("वन स्टॉप शॉप")
  • विशेष रूप से एन-टियर कहानियों को एक ही स्प्रिंट में वितरित करने में सहायता करता है (हालांकि क्या आपको वास्तव में इसकी आवश्यकता है?)
  • सामान्य शिक्षक कौशल के अंतर-स्तरीय सहयोग और विकास को बढ़ावा देता है
  • सामान्यवादियों का समर्थन करता है

नुकसान:

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

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

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

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

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


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

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

@Will "बहुत अधिक कठिन कार्यभार वितरण प्रबंधन" किस पर आधारित है? एक व्यक्ति ने एक ही कहानी को खींचा और सभी टुकड़ों को तार-तार करते हुए मुझे वास्तव में सीधा और कुशल लगता है। "चिंताओं और कसकर युग्मित स्तरों के खराब पृथक्करण को सक्षम करता है" कौन कहता है कि यह एक खड़ी टीम बनाम एक हॉज में अधिक होने की संभावना है? यदि आपकी टीम अनुशासित है (जो मैं तर्क देता हूं कि दोनों प्रकार की टीमों की आवश्यकता है) तो यह समस्या नहीं होनी चाहिए।
cottsak

6

मुझे जो बड़ी कमी मिली है, वह यह है कि एक टीम के लिए एक एकीकृत वास्तुशिल्प दृष्टिकोण के बाद एप्लिकेशन का निर्माण करना कठिन हो जाता है।

परियोजना के शुरुआती चरणों में हर कोई अलगाव में अपनी परतें लिखेगा। कहानियां (और परतें शामिल) काम करेंगी, लेकिन स्प्रिंट-एंड पर दिए गए उत्पाद को वापस देखने पर प्रत्येक डेवलपर के वास्तु विचारों के बीच थोड़े अंतर को देखना आसान होगा।

इस तरह की बात अपरिहार्य है, लेकिन अवरोधक नहीं। मैंने इसे दो तरीकों से लड़ने की कोशिश की है:

  1. प्रत्येक कहानी को लागू करने से पहले टीम के साथ लंबी डिजाइन चर्चाएं करें
    • इससे जल्दी थक जाता है। किसी को भी सूचित निर्णय लेने के लिए अक्सर बहुत जल्दी हो जाता है और फिर आप सामान पर बहस करना समाप्त कर देते हैं जिसे निश्चित रूप से वैसे भी बदलना होगा।
  2. आगे बढ़ें और रिश्तेदार अलगाव में विकसित करें, यह ध्यान में रखते हुए कि आप तकनीकी ऋण का निर्माण कर रहे हैं ।
    • यहाँ कुंजी एक मुद्दे के रूप में तकनीकी (वास्तु) ऋण को लॉग इन करना है। यह कुछ ऐसा है जिसे वापस भुगतान करना होगा।
    • कुछ स्प्रिंट के बाद एक सुसंगत और एकीकृत वास्तुकला पर निर्णय लेना आसान होगा। यह तब है जब आपको अपने कुछ तकनीकी ऋण (मौजूदा कोड को वापस लेने) का भुगतान करने के लिए सख्त स्प्रिंट का अनुरोध करना चाहिए। वैकल्पिक रूप से, आप इसे प्रोजेक्ट के अगले पुनरावृत्तियों पर वापस टुकड़े-टुकड़े में भुगतान कर सकते हैं।

केवल दूसरी समस्या जिसके बारे में मैं सोच सकता हूँ, वह यह है कि आमतौर पर किसी प्रोजेक्ट की शुरुआत में बहुत सारे बॉयलरप्लेट कोड को जोड़ना पड़ता है। वर्टिकल स्लाइस स्टोरीज लिखने का मतलब है कि पहले की कुछ कहानियों पर टीम का वेग कृत्रिम रूप से कम होगा क्योंकि ये प्री-बॉइलरप्लेट ... लेकिन जब तक हर कोई जानता है कि इससे केवल पहले दो हिस्सों को प्रभावित किया जाना चाहिए, तब तक सब ठीक है।


2
यह कैसे पालन करता है कि स्वतंत्र रूप से काम करने से आप तकनीकी ऋण का निर्माण करते हैं? जरूरी नहीं कि ऐसा लगता हो
Sklivvz

यह जरूरी नहीं कि मामला हो, लेकिन यह इसकी संभावना को बढ़ाता है। उदाहरण के लिए कोड दोहराव लें। यदि तकनीकी डोमेन की कुछ शर्तें अभी तक जम नहीं रही हैं, तो दो देव एक ही कार्यक्षमता को दो अलग-अलग वर्गों में लिख सकते हैं। अंतर केवल इतना है कि एक देव ने इसे एक कहा WobbleAdapterऔर दूसरे ने अ WibbleConverter
मेटाफ़ाइट

3
आप यह स्पष्ट नहीं करते हैं कि परतों में या लंबवत रूप से कार्य को विभाजित करते समय ये समस्याएं क्यों होती हैं। और आपको पहले पुनरावृत्तियों में बहुत सारे बॉयलरप्लेट क्यों लिखने होंगे? YAGNI
डेव हिलियर

क्षमा करें, मुझे लगता है कि बॉयलरप्लेट गलत शब्द है। मेरा तात्पर्य यह है कि चूंकि परियोजना के बहुत से बुनियादी ढाँचे वर्गों को पहले कुछ क्षेत्रों में बनाने की आवश्यकता होगी, जिसमें एक-एक हेडहेड शामिल है।
18

1
और ऊर्ध्वाधर स्लाइस में काम को विभाजित करने का मतलब है कि प्रत्येक कहानी अधिक से अधिक परतों को छूती है। यह सापेक्ष अलगाव में एक ही परत के दो डेवलपर्स कोडिंग भागों की संभावना को बढ़ाता है। जो बेमेल कार्यान्वयन दृष्टिकोणों को जन्म दे सकता है। ... यह बहुत सार लगता है ... मैं सहमत हूँ कि मैं क्या सुझाव दे रहा हूँ अपेक्षाकृत संभावना नहीं हो सकता है!
19

4

मैं किसी भी नुकसान को नहीं जानता, लेकिन ऊर्ध्वाधर कहानियों को बुरी तरह से लागू किया जा सकता है।

जब मैंने पहली बार अपना करियर शुरू किया, तो मैं एक ऐसी टीम में शामिल हो गया, जो एक्सपी करने की इच्छुक थी, लेकिन उनके पास इसका कोई अनुभव नहीं था। ऊर्ध्वाधर उपयोगकर्ता कहानियों का उपयोग करते समय हमने कई गलतियाँ कीं।

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

वर्टिकल स्टोरीज को करने से इन समस्याओं का समाधान हुआ और एकीकृत होने के लिए फिर से काम करने की बर्बादी कम हुई।

XP के कई अभ्यास हैं जो काम करने के इस तरीके का समर्थन करते हैं। किसी को भी किसी भी क्षेत्र में काम करने में सक्षम होना चाहिए और सभी से अपेक्षा की जाती है कि वे बग को ठीक करें ( सामूहिक कोड स्वामित्व )।

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

परतों के ऊपर मजबूत मालिकों के बिना, हमने पाया कि कुछ दोहराव उभर रहा था। हालाँकि यह कोई बड़ी समस्या नहीं थी, फिर भी हमें यह सुनिश्चित करने की ज़रूरत थी कि हम रिफ्लेक्टर मर्किलेसली (समर्थन के लिए उपयुक्त परीक्षणों के साथ) का अभ्यास करें ।

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

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