3 amigo principle agile
3 अमीगो सिद्धांत का परिचय:
HTML साक्षात्कार प्रश्न और फ्रेशर्स के उत्तर
इससे पहले स्क्रम सीरीज में, हमने आपको लाने की अवधारणा के साथ पेश किया था स्क्रम टीम के सदस्यों के भीतर आत्मनिर्भरता बाहरी दुनिया से किसी भी मदद की आवश्यकता के बिना व्यापार मूल्य पैदा करने वाली संस्कृति को प्रेरित करने के लिए।
हाल ही में, मुझे एक क्लाइंट प्रोजेक्ट के साथ संरेखित किया गया था जहाँ मैंने एक स्क्रैम मास्टर के रूप में काम किया था। कई स्क्रम आधारित परियोजनाओं में काम करने के बाद, मैं सफलतापूर्वक क्लाइंट के काम करने के तरीकों के भीतर कार्यप्रणाली को मिश्रित करने में सक्षम था।
हालांकि, समय की एक विशेष अवधि के बाद, समझ की आवश्यकता के आसपास बहुत सारी अस्पष्टता पाई गई थी।
हर स्क्रेम टीम के सदस्य के पास आवश्यकता समझ का अपना संस्करण है!
आप क्या सीखेंगे:
अवलोकन
यदि डेवलपर्स और QA की एक ही आवश्यकता के दो अलग-अलग दृष्टिकोण हैं, तो क्या होगा?
इस मामले में कार्रवाई का स्पष्ट पाठ्यक्रम यह होगा कि डेवलपर्स अपने दृष्टिकोण को ध्यान में रखते हुए वेतन वृद्धि का विकास करेंगे, जबकि परीक्षक अपने स्वयं के दृष्टिकोण को ध्यान में रखते हुए इसका परीक्षण करेंगे।
दो दृष्टिकोण एक अंतर पैदा करते हैं और मुद्दों को केवल स्प्रिंट के अंत की ओर संबोधित किया जाता है। इससे भी बुरा मामला यह होगा कि यदि स्प्रिंट के भीतर इन मुद्दों को संबोधित करने के लिए कोई समय नहीं बचा है, तो हमें किसी उत्पाद के फ़ालॉग में अतिरिक्त आइटम जोड़ने की स्थिति में।
उपर्युक्त समस्या कथन को हल करने के लिए, हम समग्र रूप से आवश्यकताओं पर विश्लेषण करने और मंथन करने के लिए टीम के सदस्यों के बीच अधिक आवश्यकता पर चर्चा सत्रों के समाधान के साथ आए। और इसलिए थ्री एमिगो सिद्धांत का विचार प्रकाश में आया।
थ्री एमिगो सिद्धांत पर कूदने से पहले, आइए हम पहले एजाइल टेस्टिंग प्रैक्टिस, टेस्ट फर्स्ट डेवलपमेंट (टीएफडी) में से एक पर चर्चा करें और यह द थ्री एमिगोस के साथ कैसे जुड़ा है।
टेस्ट फर्स्ट डेवलपमेंट (TFD)
जैसा कि नाम से ही पता चलता है, टेस्ट फर्स्ट डेवलपमेंट एक अभ्यास है जहाँ टेस्ट केस किसी भी विकास गतिविधि से पहले टेस्ट इंजीनियर्स द्वारा लिखे जाते हैं।
इन परीक्षण मामलों को तब पूरी टीम में चर्चा और साझा किया जाता है। टीम के सदस्यों को अब परीक्षण मामलों पर चर्चा करने, बढ़ाने और उनकी समीक्षा करने के लिए एक बैठक में जाना जाता है (जिसे Am द थ्री एमिगोस ’भी कहा जाता है)। इस बैठक के दौरान किनारे के मामलों को भी टेस्ट मामलों की सूची में जोड़ा गया है।
हम परीक्षण के मामलों को जोड़ने और समीक्षा करने के लिए उत्पाद स्वामी को भी शामिल कर सकते हैं जो एक विश्वास का निर्माण करेगा कि परीक्षण के मामले स्वीकृति मानदंड को पूरा करते हैं।
अब जब परीक्षण के मामले विकसित हो गए हैं, तो पूरा विकास इन परीक्षण मामलों पर आधारित होगा। इस घटना को परीक्षण-निर्माण चक्र के रूप में भी जाना जाता है। एक परीक्षण बिल्ड चक्र के भीतर, तब तक निर्माण करें जब तक कि सभी परीक्षण मामलों को पारित नहीं किया जाता है ताकि सिस्टम में बग के लिए कोई स्थान न रह जाए।
टेस्ट-फर्स्ट डेवलपमेंट डेवलपर्स को एक वृद्धि का निर्माण करने की अनुमति देता है जो स्वीकृति मानदंड को पूरा करता है और उत्पाद स्वामी (ग्राहक की आवाज) से खरीदारी करता है।
आजकल, टीमों ने टेस्ट ड्रिवेन डेवलपमेंट (टीडीडी) दृष्टिकोण और रूपरेखा को अपनाना शुरू कर दिया है जो टेस्ट फर्स्ट डेवलपमेंट का अगला चरण है। ककड़ी, गेज, स्पेकफ्लो आदि जैसे उपकरण सबसे लोकप्रिय हैं।
तीन अमीगो सिद्धांत
तीन अमीगोस कौन हैं?
तीन Amigo सिद्धांत कहते हैं कि तीन Amigos; व्यापार विश्लेषक, डेवलपर्स और गुणवत्ता विश्लेषकों को एक बैठक में एक साथ मिलना चाहिए जहां:
- बिजनेस एनालिस्ट टीम के साथ बिजनेस की प्रत्येक आवश्यकता का विवरण देता है।
- क्वालिटी एश्योरेंस टीम के सदस्य इन व्यावसायिक आवश्यकताओं के लिए पहले से बनाए गए टेस्ट मामलों पर चर्चा करते हैं।
- विकास टीम के सदस्य टीम के साथ वास्तुकला और निम्न-स्तरीय डिज़ाइन पर चर्चा करते हैं।
तीन अमीगो बैठक का उद्देश्य तीन अमीगो द्वारा बिजनेस स्पेसिफिकेशन्स की समझ में अंतराल को कम करना है।
बिजनेस एनालिस्ट यह सुनिश्चित करता है कि टीम में सभी को बिजनेस यूजर स्टोरी / रिक्वायरमेंट से समान समझ और अपेक्षा हो। बिजनेस एनालिस्ट प्रतिक्रिया एकत्र करता है और टीम के सदस्यों की टिप्पणियों की समीक्षा करता है। वह / वह भी लापता जानकारी जोड़ता है और यदि कोई है तो उपयोगकर्ता स्टोरी से अस्पष्ट जानकारी को हटा देता है।
चूंकि सॉफ़्टवेयर का स्वास्थ्य हमेशा अपने उच्च-गुणवत्ता मानकों द्वारा मापा जाता है, गुणवत्ता आश्वासन टीम सॉफ्टवेयर वेतन वृद्धि के कार्यात्मक और गैर-कार्यात्मक पहलुओं पर विस्तृत होती है और वृद्धि परीक्षण करने के लिए पहचाने गए परीक्षण मामलों का विवरण देती है। वे यह भी सुनिश्चित करते हैं कि सभी स्वीकार्यता मानदंड परीक्षण मामलों से मिले हैं।
टीम के अन्य सदस्य किनारे के मामलों और लापता परिदृश्यों को खोजकर परीक्षण मामलों को समृद्ध करने में मदद करते हैं। डेवलपमेंट टीम के सदस्य अपने ज्ञान तकनीकी प्रतिबंधों को साझा करेंगे जिससे परीक्षण की कमी हो सकती है।
Xbox के लिए सबसे अच्छा वीआर हेडसेट
डेवलपर्स आवश्यकताओं की उनकी समझ पर चर्चा करते हैं और वेतन वृद्धि का निर्माण करने के लिए क्या करते हैं। वे टीम के साथ आर्किटेक्चर लेआउट और लो-लेवल डिज़ाइन पर भी चर्चा करेंगे, ताकि जो निर्माण होने जा रहा है उसकी एक सामान्य समझ हो सके।
थ्री एमिगो सत्र का समग्र परिणाम यह है कि पूरी टीम को इस बात की आम समझ है कि वे अगले स्प्रिंट के हिस्से के रूप में क्या बनाने जा रहे हैं।
तीन अमीगो प्रक्रिया
तीन अमीगो प्रक्रिया निम्नलिखित हैं:
(1) प्रतिभागियों
डेवलपमेंट टीम और क्वालिटी एश्योरेंस टीम के एक-एक प्रतिनिधि और बिजनेस एनालिस्ट। इन प्रतिनिधियों को सुझाव दिया जाता है कि वे लोग जो वास्तव में अवधारणा के अधिकतम लाभ का लाभ उठाने के लिए उस आवश्यकता पर काम करने जा रहे हैं। दूसरों जैसे आर्किटेक्ट्स आदि का हमेशा बैठक में शामिल होने और उनका मार्गदर्शन प्रदान करने के लिए स्वागत है।
# 2) समय
तीन अमीगो सत्र आमतौर पर एन -1 स्प्रिंट में आयोजित किए जाते हैं। यह एक समयबद्ध बॉक्सिंग ईवेंट भी है यानी इन्हें बढ़ाया नहीं जा सकता। सत्र के लिए अनुशंसित समय बॉक्स 1 घंटे है जो इसकी अधिकतम अवधि भी है।
यदि सुविधा स्प्रिंट एन में विकसित की जानी है, तो एन -1 या एन -2 स्प्रिंट में तीन अमीगो सत्र आयोजित करने की अत्यधिक अनुशंसा की जाती है।
# 3) प्रारूप
# 1) बैठक व्यापार विश्लेषक के लिए डिजाइन दस्तावेजों या वायरफ्रेम के साथ उपस्थित लोगों के लिए आवश्यकता को प्रस्तुत करने के साथ शुरू होती है। व्यवसाय की आवश्यकता अच्छी तरह से तैयार और प्रलेखित होने की उम्मीद है। टीम से यह अपेक्षा की जाती है कि वह बैठक से पहले ही आवश्यकता से गुजर चुकी होगी।
# 2) अगले चरण के रूप में, उपस्थित लोग आवश्यकता की समीक्षा करेंगे और प्रतिक्रिया प्रदान करेंगे जो बाद में व्यापार विश्लेषक द्वारा शामिल किया जाएगा। उपस्थित लोग अस्पष्टता और अंतराल को इंगित करेंगे यदि कोई हो। बिजनेस एनालिस्ट से यह भी अपेक्षा की जाती है कि वे अस्पष्टताओं को दूर करें और आवश्यकता में अंतराल भरें।
कई बार ऐसी स्थितियाँ भी हो सकती हैं, जहाँ व्यापार विश्लेषक को अन्य उपस्थित लोगों द्वारा पोस्ट किए गए प्रश्नों की पुष्टि करने की आवश्यकता हो सकती है और उस समीक्षा को सीधे वहाँ शामिल नहीं कर सकते हैं।
# 3) एक बार जब आवश्यकता पर्याप्त रूप से तैयार हो जाती है और उपस्थित लोगों के पास अधिक प्रतिक्रिया या खुले प्रश्न नहीं होते हैं, तो आवश्यकता को 'तैयार' के रूप में चिह्नित किया जाता है।
# 4) अगला, परीक्षण मामलों को आवश्यकताओं की तरह ही उपस्थित लोगों को प्रस्तुत किया जाता है। परीक्षण मामलों के अच्छी तरह से तैयार होने और पहले से तैयार होने की उम्मीद है।
# 5) उपस्थित लोग अब परीक्षण मामलों की समीक्षा करेंगे और प्रतिक्रिया प्रदान करेंगे। क्यूए सदस्य प्रदान किए गए सभी सुझावों को शामिल करेगा। उपस्थित लोग मिस्ड टेस्ट मामलों और एज केस परिदृश्यों को भी इंगित करेंगे। यहां मुख्य उद्देश्य यह है कि परीक्षण मामलों को सभी स्वीकृति मानदंड को पूरा करना चाहिए और एक अच्छा परीक्षण कवरेज होना चाहिए।
# 6) अगला कदम उन निर्भरताओं और पूर्व-आवश्यकताओं को देखना है जो सत्र के दौरान सामने आ सकती हैं।
क्रोम के लिए सबसे अच्छा पॉप अप अवरोधक विस्तार
# 7) निर्भरताएं निर्धारित की जाती हैं और कार्रवाई की चीजें बनाई जाती हैं और उन्हें संबंधित टीम के सदस्य को सौंपा जाता है। इसी तरह, पूर्व-अपेक्षित कार्यों को बनाया और सौंपा गया है।
# 8) उपरोक्त सभी कलाकृतियों (आवश्यकता, परीक्षण के मामले, कार्य, निर्भरताएं) को जेआईआरए जैसे परियोजना प्रबंधन उपकरण में रखा जाना चाहिए ताकि हर कोई आसानी से उन तक पहुंच सके।
# 9) यदि बहुत अधिक समीक्षा टिप्पणियां हैं, तो व्यापार विश्लेषक और गुणवत्ता आश्वासन इंजीनियर सत्र के बाद उन्हें शामिल करना चुन सकते हैं।
निष्कर्ष
इस ट्यूटोरियल में, हमने आपको इस अवधारणा से परिचित कराया तीन अमीगो सिद्धांत जो मजबूत प्रतिक्रिया लूप के साथ तेज गति से सही समाधान देने के लिए बहुत फायदेमंद साबित हुआ है।
तीन अमीगो सत्र एक ही आवश्यकता की एक अलग समझ रखने के लिए कोई जगह नहीं छोड़ते हैं। बैठक का उद्देश्य सभी को एक ही पृष्ठ पर लाना है और फिर उन्हें विकास के चरण पर कूदने से पहले आवश्यकता को स्वीकार करना है।
यदि आप पहले से ही एजाइल फ्रेमवर्क में काम कर रहे हैं, तो मैं बहुत कोशिश करूँगा और द थ्री एमिगो सेशन का एक जोड़ा और अपने लिए बदलाव का अवलोकन करूँगा।
हमारा आगामी ट्यूटोरियल स्केल्ड चुस्त ढांचे के बारे में अधिक बताएगा!
PREV ट्यूटोरियल | अगले ट्यूटोरियल
अनुशंसित पाठ
- 4 कदम एजाइल प्रक्रिया के लिए सफल संक्रमण के लिए चुस्त परीक्षण मानसिकता विकसित करना
- JIRA एजाइल ट्यूटोरियल: JIRA का उपयोग कैसे करें फुर्तीली परियोजनाओं के प्रबंधन के लिए
- एजाइल मेनिफेस्टो: अंडरस्टैंडिंग एज़ाइल वैल्यूज़ एंड प्रिंसिपल्स
- एक चुस्त परीक्षक का मानसिकता परिवर्तन: फुर्तीला मैनिफेस्टो के साथ संरेखित करना
- SAFe एजाइल ट्यूटोरियल: स्केल एजाइल फ्रेमवर्क क्या है
- Agile Scrum ऑनलाइन क्विज़: Agile Scrum के अपने ज्ञान का परीक्षण करें
- स्वचालित प्रतिगमन परीक्षण: चुनौतियां, प्रक्रिया और चरण
- उदय पर चुस्त परीक्षण - बून या बैन?