क्रियाशील लीन एजाइल दृष्टिकोण

छात्र पोर्टल उदाहरण

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

हितधारक बैठक

कार्यसूची

• छात्र पोर्टल के लिए विशेषताएं सुझाएं
• प्रस्तावित विशेषता सूची की लागूता पर चर्चा करें
• विशेषताओं को कोर, अगला बैच, अच्छा होना आदि के रूप में लागू करने के लिए प्राथमिकता दें …

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

फिर हम विभिन्न हितधारकों से उपयोगकर्ता कहानियों की सूची बनाई:

छात्र प्रतिनिधि: कोर्स रजिस्टर करें, शुल्क भुगतान करें, समय समय सूची देखें, समय सूची संपादित करें, रिपोर्ट कार्ड देखें, कोर्स छोड़ें …

शैक्षिक प्रतिनिधि: कोर्स की जानकारी जोड़ें, कोर्स की जानकारी संपादित करें, कोर्स की जानकारी हटाएं …

पोर्टल प्रबंधक: कोर्स की जानकारी का बैकअप लें, छात्र खाता स्थिति संपादित करें

अब, हमारे पास एक बैच कार्ड है जिन्हें पंक्तियों और स्तंभों में व्यवस्थित किया जा सकता है

प्रस्तावित विशेषताओं को प्राथमिकता दें

डेवलपर प्रतिनिधि: हमारे पास आने वाले इटरेशन में लागू किए जाने वाली प्राथमिकता वाली उपयोगकर्ता कहानियों की सूची है। इसके लिए, हमें प्रत्येक उपयोगकर्ता कहानी के लिए गहराई से जानकारी प्राप्त करने के लिए जाना होगा। आइए पहली मुख्य विशेषता “कोर्स रजिस्टर” उपयोगकर्ता कहानी के माध्यम से चलें

हमें बैठक के लिए अंतिम उपयोगकर्ताओं से निम्नलिखित अतिरिक्त जानकारी मिली:

• शैक्षिक: छात्र को पूर्ण समय के रूप में पंजीकृत होना चाहिए
• प्रशासक: छात्र को लॉगिन करने के लिए सही खाता प्रमाण पत्र प्रदान करने चाहिए
• शैक्षिक: कोर्स भरा नहीं है
• शैक्षिक: कोर्स की पूर्व शर्तों को पूरा करना आवश्यक है
• प्रशासक: समय सूची में जोड़े जाने वाले कोर्स का दूसरे कोर्स के समय के समय स्लॉट के साथ टकराव नहीं होना चाहिए
• डेवलपर: आप इस विशेषता के साथ लक्षित प्रणाली में एक सूची के रूप में कौन सी अन्य विशेषताओं को समूहित करना चाहते हैं?
• छात्र: कोर्स छोड़ें, समय सूची देखें, समय सूची संपादित करें।

उपयोगकर्ता कहानी के 3C

अच्छी उपयोगकर्ता कहानियां केवल कथनों से अधिक हैं। एक मानक उपयोगकर्ता कहानी में तीन भाग होते हैं, जिन्हें सामान्य रूप से तीन C के रूप में जाना जाता है। प्रत्येक उपयोगकर्ता कहानी के पहले “C” को [भूमिका] के रूप में, मैं [कुछ करना चाहता हूं], ताकि [लाभ] के मानक ढांचे का पालन करना चाहिए, जो एक उपयोगकर्ता कहानी के कार्ड में डाले जाने वाले न्यूनतम सामग्री है। चर्चा उपयोगकर्ता कहानी के दूसरे “C” की सामग्री है, जो अंतिम उपयोगकर्ता, प्रोजेक्ट मालिक और विकास टीम के बीच की चर्चा का प्रतिनिधित्व करती है। इन चर्चाओं में मौखिक चर्चा या अन्य उपयोगी जानकारी जैसे ईमेल, वायरफ्रेम या प्रोजेक्ट के लिए कोई भी अन्य संबंधित सामग्री को रिकॉर्ड किया जाता है। उपयोगकर्ता कहानी का अंतिम “C” पुष्टि है, जो उपयोगकर्ता कहानी के सही ढंग से विकसित और सफलतापूर्वक डिलीवर किए जाने की पुष्टि करने के लिए उपयोग किए जाने वाले स्वीकृति मानदंड है।

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

• (दिया गया… और) कुछ संदर्भ
• (जब… और) कुछ क्रिया की जाती है
• (तब… और) कुछ क्रियाएँ करें

