चुस्त लचीली विकास पद्धति क्या है? एजाइल क्या है: कार्यप्रणाली, टीम, प्रदर्शन मूल्यांकन। कठोर संरचना के बिना एक उपकरण-स्वतंत्र सॉफ़्टवेयर विकास पद्धति जिसमें ऐसी प्रथाएँ शामिल हैं

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

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

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

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

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

एजाइल मेनिफेस्टो का इतिहास

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

• अनुकूली सॉफ्टवेयर विकास (एएसडी)
• शीशे की तरह साफ
• डायनेमिक सिस्टम डेवलपमेंट मेथड (डीएसडीएम)
• एक्सट्रीम प्रोग्रामिंग (एक्सपी)
• फ़ीचर संचालित विकास (FDD)
• व्यावहारिक प्रोग्रामिंग
• जमघट

दरअसल, ये त्वरित विकास पद्धतियां घोषणापत्र जारी होने से पहले भी मौजूद थीं। घोषणापत्र के जारी होने से लचीली पद्धतियों के विकास को एक नई गति मिली, नींव रखी गई, कोई कह सकता है कि सॉफ्टवेयर विकास के लिए एक लचीले दृष्टिकोण का संविधान।

एजाइल सॉफ्टवेयर विकास घोषणापत्र:

चुस्त तरीकों का मुख्य मीट्रिक कार्य उत्पाद है। प्रत्यक्ष संचार को प्राथमिकता देकर, चुस्त तरीके अन्य तरीकों की तुलना में लिखित दस्तावेज़ की मात्रा को कम कर देते हैं।
इससे इन तरीकों की अनुशासनहीन आलोचना होने लगी है।

हम लगातार बेहतर सॉफ्टवेयर विकास तकनीकों की खोज कर रहे हैं, खुद ऐसा कर रहे हैं और दूसरों को भी ऐसा करने में मदद कर रहे हैं। किए गए कार्य के लिए धन्यवाद, हम यह महसूस करने में सक्षम हुए कि:

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

अर्थात्, दाईं ओर जो है उसके महत्व को नकारे बिना, हम अभी भी बाईं ओर जो है उसे अधिक महत्व देते हैं।

घोषणापत्र के लेखक:

केंट बेक, माइक बीडल, एरी वैन बेनेकुम, एलिस्टेयर कॉकबर्न, वार्ड कनिंघम, मार्टिन फाउलर, जेम्स ग्रेनिंग, जिम हाईस्मिथ, एंड्रयू हंट, रॉन जेफ़्रीज़, जॉन केर्न, ब्रायन मैरिक, रॉबर्ट सी. मार्टिन, स्टीव मेलर, केन श्वाबर, जेफ सदरलैंड डेव थॉमस

एजाइल मेनिफेस्टो के संस्थापक सिद्धांत:

हम इन सिद्धांतों का पालन करते हैं:

