स्वचालित अफिनिटी तालिका का उपयोग करके उपयोगकर्ता कहानी का अनुमान कैसे लगाएं

कहानी अंक या दिन, या दोनों?

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

कहानी अनुमान के लिए अफिनिटी तालिका

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

अफिनिटी तालिका कैसे गणना करती है?

अफिनिटी तालिका में कहानी अंक और दिनों का स्वचालित रूप से अनुमान कैसे लगाया जाता है, इसे समझने के लिए हमें यह समझना होगा कि क्षैतिज ग्रिड कार्य प्रयास का प्रतिनिधित्व करते हैं, बाएं से दाएं बढ़ते हैं, और कहानी विकास की जटिलता (जैसे नई तकनीक, नया क्षेत्र आदि) ऊपर से नीचे तक बढ़ती है।

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

अनुमान के लिए उपयोगकर्ता कहानियों की अफिनिटी

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

प्रोजेक्ट स्पाइक के साथ जोखिमों को समाप्त करें

एजाइल डिक्शनरी के अनुसार स्पाइक की परिभाषा है:

“एक ऐसा कार्य जिसका उद्देश्य एक प्रश्न का उत्तर देना या जानकारी एकत्र करना है, उत्पादन के लिए भेजने योग्य उत्पाद बनाने के बजाय। कभी-कभी एक उपयोगकर्ता कहानी बनती है जिसका अच्छी तरह से अनुमान लगाना तब तक नहीं हो सकता जब तक विकास टीम किसी तकनीकी प्रश्न या डिजाइन समस्या को हल करने के लिए वास्तविक कार्य नहीं करती है। समाधान एक “स्पाइक” बनाना है, जो कोई कार्य है जिसका उद्देश्य उत्तर या समाधान प्रदान करना है।”

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