अपनी चंचलता का अनफ़ल्टरी परीक्षण

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

कुछ समय पहले, मैंने लिखा था कि कैसे मैं एजाइल को परिभाषित करता हूं:

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

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

आप कितनी बार अपडेट रोल आउट करते हैं?

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

क्या आप इस मोड में अंतहीन काम कर सकते हैं?

"स्थिर गति के साथ" का अर्थ है कि टीम के आकार में परिवर्तन को ध्यान में रखे बिना एक टीम अधिक या कम निरंतर गति के साथ नई कार्यक्षमता बना सकती है।
स्थिर गति बनाए रखने के लिए दो पहलू महत्वपूर्ण हैं:

• लोग
• तकनीकी संपत्ति

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

टीम परिवर्तनों से कैसे निपटती है?

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

कुछ लोगों ने वास्तव में एजाइल को लागू किया है।

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

1. शब्दों का संपीड़न (क्योंकि चंचल का अर्थ "तेज़" है, सही है?)
2. दस्तावेज़ीकरण का अभाव (क्योंकि चंचल का अर्थ है हम दस्तावेज़ नहीं करेंगे, सही?)
3. अंतिम मिनट तक कोड लिखना (क्योंकि चंचल का मतलब है कि आप हमेशा कुछ भी बदल सकते हैं, हुह?)

यह एक दुःस्वप्न के लिए एक नुस्खा है: तकनीकी ऋण, तनाव, अराजकता में वृद्धि और अंत में, परियोजना की डिलीवरी में एक ब्रेकडाउन और रोमांचक खेल के कई दौर "कौन दोषी है?" ।
मुझे आशा है कि यदि आप अपने आप को इस तरह के माहौल में पाते हैं, तो "आपकी चंचलता का अप्रभावी परीक्षण" आपको हेल्म में उन लोगों को यह बताने में मदद करेगा कि वास्तविक चंचलता क्या है और यह अच्छा होने पर कैसा दिखता है।
याद रखें, अगर कोई कहता है कि वह एजाइल का उपयोग करता है, तो इसका मतलब यह नहीं है कि यह वास्तव में है। अब्राहम लिंकन ने कहा: “यदि आप अपने पैर से पूंछ का नाम लेते हैं, तो कुत्ते के कितने पैर होंगे? चार। क्योंकि पैर से पूंछ का नाम रखने का मतलब यह नहीं है कि वह पैर बना ले। ”