यह सब के बारे में चुस्त है 1: लोकप्रिय एजेंडा मिथकों

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

Agile एक फुर्तीली विकास दर्शन है जिसकी नींव Agile Software Development Manifesto में वर्णित है। अवधारणा चार मुख्य मूल्यों पर आधारित है:

• लोग और बातचीत प्रक्रियाओं और उपकरणों से अधिक महत्वपूर्ण हैं;
• एक कार्यशील उत्पाद व्यापक प्रलेखन से अधिक महत्वपूर्ण है;
• अनुबंध की शर्तों पर समझौते की तुलना में ग्राहक के साथ सहयोग अधिक महत्वपूर्ण है;
• मूल योजना का पालन करने की तुलना में बदलाव के लिए तत्परता अधिक महत्वपूर्ण है।

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

एजाइल में लोकप्रियता के साथ-साथ इसकी औपचारिक व्याख्या हुई। हम मिथकों और रूढ़ियों का विश्लेषण करेंगे जो हमें एक लचीली दृष्टिकोण का सार देखने से रोकते हैं और इससे अधिक प्राप्त करते हैं।

मिथक 1. चंचलता केवल आईटी है

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

मिथक 2. फुर्तीली - निश्चित बजट परियोजनाओं के लिए नहीं

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

मिथक 3. चंचल - व्यापार और विकास के लिए एक रामबाण: लागू करें, कुछ सुधार करें

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

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



चंचल हानिकारक होगा जहां उत्पाद की "प्रसंस्करण" या "परिशोधन" की लागत बहुत अधिक है, या यहां तक ​​कि बलिदान भी शामिल हो सकता है। कहते हैं, एक परमाणु ऊर्जा संयंत्र के निर्माण के दौरान, यह स्पष्ट है कि हम पुनरावृत्त-वृद्धिशील रूप से निर्माण नहीं कर सकते हैं, जैसा कि एजाइल हमें निर्देशित करता है।

मिथक 4. स्क्रम, लीन, कानबन को अन्तर्निहित नहीं करते हैं।

तरीकों और उपकरणों को अलग किया जाना चाहिए। कार्यप्रणाली वर्कफ़्लो के निर्माण के लिए एक एल्गोरिथ्म है। उपकरण वे "ईंटें" हैं जिनका उपयोग इस एल्गोरिथम में किया जाता है।

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

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

मिथक 5. घोटाला - किसी उत्पाद को जल्दी और सस्ते में कैसे बनाया जाए।

"तेज़" के लिए, सब कुछ सच है, लेकिन "सस्ते" के लिए - नहीं। खुद के लिए न्यायाधीश: आपको एक पूर्ण टीम बनाने की आवश्यकता है, इसमें आवश्यक दक्षताओं को उजागर करना 100% है। ये लोग केवल उन्हें सौंपे गए उत्पाद के विकास पर कब्जा कर लेंगे और कुछ नहीं, जिसका अर्थ है कि उन्हें या तो ऐसे विशेषज्ञों को नियुक्त करना होगा या उन्हें किसी विभाग से "आंसू" देना होगा। व्यवसाय के भाग पर भी यही बात लागू होती है: यदि आप चाहें, यदि आप नहीं चाहते हैं, तो आपको उत्पाद स्वामी को आवंटित करना होगा, जो अपना 50-80% समय केवल इस टीम और इसके उत्पाद को समर्पित करेगा।

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


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

मिथक 6. कंबन एक बोर्ड है, जिस पर टास्क पोस्ट किए जाते हैं।

बिलकुल नहीं! बोर्ड्स कानबन में पहला, सबसे आसान कदम है। लेकिन मामला सिर्फ यहीं तक सीमित नहीं है । Kanban के केंद्र में सांख्यिकीय डेटा पर आधारित एक जटिल गणितीय उपकरण है। इसलिए, बोर्ड के साथ कंबन की बराबरी करने का मतलब है कि इसके पहलू से परे न दिखना।

संक्षेप में, कंबन का मुख्य बिंदु यह है:

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

मिथक 7. स्क्रम और कानबन को किसी भी परियोजना और कंपनियों में लगाया जा सकता है।

मुझे "रोपण" शब्द पसंद नहीं है, सब के बाद, फुर्तीली लोगों के साथ काम करने के बारे में है। टीम में सोच का एक नया दर्शन "टपकाना" के बारे में बात करना अधिक सही होगा।

इसी समय, स्क्रम और कानबन ग्राफ्टिंग एल्गोरिथ्म अलग-अलग हैं।

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

स्क्रम के कार्यान्वयन में आम तौर पर संगठन की संरचना में और ठेकेदारों के साथ अनुबंध में (आपको समय और सामग्री अनुबंध की आवश्यकता होती है) और बजट (चरणबद्ध बजट), और बाकी सब में बड़े बदलाव की आवश्यकता होती है।



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

मिथक 8. स्क्रैम केवल उन परियोजनाओं के लिए डिज़ाइन किया गया है जो स्क्रैच से बने हैं।

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

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

मिथक 9. लचीली कार्यप्रणाली का परिचय देते समय, पारंपरिक पदानुक्रम के प्रतिनिधियों के साथ टकराव अपरिहार्य है

यदि सब कुछ सही ढंग से किया जाता है - टीम को पारंपरिक पदानुक्रम से अलग करने के लिए, उत्पाद मालिक को बजट दें और वास्तव में कुशल स्करम-मास्टर को किराए पर लें, तो कोई संघर्ष नहीं होगा। लेकिन हमेशा ऐसा नहीं होता है। इन दोनों संरचनाओं को जोड़ना अक्सर असंभव होता है, इसलिए केवल एक ही रास्ता है: एक नई संरचना बनाने के लिए, त्वरित निर्णय लेने और उत्पाद कार्यान्वयन के लिए तेज।

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

युपीडी। और यहाँ एक निरंतरता है: यह सब फुर्तीली के बारे में है - 2: फुर्तीली विकास को लागू करने की विशेषताएं

समझाने का कोई समय नहीं है, सामग्री निर्बाध और प्यार से Mail.Ru क्लाउड सॉल्यूशंस टीम द्वारा तैयार की गई थी।