स्प्रिंट टास्क बोर्ड क्या है

---

एक स्प्रिंट टास्क बोर्ड क्या है?

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

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

स्प्रिंट अवधि

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

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

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

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

1. सहमत प्रोजेक्ट शेड्यूल
2. ग्राहकों/हितधारकों/उत्पाद अधिकारी की उपलब्धता (जो संभावित शंकाओं को स्पष्ट कर सकते हैं)
3. ग्राहकों की कार्य संस्कृति
4. स्क्रम टीम की क्षमता
5. स्क्रम अनुभव

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

स्प्रिंट में कार्यों (उपयोगकर्ता कथाओं) की पुष्टि

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

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

कब पुष्टि करें?

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

पुष्टि टेस्टिंग के बराबर नहीं है

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

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

कोई भी दृष्टिकोण चुनें, ध्यान रखें कि चयन किसी एक व्यक्ति का नहीं है, बल्कि सभी का है।

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