उदाहरण मानचित्रण का परिचय

इससे पहले कि आप एक उपयोगकर्ता कहानी पर काम करना शुरू करें, यह आपके स्वीकृति मानदंडों को निर्धारित करने के लिए बहुत महत्वपूर्ण है। यह तब किया जा सकता है जब आप बैकलॉग का विवरण देते हैं या अगले स्प्रिंट की योजना बनाते हैं। इसके लिए, कुछ टीमों ने 3 अमीगो (पिछले लेख में उनके बारे में अधिक), रैलियों, किक-ऑफ को विनिर्देशों या बैठकों-अध्ययनों के अनुसार विशेष बैठकें आयोजित की हैं।

इसे कॉल न करें, ज्यादातर टीमों के लिए यह मुश्किल है। मुख्य कठिनाई यह है कि ऐसी बैठकें असंरचित हैं, और उनके परिणाम समझ से बाहर हैं। वे समय लेने और बस उबाऊ हैं। नतीजतन, सत्र अनियमित या पूरी तरह से छोड़ दिया जाता है।

लेकिन ऐसी बैठकों को छोटा और बहुत उत्पादक बनाने का एक आसान तरीका है। और इस विधि को उदाहरण मेपिंग या परीक्षण मामलों की मैपिंग कहा जाता है।

यह कैसे काम करता है

विशिष्ट परीक्षण मामले (उदाहरण) एक विषय क्षेत्र का पता लगाने का एक शानदार तरीका है। वे आपकी स्वीकृति परीक्षणों के लिए एक अच्छा आधार हो सकते हैं। जब हम परीक्षण मामलों पर चर्चा करते हैं, तो अन्य पहलू सामने आते हैं जिनके बारे में भी बात करने की जरूरत है।

• नियम जो अलग-अलग मामलों को सारांशित करते हैं या इसके विपरीत परीक्षण के मामले की प्रयोज्यता को सीमित करते हैं।
• परिदृश्यों के बारे में प्रश्न जब कोई नहीं जानता कि वास्तव में क्या सच है। या परिकल्पनाएँ जिन्हें हम किसी भी तरह से आवश्यकताओं के विकास में आगे बढ़ाने के लिए आगे रखते हैं।
• नई उपयोगकर्ता कहानी जो चर्चा के दौरान सामने आई थी।

उदाहरण मैपिंग चार अलग-अलग रंगों में कार्ड का एक सेट का उपयोग करता है और नई जानकारी दर्ज करने के लिए बॉलपॉइंट पेन का उपयोग करता है। बैठक के दौरान, कार्ड पर जानकारी दर्ज की जाती है और बोर्ड पर रखी जाती है, जैसा कि ऊपर की तस्वीर में है।

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

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

जब हम एक नक्शा संकलित कर रहे हैं और मामलों पर चर्चा कर रहे हैं, तो सवाल उठ सकते हैं कि इनमें से कोई भी जवाब नहीं दे सकता है। हम उन्हें लाल स्टिकर पर ठीक करते हैं और चर्चा जारी रखते हैं।

बैठक तब तक जारी रहती है जब तक कि सभी को यह विश्वास नहीं हो जाता है कि कहानी पूरी तरह से समझ में आ गई है, या इसके लिए आवंटित समय समाप्त हो गया है।

त्वरित प्रतिक्रिया

इस तरह की बातचीत की प्रक्रिया में, इतिहास की वर्तमान समझ का एक दृश्य प्रतिनिधित्व आसानी से और जल्दी से बनाया गया है।

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

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

सीमित समय के लिए सोचें

कई अमीगो के एक समूह को लगभग 25 मिनट में एक सभ्य, सभ्य कहानी बनाना चाहिए।

यदि आप आवंटित समय को पूरा करने में असमर्थ हैं, तो कई विकल्प संभव हैं:

• आप अभी भी इस विधि का उपयोग करना सीख रहे हैं (यह सामान्य है);
• आपकी कहानी बहुत बड़ी है (यह निश्चित रूप से अब अच्छा नहीं है);
• आपकी कहानी में बहुत अनिश्चितता है।

क्या किया जा सकता है? या तो कहानी को कई में विभाजित करने की कोशिश करें, या उत्पाद के मालिक को होमवर्क दें, ताकि बाद में आप इस कहानी पर अगले सत्र में एक साथ उदाहरण के लिए मैपिंग करके लौटें, लेकिन जवाब के साथ।

ककड़ी के मैट विने ने बैठक के प्रतिभागियों को 25 मिनट में वोट करने के लिए आमंत्रित किया है कि क्या कहानी विकास के लिए प्रस्तुत करने के लिए तैयार है। यहां तक ​​कि अगर कुछ मुद्दे अनसुलझे हैं, तो टीम यह तय कर सकती है कि बहुत अनिश्चितता नहीं है, और इसे आगे भी विकसित किया जा सकता है।

लाभ

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

