एगाइल के मिथक और किंवदंतियाँ - फिरौन से लेकर आज तक

“सब कुछ जहर है, सब कुछ दवा है; दोनों खुराक से निर्धारित होते हैं। ”
पेरासेलसस

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

सबसे पहले, आइए यह समझने की कोशिश करें कि सामान्य रूप से एजाइल रैपर में हमें वास्तव में नया क्या मिला और विशेष रूप से स्क्रैम।

प्राचीन मिस्र में स्क्रम

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

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

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

यानी मुझे लगता है कि सभी प्रबंधकों ने हर समय अपनी आंतरिक (अपने जोखिम और जोखिम पर) उत्पाद बनाने के लिए एक लचीली तकनीक का इस्तेमाल किया क्योंकि:

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

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

आजकल घोटाला

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

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

आईटी बाजार के खिलाड़ियों के लिए एजाइल फायदेमंद है, क्योंकि यह उन्हें अवसर प्रदान करता है:

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

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

अपने आप को एक ऐसे व्यक्ति के स्थान पर रखने का प्रयास करें जो अपने अपार्टमेंट की मरम्मत के लिए बिल्डरों की एक टीम को काम पर रखता है और टीम के नेता से मरम्मत की शर्तें और लागत प्राप्त करने की कोशिश करता है, और जवाब में वह सुनता है:

• हम रचनात्मक लोग हैं, इसलिए हम "जैसा चल रहा है" काम करेंगे, लेकिन आप टीम और सामग्रियों के हर घंटे काम करते हैं;
• हम एक सामान्य परियोजना और योजना नहीं करेंगे, हम इसे रास्ते में समझेंगे (यदि हम कुछ गलत करते हैं, तो हम इसे आपके द्वारा भुगतान किए गए समय और अतिरिक्त सामग्रियों के लिए फिर से करेंगे);
• हम हर दो सप्ताह में अपने काम के परिणाम दिखाएंगे और अपनी समस्याओं के बारे में बात करेंगे, और फिर हम अगले दो सप्ताह की योजना बनाएंगे।

यह संभावना नहीं है कि कोई भी इस तरह के प्रस्ताव से सहमत होगा, और आईटी-कर्मचारी के ग्राहक सहमत होंगे! यही जीवन देने वाला प्रचार करता है!

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

चंचल उपासना का परिणाम

क्या आपको नहीं लगता कि उद्योग में एजाइल के व्यापक वितरण के अनुपात में सॉफ्टवेयर उत्पादों की गुणवत्ता गिरती है? अगर सरलतम और सबसे तेज़ तरीके से समस्याओं को हल करके पूरी प्रक्रिया को तेज किया जाता है, तो गुणवत्ता कहाँ से आती है? और आगे की सोच आधिकारिक तौर पर कार्यप्रणाली से मना है!

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

यह सब क्या है?

उपरोक्त सभी से, ऐसा लग सकता है कि मैं एक उत्साही चुस्त है। लेकिन ऐसा बिल्कुल भी नहीं है! और मैंने किसी को नाराज करने की कोशिश नहीं की! उन्होंने एपिग्राफ में लगाए गए महान पैरासेल्सस के शब्दों को स्पष्ट रूप से स्पष्ट करने की कोशिश की।

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

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

जैसा कि आप देख सकते हैं, Agile का स्थान सूर्य में है, लेकिन यह अनुबंध IT- विकास के क्षेत्र में बहुत सीमित है। यदि आपका प्रोजेक्ट एजाइल-उपयुक्त की श्रेणी में नहीं आता है तो क्या करें?

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

पुनश्च

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