स्क्रम बनाम कंबन: शांत रहें और जो आपको बेहतर लगे उसे चुनें

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

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

स्क्रम बनाम कंबन: दो विधियाँ, एक विकल्प

इससे पहले कि आप इस तरह के एक कठिन चयन के लिए आते हैं, आपको संभवतः वाटरफॉल बनाम एजाइल के बीच चुनाव से संबंधित एक और प्रारंभिक दुविधा का सामना करना पड़ सकता है। हालाँकि, आपने सही चुनाव किया है और अब आप चुस्त विकास की दुनिया में दो स्वतंत्र रास्तों का सामना कर रहे हैं।

स्क्रम और कंबन, एजाइल परिवार की दो शाखाएं हैं (हालांकि, कई लोग कानबन को एक स्वतंत्र पद्धति नहीं मानते हैं और इसे अन्य तरीकों से अलग रखते हैं)। दोनों लचीले और पुनरावृत्त हैं।

एक सर्वेक्षण था, 2018 में दुनिया भर के 101592 सॉफ्टवेयर डेवलपर्स के बीच आयोजित किया गया था। लगभग 86% लोग अपने काम में एजाइल का उपयोग करते हैं। प्रभावशाली लगता है, है ना?

Scrum या Kanban: सबसे अच्छा विकल्प क्या है?

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

स्क्रम फ्रेमवर्क हल्का और समझने में सरल है लेकिन मास्टर करना मुश्किल हो सकता है। इसमें छोटे पुनरावृत्तियों या स्प्रिंट होते हैं, जो आमतौर पर 2-3 सप्ताह तक होते हैं।

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

स्क्रम में विभिन्न शब्द, अवधारणाएं और कलाकृतियां हैं। उन सभी को समझने के लिए, पढ़ना और अध्ययन करना और स्क्रैम शब्दावली या अंतिम गाइड।

कानबन को उस स्थान के परिप्रेक्ष्य से अवलोकन किया जा सकता है जहां इसे बनाया गया था - टोयोटा कंपनी।

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

यहां महत्वपूर्ण क्षण यह है कि वे किसी भी क्षण प्राथमिकताएं बदल सकते हैं। वे मशीन को एक अलग मोड में बदलने में सक्षम हैं और यही वह है।

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

कानबन प्रक्रियाओं में संभावित अड़चनों की पहचान करने और लागत-प्रभावी प्रवाह प्रदान करने के लिए उन्हें ठीक करने का आश्वासन देता है।

स्क्रम और कंबन के बीच मुख्य अंतर यात्रा की लंबाई है:

• आप 2 सप्ताह के लिए स्क्रम में काम करते हैं।
• कानबन में, आप हर दिन के कार्यों के साथ डेवलपर्स प्रदान कर सकते हैं।

कानबन अधिक लचीला है। कल्पना कीजिए कि कल आपने फीचर के KPI पर नज़र रखने के लिए कुछ घटनाओं के साथ उत्पादन सर्वर के लिए एक नई सुविधा जारी की।

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

स्क्रम के मामले में, आपको पूरे स्प्रिंट का इंतजार करना होगा, यानी 2-3 सप्ताह।



स्क्रम को स्टोरी पॉइंट्स या आवर्स के साथ कार्य आकलन की आवश्यकता होती है। आप इस अनुमान के बिना स्प्रिंट नहीं बना पाएंगे। और आपको ठीक से पता होना चाहिए, कि क्या आप 2 सप्ताह में सभी कार्य पूरा कर लेंगे।

2 सप्ताह के बाद आपको बहुमूल्य आंकड़े मिलते हैं कि आपकी टीम कितने अंक या घंटे स्प्रिंट के दौरान पूरा करने में सफल रही। इस जानकारी की मदद से, एक स्क्रम मास्टर भविष्यवाणी करता है कि टीम 2 सप्ताह में कहां होगी।