ऐसा लगता है कि 3 अमीगो को इस बैठक के दौरान स्वीकृति परीक्षण लिखना चाहिए (उदाहरण के लिए, ककड़ी के लिए स्क्रिप्ट)। सिद्धांत रूप में, कुछ मामलों में यह समझ में आ सकता है, लेकिन अधिक बार यह दृष्टिकोण केवल बातचीत के वास्तविक उद्देश्य से विचलित होगा।

यह स्पष्ट है कि इस तरह की राय कहां से आती है: स्पष्ट लक्ष्य एक उपयोगकर्ता कहानी लेना है, जिसमें पहले से ही कुछ पूर्वनिर्धारित स्वीकृति मानदंड हैं, और परीक्षण मामलों को ढूंढें जिन्हें स्वीकृति परीक्षणों में बदल दिया जा सकता है।

वास्तविक लक्ष्य एक कहानी बनाने के लिए क्या आवश्यक है की एक सामान्य समझ हासिल करना है। आप उच्च प्रौद्योगिकी के बिना जल्दी से इस लक्ष्य की ओर बढ़ सकते हैं।

रिकॉर्डिंग को सरल बनाएं

इसलिए, औपचारिक घेरकिन लिपियों का उपयोग करने के बजाय, बस नामकरण सम्मेलन का उपयोग करके परीक्षण मामलों की एक सूची को जल्दी से संकलित करने का प्रयास करें।
उदाहरण के लिए:

• जहां ग्राहक अपनी रसीद भूल गया हो;
• जहां उत्पाद 15 दिन पहले खरीदा गया था।

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


यदि परिणाम ("तब") अस्पष्ट है, तो उदाहरण काम नहीं करेगा, लेकिन सवाल यह होगा।

ज्ञात अज्ञात

यदि बातचीत शुरू होती है, तो पर्याप्त जानकारी नहीं है। शायद बैठक में सही व्यक्ति नहीं है, या आपको कुछ शोध करने या स्पाइक का उपयोग करने की आवश्यकता है।


प्रत्येक भागीदार की राय सुनने के बजाय, उनके दृष्टिकोण से परिणाम क्या होना चाहिए, बस लाल कार्ड पर प्रश्न लिखें और आगे बढ़ें। तो अज्ञात ज्ञात अज्ञात में बदल जाएगा। यह एक बड़ी प्रगति है।

अनुभव से, यहां तक ​​कि उदाहरण के मानचित्रण का यह पहलू 3 अमीगो बैठकों को उबाऊ से तेज और उत्पादक में बदल सकता है।

किसे भाग लेना चाहिए?

न्यूनतम आपका 3 अमीगो है: डेवलपर, परीक्षक और उत्पाद स्वामी (व्यवसाय विश्लेषक)। यह सिर्फ एक न्यूनतम है। इसके अलावा, आप ऑपरेशन के किसी व्यक्ति, यूएक्स के विशेषज्ञ या किसी और को आमंत्रित कर सकते हैं, जो चर्चा के तहत कहानी से संबंधित है। कोई भी जो नए प्रश्नों को खोजने में मदद कर सकता है या बातचीत के दौरान प्रश्नों को उत्तरों में बदलने में मददगार होगा।

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

तो घेरकिन पर कब लिखना है?

इसे गलत मत समझो, विशेष रूप से परियोजना के शुरुआती दिनों में, जब आप एक आम भाषा विकसित करते हैं, तो घेरकिन का उपयोग करना बहुत महत्वपूर्ण है। यह महत्वपूर्ण है कि परिदृश्य व्यक्त किए जाएं ताकि टीम में हर कोई उन पर विश्वास करे।

लेकिन इस तरह से परीक्षण मामलों का वर्णन करने के लिए एक अलग तरीके की सोच की आवश्यकता होती है। यह न केवल यह तय करना आवश्यक है कि कौन से मामले विचाराधीन क्षेत्र में आते हैं, और उनके लिए सामान्य नियम स्थापित करने के लिए।

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

ऐसा कितनी बार करना है?

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

लेकिन मेरे पास एक वितरित टीम है!

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

कुछ अंतिम सुझाव

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

याद रखें, इस तरह की बैठक का अंतिम लक्ष्य वह है जिसे आप अभी तक नहीं जानते हैं । कोई बेवकूफ सवाल नहीं है, वे सभी वास्तव में समस्या की जांच करने में मदद करते हैं।

इस तकनीक का उपयोग करते हुए, आप पाएंगे कि नियम आपकी कहानी के लिए विकास की प्राकृतिक रेखाएँ बनाते हैं। शांति से प्रश्नों से संबंधित होने की कोशिश करें, उन्हें अलग करें और उन्हें एक तरफ रख दें। फिर आप मुख्य समस्या को हल करने पर ध्यान केंद्रित कर सकते हैं। आप बाद में आदर्श को जटिल कर सकते हैं और ला सकते हैं।

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