1. हमारी सर्वोच्च प्राथमिकता मूल्यवान सॉफ़्टवेयर की नियमित और शीघ्र डिलीवरी के माध्यम से ग्राहकों की संतुष्टि है।
2. आवश्यकताओं में बदलाव का स्वागत है, भले ही विकास में देरी हो। चुस्त प्रक्रियाएं ग्राहक को प्रतिस्पर्धात्मक लाभ प्रदान करने के लिए परिवर्तन का उपयोग करने में सक्षम बनाती हैं।
3. एक कार्यशील उत्पाद को जितनी बार संभव हो जारी किया जाना चाहिए, कुछ हफ़्ते से लेकर कुछ महीनों तक।
4. डेवलपर्स और व्यवसाय प्रतिनिधियों को पूरे प्रोजेक्ट के दौरान प्रतिदिन एक साथ काम करना होगा।
5. प्रेरित पेशेवरों को परियोजना पर काम करना चाहिए। काम पूरा करने के लिए परिस्थितियाँ बनाएँ, सहायता प्रदान करें और उन पर पूरा भरोसा करें।
6. टीम के साथ और टीम के भीतर सूचनाओं के आदान-प्रदान के लिए सीधा संचार सबसे व्यावहारिक और प्रभावी तरीका है।
7. एक कार्यशील उत्पाद प्रगति का मुख्य संकेतक है।
8. निवेशकों, डेवलपर्स और उपयोगकर्ताओं को अनिश्चित काल तक निरंतर लय बनाए रखने में सक्षम होना चाहिए। एजाइल ऐसी सतत विकास प्रक्रिया स्थापित करने में मदद करता है।
9. तकनीकी उत्कृष्टता और डिज़ाइन गुणवत्ता पर निरंतर ध्यान देने से परियोजना का लचीलापन बढ़ता है।
10. सादगी - अनावश्यक काम को कम करने की कला - आवश्यक है।
11. सर्वोत्तम आवश्यकताएं, वास्तुशिल्प और तकनीकी समाधान स्व-संगठित टीमों से आते हैं।
12. टीम को दक्षता में सुधार के संभावित तरीकों का व्यवस्थित रूप से विश्लेषण करना चाहिए और उसके अनुसार अपनी कार्यशैली को समायोजित करना चाहिए।

चंचल की आलोचना

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

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

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

हम कई सलाहकारों के माध्यम से रहे हैं और त्वरित बैठकों और बैठकों में अनगिनत घंटे बिताए हैं। इस अनुभव के आधार पर, हमें एहसास हुआ कि एजाइल केवल दिखावा है क्योंकि:

• महाकाव्य सिर्फ परियोजनाएं हैं
• उपयोगकर्ता कहानियाँ आसान हैं बक्सों का इस्तेमाल करें
• स्प्रिंट सिर्फ काम है
• स्टैंड-अप सिर्फ बैठकें हैं
• पुनरावृत्तियाँ केवल संस्करण हैं
• बैकलॉग केवल एक कार्य सूची है
• टीम वेग (वेग) केवल परिणाम है
• और ये कार्य वास्तविक, न्यायपूर्ण कार्य हैं

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

तीव्र विकास पद्धतियों के प्रकार

एजाइल मेनिफेस्टो में परिभाषित मूल्यों और सिद्धांतों के आधार पर, निम्नलिखित लचीली विकास पद्धतियों का गठन किया गया:

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

एजाइल मेथडोलॉजी एक ऐसा शब्द है जो आजकल हर किसी की जुबान पर है, लेकिन इसके पीछे क्या है? क्या यह परियोजना प्रबंधन के लिए रामबाण है या यह पुरानी पद्धतियों का प्रतिस्थापन है? क्या यह आईटी के अलावा कहीं और भी लागू है? इन सवालों के जवाब इस लेख में हैं.

एजाइल क्या है?

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

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

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

छोटे समूहों (जो सजातीय रचनात्मक कार्य करते हैं) के काम को व्यवस्थित करने के लिए चुस्त तरीके प्रभावी माने जाते हैं।

डाउनलोड करें और उपयोग करें:

11. सर्वोत्तम आवश्यकताएं, वास्तुशिल्प और तकनीकी समाधान स्व-संगठित टीमों से आते हैं। यह घोषणापत्र के लेखकों और हस्ताक्षरकर्ताओं की राय है, इसलिए, सभी लचीले तरीकों के ढांचे के भीतर, आवश्यकताओं और समाधानों का विकास टीम स्तर पर सौंपा गया है। प्रभावी स्व-संगठन प्राप्त करने से लक्ष्यों पर सामान्य हित और सहमति की उपस्थिति और इन लक्ष्यों को एक साथ प्राप्त करने में तालमेल की अनुमति मिलती है।

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

चंचल स्क्रम

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

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

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

अगले स्प्रिंट के लिए विकसित किए जा रहे उत्पाद की नई कार्यक्षमता योजना चरण में निर्धारित की जाती है, जिसके बाद यह स्प्रिंट बैकलॉग बनाता है, जो इसकी पूरी अवधि के दौरान नहीं बदलता है।

