3 अमीगो - गुणवत्ता उत्पाद बनाने के लिए संचार का एक तरीका

एक स्थिति की कल्पना करें - परीक्षक एक बग ढूंढता है, इसे डेवलपर के साथ चर्चा करना शुरू करता है - और वह जोर देकर कहता है कि यह बग नहीं है, क्योंकि विनिर्देश ने इस कार्यक्षमता के बारे में बात नहीं की थी। क्या वह परिचित है?

या क्योंकि आवश्यकताएं अस्पष्ट थीं, और उसने उन्हें गलत समझा। या शायद इसके विपरीत, उनके पास इतनी जानकारी थी कि फोकस खो गया था और कुछ जानकारी विकास के दौरान खो गई थी।

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

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

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

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

3 अमीगो है ...

3 एमिगो एक ऐसी प्रैक्टिस है जो ग्राहक को वितरित की जाने वाली एक सार्वभौमिक समझ प्रदान करती है। यह टीम की आवाज को व्यक्त करने में मदद करता है, न कि बिखरे हुए विचारों की अंतर्वस्तु।

टीम के भीतर संचार का यह तरीका मदद करता है:

• विकास से पहले उम्मीदों के संबंध में एक सामान्य समझौता करें
• सही तरीके से सही काम करने के तरीके पर एक समझौता करें

यह समझने में भी मदद करता है:

• हम किस समस्या का समाधान करते हैं
• क्या उपाय हैं
• हमें ऐसा करने की आवश्यकता है ताकि कार्य तैयार हो

तीन अमीगो की बैठक एक साथ सोचने का एक तरीका है जो व्यापारिक विशिष्टताओं को समझने की खाई को पाटता है। वह शांत उपयोगकर्ता कहानियों के विकास में मदद करता है।

लक्ष्य समय पर काम करना है, लेकिन एक ही समय में आगे की योजना नहीं है ताकि विवरण अप्रचलित होने का समय हो।

3 क्यों? कौन लगा रहा है आवेदन?

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

व्यापार विश्लेषक या पीओ

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

डेवलपर्स

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

टेस्टर

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

अभ्यास कब लागू किया जाता है?

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

एक गैर-परीक्षण विनिर्देश में अस्पष्ट, विरोधाभासी, अपूर्ण, दोहराव और कभी-कभी पुरानी आवश्यकताएं भी हैं। ऐसा इसलिए है क्योंकि हर कोई समझता है कि उन्होंने अपने तरीके से पढ़ा और सुना है। इसलिए, व्याख्या में मतभेद उत्पन्न होते हैं।

और यदि प्रलेखन बड़ा और विस्तृत है, तो इसे पढ़ना परीक्षण या विकास प्रक्रिया से अधिक समय लग सकता है।

हमारी व्यावसायिक पंक्ति में, हमने इस अभ्यास को लागू करने का निर्णय लिया जब परीक्षण में काम शुरू हो गया। हमने 3 मुख्य समस्याओं की पहचान की:

1. परीक्षण चरण में, आवश्यकताओं के स्पष्टीकरण के कारण कई रिटर्न हुए। ये परीक्षण और विकास में ठोस थे, जब एक व्यापार विश्लेषक ने यह निर्धारित किया कि इसे कैसे काम करना चाहिए।
2. बहुत विस्तृत विवरण के कारण कार्य के परीक्षण में देरी हुई। मामले अक्सर होते थे, जब परीक्षक केवल आवश्यकताओं का अध्ययन करने और परीक्षण मामलों को विकसित करने में 3-6 घंटे खर्च कर सकता था, और परीक्षण लगभग 30 मिनट तक ही होता था। और सबसे अहम् मामला यह था कि जब विनिर्देश का अध्ययन करने के 2 सप्ताह बाद परीक्षण शुरू किया गया था, तो यह बहुत जटिल था। और विस्तृत।
3. खैर, सबसे आम समस्या यह थी कि स्वीकृति परीक्षण के दौरान बहुत सारे कीड़े थे। उन बग्स से बचा जा सकता है जो अगर विकास से पहले उनके बारे में सोचा गया था।

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

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

एसी का अभ्यास करने के लिए चरण

1. हम उपयोगकर्ता कहानी के रूप में आवश्यकताओं को तैयार करते हैं

मैं उपयोगकर्ता कहानियों के आधार पर आवश्यकताओं को विकसित करने के लिए आवेदन करने की सलाह देता हूं। और एक कहानी के आधार पर और केवल अध्ययन करने के लिए 3 अमीगो की बैठक में।

यहां, एक बहुत महत्वपूर्ण बिंदु यह है कि व्यवसाय से आवश्यकता वास्तव में एक उपयोगकर्ता कहानी के रूप में तैयार की जाती है। अर्थात्, यह अपने आप में 3 भागों में निहित है, अर्थात्:

