द्वीप स्क्रेम भूल गया

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

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

अपने क्षितिज का विस्तार करने के लिए, साथ ही अपने आंतरिक सवालों का जवाब पाने के लिए, बिल्ली के नीचे आपका स्वागत है ...

वह भूमि जिसे स्करम भूल गए

बहुत सी स्क्रैम परियोजनाओं में क्या गलत है? टीम का प्रदर्शन पहले क्यों उछलता है और फिर घटने लगता है? कुछ स्क्रम टीम समय-समय पर स्क्रम को क्यों छोड़ती हैं? क्या चल रहा है?

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

Scrum आपको एक त्वरित शुरुआत देता है! यह महान है। अक्सर पहले स्प्रिंट स्क्रेम की पहली विशेषताओं में आते हैं। प्रबंधक और ग्राहक खुश हैं। टीम शानदार ढंग से काम करती है, और वह भी खुश है। हर कोई खुश है और स्क्रेम को एक बड़ी सफलता के रूप में देखता है।

यह अगले और अगले स्प्रिंट में दोहराया जाता है। प्रदर्शन अधिक है। सिस्टम धीरे-धीरे बनाया जा रहा है, और सभी कार्यक्षमता पहले से ही काम कर रही है। उम्मीदें बनीं। योजनाएं बनी हैं। उत्साह स्करम पर मंडराता है। हाइपरप्रोडक्टिव हासिल किया!

हाइपरप्रोडक्टिविटी के कारणों में से एक कोड आधार का छोटा आकार है। छोटे कोडबेस को मैनेज करना आसान है। सुधार करना आसान है; नई सुविधाओं को जोड़ना आसान है।

लेकिन कोड तेजी से बढ़ता है; और जब कोड आधार बड़ा हो जाता है, तो इसे बनाए रखना कठिन हो जाता है। कोड गिरावट के कारण प्रोग्रामर काफी धीमा हो जाते हैं। एक खराब लिखित प्रणाली के भारी लोड के कारण असंभव को टीमों को "उड़ा" दिया जाता है। यदि इस पर पहले से ध्यान नहीं दिया जाता है, तो हाइपर-उत्पादक स्क्रेम टीम एक बीमारी में गिर जाएगी जो बहुत सारे सॉफ्टवेयर प्रोजेक्ट्स को मार देती है। उन्होंने एक मेस बनाया (नोट प्रति: मेस)।

"रुको!" - मैंने सुना है आप कहते हैं। “मुझे लगा कि टीम को मजबूत करने के लिए स्क्रैम की आवश्यकता थी! मुझे लगा कि टीम गुणवत्ता सुनिश्चित करने की पूरी कोशिश करेगी। मैंने सोचा था कि एक दृढ़ स्करम टीम एक गड़बड़ नहीं बनाएगी! ”

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

कोई जवाब नहीं है। कारण यह है कि स्क्रैम टीम एक गड़बड़ बनाता है क्योंकि इसे बनाने के लिए इसे मजबूत और उत्तेजित किया जाता है। और स्क्रम टीम इसे जल्दी, बहुत तेजी से बना सकती है! गंदगी पैदा करने के मामले में स्क्रम टीम हाइपरप्रोडक्टिव है। जब तक आप इसके बारे में नहीं जानेंगे, तब तक गंदगी “इतनी बड़ी और इतनी गहरी, इतनी ऊंची होती जाएगी कि आप इसे खत्म नहीं कर सकते। कोई रास्ता नहीं है। ”

और जब आता है, उत्पादकता गिरती है। नैतिकता गिर रही है। ग्राहक और प्रबंधक बुराई बन जाते हैं। जिंदगी खराब है।

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

हमें गति बनाए रखते हुए तेजी से आगे बढ़ने और स्वच्छ रहने की जरूरत है। दो लक्ष्यों को प्राप्त करने के लिए एक टीम को कैसे उत्तेजित किया जाए? बस। हम दोनों को मापते हैं और उसी को पुरस्कृत करते हैं। यदि कोई टीम तेजी से आगे बढ़ती है, लेकिन गंदा काम करती है, तो उसे इनाम नहीं मिलेगा। यदि टीम साफ रहती है, लेकिन कोई इनाम नहीं मिलता है। यदि कोई टीम तेजी से आगे बढ़ती है और साफ रहती है, तो उसे प्रोत्साहित किया जाता है!

हम इंजीनियरिंग विषयों और टेस्ट डेवलपमेंट (टीडीडी), कंटीन्यूअस इंटीग्रेशन, पेयर प्रोग्रामिंग, कलेक्टिव कोड ओनरशिप और रीफैक्टरिंग जैसी प्रथाओं को लागू करके अव्यवस्था को माप सकते हैं; यानी चरम प्रोग्रामिंग (XP) के इंजीनियरिंग अभ्यास।

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

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

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

