चंचल विश्लेषण। मिथक और वास्तविकता

मैं परिचय देता हूं

बूथ ले जाया जाना चाहिए! कोई भी मौसम नहीं है, ताकि कुछ लोग शंदर न करें।
अब टॉयलेट को लेकर असमंजस में है, तो बीच के केबिन से ...
(x / f राष्ट्रीय मछली पकड़ने की विशेषताएं)

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

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

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

II सॉफ्टवेयर उत्पाद विकास तकनीकों के उद्भव की पृष्ठभूमि

इतिहास एक मांस के पेस्ट की तरह है: यह पका हुआ नहीं है कि यह कैसे पकाया जाता है।
एल्डस हक्सले

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

1. झरने के बारे में मिथक और वास्तविकता

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

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

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

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

2. क्या नहीं अगर झरना?

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

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

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

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

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

आगे के विश्लेषण और तुलना के साथ, यह ध्यान दिया जा सकता है कि आरयूपी की कुछ प्रमुख विशेषताएं आंशिक रूप से वाटरफॉल तकनीक से विरासत में मिली हैं।

1. सॉफ्टवेयर उत्पादन के लिए चक्रीय दृष्टिकोण । आरयूपी परियोजना का जीवन चक्र 4 चरणों और 9 कार्य प्रक्रियाओं में विभाजित है।
2. Iterative विकास की प्रक्रिया । आरयूपी परियोजना में 2 से 6 सप्ताह की अनुशंसित अवधि के साथ पुनरावृत्तियों का क्रम होता है।
3. आवश्यकताओं का अनिवार्य विकास । आरयूपी आवश्यकताओं का वर्णन करने के लिए उपयोग मामलों का उपयोग करता है या मामलों का उपयोग करता है। प्रत्येक उपयोग का मामला सिस्टम के साथ उपयोगकर्ता इंटरैक्शन के परिदृश्य का वर्णन है जो पूरी तरह से एक विशिष्ट उपयोगकर्ता कार्य करता है।
4. एक वृद्धिशील दृष्टिकोण का उद्देश्य उत्पाद की कार्यक्षमता में वृद्धि करना है। पुनरावृत्ति नियोजन की मुख्य इकाई उपयोग मामला है, जो आपको परियोजना के दौरान आवश्यकताओं, डिजाइन निर्णयों और कार्यान्वयन के लिए आवश्यक परिवर्तन करने की अनुमति देता है।

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

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

3. नींव को उखाड़ फेंकना

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

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

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

इस पर, ऐतिहासिक भ्रमण पूरा किया जा सकता है और शरीर के करीब बोलने के लिए इसे स्थानांतरित किया जा सकता है ...

III लचीली कार्यप्रणाली की घटना का विश्लेषण

प्रत्येक इकाई को आपके मुंह में चिपकाने से पहले तर्क के संदर्भ में विश्लेषण किया जाना चाहिए।
वुडी एलन।

1. लचीली पद्धतियों की परिभाषा

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

चुस्त शब्द से सबसे पहले जो खोज इंजन में पाया गया था:

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

निम्नलिखित महत्वपूर्ण बिंदुओं को इस परिभाषा से अलग किया जा सकता है:

1. Iterative दृष्टिकोण का उपयोग करना । यहां कुछ भी नया नहीं है, मैंने सॉफ्टवेयर विकास के तरीकों के बारे में नहीं सुना है जो इस सिद्धांत से इनकार करते हैं;
2. आवश्यकताओं का गठन उत्पाद विकास के दौरान, चरणों में किया जाता है । यह कई अन्य तकनीकों से एक महत्वपूर्ण अंतर है। कुछ मायनों में यह एक फायदा देता है, कुछ मायनों में यह मौलिक सीमाओं का परिचय देता है। हम बाद में दोनों पर चर्चा करेंगे;
3. ग्राहक सहित सभी टीम के सदस्यों की निरंतर करीबी बातचीत का उपयोग करना । अधिकांश अन्य तरीके, ज़ाहिर है, ग्राहकों के साथ टीमवर्क पर ध्यान देते हैं, लेकिन इस संचार को एक अतिरिक्त परियोजना संसाधन के रूप में स्थान देते हैं जो एक पूर्ण लाभ देता है और अधिक अनन्य है;
4. स्वयं सेवी टीम । यह माना जाता है कि प्रत्येक पुनरावृत्ति एक डीब्रीफिंग और प्रक्रिया में एक रचनात्मक परिवर्तन के साथ समाप्त होती है, जो टीम के निरंतर विकास में योगदान करती है। इसी तरह की तकनीकों को पहले की तकनीकों से सबसे अधिक उधार लिया जाता है। उदाहरण के लिए, यह RUP का अभ्यास करता है।