मैं <भूमिका> के रूप में, मैं <कार्रवाई> चाहता हूं, ताकि <प्रेरणा>

यह वास्तव में सबसे लोकप्रिय कस्टम स्टोरीटेलिंग टेम्प्लेट है जिसे कॉननेक्स्ट्रा कहा जाता है। अन्य टेम्पलेट भी हैं, लेकिन मैं इसे एक का उपयोग करने की सलाह देता हूं। और क्यों, अब मैं समझाऊंगा।

परंपरागत रूप से, उपयोगकर्ता की कहानी बनाते समय 2 समस्याएं हैं:

• रिकॉर्डिंग करते समय, या तो कार्रवाई और प्रेरणा को छोड़कर, भूमिका को इंगित नहीं करते हैं
• या वे भूमिका और कार्रवाई का संकेत देते हैं, और वे प्रेरणा को बाहर फेंक देते हैं।

यह वास्तव में समस्याओं का कारण बनता है, और मैं यह समझाने की कोशिश करूंगा कि कौन से उदाहरण सरल उदाहरण हैं।

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

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

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

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

आवश्यकता के बाद टीम (3 amigo) द्वारा उपयोगकर्ता कहानी और सत्यापन में परिवर्तन के चरण को पारित किया गया है, हम स्वीकृति मानदंडों के विस्तार के साथ आगे बढ़ सकते हैं।

2. हम 3 अमीगो की बैठक में उपयोगकर्ता कहानी के लिए स्वीकृति मानदंडों को पूरा करते हैं

पहले आपको यह तय करने की आवश्यकता है कि स्वीकृति मानदंड सभी समान क्या हैं।

तो, ग्राहक से स्वीकृति मानदंड आवश्यकताएं हैं; विनिर्देश जिसके द्वारा / उपयोगकर्ता कहानी प्रणाली की जाँच की जा सकती है।

उनके पास एक वैकल्पिक नाम है, संतुष्टि की शर्तें - उम्मीदों की संतुष्टि के लिए शर्तें (लेखक माइक कोहन)।

3 अमीगो की बैठक में पहले से ही तैयार टीम आती है। उनके पास पहले से ही एक मान्य उपयोगकर्ता कहानी है, जो शायद पहले से ही स्वीकृति मानदंडों का कुछ सेट है जिसे व्यापार प्रतिनिधि ने स्वतंत्र रूप से तैयार किया है।

बैठक के दौरान, प्रतिभागियों के कार्य इसके बाद के कार्यान्वयन के लिए पर्याप्त मानदंड के साथ इतिहास को पूरक / समृद्ध करना है।

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

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

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

उदाहरण के लिए:

*     ,     .*> 

3. हम समय को बनाए रखते हैं

एक अच्छी तरह से विघटित अमेरिका में आमतौर पर 10 से अधिक स्वीकृति मानदंड नहीं होते हैं। यदि चर्चा की प्रक्रिया में बड़ी संख्या में स्वीकृति मानदंड पाए जाते हैं और वे सभी कार्यान्वयन के अधीन हैं, तो इस कहानी को स्वीकृति मानदंडों के एक अलग पूल के साथ कई कहानियों में विघटित होना चाहिए।

यदि ऐसा नहीं किया जाता है, तो 3 अमीगो की बैठक में बहुत देरी होगी।

3 अमीगो की बैठक के लिए इष्टतम समय 30 मिनट से 1 घंटे तक है।

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

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

4. मानदंडों के अध्ययन को पूरा करने के लिए, हम यूएसआर हेयुरिस्टिक का उपयोग करते हैं

जब मैं टीमों को यह अभ्यास सिखाता हूं, तो मैं अनुभव की कमी को दूर करने के लिए उनके मार्ग की शुरुआत में हीरॉस्टिक का उपयोग करने की सलाह देता हूं। अनुभव के साथ, टीम के पास अपने स्वयं के आंकड़े और जाँचकर्ता हैं जो विकासशील मानदंडों के लिए क्या देखना है।

यूएसआर अनुमानी आपको उन सभी स्तरों पर मानदंडों पर विचार करने की अनुमति देता है जो ग्राहक को सबसे अधिक जानकारी प्राप्त करने के लिए आवश्यक हैं।

इस प्रकार,

1. USER - उपयोगकर्ता सिस्टम के साथ क्या करना चाहता है?
2. सिस्टम - सिस्टम को क्या करना चाहिए?
3. RISKS - क्या समस्याएं उत्पन्न हो सकती हैं?

पहले USER समूह के सभी मानदंडों को पूरा करना महत्वपूर्ण है, और उसके बाद ही सिस्टम स्तर पर आगे बढ़ें। यहां, फ्रंट और बैकएंड डेवलपर्स शामिल हैं, और अपने सिस्टम के स्तर पर वे यूएसईआर समूह से मानदंडों को लागू करने के लिए क्या होना चाहिए, इसके लिए स्वीकृति मानदंड तैयार कर सकते हैं।

