कंप्यूटर उद्योग अस्पष्ट भाषा, कठोर शब्दजाल और जटिल विचारों से भरा हुआ है जिन्हें समझना मुश्किल है और आपके दिमाग को कम्प्यूटेशनल बफरिंग के उन्माद में भेज सकता है।
झरना? स्क्रम? फुर्तीला?
अगर ये वाक्यांश आपके लिए पूरी तरह से विदेशी हैं, तो चिंता न करें; हैशडॉर्क टेक गीक्स की आपकी सहायक टीम विकास प्रक्रिया के इन महत्वपूर्ण चरणों के बीच के अंतर को समझने में आपकी सहायता करने के लिए यहां है ताकि आप जानकार बन सकें।
इस ब्लॉग पोस्ट में चुस्त, स्क्रम और वाटरफॉल तकनीकों को शामिल किया जाएगा, साथ ही साथ प्रत्येक आपकी टीम को समग्र रूप से कैसे मदद कर सकता है।
चलो फुर्ती से शुरू करते हैं, और हम बाकी को साथ लेकर चलेंगे।
चंचल क्या है?
फुर्तीली सॉफ्टवेयर विकास एक पुनरावृत्त, वृद्धिशील दृष्टिकोण का अनुसरण करता है। एक परियोजना की शुरुआत में व्यापक तैयारी के बजाय, एजाइल तकनीक समय के साथ बदलती जरूरतों के लिए लचीली होती है और अंतिम उपयोगकर्ताओं से निरंतर प्रतिक्रिया को बढ़ावा देती है।
क्रॉस-फ़ंक्शनल टीमें समय के साथ उत्पाद पुनरावृत्तियों पर काम करती हैं, और इस काम को बैकलॉग में वर्गीकृत किया जाता है और व्यवसाय या ग्राहक मूल्य के आधार पर प्राथमिकता दी जाती है। प्रत्येक पुनरावृत्ति का उद्देश्य एक उपयोगी उत्पाद बनाना है।
नेतृत्व चुस्त कार्यप्रणाली में सहयोग, जिम्मेदारी और आमने-सामने संचार को बढ़ावा देता है।
व्यावसायिक हितधारकों और डेवलपर्स को यह सुनिश्चित करने के लिए सहयोग करना चाहिए कि उत्पाद उपभोक्ता की मांगों और कंपनी के लक्ष्यों को पूरा करता है।
वाक्यांश "फुर्तीली विकास" विभिन्न तरीकों और रूपरेखाओं को संदर्भित करता है जो आदर्शों और सिद्धांतों पर आधारित हैं चंचल मेनिफेस्टो.
विशेषज्ञ चुस्त सिद्धांतों और मूल्यों का पालन करने की सलाह देते हैं और सॉफ्टवेयर विकास के करीब पहुंचते समय किसी विशेष वातावरण में सही कार्रवाई करने के लिए एक गाइड के रूप में उनका उपयोग करते हैं।
फुर्तीले सॉफ्टवेयर विकास समुदाय के लिए सहयोगी और स्व-आयोजन टीम फोकस के मुख्य क्षेत्र हैं।
टीमों को स्वायत्त रूप से यह तय करने की अनुमति है कि वे किसी विशेष परियोजना से कैसे निपटेंगे, लेकिन इसका मतलब यह नहीं है कि पर्यवेक्षक मौजूद नहीं हैं। इसलिए फुर्तीली टीमें क्रॉस-फंक्शनल हैं।
एक चुस्त प्रतिमान में, प्रबंधक अभी भी आवश्यक हैं। वे यह सुनिश्चित करते हैं कि टीम के प्रत्येक सदस्य के पास परियोजना के लिए आवश्यक योग्यताएं हैं या प्राप्त हैं।
एक चुस्त ढांचे में प्रबंधक एक ऐसे माहौल को बढ़ावा देकर काम करते हैं जो टीम में सर्वश्रेष्ठ लाता है। लेकिन नेतृत्व करने के बजाय, वे अक्सर पीछे की सीट लेते हैं और टीम को यह तय करने देते हैं कि वे चीजों को कैसे वितरित करेंगे।
प्रबंधक केवल तभी शामिल होते हैं जब टीम बार-बार सफलता के बिना समस्याओं को हल करने का प्रयास करती है।
चुस्त विकास चक्र
फुर्तीली विकास चक्र के चरणों को नीचे सूचीबद्ध किया गया है। यह याद रखना महत्वपूर्ण है कि ये चरण क्रम में नहीं होने चाहिए क्योंकि वे लचीले होते हैं और लगातार बदलते रहते हैं। इनमें से कई चरण एक साथ होते हैं।
- प्लानिंग: एक परियोजना टीम द्वारा यह तय करने के बाद कि एक विचार व्यावहारिक और व्यावहारिक है, वे सुविधाओं की तलाश शुरू करते हैं। इस चरण का उद्देश्य प्रत्येक सुविधा को प्राथमिकता देना है और विचार को छोटे वर्कपीस (सुविधाओं) में तोड़ने के बाद इसे एक पुनरावृत्ति के लिए असाइन करना है।
- आवश्यकताओं के विश्लेषण: व्यावसायिक आवश्यकताओं को निर्धारित करने के लिए, इस चरण में प्रबंधकों, हितधारकों और उपयोगकर्ताओं के साथ कई चर्चाएँ होती हैं। उत्पाद का उपयोग कौन करेगा और वे इसका उपयोग कैसे करेंगे, यह टीम द्वारा एकत्र किए जाने वाले विवरणों में से एक है। ये मानक विशिष्ट, लागू और मात्रात्मक होने चाहिए।
- डिज़ाइन: पिछले चरण में पाई गई आवश्यकताओं का उपयोग सिस्टम और सॉफ्टवेयर डिजाइन तैयार करने के लिए किया जाता है। उत्पाद या समाधान की उपस्थिति पर विचार टीम द्वारा किया जाना चाहिए। परीक्षण टीम द्वारा परीक्षण के लिए एक रणनीति या योजना भी विकसित की जाती है।
- कार्यान्वयन, कोडिंग, या विकास: इस चरण का फोकस सुविधाओं के निर्माण और मूल्यांकन और पुनरावृत्तियों की तैनाती की योजना बनाने पर है (पुनरावृत्ति और वृद्धिशील विकास दृष्टिकोण [आईआईडी] का पालन करते हुए)। क्योंकि कोई सुविधाएँ प्रदान नहीं की जा रही हैं, विकास अवधि का पुनरावृत्ति 0 शुरू होता है। अनुबंध, सेटिंग स्थापित करने और फंडिंग जैसी गतिविधियों को पूरा करके, यह पुनरावृत्ति भविष्य के विकास के लिए आधार प्रदान करती है।
- परीक्षण: कोड बनाए जाने के बाद, यह सुनिश्चित करने के लिए आवश्यकताओं के विरुद्ध परीक्षण किया जाता है कि उत्पाद वास्तव में उपयोगकर्ता की मांगों को पूरा करता है और व्यावसायिक उद्देश्यों को पूरा करता है। इस स्तर पर इकाई, एकीकरण, प्रणाली और स्वीकार्यता परीक्षण किया जाता है।
- तैनाती: परीक्षण के बाद, उत्पाद ग्राहकों को भेजा जाता है ताकि वे इसका उपयोग कर सकें। हालांकि परिनियोजन के बाद परियोजना समाप्त नहीं हुई है। उत्पाद का उपयोग शुरू करने के बाद ग्राहक अतिरिक्त समस्याओं का सामना कर सकते हैं, जिसका समाधान खोजने के लिए प्रोजेक्ट टीम की आवश्यकता होगी।
फायदे
- तेज़, उच्च-गुणवत्ता वाली डिलीवरी: परियोजना को पुनरावृत्तियों (प्रबंधनीय इकाइयों) में विभाजित करके, टीम उच्च-गुणवत्ता वाले सहयोग, विकास और परीक्षण पर ध्यान केंद्रित करने में सक्षम है। जब प्रत्येक पुनरावृत्ति के साथ परीक्षण किया जाता है, तो समस्याएँ पाई जाती हैं और उन्हें अधिक तेज़ी से ठीक किया जाता है। इसके अतिरिक्त, निरंतर, बाद के संशोधनों के साथ, इस उच्च गुणवत्ता वाले सॉफ़्टवेयर को अधिक तेज़ी से आपूर्ति की जा सकती है।
- बदलाव का स्वागत है: हालांकि योजना चक्र छोटे होते हैं, परियोजना में किसी भी बिंदु पर परिवर्तनों को स्वीकार करना और समायोजित करना आसान होता है। बैकलॉग को हमेशा सुधार और प्राथमिकता दी जा सकती है, जिससे टीमों को कुछ हफ़्ते में परियोजना में बदलाव करने की अनुमति मिलती है।
- अंतिम लक्ष्य ज्ञात नहीं हो सकता है: अंतिम लक्ष्य स्पष्ट रूप से परिभाषित नहीं होने पर परियोजनाओं के लिए Agile उत्कृष्ट है। जैसे-जैसे परियोजना आगे बढ़ेगी, उद्देश्य स्पष्ट होते जाएंगे और विकास इन बदलती जरूरतों को आसानी से समायोजित करने में सक्षम होगा।
- निरंतर सुधार: फुर्तीली कार्यक्रम परियोजना के सभी चरणों में उपयोगकर्ता और टीम इनपुट को बढ़ावा देते हैं, जो अगले पुनरावृत्ति को बेहतर बनाने के लिए सीखी गई बातों को लागू करने की अनुमति देता है।
- ग्राहकों की राय को महत्व दिया जाता है: ग्राहकों के लिए काम पूरा होते देखने, फीडबैक देने और वास्तव में अंतिम परिणाम को प्रभावित करने के कई अवसर हैं। प्रोजेक्ट टीम के साथ इतनी घनिष्ठता से बातचीत करके, उनमें स्वामित्व की भावना विकसित हो सकती है।
- मजबूत टीम वर्क: फुर्तीली नियमित संचार और व्यक्तिगत मुलाकातों के महत्व पर जोर देती है। टीमों में काम करते समय लोग जिम्मेदारी ले सकते हैं और कुछ परियोजना घटकों के मालिक हो सकते हैं।
नुकसान
- टीम के सदस्यों को पता होना चाहिएe: फुर्तीली टीमें अक्सर छोटी होती हैं। इस प्रकार, टीम के सदस्यों के पास कौशल की एक विस्तृत श्रृंखला होनी चाहिए। इसके अतिरिक्त, उन्हें चुनी हुई एजाइल तकनीक का उपयोग करके समझना और सहज महसूस करना चाहिए।
- योजना कम सटीक हो सकती है: सटीक डिलीवरी तिथि निर्धारित करना कभी-कभी चुनौतीपूर्ण हो सकता है। एजाइल टाइम-बॉक्सिंग डिलीवरी पर बनाया गया है, और प्रोजेक्ट मैनेजर अक्सर कार्यों की प्राथमिकताओं को पुनर्व्यवस्थित करते हैं। इस प्रकार, यह संभव है कि कुछ डिलिवरेबल्स जो शुरू में डिलीवरी के लिए निर्धारित किए गए थे, समय पर समाप्त नहीं होंगे। इसके अतिरिक्त, पूरे कार्यक्रम में किसी भी बिंदु पर अधिक स्प्रिंट जोड़े जा सकते हैं, पूरे शेड्यूल को लंबा कर सकते हैं।
- दस्तावेज़ीकरण की अवहेलना की जा सकती है: टीम के कुछ सदस्य यह मान सकते हैं कि दस्तावेज़ीकरण पर ध्यान केंद्रित करना कम महत्वपूर्ण है क्योंकि एजाइल मेनिफेस्टो संपूर्ण दस्तावेज़ीकरण से ऊपर काम करने वाले सॉफ़्टवेयर का समर्थन करता है। फुर्तीली टीमों को दस्तावेज़ीकरण और संवाद के बीच आदर्श संतुलन बनाना चाहिए, भले ही संपूर्ण दस्तावेज़ीकरण परियोजना की सफलता की गारंटी नहीं दे सकता है।
- अंतिम आउटपुट बहुत भिन्न हो सकता है: प्रारंभिक एजाइल परियोजना के लिए एक स्पष्ट रणनीति नहीं हो सकती है, और इसलिए समाप्त परिणाम पहले प्रत्याशित से बहुत बदल सकता है। क्लाइंट इनपुट बदलने के आधार पर नए पुनरावृत्तियों को जोड़ने के परिणामस्वरूप काफी भिन्न अंतिम आउटपुट हो सकता है, क्योंकि एजाइल इतना अनुकूलनीय है।
- डेवलपर्स की समय प्रतिबद्धता: चुस्त प्रभावी होने के लिए विकास टीम को परियोजना के लिए पूरी तरह से प्रतिबद्ध होना चाहिए। फुर्तीली पद्धति, जो एक पारंपरिक दृष्टिकोण से अधिक समय लेती है, को निरंतर सक्रिय भागीदारी और सहयोग की आवश्यकता होती है। इसके अतिरिक्त, इसका तात्पर्य है कि डेवलपर्स को पूरी परियोजना की लंबाई के लिए प्रतिबद्ध होना चाहिए।
झरना क्या है?
सॉफ्टवेयर इंजीनियरिंग और आईटी परियोजनाओं के लिए सिस्टम के विकास जीवन चक्र (एसडीएलसी) का सबसे लोकप्रिय पुनरावृत्ति "झरना दृष्टिकोण" के रूप में जाना जाता है, जो अनुक्रमिक, रैखिक प्रक्रिया का पालन करता है।
गैंट चार्ट, बार चार्ट का एक रूप जो प्रत्येक कार्य की शुरुआत और समाप्ति तिथियों को प्रदर्शित करता है, कभी-कभी इसकी योजना बनाने के लिए उपयोग किया जाता है।
आठ चरणों में से एक के समाप्त होने के बाद विकास दल निम्न स्तर तक आगे बढ़ता है। टीम पूरी प्रक्रिया को फिर से शुरू किए बिना पूर्व चरण में वापस नहीं आ सकती है।
इसके अतिरिक्त, टीम के अगले स्तर पर जाने से पहले क्लाइंट को आवश्यकताओं का मूल्यांकन करने और उन्हें स्वीकार करने की आवश्यकता हो सकती है।
वाटरफॉल मॉडल को विनिर्माण और निर्माण क्षेत्रों के अत्यधिक संगठित वातावरण में विकसित किया गया था, जहां समायोजन निषेधात्मक रूप से महंगा या असंभव भी हो सकता है।
झरने की तकनीक का नाम इसलिए रखा गया है क्योंकि इसका उद्देश्य सिर्फ एक दिशा में - नीचे की ओर - झरने की तरह बहना है। इसके चरणों में विश्लेषण, प्रारंभ, परीक्षण, डिजाइन, भवन, परिनियोजन, रखरखाव और परीक्षण शामिल हैं।
किसी भी अन्य रणनीति की तरह, जलप्रपात तकनीक के कई फायदे हैं। एक यह है कि परियोजना नियोजन और डिजाइन के चरण अधिक सुस्थापित हैं।
जब वॉटरफॉल सॉफ़्टवेयर डेवलपमेंट का उपयोग करते हुए प्रोजेक्ट डिलिवरेबल्स की बात आती है तो ग्राहक और विकास टीम अधिक संरेखित होती है। चूंकि आप शुरू से ही परियोजना के दायरे से अवगत हैं, इसलिए जलप्रपात विकास भी प्रगति की निगरानी करना आसान बनाता है।
वाटरफॉल प्रक्रिया विशेषज्ञों, डेवलपर्स, विश्लेषकों और परीक्षकों का उपयोग परियोजना में अपनी नौकरी पर ध्यान केंद्रित करने के लिए करती है, बजाय इसके कि पूरी टीम एक कदम पर जोर दे।
झरने के चरण
झरने के छह चरण एक के बाद एक होने चाहिए:
- आवश्यकताओं को इकट्ठा करना और भंडारण करना: आपको इस समय इस परियोजना की मांग के बारे में पूरी जानकारी एकत्र करनी चाहिए। इस डेटा को एकत्र करने की कई तकनीकें हैं, जिनमें साक्षात्कार, सर्वेक्षण और सहयोगात्मक विचार-मंथन शामिल हैं। इस चरण के समाप्त होने तक परियोजना की जरूरतें स्पष्ट होनी चाहिए, और आपकी टीम को आवश्यकता दस्तावेज की एक प्रति प्राप्त होनी चाहिए।
- एक प्रणाली का डिजाइन: सिस्टम को आपकी टीम द्वारा पूर्व निर्धारित विनिर्देशों का उपयोग करके डिज़ाइन किया गया है। इस चरण के दौरान, कोई कोडिंग नहीं की जाती है, लेकिन टीम हार्डवेयर या प्रोग्रामिंग भाषा के लिए आवश्यकताएं निर्धारित करती है।
- कार्यान्वयन: इस चरण में कोडिंग शामिल है। पिछले चरण के डेटा का उपयोग प्रोग्रामर द्वारा प्रयोग करने योग्य उत्पाद बनाने के लिए किया जाता है। कोड को अक्सर छोटे-छोटे हिस्सों में लागू किया जाता है जो एक चरण के समापन या दूसरे की शुरुआत में संयुक्त होते हैं।
- परीक्षण: कोड पूरा होने के बाद उत्पाद का परीक्षण शुरू हो सकता है। कोई भी समस्या परीक्षकों द्वारा सावधानीपूर्वक ढूंढी और रिपोर्ट की जाती है। यदि महत्वपूर्ण समस्याएं दिखाई देती हैं तो पुनर्मूल्यांकन के लिए आपकी परियोजना को पहले चरण में वापस जाने की आवश्यकता हो सकती है।
- वितरण/तैनाती: इस बिंदु पर उत्पाद समाप्त हो गया है, और आपकी टीम डिलिवरेबल्स को परिनियोजन या रिलीज़ के लिए सबमिट करती है।
- रखरखाव: ग्राहक ने उत्पाद प्राप्त कर लिया है और उसका उपयोग कर रहा है। जब समस्याएं दिखाई दें तो उन्हें ठीक करने के लिए आपकी टीम को सुधार और अपडेट विकसित करने की आवश्यकता हो सकती है। फिर से, महत्वपूर्ण समस्याएं चरण एक पर लौटने के लिए कह सकती हैं।
फायदे
- संचालित करने और प्रबंधित करने में आसान: वाटरफॉल दृष्टिकोण का उपयोग करना और समझना आसान है क्योंकि प्रत्येक परियोजना को समान अनुक्रमिक तरीके से संभाला जाता है। वाटरफॉल परियोजना शुरू करने से पहले, टीम को किसी पूर्व विशेषज्ञता या प्रशिक्षण की आवश्यकता नहीं होती है। झरना दृष्टिकोण बहुत सख्त है; प्रत्येक चरण में डिलिवरेबल्स और समीक्षा का एक सेट होता है, जिससे इसे प्रशासित करना और बनाए रखना आसान हो जाता है।
- एक अच्छी तरह से प्रलेखित कार्यप्रणाली की आवश्यकता है: जलप्रपात पद्धति के लिए आवश्यक दस्तावेज परीक्षणों और कोड के पीछे के तर्क को स्पष्ट करने में मदद करते हैं। इसके अतिरिक्त, यदि हितधारक किसी निश्चित चरण पर या भविष्य की किसी पहल के लिए अतिरिक्त जानकारी चाहते हैं तो यह एक पेपर ट्रेल बनाता है।
- अनुशासन का प्रवर्तन: जलप्रपात परियोजना के प्रत्येक चरण की शुरुआत और अंत होता है, जिससे हितधारकों और ग्राहकों को प्रगति के बारे में बताना आसान हो जाता है। टीम कोड बनाने से पहले आवश्यकताओं और डिजाइन को पहले रखकर समय सीमा खोने की संभावना को कम कर सकती है।
नुकसान
- सटीक आवश्यकताओं को इकट्ठा करना मुश्किल हो सकता है: उपभोक्ताओं और हितधारकों के साथ उनकी जरूरतों को निर्धारित करने के लिए बात करना वाटरफॉल परियोजना के प्रारंभिक चरणों में से एक है। परियोजना के इस प्रारंभिक चरण में, उनकी विशेष आवश्यकताओं का पता लगाना चुनौतीपूर्ण हो सकता है। ग्राहक अक्सर अपनी आवश्यकताओं के बारे में सीखते हैं क्योंकि परियोजना विकसित होती है बजाय उन्हें सामने व्यक्त करने के।
- परिवर्तनों को समायोजित करना मुश्किल है: एक चरण पूरा करने के बाद चालक दल काम फिर से शुरू नहीं कर सकता है। यदि वे परीक्षण चरण के दौरान सीखते हैं कि आवश्यकता प्रक्रिया के दौरान कार्यक्षमता गायब थी, तो वापस जाना और इसकी मरम्मत करना बहुत कठिन और महंगा है।
- सॉफ्टवेयर इसकी नियत तारीख के बाद प्रदान किया जाता है: वास्तविक कोडिंग शुरू होने से पहले परियोजना के दो से चार चरणों को पूरा किया जाना चाहिए। परिणामस्वरूप जीवन चक्र के अंत तक हितधारकों को कार्यात्मक सॉफ़्टवेयर दिखाई नहीं देगा।
स्क्रम क्या है?
Agile को व्यवहार में लाने के लिए सबसे लोकप्रिय प्रक्रिया ढांचे में से एक Scrum है, जो Agile का सबसेट है।
यह जटिल सॉफ्टवेयर और उत्पादों के निर्माण के प्रबंधन के लिए एक पुनरावृत्त प्रतिमान है। स्प्रिंट, जो एक से दो सप्ताह तक चलने वाले निश्चित-लंबाई वाले पुनरावृत्तियों हैं, टीम को नियमित समय पर सॉफ़्टवेयर जारी करने में सक्षम बनाते हैं।
प्रत्येक स्प्रिंट के बाद अगले चरणों पर चर्चा करने के लिए हितधारक और टीम के सदस्य एक साथ मिलते हैं। स्क्रम में भूमिकाएं, जिम्मेदारियां और बैठकें स्थिर रहती हैं।
उदाहरण के लिए, स्क्रम स्प्रिंट योजना, दैनिक स्टैंड-अप, स्प्रिंट डेमो, और स्प्रिंट रेट्रोस्पेक्टिव को चार अनुष्ठानों के रूप में निर्दिष्ट करता है जो प्रत्येक स्प्रिंट संरचना प्रदान करते हैं।
टीम प्रत्येक स्प्रिंट के दौरान दृश्य कलाकृतियों जैसे टास्क बोर्ड या बर्नडाउन चार्ट का उपयोग प्रगति प्रदर्शित करने और वृद्धिशील प्रतिक्रिया प्राप्त करने के लिए करेगी।
स्क्रम में, टीम और उत्पाद स्वामी सिस्टम कार्यक्षमता को पहचानने और प्राथमिकता देने के लिए मिलकर काम करते हैं। वे एक उत्पाद बैकलॉग बनाकर इसे प्राप्त करते हैं, जिसमें सॉफ़्टवेयर का उत्पादन करने के लिए आवश्यक सभी कार्य शामिल होते हैं जो कि इच्छित कार्य करता है।
बग पैच, गैर-कार्यात्मक आवश्यकताएं, और सुविधाएं सभी को कतार में शामिल किया जाना चाहिए। क्रॉस-फ़ंक्शनल टीमों को निरंतर स्प्रिंट में सॉफ़्टवेयर वृद्धि देने के लिए अनुमान लगाना और साइन अप करना चाहिए, जो आमतौर पर 30 दिनों तक रहता है, एक बार उद्देश्य स्थापित हो जाने के बाद।
उस स्प्रिंट के लिए बैकलॉग करने के बाद केवल टीम स्प्रिंट में कार्यक्षमता जोड़ सकती है।
अगली स्प्रिंट डिलीवरी, उत्पाद बैकलॉग का मूल्यांकन किया जाता है और, यदि आवश्यक हो, तो पुन: प्राथमिकता दी जाती है, और निम्नलिखित वितरण योग्य सेट को निम्नलिखित स्प्रिंट का हिस्सा बनने के लिए चुना जाता है।
स्क्रम प्रक्रिया
- उत्पाद बैकलॉग: उत्पाद बैकलॉग में आइटम ऑर्डर करने के लिए, उत्पाद स्वामी और स्क्रम टीम मिलते हैं (उत्पाद बैकलॉग पर काम उपयोगकर्ता कहानियों और आवश्यकताओं से आता है)। उत्पाद बैकलॉग उन कार्यों की सूची के बजाय उत्पाद के लिए सभी वांछित सुविधाओं की एक सूची है जिन्हें समाप्त करने की आवश्यकता है। उसके बाद, विकास दल प्रत्येक स्प्रिंट में निष्पादित करने के लिए उत्पाद बैकलॉग से कार्यों का चयन करता है।
- स्प्रिंट योजना: प्रत्येक स्प्रिंट से पहले, उत्पाद स्वामी स्प्रिंट प्लानिंग मीटिंग में टीम को बैकलॉग में शीर्ष आइटम वितरित करता है। समूह तब उत्पाद बैकलॉग से आइटम का चयन करता है जिसे वे स्प्रिंट के दौरान समाप्त कर सकते हैं और उन्हें स्प्रिंट बैकलॉग (जो स्प्रिंट में पूरा करने के लिए कार्यों की एक सूची है) में ले जाता है।
- बैकलॉग का शोधन/संवारना: यह सुनिश्चित करने के लिए कि निम्नलिखित स्प्रिंट के लिए बैकलॉग तैयार किया गया है, टीम और उत्पाद स्वामी एक स्प्रिंट के समापन पर मिलते हैं। टीम उन उपयोगकर्ता कहानियों को त्याग सकती है जो अब प्रासंगिक नहीं हैं, नई जोड़ सकती हैं, उस क्रम को संशोधित कर सकती हैं जिसमें उन्हें संबोधित किया जाना चाहिए, या उपयोगकर्ता कहानियों को छोटे कार्यों में विभाजित कर सकता है। इस "सौंदर्य" बैठक के दौरान, यह सुनिश्चित किया जाएगा कि बैकलॉग में केवल वही चीजें शामिल हैं जो प्रासंगिक, गहन और परियोजना के लक्ष्यों के अनुरूप हैं।
- हर दिन स्क्रम बैठकें: डेली स्क्रम नामक 15 मिनट की स्टैंड-अप मीटिंग में, टीम का प्रत्येक सदस्य अपने उद्देश्यों और उत्पन्न होने वाली किसी भी समस्या पर चर्चा करता है। पूरे स्प्रिंट के दौरान हर दिन, टीम डेली स्क्रम में भाग लेती है, जो सभी को काम पर रखती है।
- स्प्रिंट का आकलन करने के लिए बैठकटी: टीम प्रत्येक स्प्रिंट के समापन पर एक स्प्रिंट समीक्षा बैठक में अपना काम प्रस्तुत करती है। रिपोर्ट या पावरपॉइंट प्रेजेंटेशन के बजाय, इस मीटिंग में एक वास्तविक प्रदर्शन शामिल होना चाहिए।
- पूर्वव्यापी स्प्रिंट बैठक: टीम निम्नलिखित स्प्रिंट में किए जाने वाले किसी भी संशोधन के साथ-साथ प्रत्येक स्प्रिंट के समापन पर उनके लिए कितनी अच्छी तरह काम कर रही है, इस पर चर्चा करती है। टीम स्प्रिंट के सकारात्मक पहलुओं, नकारात्मक पहलुओं और सुधार के क्षेत्रों पर चर्चा कर सकती है।
फायदे
- टीम से अधिक जिम्मेदारी: स्क्रम टीम को क्या करना है और कब करना है, यह निर्देश देने वाला कोई प्रोजेक्ट मैनेजर नहीं है। प्रत्येक स्प्रिंट में जो काम पूरा किया जा सकता है, उसके बजाय पूरी टीम द्वारा तय किया जाता है। वे सभी सहयोग करते हैं और एक दूसरे को हाथ प्रदान करते हैं, टीम वर्क को बढ़ाते हैं और टीम के प्रत्येक सदस्य में व्यक्तित्व को बढ़ावा देते हैं।
- बेहतर परियोजना दृश्यता और पारदर्शिता: कम गलतफहमी और अनिश्चितता है क्योंकि टीम में हर कोई अपनी जिम्मेदारियों से अवगत है, लगातार स्टैंड-अप मीटिंग्स के लिए धन्यवाद। टीम नियंत्रण से बाहर होने से पहले ही समस्याओं से निपट सकती है क्योंकि मुद्दों को पहले ही देख लिया जाता है।
- बढ़ी हुई लागत में कटौती: लगातार संचार किसी भी समस्या या परिवर्तन के होते ही टीम को सूचित करता है, जो लागत बचाने और गुणवत्ता में सुधार करने में मदद करता है। छोटे फीचर खंड निरंतर प्रतिक्रिया प्रदान करते हैं और बड़ी त्रुटियों के समाधान के लिए बहुत महंगा होने से पहले प्रारंभिक त्रुटि सुधार की अनुमति देते हैं।
- परिवर्तनों के अनुकूल होने में आसान: बार-बार फीडबैक लूप और शॉर्ट स्प्रिंट होने पर परिवर्तनों से निपटना और उनके अनुकूल होना आसान होता है। एक उदाहरण के रूप में, यदि टीम को एक स्प्रिंट के दौरान एक नई उपयोगकर्ता कहानी मिलती है, तो वे बैकलॉग शोधन बैठक में उस सुविधा को निम्नलिखित स्प्रिंट में जल्दी से जोड़ सकते हैं।
नुकसान
- स्कोप रेंगना खतरा: एक निर्धारित पूर्णता तिथि के अभाव के कारण, कुछ स्क्रम प्रोजेक्ट्स को स्कोप रेंगने का सामना करना पड़ सकता है। यदि पूरा करने की कोई समय सीमा नहीं है, तो हितधारकों को और अधिक सुविधाओं की मांग जारी रखने के लिए लुभाया जा सकता है।
- एक खराब स्क्रम मास्टर सब कुछ पटरी से उतार सकता है: एक प्रोजेक्ट मैनेजर एक स्क्रम मास्टर के समान नहीं होता है। स्क्रम मास्टर को उस टीम पर भरोसा करना चाहिए जिसकी वे निगरानी कर रहे हैं और उन्हें कभी निर्देश नहीं देना चाहिए। स्क्रम मास्टर के पास टीम पर अधिकार नहीं है। यदि स्क्रम मास्टर टीम को प्रबंधित करने का प्रयास करता है तो प्रोजेक्ट विफल हो जाएगा।
- सटीकता के मुद्दे खराब बताए गए कार्यों के परिणामस्वरूप हो सकते हैं: यदि कार्य स्पष्ट रूप से निर्दिष्ट नहीं हैं, तो परियोजना व्यय और कार्यक्रम सटीक नहीं होंगे। योजना चुनौतीपूर्ण हो जाती है और यदि प्रारंभिक लक्ष्यों को परिभाषित नहीं किया जाता है तो स्प्रिंट अनुमान से अधिक समय ले सकते हैं।
- एक टीम के लिए जरूरी है अनुभव और समर्पण: टीम के सफल होने के लिए, भूमिकाओं और कर्तव्यों को स्पष्ट रूप से परिभाषित किया जाना चाहिए। स्क्रम टीम को तकनीकी कौशल वाले टीम के सदस्यों की आवश्यकता होती है क्योंकि कोई स्पष्ट रूप से परिभाषित भूमिकाएँ नहीं होती हैं (हर कोई सब कुछ करता है)। टीम को दैनिक स्क्रम सत्रों में भाग लेने और परियोजना के जीवन के लिए एक साथ रहने के लिए भी प्रतिबद्ध होना चाहिए।
एजाइल बनाम स्क्रम
भले ही Agile और Scrum एक ही कार्यप्रणाली का उपयोग करते हैं, दोनों के बीच कुछ भिन्नताएं हैं। एजाइल मेनिफेस्टो पुनरावृत्त विकास के माध्यम से सॉफ्टवेयर बनाने के सिद्धांतों के एक सेट की रूपरेखा तैयार करता है।
दूसरी ओर, स्क्रम दिशानिर्देशों का एक समूह है, जिसका एजाइल सॉफ्टवेयर विकास करते समय पालन किया जाना चाहिए। एजाइल एक अवधारणा है, जबकि स्क्रम इसे व्यवहार में लाने की एक तकनीक है।
स्क्रम एजाइल को लागू करने का एक तरीका है, इसलिए इन दोनों में कई चीजें समान हैं। दोनों दृष्टिकोण पुनरावृत्त हैं, जल्दी और लगातार सॉफ़्टवेयर वितरण को प्राथमिकता देते हैं, और परिवर्तन को स्वीकार करते हैं। वे खुलेपन और चल रहे विकास का भी समर्थन करते हैं।
फुर्तीली बनाम झरना
कठोर बनाम लचीला सबसे अच्छा झरना प्रक्रिया और फुर्तीली के बीच के अंतर का वर्णन करता है। जबकि एजाइल तरल है और लगातार बदल रहा है, वाटरफॉल एक अधिक सख्त, अधिक कठोर कार्यप्रणाली है।
उनके बीच ये और भेद इस प्रकार हैं:
- फुर्तीली को रैखिक दृष्टिकोण की आवश्यकता नहीं होती है, जबकि झरना अनुक्रमिक होता है।
- जबकि वाटरफॉल परियोजनाओं में अक्सर जरूरतों को पूर्वनिर्धारित किया जाता है, उन्हें फुर्तीली पहलों में बदलाव और अनुकूलन के लिए प्रत्याशित किया जाता है।
- एजाइल के विपरीत, जलप्रपात परियोजनाएं उस कार्य में संशोधन करने की अनुमति नहीं देती हैं जो पहले चरण में पूरा किया गया था।
- जलप्रपात एक संगठित प्रक्रिया है जिसमें आपको अगले चरण पर जाने से पहले प्रत्येक चरण को पूरा करना होगा। हालांकि, एजाइल एक लचीली कार्यप्रणाली है जो आपको अपनी गति से परियोजना के साथ आगे बढ़ने देती है।
फुर्तीली बनाम झरना बनाम स्क्रम
- जलप्रपात इस बात पर विश्वास बढ़ाता है कि योजना के तुरंत बाद क्या प्रदान किया जाएगा। एजाइल विकास पर्यावरण की सर्वोत्तम प्रथाओं पर निर्भर करता है। यहां, कई परियोजना जोखिमों को अच्छी तरह से प्रबंधित किया जा सकता है क्योंकि परिणामों का लगातार मूल्यांकन किया जाता है।
- वाटरफॉल टीम और परियोजना के एक ही स्थान पर आधारित होने का अनुमान नहीं लगाता है। जबकि स्क्रम और फुर्तीले को कर्मचारियों के सह-स्थान की आवश्यकता होती है।
- एजाइल परियोजना पुनर्विक्रय को कम करने पर ध्यान केंद्रित करता है और परिवर्तनों को बहुत पहले शामिल करने के लिए प्रोत्साहित करता है। जलप्रपात के विपरीत, जो अलग तरह से प्रतिक्रिया करता है, स्क्रम भी परिवर्तनों की शीघ्र खोज को सक्षम बनाता है।
- अंतिम उत्पाद के लिए एक अधिक कॉम्पैक्ट ब्लूप्रिंट चुस्त और स्क्रम द्वारा प्रदान किया जाता है। यह खरीदार से किए गए वादों के साथ एक समस्या पैदा करता है। इसके विपरीत, वाटरफॉल ग्राफिक ग्राहकों और डेवलपर्स को तैयार परिणाम का बेहतर प्रभाव देता है।
- इनमें से प्रत्येक तकनीक में उनके निर्माण में शामिल कार्यों को व्यवस्थित और अनुकरण करने के लिए उपकरणों का एक सेट होता है।
निष्कर्ष
यदि आपने अब तक अनुसरण किया है और वाटरफॉल, एजाइल और स्क्रम प्रक्रियाओं के बीच अंतर के बारे में अपने ज्ञान में विश्वास रखते हैं, तो आपको पहले से ही पता होना चाहिए कि कौन सी रणनीति आपके और आपकी टीम के लिए सबसे अच्छा काम करेगी।
वाटरफॉल तकनीक, जो एक निश्चित दायरे, समय सीमा और बजट वाली परियोजनाओं के लिए है, आपके लिए सबसे अच्छा विकल्प हो सकता है यदि आप कठोर नियमों और प्रक्रियाओं को पसंद करते हैं और पाते हैं कि वे स्पष्टता लाते हैं।
दूसरी ओर, यदि स्वतंत्रता और अनुकूलनशीलता की पेशकश आपको प्रेरित करती है, तो यह वह जगह हो सकती है जहां आपको अपना ध्यान रखना चाहिए।
स्क्रम जाने का रास्ता है, हालांकि, यदि आप एक लचीले ढांचे के अंदर थोड़ा अनुशासन चाहते हैं।
हालांकि, जिस परियोजना पर आप काम कर रहे हैं और आपके अंतिम परिणाम के आलोक में आपको इन दृष्टिकोणों पर विचार करना चाहिए।
एक जवाब लिखें