सिद्धांत रूप में, हमने इस विवरण में से बहुत कुछ खोजने का प्रबंधन नहीं किया है, इसलिए हम स्पष्टीकरण पर चलते हैं:

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

लेकिन हम पहले से ही अच्छे पुराने आरयूपी में उसी दृष्टिकोण पर विचार कर रहे थे। यही है, यहां मौलिक रूप से नया कुछ भी नहीं है।

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

एजाइल में प्रथाओं को शामिल नहीं किया गया है, लेकिन उन मूल्यों और सिद्धांतों को परिभाषित करता है जो टीमों का मार्गदर्शन करते हैं। एजाइल विकास प्रक्रियाओं का एक परिवार है, सॉफ्टवेयर विकास के लिए एकमात्र दृष्टिकोण नहीं है, और एजाइल मैनिफेस्टो द्वारा परिभाषित किया गया है।

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

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

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

लेकिन चूँकि हम यहाँ निष्पक्ष घटना का निष्पक्ष विश्लेषण करने के लिए हैं, इसलिए हम अपना अध्ययन जारी रखेंगे। आइए मूल स्रोत पर चलते हैं - अजेल मेनिफेस्टो:

2. आइए Agile Manifesto के मुख्य विचारों का विश्लेषण करें

मुख्य विचार:

1. लोग और इंटरैक्शन प्रक्रियाओं और उपकरणों से अधिक महत्वपूर्ण हैं;
2. एक कार्य उत्पाद व्यापक प्रलेखन से अधिक महत्वपूर्ण है;
3. अनुबंध की शर्तों पर बातचीत करने की तुलना में ग्राहक के साथ सहयोग अधिक महत्वपूर्ण है;
4. मूल योजना का पालन करने की तुलना में परिवर्तन की इच्छा अधिक महत्वपूर्ण है।

चलो मरहम में एक मक्खी के साथ शुरू करते हैं। मेरे लिए व्यक्तिगत रूप से, सभी बिंदु विवादास्पद हैं। आइए क्रम में चलते हैं:

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

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

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

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

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

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

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

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

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

3. एजाइल मेनिफेस्टो के सिद्धांतों पर चर्चा करें

चूँकि हम विषय के बारे में एक खुला दिमाग बनाना चाहते हैं, आइए हम कम से कम उन सिद्धांतों पर ध्यान दें जो कि एजाइल मेनिफेस्टो बताते हैं:

• मूल्यवान सॉफ़्टवेयर की प्रारंभिक और निर्बाध आपूर्ति के कारण ग्राहकों की संतुष्टि;
• विकास के अंत में भी आवश्यकताओं में परिवर्तन का स्वागत (यह परिणामी उत्पाद की प्रतिस्पर्धात्मकता को बढ़ा सकता है);
• काम करने वाले सॉफ़्टवेयर की लगातार डिलीवरी (हर महीने या सप्ताह या अधिक बार);
• परियोजना के दौरान डेवलपर्स के साथ ग्राहक के करीब, दैनिक संचार;
• परियोजना को प्रेरित व्यक्तियों द्वारा किया जाता है जो आवश्यक कार्य स्थितियों, सहायता और विश्वास के साथ प्रदान किए जाते हैं;
• सूचना प्रसारित करने की अनुशंसित विधि एक व्यक्तिगत बातचीत (आमने सामने) है;
• चल रहा सॉफ्टवेयर प्रगति का सबसे अच्छा उपाय है;
• , ;
• ;
• — ;
• , ;
• . .

उपरोक्त में से अधिकांश अन्य तरीकों का खंडन नहीं करता है और यह बहुत ही उचित है।

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

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

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

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

IV चुस्त तरीके के आवेदन

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

यदि समीक्षा के दौरान इतने महत्वपूर्ण मूल्यांकन उत्पन्न हुए, तो यह सब कैसे काम करता है?
एजाइल की सफलता, जाहिरा तौर पर छोटी परियोजनाओं में तकनीक के उपयोग की प्रभावशीलता में योगदान देती है और उपरोक्त सभी वस्तुओं के उपयोग की समानता (समानता)।

1. फुर्तीली के उपयोग के लाभ

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

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

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

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

2. लघु परियोजनाएं - एजाइल के लिए एक आरामदायक वातावरण

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

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

