स्क्रम के साथ काम करना

प्रयोक्ता कहानी

विकास में सॉफ्टवेयर के लिए आवश्यकताओं को बताने के लिए उपयोगकर्ता कहानियां एक प्रभावी तरीका हैं। ऐसी कहानियों में सॉफ़्टवेयर के उपयोगकर्ता की ओर से संक्षिप्त सलाह होती है।

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

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

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

कहानी की संरचना इस तरह दिखती है: "एक उपयोगकर्ता <उपयोगकर्ता प्रकार> के रूप में, मैं <परिणाम> प्राप्त करने के लिए <कार्रवाई> करना चाहता हूं" (एक उत्पाद स्वामी के रूप में मैं चाहता हूं ...)। ऐसी संरचना न केवल सरल है, बल्कि सभी के लिए समझ में भी आती है।

उपयोगकर्ता कहानियों का उपयोग करने के लाभ:

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

उपयोगकर्ता कहानियों का नुकसान:

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

बकाया

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

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

दो महत्वपूर्ण बैकलॉग स्थितियां

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

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

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

ग्राहक को किन कारकों के आधार पर प्राथमिकता देनी चाहिए?

• उपयोगकर्ताओं के लिए प्रासंगिकता।
• प्रतिक्रिया की उपस्थिति।
• विकास की जटिलता।
• कार्यों के बीच संबंध ("बी" को पूरा करने के लिए, आपको पहले "ए" करने की आवश्यकता है)।

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

बैकलॉग कैसे रखें

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

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

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

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

ऑपरेशन के दौरान सीधे बदलाव करने से बचने की सिफारिश की जाती है। यह वर्कफ़्लो और प्रोग्रामर्स की भावनात्मक स्थिति पर बुरा प्रभाव डालता है।

पूरे वेग से दौड़ना

स्प्रिंट एक छोटी अवधि है जिसके दौरान पहले से सहमत कार्य को पूरा किया जाना चाहिए। स्प्रिंट्स स्क्रम और एजाइल पद्धतियों पर आधारित होते हैं। सही स्प्रिंट चुनने से फुर्तीली टीम को गुणवत्तापूर्ण सॉफ़्टवेयर विकसित करने में मदद मिलती है।

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

स्क्रम कैसे योजना बनाता है और स्प्रिंट को निष्पादित करता है?

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

सॉफ्टवेयर ग्राहक, स्क्रम मास्टर और प्रोग्रामर कार्य कार्यों की सूची निर्धारित करने में शामिल होते हैं। ग्राहक स्प्रिंट के लक्ष्य और बैकलॉग से कार्यों की व्याख्या करता है।

फिर टीम एक योजना विकसित करती है जिसके अनुसार स्प्रिंट में कार्य पूरे किए जाएंगे। यह योजना, चयनित कार्य मदों के साथ, स्प्रिंट बैकलॉग कहलाती है। योजना बैठक के बाद, टीम काम पर लग जाती है। डेवलपर्स बैकलॉग से कार्यों का चयन करते हैं, जैसे ही काम पूरा हो जाता है, प्रत्येक कार्य की स्थिति "प्रगति में" से "पूर्ण" में बदल जाती है।

स्प्रिंट के दौरान, टीम वर्तमान मुद्दों और प्रगति पर चर्चा करने के लिए दैनिक स्क्रम बैठकें (स्टैंड-अप) आयोजित करती है। स्प्रिंट के समापन को प्रभावित करने वाली कठिनाइयों की पहचान करने के लिए ऐसी बैठकों की आवश्यकता होती है।

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

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

क्या ध्यान दें और क्या न करें

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

हमें क्या करना है:

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

क्या बचें:

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

जमघट बोर्ड

स्क्रम बोर्ड एक उपकरण है जो यह दर्शाता है कि स्क्रम टीम का कार्य कैसे किया जाता है। आप ऐसे बोर्ड पर कागज पर, दीवार पर या इलेक्ट्रॉनिक रूप में जानकारी प्रदर्शित कर सकते हैं (JIRA, Trello)।

एक स्क्रम बोर्ड में कम से कम तीन कॉलम होते हैं: टू डू, इन प्रोग्रेस और डन। यहाँ एक उदाहरण बोर्ड है:

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

काम का एक हिस्सा पूरा होने के बाद, कार्ड को पूरे बोर्ड में अगले कॉलम में ले जाया जाता है। टीम के काम की प्रगति की दृश्यता दिखाने के लिए, बर्नडाउन चार्ट पर "शेष कार्य" दिन के हिसाब से मदद करता है।

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

कार्य समय चार्ट

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

चार्ट दो प्रकार के होते हैं:

• बर्नडाउन चार्ट स्प्रिंट में कार्य की प्रगति दिखा रहा है।
• बर्नडाउन चार्ट उत्पाद के रिलीज़ होने तक कार्य की प्रगति दिखा रहा है (डेटा को कई स्प्रिंट से सारांशित किया गया है)।

चार्ट उदाहरण:

यह उदाहरण मनोविज्ञान का उपयोग करता है: चार्ट पूर्ण किए गए कार्यों की संख्या नहीं दिखाता है, लेकिन शेष (पूर्ण नहीं) की संख्या दिखाता है।

यानी अगर टीम ने 100 में से 90 काम किए हैं, तो यह गलत एहसास हो सकता है कि सब कुछ तैयार है। आखिरकार, 90 से 100 कार्यों की प्रगति वास्तव में कुछ भी नहीं बदलती है।

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