अधिक उत्पादकता और कम दर्द के साथ स्क्रम का उपयोग कैसे करें

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

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

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

स्क्रम का बहुत संक्षेप में परिचय

एजाइल पद्धतियाँ निम्नलिखित सामान्य सिद्धांतों पर आधारित हैं, जिन्हें तथाकथित "एजाइल मेनिफेस्टो" में परिभाषित किया गया है:

• "व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत"
• "व्यापक दस्तावेज़ीकरण पर कार्यशील सॉफ़्टवेयर"
• "अनुबंध वार्ता पर ग्राहक सहयोग"
• "एक योजना का पालन करके परिवर्तन का जवाब देना"

(स्रोत: एजाइल मेनिफेस्टो )

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

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

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

भूमिकाएँ हैं:

• टीम : इसमें विश्लेषक, डेवलपर्स, परीक्षक और सामान्य तौर पर परियोजना में शामिल हर तरह के पेशेवर शामिल हो सकते हैं। इसे स्क्रम नियोजन सत्रों की सीमाओं के भीतर स्व-संगठित तरीके से काम करना चाहिए।

• स्क्रम मास्टर : वह सभी स्क्रम प्रक्रियाओं का समन्वय करता है, बैठकें आयोजित करता है, इत्यादि।

• उत्पाद स्वामी : उत्पाद की जिम्मेदारी उसकी है। वह तथाकथित उत्पाद बैकलॉग का प्रबंधन करता है, जिसमें स्पष्ट रूप से व्यक्त की गई सभी आवश्यक विशेषताएं शामिल हैं। वह टीम के साथ उन पर चर्चा कर सकता है, और उससे सहायता प्राप्त कर सकता है, लेकिन वह एकमात्र जिम्मेदार है।

  
  

घटनाएँ हैं:

• स्प्रिंट : पुनरावृत्तीय विकास में एकल वृद्धि का प्रतिनिधित्व करता है। इसकी अवधि आमतौर पर दो सप्ताह से एक महीने तक होती है।

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

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

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

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

  
  

कलाकृतियाँ हैं:

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

किसी प्रकार के सिद्धांत के साथ स्क्रम को भ्रमित न करें

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

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

स्क्रम का वास्तविक उद्देश्य विकास प्रक्रिया में "पृष्ठभूमि शोर" की मात्रा को कम करना और सबसे महत्वपूर्ण चीजों पर फोकस में सुधार करना है। यदि सही लचीलेपन और विनम्रता के साथ इसका उपयोग किया जाए तो यह ऐसा करने में प्रभावी हो सकता है।

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

एक वास्तविक उपयोग का मामला

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

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

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

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

हमें स्क्रम में बिल्कुल भी प्रशिक्षित नहीं किया गया था, लेकिन हम सभी इसकी बुनियादी बातों के प्रति सचेत थे। परियोजना के लिए हमारे मन में मुख्य दिशानिर्देश, पद्धतिगत और तकनीकी दोनों थे:

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

स्क्रम अभ्यास

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

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

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

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

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

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

स्वचालन उपकरण द्वारा गतिविधियों/स्रोतों पर नज़र रखना

कार्यप्रणाली प्रथाओं के अलावा, हमें इन मुख्य चिंताओं को हल करने के लिए उपकरणों की भी आवश्यकता थी:

• कोड को संस्करणित करना, उसके परिवर्तनों को ट्रैक करना और उन्हें टीम में साझा करना।

• गतिविधियों और बग समाधान पर नज़र रखना: क्या करना है, किसे क्या सौंपा गया है, और इसकी स्थिति क्या है।

• मिलान स्रोत कोड गतिविधियों के साथ बदलता है।

  
  

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

कोड वर्जनिंग के लिए, हमने Git का उपयोग किया क्योंकि यह सबसे स्वाभाविक विकल्प है। Git का उपयोग विभिन्न तरीकों से किया जा सकता है, और हमने व्यक्तिगत रूप से Gitflow को वर्कफ़्लो पैटर्न के रूप में अपनाया है।

गतिविधियों पर नज़र रखने के लिए हमने Redmine का उपयोग किया, जो परियोजना प्रबंधन के उद्देश्य से एक सामान्य मंच है।

तीसरी चिंता से निपटने के लिए, हमने अपने Git रिपॉजिटरी को Redmine के साथ इस तरह से एकीकृत किया कि Git कमिट को कमिट कमेंट में एक समस्या पहचान कोड का उपयोग करके विशिष्ट Redmine टिकटों से संबंधित किया जा सके। इस तरह हमारे पास गतिविधियों और कार्य की Git इकाइयों के बीच पूर्ण मानचित्रण था।

इकाई और एकीकरण परीक्षण के साथ व्यवहार संचालित विकास दृष्टिकोण

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

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

इसमें शामिल मुख्य प्रौद्योगिकियाँ थीं:

• ककड़ी : REST सेवाओं के साथ स्प्रिंग बूट एप्लिकेशन में एकीकृत

• अन्य परीक्षण उपकरण: एकीकरण परीक्षणों का समर्थन करने के लिए जुनीट , मॉकिटो और स्प्रिंग बूट लाइब्रेरी।

  
  

निम्नलिखित मानसिक मानचित्र ऊपर चर्चा की गई चीजों का सारांश दिखाता है:

विचार

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

एक खेल सादृश्य

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

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

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

प्रबंधकों का प्रबंधन

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

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

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

सच कहूँ तो, मैंने हाल ही में इस कठोर वास्तविकता का प्रयोग किया है। आम तौर पर इन लोगों को इस बात का ज़रा भी अंदाज़ा नहीं होता कि किसी कार्यप्रणाली के सिद्धांत क्या हैं, और ऐसे नियमों से लोगों को परेशान करते रहते हैं जिन्हें वे समझते भी नहीं हैं।

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

कार्यप्रणाली, परीक्षण प्रथाओं, ट्रैकिंग गतिविधियों और संबंधित उपकरणों के बीच संतुलन

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

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

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

निष्कर्ष

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