Cucumber और Jbehave परीक्षण फ्रेमवर्क जैसे उपकरण ऑटोमेटेड परीक्षण के लिए दिया/तब/तब टेम्पलेट के उपयोग को प्रोत्साहित करते हैं, हालांकि इसका उपयोग उपकरण के उपयोग के बिना भी एक तर्कसंगत तरीके के रूप में किया जा सकता है।

आइए “कोर्स रजिस्टर” उपयोगकर्ता कहानी के लिए सभी जानकारी एकत्र करें और इसे 3Cs प्रारूप में रखें:

अब, आइए जानकारी को UeXceler में डालें जिसमें पहले विकसित किए गए रूपांतरण और पुष्टि शामिल है।

एपिक को उपयोगकर्ता कहानियों में विभाजित करना

यदि हम “कोर्स रजिस्टर” उपयोगकर्ता कहानी का विस्तार से अध्ययन करें, तो हमें यह पता चल सकता है कि यह एक स्प्रिंट में रखे जाने के लिए बहुत बड़ी उपयोगकर्ता कहानी है। हम इसे एक एपिक (बड़ी उपयोगकर्ता कहानी) के रूप में ले सकते हैं, जिसे संबंधित छोटी उपयोगकर्ता कहानियों के समूह में विभाजित किया जा सकता है। हम एक एपिक को कार्यों में विभाजित कर सकते हैं, मैं इसे क्षैतिज विभाजन कहूँगा, या वैकल्पिक रूप से हम एपिक को परिदृश्यों में विभाजित कर सकते हैं और इसे ऊर्ध्वाधर विभाजन कह सकते हैं।

क्षैतिज विभाजन

एक बड़ी सुविधा बनाने के पारंपरिक तरीके के रूप में इसे वास्तुकला परतों पर किए जाने वाले कार्यों में विभाजित करना था। उदाहरण के लिए, मॉडल व्यू एंड कंट्रोल (MVC) या क्लाइंट-सर्वर वास्तुकला, ताकि हम तंत्र वास्तुकला के लिए चिंता के विभाजन को सुनिश्चित करें, और बाद में इसे n-परत वास्तुकला में समायोजित करें, जैसे GUI, नियंत्रण तर्क, वस्तु मॉडल, वस्तु संबंधात्मक मैपिंग, डेटाबेस परतें आदि। n-परत वास्तुकला के लिए काफी बहुत है, और मैं यहाँ कुछ उदाहरण दे रहा हूँ:

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

n-परत वास्तुकला पर आधारित काफी सफल वास्तुकला हैं, जैसे रूबी ऑन रेल्स और वेब सेवाओं पर आधारित वास्तुकला।

उपयोगकर्ता कहानियाँ और क्षैतिज विभाजन

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

ऊर्ध्वाधर विभाजन

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

आमतौर पर, क्षैतिज विभाजन फीचर को वास्तुकला घटक स्तर पर उपयोगकर्ता कहानियों या कार्यों में विभाजित करता है। उदाहरण: फ्रंट एंड UI, डेटाबेस या बैकएंड सेवाएँ। दूसरी ओर, ऊर्ध्वाधर काट एक कार्यात्मक, प्रदर्शनीय, सॉफ्टवेयर बनाता है जो व्यावसायिक मूल्य जोड़ता है। इस प्रकार, ऊर्ध्वाधर विभाजन टीम की प्रत्येक स्प्रिंट में संभावित रूप से भेजे जा सकने वाले उत्पाद अनुभाग को डिलीवर करने की क्षमता में सुधार करता है। एक केक को क्रीम, चॉकलेट, फल और केक की परतों के साथ काटने की कल्पना करें। यदि आप केक को क्षैतिज रूप से काटें, तो आपके दोस्त को केवल केक, चॉकलेट, क्रीम या फल का एक टुकड़ा मिलेगा। मैं यकीन करता हूँ कि आपके दोस्तों को वह टुकड़ा पसंद आएगा जिसमें सभी परतों का थोड़ा-थोड़ा हो। केवल एक परत के टुकड़े के साथ आपके दोस्तों को पूरे केक का वास्तविक स्वाद नहीं मिलेगा। आपके दोस्तों के लिए अधिक उपयुक्त तरीका ऊर्ध्वाधर काट बनाना है (आवश्यक मूल्य)।

लक्ष्य के साथ एपिक को क्षैतिज विभाजित करना

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

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

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