यदि यह उत्पाद एक बार का है और इसे विकसित करने की योजना नहीं है, तो यह काफी पर्याप्त है।

3. मैं मध्यम आकार की परियोजनाओं में एजाइल का उपयोग कैसे कर सकता हूं

मध्यम आकार की परियोजनाओं में एजाइल का उपयोग करना भी बहुत प्रभावी हो सकता है।

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

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

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

4. बड़े एकीकरण परियोजनाओं में एजाइल का प्रभावी ढंग से उपयोग कैसे करें

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

एक ही योजना एक बड़े जटिल प्रणाली के छोटे सुधार या क्रमिक विकास के लिए लागू है, खासकर यदि आपको कुछ शोध कार्य करने की आवश्यकता है।

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

इस खंड में, यह एजाइल पर आधारित मौजूदा तरीकों का उल्लेख करने योग्य है, लेकिन बड़े पैमाने पर समस्याओं को हल करने की ओर गुरुत्वाकर्षण है।

एजाइल यूनिफाइड प्रोसेस (AUP) स्कॉट एंबलर द्वारा विकसित यूनिफाइड प्रोसेस (UP) का सरलीकृत संस्करण है। यह सॉफ्टवेयर डेवलपमेंट मेथोडोलॉजी लचीली कार्यप्रणाली और एकीकृत प्रक्रिया के तत्वों को जोड़ती है। विशेष रूप से, AUP में परीक्षण (TDD), लचीले मॉडलिंग (इंग्लिश एजाइल मॉडलिंग) और डेटाबेस रीफैक्टरिंग, लचीले परिवर्तन प्रबंधन का उपयोग करके विकास शामिल है।

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

5. चंचल का उपयोग कैसे न करें

एक समान रूप से महत्वपूर्ण खंड, शायद जिसके लिए पूरे विश्लेषण पर विचार किया गया था।

1. मेरे विरोधी रेटिंग में नेता वह स्थिति है जब वे एजाइल, या इसके कुछ सिद्धांतों का उपयोग करने की कोशिश करते हैं, न कि किसी विशेष लक्ष्य को प्राप्त करने के लिए जिसे वे सुनिश्चित करने की अनुमति देते हैं, लेकिन बस # संक्षिप्त। क्योंकि यह एक प्रवृत्ति है, यह सभी के होंठों पर है। उदाहरण के लिए, किसी ने आईटी पार्टी में सकारात्मक समीक्षा साझा की, थोड़ा अल्पकालिक और यहां तक ​​कि अभिमानी, लेकिन एक अफवाह थी, एक प्रवेश दिखाई दिया। और अब उन्होंने पहले से ही खुद को एजाइल के अनुयायी कहा है, वे बाकी के साथ संचार में महसूस करते हैं - एक निश्चित अभिजात वर्ग के क्लब से संबंधित। यह सब कार्यप्रणाली की स्पष्ट सादगी और इसकी सीमाओं की धुंधली रूपरेखा में योगदान देता है। इस सिद्धांत पर कार्यान्वयन विचारहीन और औपचारिक रूप से होता है। औपचारिकता को कम करने के लिए डिज़ाइन किए गए सिद्धांतों को लोग औपचारिक रूप से और अप्रत्याशित रूप से लागू करते हैं।
   
   उदाहरण के लिए, हाल के मामलों में से एक। एक कंपनी में, रेट्रोस्पेक्टिव्स का संचालन करते हुए, उन्हें टाइमलैड्स द्वारा मना किया गया था। यहाँ एक ऐसी चिप है। अप्रत्याशित रूप से। पहले सोचा: ठीक है, शायद वे सही हैं ताकि समस्याओं पर चर्चा करते समय टीम पर अधिकारियों का कोई दबाव न हो, आदि। लेकिन टिमिलिड्स नाराज हैं, वे एक नुकसान में हैं और यह पता लगाना चाहते हैं। मैंने मुझे समझाने की कोशिश की कि वे कहते हैं कि यह बेहतर हो सकता है, मुख्य बात यह है कि आपको एक इच्छा सूची मिलती है, जिसमें एक सूची बदलनी होगी, क्या सुधार करने की आवश्यकता है, आदि। और यहाँ एक भयानक रहस्य सामने आया था। और इन सभाओं के परिणामस्वरूप प्रक्रियाओं में सुधार के लिए कोई परिणाम और इच्छाएं नहीं होती हैं। सज्जनों IT_shniki, और फिर ऐसा पूर्वव्यापी क्यों? बस एक दूसरे की प्रशंसा करें और टीम भावना को बढ़ावा दें? ए, कहते हैं, और बी ने कहा। आखिरकार, कार्यप्रणाली की इस प्रक्रिया का मुख्य उद्देश्य यह है कि: "टीम को दक्षता में सुधार के लिए संभावित तरीकों का व्यवस्थित रूप से विश्लेषण करना चाहिए और तदनुसार अपने काम की शैली को समायोजित करना चाहिए।"
