केस स्टडी और मॉडलिंग के आधार पर स्क्रैम और कानबन दृष्टिकोणों को लागू करने के परिणामों का एक तुलनात्मक अध्ययन

2014 लुक्सॉफ्ट ट्रेनिंग ट्रेनिंग सेंटर से दिलचस्प प्रशिक्षण और मास्टर कक्षाओं से भरा होने का वादा करता है। नए साल की पहली तिमाही में, प्रोफेसर मिशेल मार्केज़ इटली के कैग्लियारी विश्वविद्यालय में सॉफ्टवेयर इंजीनियरिंग में एक प्रोफेसर से मिलने जाएंगे।

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

केस स्टडी और मॉडलिंग के आधार पर स्क्रैम और कानबन दृष्टिकोणों को लागू करने के परिणामों का एक तुलनात्मक अध्ययन

लेखक: डेविड एंडरसन, गिउलिओ कॉनकस, मारिया इलारिया लुनेसु, मिशेल मार्चेसी और होंगयु झांग

यह लेख एक व्यक्तिगत SEI विकास प्रक्रिया पर आधारित एक पारंपरिक सॉफ्टवेयर से पारंपरिक दृष्टिकोण से संक्रमण का विश्लेषण करता है, जिसे लिमिटेड WIP के रूप में जाना जाता है। इस केस स्टडी के विश्लेषण के दौरान प्राप्त डेटा का उपयोग विकास प्रक्रिया के सिम्युलेटर की उपयुक्तता का आकलन करने के लिए किया जाता है, जिसे हमने विकसित किया था, साथ ही स्क्रम प्रक्रिया का उपयोग करने की संभावना को सत्यापित करने के लिए स्क्रम प्रक्रिया के मॉडलिंग के लिए इनपुट डेटा।

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

रखरखाव टीम में दो भाग शामिल थे: एक विकास दल और एक परीक्षण दल, तीन लोग प्रत्येक। टीमों ने महीने में औसतन 22 दिन, महीने में 12 महीने काम किया। सेवा अनुरोध बेतरतीब ढंग से आया, औसतन 20-25 अनुरोध प्रति माह। प्रत्येक अनुरोध एक मूल्यांकन चरण, एक वैध-अनुपयुक्त समाधान, लॉगबुक में कार्यों को दर्ज करने के चरण और विकास और परीक्षण चरणों से गुजरा। टीमों की योग्यता के बावजूद, यह प्रक्रिया हमेशा सुचारू रूप से नहीं चली। पूर्ण किए गए अनुरोधों की संख्या प्रति माह 5-7 थी, और बकाया की वृद्धि प्रति माह 6 अनुरोधों की तीव्रता के साथ हुई। जब टीम ने अक्टूबर 2004 में कानबन वर्चुअल सिस्टम की शुरुआत की, तो अनुरोधों के बैकलॉग में 80 अनुरोध थे, और उनकी संख्या बढ़ती रही। जिस क्षण उन्हें 125 से 155 दिनों तक की अवधि के अनुरोधों को निष्पादित करने का औसत समय था, जो मूल रूप से इच्छुक पार्टियों के अनुरूप नहीं था।

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

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

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

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

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

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

हमने ऊपर वर्णित Microsoft टीम को प्रस्तुत डेटा सिमुलेशन सेवा अनुरोधों का उपयोग करके प्रस्तुत सभी तीन मॉडलों की नकल की। हमने चार साल की अवधि (1056 दिन, प्रति माह 22 दिन) को कवर करते हुए अनुरोधों के दो सेट उत्पन्न किए। अनुरोधों को पूरा करने के लिए आवश्यक प्रयास का वितरण सामान्य है: औसतन 2.5 दिनों के मानक विचलन के साथ 8.5 दिन। अध्ययन की गई तीन प्रक्रियाओं में से प्रत्येक के लिए, हमने एक ही इनपुट डेटा के साथ सिमुलेशन की एक श्रृंखला का प्रदर्शन किया। यादृच्छिक संख्या जनरेटर द्वारा उत्पन्न विभिन्न प्रारंभिक संख्याओं के साथ कई रन के बाद, प्रत्येक प्रक्रिया और प्रत्येक इनपुट डेटा सरणी के लिए काफी स्थिर परिणाम प्राप्त किए गए थे।

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

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

स्रोत: XP2012 सम्मेलन की कार्यवाही में प्रकाशित एक लेख का सारांश

मिशेल मार्केज़ की आगामी मास्टर क्लास, "लीन बनाम कानबन", सॉफ्टवेयर विकास के तरीकों पर केंद्रित है। प्रशिक्षण केंद्र की वेबसाइट पर मास्टर वर्ग के बारे में विस्तृत जानकारी ।