1. छात्र को पंजीकृत छात्र होना चाहिए, वरना वह नए छात्रों के लिए नोटिफिकेशन द्वारा दिए गए प्रमाणपत्र के बिना रहेगा। यदि उसे नोटिफिकेशन मिल चुका है लेकिन खाता अभी तक सक्रिय नहीं हुआ है, तो उसे ऑनलाइन नया खाता पंजीकृत करना होगा (लाल वृत्त के चिह्नित 1)
2. यदि हम लॉगिन प्रक्रिया को थोड़ा गहराई से खोदें, तो हमें पता चलता है कि यदि छात्र तीन बार गलत तरीके से प्रमाण पत्र प्रदान करता है, तो उसे “पासवर्ड रीसेट प्रक्रिया” में प्रवेश करना होगा (लाल वृत्त के चिह्नित 2 और 3)

सामान्य उपयोगकर्ता कहानियों का विभाग

आइए इन उपयोगकर्ता कथाओं को UeXceler में बनाएं:

लॉगिन खाता उपयोगकर्ता कथा सामान्य उपयोगकर्ता कथा विभाग के तहत बनाई गई है। लॉगिन उपयोगकर्ता कथाओं के अलावा, सामान्य उपयोगकर्ता कथा विभाग के तहत दो और संबंधित उपयोगकर्ता कथाएं भी बनाई जा रही हैं, जिनमें से एक ‘पासवर्ड रीसेट’ और दूसरी ‘नए छात्र खाते का निर्माण’ है, निम्नलिखित कारणों से:

• यदि छात्र तीन बार गलत रूप से खाता प्रमाण प्रदान करता है, तो ‘पासवर्ड रीसेट’ उपयोगकर्ता कथा को ट्रिगर कर देगा;
• और यदि एक नए छात्र ने अभी तक छात्र खाते के लिए पंजीकरण नहीं कराया है, तो वह लॉगिन स्क्रीन के भीतर ‘नए छात्र खाते का निर्माण’ उपयोगकर्ता कथा को ट्रिगर कर सकता है।

1. एक छात्र के रूप में, मैं छात्र पोर्टल में लॉगिन करना चाहता हूं, ताकि…
2. पोर्टल प्रबंधक के रूप में, मैं यह सत्यापित करना चाहता हूं कि जो व्यक्ति लॉगिन कर रहा है, वह पंजीकृत छात्र है, ताकि…
3. पाठ्यक्रम नेता के रूप में, मैं चयनित पाठ्यक्रम को छात्र के समय सारणी में जोड़ने से पहले उपयुक्तता की जांच करना चाहता हूं, ताकि…

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

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

उपयोग केस विभाग

ऊपर दिए गए चित्र में तीन शेष लाल वृत्ताकार चिह्नित 4, 5 और 6 हैं। ये एपिक ‘पाठ्यक्रम पंजीकरण’ के वैकल्पिक परिदृश्य हैं। इन तीनों में से कोई भी शर्त असत्य हो जाती है, तो उसके लिए एक वैकल्पिक परिदृश्य होगा और इसे विभाजित उपयोगकर्ता कथा के रूप में दर्शाया जा सकता है। शायद, हम इसे क्षैतिज या लंबवत रूप से विभाजित कर सकते हैं, लेकिन क्या लंबवत विभाजन हमेशा अधिक वरीयता दी जाती है? आवश्यक नहीं, यह वास्तविक स्थिति पर निर्भर करता है। दुनिया में एक आकार सभी के लिए फिट नहीं होता है, हमें यह विचार करना होगा कि आपके मामले के लिए कौन सी विधि अधिक उपयुक्त है। मैं इसे थोड़ा अधिक विस्तार से समझाता हूं।

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

एपिक को परिदृश्यों में विभाजित करना

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

1. पाठ्यक्रम नेता के रूप में, मैं चयनित पाठ्यक्रम को छात्र के समय सारणी में जोड़ने से पहले अनिवार्य शर्तों की जांच करना चाहता हूं, ताकि…
2. पाठ्यक्रम नेता के रूप में, मैं पाठ्यक्रम उपलब्धता की जांच करना चाहता हूं जब तक पाठ्यक्रम को छात्र के समय सारणी में जोड़ने की अनुमति नहीं दी जाती है, ताकि…
3. पाठ्यक्रम नेता के रूप में, मैं छात्र के समय स्लॉट की उपलब्धता की जांच करना चाहता हूं जब तक चयनित पाठ्यक्रम को छात्र के समय सारणी में जोड़ने की अनुमति नहीं दी जाती है, ताकि…

एपिक को कार्यों में विभाजित करना

यदि हम एपिक को छोटे कार्यों में विभाजित करना चाहते हैं ताकि एक ही स्प्रिंट में समानांतर विकास किया जा सके, निम्नलिखित तरीके से:

1. पाठ्यक्रम क्वोटा स्थिति की जांच करें
2. पाठ्यक्रम की आवश्यकताओं की जांच करें
3. समय स्लॉट की जांच करें

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