और अंत में, जोखिम बैंड। सबसे अधिक बार, यह आवश्यकताओं के विस्तार के बारे में भूल जाता है, हालांकि यह कोई कम महत्वपूर्ण नहीं है। यह विभिन्न जटिल मामलों को कवर करता है जिन्हें आप लागू नहीं कर सकते हैं। लेकिन एक टीम के रूप में जोखिमों को स्वीकार करने और स्वीकार करने की आवश्यकता होती है।

विकास से पहले परीक्षण मामलों को विकसित करने के लिए अभ्यास को लागू करने के तरीके

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

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

यह सामान्य प्रक्रिया में कैसे दिख सकता है (जब आपको यह बैठक आयोजित करने की आवश्यकता हो)

यह अनुशंसा की जाती है कि आप एक ही बैठक में केवल एक उपयोगकर्ता कहानी के लिए आवश्यकताओं को पूरा करें। अधिक की अनुमति है, बशर्ते ये बहुत छोटी कहानियां हैं या वे अर्थ में परस्पर जुड़े हुए हैं।

चूंकि स्प्रिंट में आप तैयार-टू-वर्क कहानियां लेते हैं, तो योजना बनाने से पहले 3 अमीगो कहानियों की एक बैठक आयोजित की जानी चाहिए। अन्यथा, आप प्रारंभिक अनुमान के साथ एक बड़ी गलती करने का जोखिम चलाते हैं। व्यवहार में, 3 अमीगो की बैठक के बाद कहानी का मूल्यांकन मूल से बहुत अलग है।

इसके अलावा, डीओडी के लिए तत्परता के एक संकेतक के रूप में एक नया आइटम जोड़ना समझ में आता है कि कहानी स्प्रिंट में इस पर काम करने के लिए तैयार है।

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

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

बैठक 3 अमीगो का परिणाम क्या है?

• स्क्रिप्ट / उदाहरण (स्पष्ट उत्तर)
• निर्दिष्ट नियम / स्वीकृति मानदंड
• नई / विघटित कहानियाँ
• समस्या क्षेत्र की आम समझ
• सहानुभूति (सहानुभूति, सहभागिता)

तीन अमीगो का मुख्य परिणाम " दिए गए / कब / तब" प्रारूप में लिखे गए स्वीकृति परीक्षण हैं। वास्तव में, उन्हें लिखना हमें जितना चाहिए, उससे अधिक समय लग सकता है, इसलिए जब सभी लोग एक साथ हों तो सभी आवश्यकताओं को औपचारिक रूप देना औपचारिकता नहीं है। आमतौर पर, एक डेवलपर या परीक्षक इस बॉक्स से बाहर काम करेंगे। और जैसे ही उनके पास सभी मापदंड और परीक्षण मामले दर्ज होते हैं, 3 एमिगोस संक्षेप में देखते हैं कि क्या हुआ यह सुनिश्चित करने के लिए कि हर कोई दर्ज किए गए से सहमत है।

3 अमीगो के अभ्यास का उपयोग करने का लाभ

अमीगोस 3 रणनीति पूरी टीम की प्रभावशीलता पर भारी प्रभाव डाल सकती है, साथ ही आपकी परियोजनाओं की गुणवत्ता और स्थिरता पर, परिवर्तन करने के लिए गतिशीलता और लचीलेपन को बढ़ा सकती है।

यहाँ कुछ और बोनस दिए गए हैं:

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

हमारी टीम, अभ्यास का उपयोग करते हुए, गलत विनिर्देशों के कारण कार्य रिटर्न को कम करने में सक्षम थी। बैकेंड कार्यों को "पहली बार" विकसित करना सीखा। यही है, बग के बिना और तुरंत ठेस पर।

नुकसान

• अपने आप को सिर्फ तीन लोगों तक सीमित न रखें। यदि आपको अधिक आवश्यकता है - कॉल करें।
• पूरी टीम से नहीं मिले। इस बैठक में, इस सुविधा को लागू करने के लिए न्यूनतम संख्या में लोग होने चाहिए।
• इसे एक नियमित बैठक न मानें - एक अनुष्ठान। अन्यथा, टीम की बैठकों की संख्या बढ़ाने से नकारात्मक होगा।

QualityConf सम्मेलन में मास्टर वर्ग

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

दृष्टिकोण इतिहास

दृष्टिकोण के लेखक: जॉर्ज डिनविडी, 2009।

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

https://www.agilealliance.org/glossary/three-amigos/

https://www.infoq.com/interviews/george-dinwiddie-three-amigos

https://www.agileconnection.com/article/three-amigos-strategy-developing-user-stories

https://www.stickyminds.com/better-software-magazine/three-amigos