चंचल को मारने के 6 तरीके

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

फुर्तीली क्या है

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

ठीक है, अब, वास्तव में, आप "एगिल" को मारने के तरीकों पर विचार कर सकते हैं।

एक औपचारिकता में बदलो

मान लीजिए कि एक निश्चित नेता ने एजाइल पर बहुत साहित्य पढ़ा है और अब इस ज्ञान को व्यवहार में लाने के लिए उत्सुक है। उनके क्रियात्मक भाषण कुछ इस तरह दिख सकते हैं:

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

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

आशा है सब कुछ ठीक हो जाए

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

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

प्रक्रिया में अपूर्ण टीम की भागीदारी

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

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

चयनात्मक आवेदन

कभी-कभी आप नेताओं से कुछ इस तरह सुन सकते हैं:

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

और फिर यह शांत नहीं होता है। सबसे पहले, आपको तत्काल मरम्मत करना होगा कि जल्दबाजी में रिलीज से क्या टूट गया, फिर जल्दबाजी से क्या टूट गया, फिर एक फिक्स है, आदि।

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

तुरंत परिणाम की अपेक्षा करें

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

वस्तुतः कोई भी नई कार्यप्रणाली तुरंत पूर्ण क्षमता पर काम करना शुरू नहीं करती है। अधिक संभावना है, इसके विपरीत, आमतौर पर उपयोग करने और चलने की कुछ अवधि होती है, जब पिछले तरीकों की तुलना में कार्य क्षमता घट जाती है (कभी-कभी महत्वपूर्ण रूप से!)। और केवल वे जो इस अवधि को पार करने में सक्षम थे, वे डरते नहीं थे और रास्ते के बीच में नहीं रुकते थे, अंत में उन्हें वांछित प्रभाव मिलेगा।

मत बदलो

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

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

निष्कर्ष

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