2. मेरी रैंकिंग में दूसरी स्थिति यह है जब टीम जटिल व्यवहार या तार्किक एल्गोरिदम के साथ परियोजनाओं में आवश्यकताओं को तैयार करने के लिए बचत करने का निर्णय लेती है। यही है, जब उपयोगकर्ता कहानी समस्या के हिमशैल का केवल एक छोटा सा टिप है, और इसका मुख्य भाग दिखाई नहीं देता है और कार्यान्वयन के लिए विस्तृत, गहन विश्लेषण और डिजाइन की आवश्यकता होती है। इससे क्या होता है?
   
   काम शुरू करने से पहले, न तो ग्राहक और न ही डेवलपर्स भी लगभग उस काम की मात्रा को समझते हैं जो उन्हें करने की आवश्यकता है। और तदनुसार: या तो ग्राहक भुगतान करेगा, भुगतान करेगा और भुगतान करेगा, हर बार वे उसे समझाएंगे कि सब कुछ अधिक कठिन हो गया है और अब काम अभी भी दिखाई नहीं दे रहा है और समाप्त हो रहा है। और आखिरकार, यह छोड़ने के लिए एक दया होगी और धीरे-धीरे कड़ी समझ से शुरू करना होगा कि यह "सुनहरा" उत्पाद कभी भी भुगतान नहीं करेगा। या तो डेवलपर्स, एक निश्चित राशि / समय के लिए काम पूरा करने के लिए सहमत हो गए हैं, ग्राहक द्वारा कल्पना से बाहर निकलने तक उत्पाद को अपने स्वयं के खर्च पर समाप्त और रीमेक करेंगे, या वह एक लचीली दृष्टिकोण के पीड़ितों पर दया करता है।
3. एक सम्मानजनक तीसरा स्थान उस स्थिति से लिया जाता है जब एक बड़ी बहुआयामी परियोजना में (और अचानक एक एकीकरण भी) टीम समाधान वास्तुकला पर काम करने से बचाने का फैसला करती है और लघु पुनरावृत्तियों में व्यक्तिगत उपयोगकर्ता कहानियों को लागू करना शुरू करती है। संभावना की एक उच्च डिग्री के साथ यह होगा कि 3-5 पुनरावृत्तियों के बाद, जब एक नया कार्यात्मक बनाने की कोशिश कर रहा है, तो यह पता चलता है कि आपको पूरे पिछले एक को फिर से करने की आवश्यकता है, क्योंकि मूल सिद्धांत जिन पर यह कार्यात्मक होना चाहिए था, उन पर ध्यान नहीं दिया गया। इससे भी बदतर, अगर 10 वीं पुनरावृत्ति के बाद यह पाया जाता है कि चयनित प्रौद्योगिकियां ग्राहक की सभी आवश्यकताओं को पूरा करने की अनुमति नहीं देती हैं और सभी को फिर से शुरू करना आवश्यक है। शायद कमांड बदलकर।
4. जिस स्थिति में एक तेज और अविश्वसनीय रूप से लचीला स्टार्टअप एक सुस्त बाजार खंड के खुले स्थानों में टूट रहा है, वह शीर्ष तीन में नहीं आया। एक स्टार्ट-अप, यह एक स्टार्टअप भी है, जिसमें इसकी कोई नींव, बंधन, संलग्नक और एक ही समय में स्थिरता और स्थिरता नहीं है। और सीधे शब्दों में कहें तो लगभग कोई दस्तावेज नहीं है, टीम सामंजस्यपूर्ण नहीं है और अक्सर बदलती रहती है। बाजार सचमुच टीम को फाड़ रहा है, स्टैक्ड क्षेत्र में अधिक से अधिक नए समाधानों की मांग कर रहा है, और बाद की सभी परियोजनाएं बस उनकी आंखों के सामने गिर रही हैं। सबसे अधिक बार, यह इस तथ्य से समझाया जाता है कि टीम को औद्योगिक सॉफ्टवेयर उत्पादन , वितरण के संगठन और उत्पाद समर्थन की प्रक्रियाओं की समझ नहीं है।

संक्षेप में देना

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

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