स्क्रम के 3 नुकसान और उन्हें कैसे ठीक करें

आइए भयानक स्टैंड-अप मीटिंग्स, अनुमान नरक और उपयोगकर्ता मूल्य प्रदान करने और इसके बजाय महान उत्पादों का निर्माण करने से छुटकारा पाएं।

Unsplash पर रैंडी फेथ द्वारा फोटो

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

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

2018 में वापस, मैंने एक लेख लिखा, जो उस समय मैंने सोचा था कि सॉफ्टवेयर इंजीनियरिंग के लिए स्क्रैम का उपयोग करने की कीमत थी। उस लेख को कुंठित डेवलपर्स से बहुत प्रशंसा मिली, साथ ही साथ समीक्षकों की एक अच्छी मात्रा से जो मेरे द्वारा बताई गई बातों को मानते थे।

तब से, मैं यह पता लगाने के लिए एक यात्रा पर गया कि यह "खराब" स्क्रम क्या है। स्क्रेम को पूरी तरह से लिखने के बजाय, जो संभवतः सॉफ़्टवेयर विकास के लिए काम नहीं कर सकता है, मैंने खराब तत्वों को इंगित करने पर ध्यान केंद्रित किया, और उन्हें सार्थक, उत्पादक तत्वों में बदलने के तरीके तैयार करने का प्रयास किया।

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

उपयोगी दैनिक स्टैंड-अप मीटिंग का संचालन करें

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

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

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

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

बैठक के बजाय यह साबित करने के बारे में कि आपने कल सार्थक काम किया है, और आज भी करना जारी रखेंगे, बैठक में अधिक प्रभावी सहायक चरित्र होगा। आपको मौके पर यह तय करना होगा कि आगे किस कार्य को करना है, और यदि आपका मार्ग अवरुद्ध है, तो आप इसे सही तरीके से संबोधित कर सकते हैं।

PS यदि आप इस कहानी में प्रबंधक हैं, तो मुझे पता है कि बैठक से खुद को काटना मुश्किल है। आपकी अनुपस्थिति का अनुरोध करना टीम के सदस्यों के लिए और भी कठिन है। शायद आपकी टीम के साथ इस पर चर्चा करना और थोड़े समय के लिए प्रबंधक-कम बैठकों की कोशिश करना यह मापने का एक अच्छा तरीका हो सकता है कि क्या बैठक आपके बिना अधिक उत्पादक बन जाती है या नहीं।

रॉब हैम्पसन द्वारा अनस्प्लैश पर फोटो

उपयोगकर्ता मान पर ध्यान न दें

एक कारण यह है कि कंपनियां स्क्रम जैसे फ्रेमवर्क को लागू करती हैं क्योंकि वे अपने अंतिम-उपयोगकर्ताओं को तेजी से मूल्य वितरित करना चाहते हैं। यह जोड़ी व्यक्तिगत स्प्रिंट की छोटी अवधि के साथ अच्छी तरह से, साथ ही उनके बीच फोकस समायोजन करने की क्षमता के साथ।

यहां आप जो सबसे बड़ी गलती कर सकते हैं, वह सिर्फ आपके अंतिम-उपयोगकर्ताओं के लिए मूल्य पहुंचाने के प्रति जुनूनी है। जिस तरह सड़ते हुए समर्थन वाले बीम के साथ एक इमारत में एक अतिरिक्त मंजिल को जोड़ने का कोई मतलब नहीं है, यह एक ऐसी परियोजना में सुविधाओं को जोड़ने के लिए बहुत कम समझ में आता है जो अपने स्वयं के वजन के नीचे ढह रही है।

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

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

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

सुसमाचार के लिए अनुमान मत लो

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

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

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

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

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

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

जबकि टीम समय के साथ काम का अनुमान लगाने में बेहतर हो जाती है, हमेशा ध्यान रखें कि छोटी चीजें पूरी तरह से अनुमान को फेंक सकती हैं। वास्तविक मूल्य किए गए वास्तविक काम में है, न कि अनुमान सही था या नहीं।

निष्कर्ष

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

एक स्क्रम कार्यान्वयन को निरंतर सुधार का विषय होना चाहिए। अगर आपकी टीम के लिए कुछ काम नहीं करता है; इसे अनुकूलित करें। स्क्रेम को समारोहों और बैठकों का एक अपरिवर्तनीय सेट नहीं होना चाहिए - यह एक तरल पदार्थ होना चाहिए जो आपकी टीम पर बढ़ता है और आपको दिशानिर्देशों का एक सेट देता है जो आपको अधिक उत्पादक और कुशल बनने में मदद करते हैं।

मैं किसी भी तरह से उत्साही उत्साही उत्साही नहीं हूं, और मैं शायद कभी नहीं रहूंगा। लेकिन 2018 में मेरे द्वारा लिखे गए लेख के विपरीत, हो सकता है कि, मुझे नहीं लगता कि एक संस्था के रूप में स्क्रम सॉफ्टवेयर विकास टीमों के लिए एक बुरी बात है।

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

सॉफ्टवेयर को विकसित करने का सबसे अच्छा तरीका वह तरीका है जो आपकी टीम के लिए काम करता है। उस पर ध्यान दें। आराम भूल जाते हैं।

यह सभी देखें

मुझे एक सक्षम डेवलपर कैसे पता चलेगा जो खरोंच से एक नए विचार परियोजना को विकसित कर सकता है? मैं अपने वेब स्क्रैपर को एक साइट से कई साइटों तक कैसे बढ़ा सकता हूं और क्या यह कुछ उत्पादों के लिए खोज करने का एक तरीका है? सामने वाले के विकास में "समस्या को रास्ता देखने" की क्षमता कैसे प्राप्त होती है? गहन सीखने के बारे में जानने के लिए सबसे अच्छे संसाधन क्या हैं? कैसे Android पर कैमरा निष्क्रिय करने के लिएमैं एक शुरुआत के रूप में बिना किसी पैसे के एक सिद्ध प्रणाली का उपयोग करके असीमित धन ऑनलाइन कैसे बना सकता हूं? paypal स्टूडेंट अकाउंट कैसे बनायेसाइटों को होस्ट करने के लिए आपको कितना अपलोड बैंडविड्थ की आवश्यकता है?