कार्यप्रणाली परियोजना में भूमिकाओं की संरचना भी प्रदान करती है:

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

फाइनेंसरों को एजाइल की आवश्यकता क्यों है?

फाइनेंसरों के लिए एगिल्व ​​परियोजना प्रबंधन पद्धति के मुख्य लाभ:

• परियोजना प्रलेखन के दीर्घकालिक विकास पर पैसे बचाने की संभावना;
• बजट पर उच्च स्तर का नियंत्रण (

आधुनिक प्रबंधन में, "लचीले" प्रबंधन मॉडल को तीन अलग-अलग संदर्भों में माना जाता है, जो (प्रत्येक अपने तरीके से) परिभाषित करता है कि एजाइल क्या है।

एजाइल के अर्थ के तीन खंड

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

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

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

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

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

चुस्त प्रबंधन के सिद्धांत

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

1. उत्पाद को अनुकूलित करने के लिए उपभोक्ता और परिणाम तैयार करने में उसकी भागीदारी की डिग्री महत्वपूर्ण है।
2. निर्णय लेने के लिए टीमों को अत्यधिक प्रभावी और एकजुट होना चाहिए।
3. चरण-दर-चरण और चक्रीय कार्य प्रक्रिया का आधार बन जाता है। परियोजना को छोटे-छोटे भागों में विभाजित किया गया है जिन्हें परियोजना के समग्र रूप से पूरा होने से पहले एक निश्चित तिथि तक पूरा किया जाता है।
4. प्रदर्शन मूल्यांकन का ध्यान मध्यवर्ती परियोजना राज्यों की लगातार प्रस्तुतियों पर है।
5. अपने काम में, टीम पेरेटो कानून पर भरोसा करती है, जिसके अनुसार 20% प्रयास 80% दक्षता देते हैं, जिससे उपभोक्ता को परिणाम प्रस्तुत करने से पहले प्रत्येक व्यक्तिगत चक्र को पूर्णता में नहीं लाना संभव हो जाता है। प्रत्येक नए पुनरावृत्ति के साथ उत्पाद में स्वाभाविक रूप से सुधार होता है।
6. यह अपेक्षा की जाती है कि अगले चरण पर जाने से पहले एक चरण पूरा किया जाना चाहिए।

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

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

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

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

एजाइल को लागू करने में विशिष्ट गलतियाँ और दृष्टिकोण के नुकसान

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

सामान्य कार्यान्वयन त्रुटियों में निम्नलिखित शामिल हैं:

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

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

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

परियोजनाओं का महाविस्फोट

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

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

स्क्रम के निर्माता जेफ सदरलैंड के अनुसार, यह 1980 के दशक के अंत में सीपीएसयू केंद्रीय समिति के पोलित ब्यूरो के व्यवहार की याद दिलाता है, जिसने कथित तौर पर सोवियत संघ के पतन की पूर्व संध्या पर प्राप्त रिपोर्टों पर विश्वास किया था।

चंचल तरीकों को उनके लचीलेपन के कारण इससे निपटने के लिए डिज़ाइन किया गया है। हम कह सकते हैं कि एजाइल कई दृष्टिकोणों का मिश्रण है, जिसे सिद्धांतों के एक सेट का उपयोग करके सभी प्रकार के जोखिमों को कम करने के लिए डिज़ाइन किया गया है। ये समान सिद्धांत और 4 मुख्य विचार 2001 के एजाइल मेनिफेस्टो में एकत्र किए गए हैं।

चंचल घोषणापत्र

यदि हम उन विचारों को "क्रिस्टलीकृत" करने के लिए भाषा को सरल बनाते हैं जो सक्रिय रूप से काम करने वाले प्रत्येक व्यक्ति का मार्गदर्शन करते हैं, तो हमें कुछ इस तरह मिलता है:

• सबसे महत्वपूर्ण चीज़ लोग हैं, चीज़ें नहीं
• दस्तावेज़ीकरण (जिसे अभी तक कोई नहीं पढ़ता) किसी के काम में हस्तक्षेप नहीं करना चाहिए
• अनुबंध को दोबारा पढ़ने के बजाय सहयोग करें
• जियो, सांस लो, बदलो - जितनी जल्दी हो सके

प्रक्रियाएं कैसे काम करती हैं

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

1. उत्पाद स्वामी का चयन करें- यह वह व्यक्ति है जो देखता है कि आप किस लक्ष्य की ओर जा रहे हैं और अंत में आप क्या प्राप्त करना चाहते हैं।

2. एक टीम तय करें- कौशल वाले 3 से 10 लोग जो आपको परिणाम प्राप्त करने की अनुमति देंगे (यानी, एक व्यावहारिक उत्पाद)।

3. स्क्रम मास्टर का चयन करें- यह व्यक्ति परियोजना की प्रगति की निगरानी करता है और टीम को कठिनाइयों से निपटने में मदद करता है।

4. एक उत्पाद बैकलॉग बनाएं- उत्पाद के लिए सभी आवश्यकताओं को एक स्थान पर (अधिमानतः एजाइल बोर्ड पर) एकत्र करें और प्राथमिकता दें। उत्पाद स्वामी को सभी इच्छाओं पर विचार करना चाहिए और एकत्र करना चाहिए। फिर टीम को यह देखने के लिए बैकलॉग का मूल्यांकन करना चाहिए कि क्या यह सब किया जा सकता है और इसमें कितना समय लगेगा।

यांडेक्स में एक फुर्तीला बोर्ड इस तरह दिखता है -।

5. अपने स्प्रिंट की योजना बनाएं- समय की अवधि (एक या दो सप्ताह) जिसके दौरान टीम कार्यों का एक निश्चित सेट पूरा करती है। स्प्रिंट नियमित होंगे: उदाहरण के लिए, तैयार उत्पाद प्राप्त होने तक दो सप्ताह तक 15 बार।

6. प्रतिदिन 15 मिनट के लिए बैठकें आयोजित करें (और एक मिनट भी अधिक नहीं)- एजेंडे में तीन प्रश्न हैं, जिनका हर कोई संक्षेप में उत्तर देता है: मैंने कल क्या किया, मैं आज क्या करूंगा, और कौन सी बाधाएं मुझे "ऊंचाइयां छूने" से रोकती हैं।

7. समीक्षा करें- स्प्रिंट के अंत में, टीम बताती है कि वे क्या करने में कामयाब रहे और उत्पाद के कामकाजी हिस्सों का प्रदर्शन करते हैं। समीक्षाओं में कोई भी भाग ले सकता है: उत्पाद स्वामी, मुख्य ग्राहक, या संभावित ग्राहक भी।

8. पूर्वव्यापी आचरण करें- प्रत्येक स्प्रिंट के बाद, एजाइल टीम समस्याओं पर चर्चा करती है और समाधान ढूंढती है। एक परिवर्तन योजना होनी चाहिए जिसे टीम तुरंत लागू करेगी - अगले स्प्रिंट पर।

स्क्रम को कैसे लागू करें और टीम की दक्षता कैसे बढ़ाएं, इस बारे में अधिक जानकारी के लिए इस लेख को पढ़ें।

स्क्रम एक टीम वर्क पद्धति से कहीं अधिक है। स्क्रम सभी मानवीय प्रयासों की गति को तेज करता है। इससे कोई फर्क नहीं पड़ता कि परियोजना या समस्या क्या है, स्क्रम का उपयोग उत्पादकता बढ़ाने और बेहतर परिणाम प्राप्त करने के किसी भी प्रयास में किया जा सकता है।

चपलता को दृष्टि से जानें

चुस्त तरीकों को "सिग्नल फ़्लैग" जैसी प्रमुख विशेषताओं द्वारा आसानी से पहचाना जा सकता है।

1. जोखिम को कम करना किसी भी त्वरित दृष्टिकोण का मुख्य लक्ष्य है।
2. पुनरावृत्तीय विकास - छोटे चक्रों में कार्य करना।
3. लोग और संचार सबसे महत्वपूर्ण हैं.

यदि आप एजाइल को नदी के दोनों किनारों से देखते हैं - ग्राहक और टीम - तो यह दृष्टिकोण सभी के लिए समझ में आता है।

• ग्राहक को समय पर कम से कम एक न्यूनतम कार्यात्मक उत्पाद प्राप्त करने की आवश्यकता है (इससे कोई फर्क नहीं पड़ता कि हम सॉफ्टवेयर या अन्य प्रक्रियाओं और घटनाओं के बारे में बात कर रहे हैं), उसकी जेब में डोनट छेद छोड़े बिना स्थितियों को बदलें - यह पहले से ही है जोखिम बीमा का प्रश्न.

• टीम को ग्राहक और सहकर्मियों के साथ संचार से लाभ होता है (ताकि इसके बिना: "आपने मुझे गलत समझा - सब कुछ जल्दी से फिर से करें। और हाँ, कल इसकी आवश्यकता थी!"), प्रक्रियाओं की पारदर्शिता, जो आश्चर्य की संभावना को कम करती है, और त्वरित समाधान समस्याओं का. वैसे बहुत से लोग समझते हैं कि समय कहां चला जाता है और काम कहां अटक जाता है। यह एक छोटी सी चीज़ है (वास्तव में नहीं), लेकिन यह अच्छी है।

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

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

कौन इसे पसंद नहीं करेगा?

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

यह सभी आज के लिए है। अगली बार हम स्क्रम ऑफ़ स्क्रम्स के बारे में बात करेंगे और रूसी वास्तविकता में लचीली पद्धतियाँ कैसे काम करती हैं। स्विच मत करो.

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

• अनुवाद

"कोई भी व्यवसाय हमेशा अपेक्षा से अधिक समय लेता है, भले ही हम हॉफ़स्टैटर के नियम को ध्यान में रखें।"
- हॉफस्टैटर का नियम

फुर्तीले विषय पर यूट्यूब पर सबसे ज्यादा देखा जाने वाला वीडियो। इस लेख के प्रकाशन के समय 744,625 बार देखा गया। आसान प्रस्तुति शैली, चित्र और केवल 15 मिनट - मैंने अब तक देखा सबसे अच्छा। TED अवकाश ले रहा है.

भूमिकाएँ

यह पैट है उत्पाद स्वामी. वह तकनीकी विवरण नहीं जानती है, लेकिन उसके पास बड़ी तस्वीर का एक दृष्टिकोण है, वह जानती है किस लिएहम एक उत्पाद बना रहे हैं, यह किन समस्याओं का समाधान करेगा और किसके लिए।

यह इच्छुक लोग. वे उत्पाद का उपयोग करेंगे, उसका समर्थन करेंगे, या अन्यथा विकास में शामिल होंगे।

यह प्रयोक्ता कहानियां. वे इच्छुक पार्टियों की इच्छाओं को व्यक्त करते हैं। उदाहरण के लिए, "एयरलाइन बुकिंग प्रणाली में, उपयोगकर्ता को उड़ान द्वारा खोज करने में सक्षम होना चाहिए।"

हितधारकों के पास बहुत सारे विचार हैं, और पैट विचारों को उपयोगकर्ता कहानियों में बदलने में मदद करता है।

यह विकास दल. जो करेंगे निर्माणकार्य प्रणाली.

बैंडविड्थ

चूँकि कमांड का उपयोग होता है लचीली विकास पद्धति, वे इन सभी कहानियों को बड़ी रिलीज़ तक जमा नहीं करते हैं, इसके विपरीत, वे उन्हें तुरंत और जितनी बार संभव हो रिलीज़ करते हैं। वे आम तौर पर प्रति सप्ताह 4-6 उपयोगकर्ता कहानियाँ जारी करते हैं। यह उनका है THROUGHPUT. इसे मापना बहुत आसान है - 7 दिनों में उपयोगकर्ता कहानियों की संख्या।

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

समस्या यह है कि इसमें बहुत सारी इच्छुक पार्टियाँ हैं और उनके अनुरोधों को प्रति सप्ताह 4-6 कहानियों से संतुष्ट नहीं किया जा सकता है।

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

यदि हम वह सब कुछ करें जो वे हमसे करने को कहते हैं तो क्या होगा? हम पर काम का बोझ बढ़ जाएगा.

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

इस मामले में स्क्रम और एक्सपी "कल का मौसम" पद्धति का उपयोग करते हैं। टीम का कहना है: "हाल ही में हम प्रति सप्ताह 4-6 फीचर कर रहे हैं, अगले सप्ताह हम कौन से 4-6 फीचर करेंगे?"

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

कानबन खुद को कुछ कार्यों तक सीमित रखने की सलाह देते हैं - डब्ल्यूआईपी सीमा। मान लीजिए कि टीम ने निर्णय लिया है कि 5 उपयोगकर्ता कहानियों की एक स्वीकार्य संख्या है, जिस पर वे बिना किसी अतिभार के, एक से दूसरे पर कूदे बिना एक साथ काम कर सकते हैं।

ये दोनों दृष्टिकोण अच्छी तरह से काम करते हैं और ये दोनों कार्यों की एक कतार बनाते हैं, जिसे स्क्रम में बैकलॉग या कार्यों की प्राथमिकता वाली सूची कहा जाता है।

इस कतार को भी प्रबंधित करने की आवश्यकता है। यदि हितधारक प्रति सप्ताह 10 कहानियों का अनुरोध करते हैं, और टीम 4-6 कहानियों को लागू करती है, तो यह कतार और बड़ी हो जाएगी। और जल्द ही आपका बैकलॉग छह महीने पहले ही निर्धारित कर दिया जाएगा। यानी एक कहानी को रिलीज होने के लिए 6 महीने का इंतजार करना होगा।

अपनी कार्य सूची को नियंत्रण में रखने का केवल एक ही तरीका है - "नहीं" शब्द

किसी उत्पाद स्वामी के लिए यह सबसे महत्वपूर्ण शब्द है. उसे प्रतिदिन दर्पण के सामने इसका अभ्यास करना चाहिए।

"हाँ" कहना आसान है. लेकिन इससे भी महत्वपूर्ण कार्य है तय करें कि क्या नहीं करना हैऔर इसके लिए ज़िम्मेदारी उठाएँ. उत्पाद स्वामी यह क्रम भी निर्धारित करता है कि हम अभी क्या करेंगे और बाद में क्या करेंगे। यह जटिल कार्य है और इसे विकास टीम और कम से कम एक हितधारक के साथ मिलकर किया जाना चाहिए।

सही ढंग से प्राथमिकता देने के लिए, उत्पाद स्वामी को प्रत्येक कहानी के मूल्य और उसके दायरे को समझना चाहिए।

निर्णय लेना

कुछ कहानियाँ बिल्कुल आवश्यक हैं, और कुछ केवल बोनस सुविधाएँ हैं। कुछ कहानियों को विकसित होने में कुछ घंटे लगेंगे, जबकि अन्य को विकसित होने में महीनों लगेंगे।

कहानी के आकार और मूल्य के बीच क्या संबंध है? बिलकुल नहीं।अधिक का मतलब बेहतर नहीं है. किसी कार्य का मूल्य और जटिलता ही पैट को प्राथमिकता देने में मदद करती है।

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

हर बार जब डेवलपर्स कुछ नया जारी करते हैं, तो हम अधिक जानकारी सीखते हैं और बेहतर तरीके से नेविगेट कर सकते हैं।

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

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

आईटी उत्पाद के मालिक को लगातार सभी के साथ संवाद करना चाहिए

अनुभवी उत्पाद मालिक सफलता के दो घटकों की पहचान करते हैं: काम के प्रति जुनून और संचार। उत्पाद स्वामी टीम के साथ मिलकर किन समस्याओं का समाधान करता है?

विकास की जटिलता और उपयोगकर्ता कहानी मूल्य को संतुलित करना

प्रारंभिक चरण में, बैलेंस शीट को अनिश्चितता और एक साथ कई जोखिमों का खतरा होता है।

जोखिम

व्यावसायिक जोखिम: "क्या हम सही काम कर रहे हैं?"

सामाजिक जोखिम: "क्या हम वह कर सकते हैं जो हमें करने की आवश्यकता है?"

तकनीकी जोखिम: "क्या परियोजना इस प्लेटफ़ॉर्म पर काम करेगी?"

लागत और कार्यान्वयन समय के साथ जोखिम: "क्या हम इसे समय पर बनाएंगे और क्या पर्याप्त पैसा होगा?"

ज्ञान को जोखिम के विपरीत माना जा सकता है। जब अनिश्चितता अधिक होती है, तो हम ज्ञान प्राप्त करने पर ध्यान केंद्रित करते हैं - इंटरफ़ेस प्रोटोटाइप, तकनीकी प्रयोग,

ज्ञान मूल्यों और ग्राहक मूल्यों के बीच व्यापार-बंद

ग्राहक के दृष्टिकोण से, वक्र इस प्रकार दिखता है:

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

अल्पकालिक और दीर्घकालिक सोच के बीच समझौता

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

सही काम करें, काम सही तरीके से करें, या काम जल्दी करें?

आदर्श रूप से, तीनों एक ही समय में, लेकिन वास्तव में आपको चुनना होगा।

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

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

हम यहां रिकॉर्ड समय में एक सुंदर मंदिर बना रहे हैं। लेकिन उपयोगकर्ता को मंदिर की आवश्यकता नहीं थी, उसे एक कैंपेरवन की आवश्यकता थी।

स्क्रम में भूमिकाओं के बीच एक स्वस्थ तनाव है

उत्पाद स्वामी सही चीज़ों के निर्माण पर ध्यान केंद्रित करता है। टीम चीज़ों को सही ढंग से बनाने पर ध्यान केंद्रित करती है। स्क्रम मास्टर या एजाइल कोच फीडबैक लूप को छोटा करने पर ध्यान केंद्रित करता है।

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

एक नया उत्पाद विकसित करने और पुराने उत्पाद को सुधारने के बीच समझौता

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

कहानी विनाश कार्यक्रम

समय-समय पर, हितधारक पैट से पूछेंगे, "मेरी सुविधा कब जारी होगी?" या "क्रिसमस तक कितनी सुविधाएँ जारी की जाएंगी?" उत्पाद स्वामी को उपयोगकर्ता की अपेक्षाओं को प्रबंधित करने में सक्षम होना चाहिए। और अपेक्षाओं को यथार्थवादी ढंग से प्रबंधित करें।

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

मान लीजिए कि कोई इच्छुक पक्ष पूछता है कि यह सुविधा कब बनाई जाएगी?

यह एक निश्चित सामग्री और अनिश्चित अवधि वाला प्रश्न है। उत्तर देने के लिए पैट दो ट्रेंड लाइनों का उपयोग करता है। इसका जवाब अप्रैल या मई में है.

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

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

आमतौर पर समय बढ़ाने की तुलना में किसी प्रोजेक्ट की सामग्री को कम करना बेहतर होता है। यदि हम सामग्री कम करते हैं, तो हमारे पास समय सीमा को आगे बढ़ाने का अवसर होगा। हम कुछ को यहां और बाकी को बाद में जारी कर सकते हैं।

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