टीडीडी चिकित्सक बड़ी संख्या में स्वचालित रूप से परीक्षण बनाते हैं जो एक दूसरे का समर्थन करते हैं और एक प्रतिगमन सेट होते हैं। यह वह है जिसे आप माप सकते हैं! उपाय का कवरेज। परीक्षणों की संख्या को मापें। स्प्रिंट में नए परीक्षणों की संख्या को मापें। प्रत्येक स्प्रिंट में रिपोर्ट किए गए दोषों की संख्या को मापें और परीक्षणों के साथ कोड कवरेज की पर्याप्तता निर्धारित करने के लिए इसका उपयोग करें (नोट: परीक्षण कवरेज)।

लक्ष्य परीक्षण सूट में उस बिंदु पर आत्मविश्वास बढ़ाना है जहां आप उत्पाद वितरित कर सकते हैं (नोट: उत्पाद को तैनात करें) जैसे ही परीक्षण सूट पास होता है। इसलिए, "अन्य" परीक्षणों की संख्या को मापें जो आपको लगता है कि किया जाना चाहिए, और उनकी कमी को प्राथमिकता दें; खासकर अगर यह मैनुअल परीक्षण है!

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

अनकम्प्रेस्ड सिस्टम, या सिस्टम जहां प्रलेखन उत्पाद कोड (लगभग अनुवाद। उत्पादन कोड) के अनुसार अपडेट नहीं किया जाता है, गड़बड़ हैं। टीडीडी के दौरान प्राप्त इकाई परीक्षण निम्न-स्तरीय प्रणाली वास्तुकला का वर्णन करने वाले दस्तावेज हैं। प्रत्येक प्रोग्रामर को यह जानने की जरूरत है कि सिस्टम का एक हिस्सा कैसे काम करता है, परीक्षण को एक अस्पष्ट, सटीक विवरण के रूप में पढ़ सकता है। जब तक वे काम करेंगे तब तक ये दस्तावेज कभी भी अपनी प्रासंगिकता नहीं खोएंगे।

परीक्षणों के आकार को मापें। टेस्ट विधि कोड की पांच और बीस लाइनों के बीच होनी चाहिए। परीक्षण कोड की कुल मात्रा उत्पाद कोड की संख्या के लगभग बराबर होनी चाहिए।

परीक्षणों की गति को मापें। टेस्ट जल्दी से काम करना चाहिए; मिनट, घंटे नहीं। त्वरित परीक्षण को प्रोत्साहित करें।

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

माप चक्रवाती जटिलता । ऐसे कार्य जो बहुत जटिल हैं (जैसे cc> 6 या इसके करीब) को फिर से भरना चाहिए। Crap4J जैसे उपकरणों का उपयोग उन तरीकों और कार्यों की पहचान करने के लिए जो इस नियम का उल्लंघन करते हैं और जिनमें कम से कम परीक्षण कवरेज है।

कार्यों और कक्षाओं के आकार को मापें। मध्य फ़ंक्शन में कोड की 10 से कम लाइनें होनी चाहिए। 20 से अधिक लाइनों को तोड़ना होगा। 500 से अधिक लाइनों को दो या अधिक वर्गों में विभाजित किया जाना चाहिए। ब्रेथवेट सहसंबंध को मापें, इसका मान 2 से अधिक होना चाहिए।

माप निर्भरता मैट्रिक्स। सुनिश्चित करें कि कोई परिपत्र निर्भरता नहीं हैं। सुनिश्चित करें कि निर्भरता का प्रवाह निर्भरता को संभालने के सिद्धांत के अनुसार और स्थिर सार के सिद्धांत के अनुसार अमूर्तता की दिशा में जाता है ( नोट: स्थिर सार का सिद्धांत: पैकेज जो संभव हो उतना ही अपरिवर्तनीय हैं। मुमकिन होना चाहिए। पैकेज योग्य होना चाहिए। पैकेज अमूर्त पैकेज आनुपातिक होना चाहिए)। परिवर्तनशीलता। )।

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

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

प्रति दिन कमिट की संख्या की गणना करें। यह संख्या टीम के डेवलपर्स की संख्या से अधिक होनी चाहिए। बार-बार आने के लिए प्रोत्साहित करें।

इस महीने में बनने वाले दिनों की संख्या की गणना करें। गिरते हुए महीनों को प्रोत्साहित करें। समय को मापें जबकि खराबी समाप्त नहीं होती है।

परीक्षण कहानियां (नोट: कहानी परीक्षण) व्यवसाय विश्लेषकों और परीक्षकों द्वारा विकसित उच्च-स्तरीय दस्तावेज हैं। वे ग्राहक के दृष्टिकोण से प्रणाली के व्यवहार का वर्णन करते हैं। FitNesse या Cucumber जैसे टूल के साथ लिखे गए ये परीक्षण ऐसी आवश्यकताएं हैं जिनका पालन किया जाना चाहिए। जब ये परीक्षण बीत चुके हैं, तो टीम को पता है कि इसने उन कहानियों को पूरा कर लिया है जो इन परीक्षणों में वर्णित हैं।

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

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

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

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