वर्तमान में जिस कंपनी में मैं काम करता हूं, हमने देखा है कि कभी-कभी, कुछ कहानियाँ एक-दूसरे से जुड़ी होती हैं (जैसे कि बहुत युग्मित)। यह हो सकता है कि वे एक ही समग्र विशेषता से संबंधित हों, या कि वे अलग-अलग विशेषताएं हों, लेकिन उनमें से कुछ ऐसे हैं जिन्हें अगले लोगों के साथ जारी रखने के लिए पहले समाप्त करने की आवश्यकता है, आदि।
पुनरावृति के वर्कफ़्लो को रोकने के बिना, आप इस मामले को कैसे संभालेंगे? क्या हम कुछ गलत कर रहे हैं?
जवाबों:
यह एक बड़ा सवाल है। थ्योरी कहती है कि उपयोगकर्ता की कहानियों को स्वतंत्र होना चाहिए लेकिन मैं कभी भी इसे पूरी तरह से हासिल नहीं कर पाया।
मेरी राय में सबसे महत्वपूर्ण निर्भरता का संचार करना है ताकि टीम और उत्पाद के मालिक दोनों इसके बारे में जानते हों। यह उत्पाद के मालिक को या तो उपयोगकर्ता कहानियों को फिर से परिभाषित करने के लिए मजबूर करेगा ताकि निर्भरता को हटा दिया जाए (उदाहरण के लिए उपयोगकर्ता कहानियों को विलय करके) या तदनुसार व्यावसायिक प्राथमिकता को परिभाषित करना ताकि प्रमुख उपयोगकर्ता कहानी को पहले लागू किया जाए।
प्राथमिकता और पीओ के निर्णय के आधार पर आप या तो दोनों को एक ही स्प्रिंट में लागू करेंगे या आश्रित को बाद में बिना किसी समस्या के लागू किया जाएगा क्योंकि मूलधन पहले ही हो जाएगा।
सबसे खराब स्थिति यह है कि A, B पर निर्भर है और B, A पर निर्भर है। ऐसे मामले में उपयोगकर्ता की कहानियों को शायद सबसे अधिक गलत तरीके से परिभाषित किया गया है और शायद A और B को लिखा जाना चाहिए (ज्यादातर स्वतंत्र या केवल एक ही तरह से निर्भरता के साथ) और C पर निर्भर ए और बी।
उसी के अनुसार योजना बनाएं।
उन्हें एक ही स्प्रिंट में रखो, और चूंकि उपयोगकर्ता कहानियां भी स्प्रिंट बैकलॉग में प्राथमिकता दी जाती हैं, इसलिए आपको कोई समस्या नहीं होगी।
चूंकि आपकी टीम इसमें भाग लेती है, वे निर्भरता के बारे में जानते हैं, इसलिए ऐसा कुछ नहीं है जिससे आपको डरना चाहिए। वे वयस्क हैं और यदि आप उन्हें निर्भरता के बारे में समझाते हैं (आमतौर पर वे आपको यह समझाएंगे), तो चीजें आसानी से चलेंगी।
एजाइल में, झरने की तरह, आप एक समय में केवल एक ही काम कर सकते हैं। और आप आमतौर पर ए से पहले बी करते हैं अगर बी को ए की जरूरत है। यह सामान्य ज्ञान है।
निर्भरता एक गंध हो सकती है जो आप अपनी कहानियों को सिस्टम के माध्यम से लंबवत के बजाय क्षैतिज रूप से काट रहे हैं। किसी विशेष सुविधा के लिए विकास में यूजर इंटरफेस के माध्यम से डेटाबेस डिजाइन को संशोधित करने से सब कुछ शामिल होना चाहिए। यदि आप पाते हैं कि आप अपना सारा प्रयास किसी उपयोगकर्ता कहानी पर सिस्टम संरचना के कुछ निचले स्तर पर खर्च कर रहे हैं, जैसे, डेटाबेस लुकअप के लिए हैंडलर रूट लिखना, तो आप कहानियों के बीच निर्भरता पैदा कर सकते हैं। और, आप शायद अपनी उपयोगकर्ता कहानियों को गलत लिख रहे हैं।
आपकी सबसे अच्छी शर्त यह है कि अपनी भरोसेमंद उपयोगकर्ता कहानियों को छोटे-छोटे टुकड़ों में तोड़ दिया जाए, जो यथासंभव स्वतंत्र हो सकते हैं। उन्हें आपको उन कहानियों से निपटना चाहिए जो पहले पर निर्भर हैं (जैसे आपने कहा: दूसरों को जारी रखने के लिए जिन्हें पहले समाप्त करने की आवश्यकता है)। एक भरोसेमंद सूचकांक की तरह कुछ बनाएँ: अगर कहानी 3 में कहानी 1 की तुलना में अधिक प्रतिपादक हैं, तो आप कहानी 3 से पहले ही निपट लेंगे।
यदि आपकी निर्भरता बहुत अधिक रोक रही है, तो यह पूरी तरह से काम को रोकने के लिए एक अच्छा विचार हो सकता है (हाँ, अपने वर्तमान स्प्रिंट के बीच में हाँ) और अपनी प्राथमिकता उपयोगकर्ता कहानियों को फिर से आश्वस्त करें और उन्हें पहले से निपटाएं