एक ही उत्पाद पर कई विकास टीमों के काम करने के मामले में "पूर्ण" की परिभाषा


12

स्क्रैम परीक्षणों में से एक में "डन" का वर्णन करने वाली परिभाषा के बारे में सवाल होता है जब एक ही उत्पाद पर कई विकास दल एक कार्य करते हैं।

एक उचित उत्तर में कहा गया है कि उन विकास टीमों के पास "पूर्ण" की ऐसी परिभाषा होनी चाहिए जो उनके संयुक्त कार्य को संभावित रूप से विश्वसनीय बना सके।

इस प्रश्नोत्तरी के उचित उत्तर से मेरे लिए क्या स्पष्ट नहीं है:

  • क्या टीमों को "किया" की अलग-अलग परिभाषा हो सकती है? किस हद तक?
agile  scrum 

एक ऐसी टीम के बारे में सोचें जो सीधे किसी उत्पाद के साथ-साथ अन्य टीमों द्वारा उपयोग किए जा रहे कार्य को भी जारी करती है।
इयान

या उदाहरण के लिए सॉफ्टवेयर के अंग्रेजी संस्करण फ्रेंच में अनुवादित होने से पहले जहाज कर सकते हैं,।
इयान

इस तरह का भ्रम है कि मैं कभी नहीं कहता कि कुछ भी किया जाए। इसके बजाय मैं हमेशा वही कहता हूं जो हमने किया। अगर कुछ किया जाता है तो निर्णय लेना एक बातचीत है। घोषणा नहीं है। भले ही आप किस परिभाषा का पालन करें।
candied_orange 22

जवाबों:


16

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

यदि प्रत्येक टीम अलग तरीके से "किया गया" परिभाषित करती है और उम्मीद करती है कि अन्य टीम उस परिभाषा के बारे में जान सकें, तो आप कई समस्याओं में भाग लेंगे:

  • जब एक एकीकरण समस्या उत्पन्न होती है, तो कोई भी टीम इसे ठीक करने का प्रभार नहीं लेना चाहेगी। आखिरकार, यह "किया" गया जब उन्होंने चीजों को एकीकृत करना शुरू किया, इसलिए यह दूसरी टीम के काम के साथ कुछ होना चाहिए।

  • जब आपके पास मुट्ठी भर टीमें होती हैं, तो हर किसी की "की गई परिभाषा" को याद रखना मुश्किल हो जाता है - खासकर जब टीमों के बीच मतभेद होते हैं।

  • की गई परिभाषा को यह शामिल करने की गारंटी नहीं है कि एकीकरण कार्य ठीक से काम कर रहा है।

स्वीकार किए गए उत्तर में स्पष्ट रूप से कहा गया है कि चीजें तब तक नहीं की जाती हैं जब तक कि सभी टीमों से काम एकीकृत और ठीक से काम नहीं करता है। यह भरोसेमंद होना चाहिए, और इस प्रकार यह संपूर्ण उपयोगकर्ताओं द्वारा स्वीकार किए जाने में सक्षम है।


टिप्पणियों के जवाब में संपादित करें: इसका मतलब यह नहीं है कि हर टीम की परिभाषा समान है। इसका अर्थ है कि हर टीम की परिभाषा का हिस्सा बड़ा सिस्टम है और अन्य एकीकृत घटक नहीं टूटे हैं।


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

2
@Andremoniy, सही उत्तर वास्तव में एक एकल DoD के बारे में कुछ नहीं कहता है , लेकिन इसका मतलब यह है कि सभी टीमों के DoD का एक सामान्य तत्व होना चाहिए कि समग्र उत्पाद कार्यशील रहे। एक एपीआई के अलग-अलग कार्यान्वयन पर काम करने वाली विभिन्न टीमों का आपका उदाहरण मुझे इस बात से सहमत नहीं करता है कि इसे एकल उत्पाद कहा जा सकता है।
बार्ट वैन इनगेन शेनॉउ

2
@Andremoniy, जैसे ही एक टीम किसी अन्य टीम के काम पर निर्भर करती है, एकीकरण के मुद्दे (विल) हो सकते हैं, भले ही भागों को विभिन्न स्थानों पर तैनात किया गया हो। यह एक एकीकरण मुद्दा भी है, उदाहरण के लिए, जब एक माइक्रो-सर्विस अप्रत्याशित, संभवतः गलत तरीके से किसी अन्य माइक्रो-सर्विस का उपयोग करती है।
बार्ट वैन इनगेन शेनॉ

2
@Andremoniy: आप सही कह रहे हैं कि उन दो टीमों को एक ही DoD का उपयोग नहीं करना चाहिए, लेकिन वे इस नियम को साझा कर सकते हैं कि किसी भी परिवर्तन को दूसरी टीम को नकारात्मक रूप से प्रभावित नहीं करना चाहिए (जो कि ज्यादातर काम को ट्रिगर करने के लिए होगा यदि पीछे के इंटरफेस में बदलाव शामिल हो -एंड सर्वर)।
बार्ट वैन इनगेन शेनॉउ

1
@Andremoniy: आपकी टिप्पणियों के लिए धन्यवाद। आपके द्वारा लाए गए कुछ मुद्दों के समाधान के लिए मैंने अपना उत्तर अपडेट कर दिया है।
ग्रेग बरगार्ड

6

मैं एक स्थिति की कल्पना कर सकता हूं, जहां एक टीम "डोन" को "डेवलपमेंट डोन" (यानी कोड को रेपो में मिला देती है) के रूप में परिभाषित करती है, जबकि अन्य इसे "टेस्टिंग डोन" (यानी क्यू / ए और जारी किए गए कोड) के रूप में परिभाषित करते हैं।

यह स्वाभाविक रूप से गंभीर समस्याएं पैदा करेगा क्योंकि समग्र उत्पाद राज्य काफी हद तक अपरिभाषित होगा और इसलिए यह बताना कठिन होगा कि क्या हम वास्तव में इसे जारी कर सकते हैं या नहीं।


क्या आप उचित उत्तर को एक ऐसा बताते हैं कि सभी टीमों को समान परिभाषा साझा करनी चाहिए?

हाँ, मैं सहमत हूँ कि एक साधारण कारण के लिए एक सामान्य परिभाषा होनी चाहिए - एक जटिल परियोजना को एक पेड़ संरचना माना जा सकता है जहां उपप्रोजेक्ट (जैसे माइक्रोसर्विस) समग्र उत्पाद (जैसे MyCool ERP) का निर्माण करते हैं। तो एक निश्चित समय में, आप जानना चाहते हैं कि क्या उत्पाद का एक नया संस्करण जारी किया जा सकता है। लेकिन अगर आपके पास विशेष उप-भागीदारों के लिए अलग-अलग DoD है, तो यह जानकारी कटौती करने के लिए बेहद कठिन हो जाती है।
Pawel Gorczynski
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.