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