कानबन में, लोग भी अनुमान लगा सकते हैं, लेकिन यह वैकल्पिक है। कोई टीम वेग नहीं है। आप कार्य पूरा होने के लिए केवल एक औसत समय मानते हैं और इसे एक साइकिल समय रिपोर्ट में गिनते हैं।

टास्क साइकल का समय = किसी कार्य पर काम करने में लगने वाला समय - वह समय जब कार्य शुरू किया गया था

ज़रा सोचिए कि स्क्रम में मौजूदा लक्ष्य एक स्प्रिंट को खत्म करना है लेकिन कानबन के लिए, आपको एक कार्य पूरा करना होगा।

सिद्धांत से अभ्यास तक: जिस तरह से हम इसे करते हैं

सीमा को पोंछते हुए

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

यह इष्टतम है जब लोग एक समय में केवल एक ही कार्य पर काम करते हैं। आमतौर पर एक डेवलपर को एक कार्य से दूसरे में स्विच करने में 15 मिनट लगते हैं ।

आपको चाय बनाने के लिए समय चाहिए, वेब पर कुछ लेखों को देखने के लिए, नए कार्य के लिए आवश्यकताओं को पढ़ने के लिए, यह याद रखने के लिए कि आपने कहां-कहां रुका है और कोड में वह स्थान पाया है।

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

Swimlanes

कोई भी विफलताओं से सुरक्षित नहीं है और आपकी साइट व्यवसाय के घंटों के दौरान काम नहीं कर सकती है। आप उदाहरण के लिए, अपने DevOps इंजीनियर को इसे तुरंत ठीक करने के लिए एक कार्य बनाते हैं और असाइन करते हैं।

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

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

हम एक "सोमडे" स्विमलन का भी उपयोग करते हैं जो उन सभी कार्यों को कवर करता है जो हम संभवतः उस ब्लॉक के तहत एक दिन करेंगे।

स्विमलेन सभी अनावश्यक चीजों को अलग करने में मदद करता है ताकि लोग महत्वपूर्ण कार्यों पर ध्यान केंद्रित कर सकें।

उप-स्तंभ

इसके ठीक बाद एक "कोडिंग" कॉलम और एक "परीक्षण" है। जब डेवलपर अपना कार्य पूरा करता है, तो वह इसे "परीक्षण" पर ले जाता है। आप सोच सकते हैं कि परीक्षक ने पहले से ही इस कार्य पर काम करना शुरू कर दिया है, लेकिन वास्तव में, वह एक और काम कर रहा है। एक बार जब डेवलपर परीक्षण के लिए कार्य को आगे बढ़ाता है, तो वह QA के लिए WIP सीमा को परेशान करता है। यह एक वास्तविक चुनौती है!

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

फिर भी, अगर WIP की सीमाएं नहीं तोड़ी जानी चाहिए तो अगला कार्य कैसे किया जाएगा? उप-कॉलम सहायता करते हैं। डेवलपर बस पूर्ण कार्य को "कोडिंग टू-डू" उप-कॉलम से "कोडिंग डन" पर ले जाता है। और परीक्षक, समय आने पर, "कोडिंग डन" उप-कॉलम से एक नया परीक्षण कार्य लेगा।

अंतिम विचार

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

उत्पाद विकास की शुरुआत में स्क्रेम बेहतर दिखता है क्योंकि यह समय सीमा को आसान बनाने में मदद करता है। इसके अतिरिक्त, टीमों में पर्याप्त संचार है। वे शुरुआत से पहले स्प्रिंट बैकलॉग पर अच्छी तरह से चर्चा करते हैं।

वे अपने रचनाकारों के साथ कार्यों पर चर्चा करते हैं। टीम प्लानिंग पोकर सिस्टम के अनुसार कार्यों का अनुमान लगाती है। वास्तव में, स्क्रैम उत्पाद के मूल को समझने में मदद करता है।

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

क्या आपने दोनों तरीकों को लागू किया है? कंबन बनाम स्क्रैम विपक्ष में आपका पसंदीदा क्या है?