सॉफ्टवेयर विकास (या शायद किसी भी नौकरी में) में मुख्य समस्या क्या है? जब मैंने अपने सहयोगियों से एक प्रश्न पूछा, तो मुझे अलग-अलग उत्तर मिले: आवश्यकताओं में बदलाव, उम्मीदें बेमेल होना, कोड की गुणवत्ता, अन्य टीमों के साथ बातचीत ... खुद के लिए संक्षेपण - संचार सबसे महत्वपूर्ण समस्याओं में से एक है।
संचार के दौरान, हर कोई अपने तरीके से सब कुछ समझता है, जो कहा गया था, उससे अलग तरीके से व्याख्या करता है। ग्राहक अपने सिर में एक निश्चित छवि रखता है जिसे वह शब्दों और चित्रों में बदलने की कोशिश कर रहा है, डेवलपर, इन शब्दों को सुनकर, उन्हें अपने सिर में अपनी खुद की छवि में परिवर्तित करता है। और इस श्रृंखला में कई लिंक हो सकते हैं।
इस समस्या को हल करने के लिए, लोग एक विस्तृत TOR लिखते हैं। लेकिन क्या इससे समस्या हल हो जाती है? वही सवाल, जैसा कि मैं इसे देखता हूं, बॉब मार्टिन और मार्टिन फाउलर ने अपने सहयोगियों से एक साथ पूछा था जब उन्होंने फरवरी 2001 में एजाइल मैनिफेस्ट लिखा था। आइए इस मुद्दे पर एक साथ यह पता लगाने की कोशिश करते हैं, और फुर्तीली में ही प्रकट होता है।
कहानी
2000 की सर्दियों में तथाकथित चरम प्रोग्रामिंग के नेताओं की एक बैठक हुई, उन्होंने विकास के तरीकों पर चर्चा की और परिणामस्वरूप कुछ लाइट पद्धति की पेशकश करने लगे। कुछ लोगों को दिलचस्पी थी (मैं किसी को नाराज नहीं करना चाहता), सबसे अधिक संभावना है कि उन्होंने इस विषय पर अधिक चुटकुले बनाए। हालांकि, उस बैठक के कई बाहरी लोगों ने एक साल बाद अपना आयोजन किया। यह सब इस तथ्य से शुरू हुआ कि बॉब मार्टिन (उन्होंने कोड की गुणवत्ता के बारे में प्रसिद्ध पुस्तक लिखी), पिछली बैठक के नेताओं के लिए एक समाचार पत्र बनाया - चलो एक साथ मिलें और बात करें। वास्तव में कुछ भी ठोस नहीं है। कुछ समय के लिए वे जगह और समय के बारे में परेशान थे। नतीजतन, वे 11 फरवरी, 2001 को यूटा में एक स्की रिसॉर्ट में एकत्र हुए। विकास क्षेत्र के 17 लोग, जिनमें बॉब मार्टिन, मार्टिन फाउलर और अन्य शामिल हैं। वे पी गए, फाउलर स्कीइंग कर गए, और चर्चा के बाद,
एजाइल मैनिफेस्ट अस्तित्व में आया।
सिद्धांत रूप में, सभी सबसे महत्वपूर्ण पाठ के एक पृष्ठ द्वारा शाब्दिक रूप से व्यक्त किया जा सकता है, जिसे
यहां पढ़ा जा सकता
है ।
लेकिन छोटी और सावधानीपूर्वक सोची गई हर चीज की तरह, इसे पढ़ने के लिए बस इसे समझना मेरे लिए व्यक्तिगत रूप से आसान नहीं था। इसलिए, आइए विस्तार से विचार करें कि जिन लोगों ने एजाइल मेनिफ़ेस्ट पर हस्ताक्षर किए थे, उनके मन में क्या था।
फुर्तीला सिद्धांत
यह है कि क्या सही है के महत्व को नकारे बिना,
फिर भी, हम बाईं ओर अधिक मूल्य रखते हैं।
यह एक बहुत ही महत्वपूर्ण पहलू है जिसे हमेशा एक घोषणापत्र पढ़ते समय ध्यान में रखना चाहिए, और वास्तव में हर दिन काम करना चाहिए। आइए मुख्य प्रकट बयानों पर चर्चा करें।
लोग और इंटरैक्शन प्रक्रियाओं और उपकरणों से अधिक महत्वपूर्ण हैं
पहली नज़र में, यह सभी जीरा परियोजनाओं, बग ट्रैकर्स, टाइम लॉगर और अन्य टूल और सभी कॉन्फ़िगर की गई प्रक्रियाओं को दूर करने के लिए एक कॉल की तरह लग सकता है। सहकर्मियों के साथ मौखिक रूप से चर्चा करना आसान हो सकता है कि कोई क्या कर रहा है। अगर केवल हर कोई खुश था। लेकिन यह थोड़ा यूटोपियन लगता है, है ना?
यह सिद्धांत बताता है कि किसी भी चीज की विकास प्रक्रिया का निर्माण करते समय, यह याद रखना महत्वपूर्ण है कि यह क्यों, किसके लिए और किस उद्देश्य से किया गया है। यह प्रक्रिया की खातिर एक प्रक्रिया बनाने के लिए बहुत कम समझ में आता है। क्योंकि काम अंततः लोगों द्वारा किया जाएगा, आप और मैं। क्या होगा अगर सभी चिंगारी, हमारी आँखों में सभी ब्याज को युट्रेक में काम से बदल दिया जाता है या जीर में कीड़े हो जाते हैं? यह एक अच्छी तरह से आयोजित प्रक्रिया के लिए बेकार है जो ग्राहक के सामने पूरी सुरक्षा प्रदान करता है, लेकिन वास्तविक विकास समस्याओं को हल नहीं करता है। नौकरशाही (औपचारिक) विवरण आसानी से एक परियोजना पर लोगों के नुकसान का कारण बन सकता है। मुझे लगता है कि वही योजना बनाने के लिए जाता है। आपने पिछली बार कब योजना बनाई थी, जो अंत में कम से कम 60-70 प्रतिशत सटीक रही?
मेरी राय में, इस सिद्धांत का सिद्धांत इस तरह लग सकता है:
लोगों के लिए प्रक्रियाएं, प्रक्रियाओं के लिए लोग नहीं
घोषणापत्र यह कैसे बताता है कि हम इस सिद्धांत को लागू करने के करीब हैं?
- प्रेरित पेशेवरों को परियोजना पर काम करना चाहिए।
- प्रत्यक्ष संचार सबसे व्यावहारिक और प्रभावी है।
- सबसे अच्छी आवश्यकताएं और वास्तु समाधान स्वयं-व्यवस्थित टीमों से आते हैं।
- टीम को लगातार अपने काम का विश्लेषण करना चाहिए और प्रक्रिया का अनुकूलन करना चाहिए।
टीम सामान्य रूप से क्या विकसित करती है? ग्राहक के लिए उत्पाद।
एक कार्यशील उत्पाद व्यापक प्रलेखन से अधिक महत्वपूर्ण है
अगर व्याख्या की जाती है, तो माथे पर, मुझे लगता है कि कई लोग सहमत होंगे। लेकिन आप यहां और क्या देखते हैं? व्यक्तिगत रूप से, मैं यहां देखता हूं कि एक उत्पाद जो काम करता है, और
समय पर काम करता है, पूरी तरह से लिखे गए कोड की तुलना में अधिक महत्वपूर्ण है। ये कई अर्थों में क्रूर और डरावने शब्द हैं, इसलिए मुझे ऐसा नहीं कहना चाहिए। लेकिन मेरे सभी करियर I, अलग-अलग लोगों से सीखते हुए, विचार के अधिक से अधिक आश्वस्त हो गए - अगर मैं एक परियोजना के बीच चयन करता हूं जो कोड और वास्तुकला के मामले में आदर्श है, और एक परियोजना जो अंदर बहुत सुंदर नहीं है, लेकिन जो दुनिया को फायदा पहुंचाती है, मैं दूसरा चुनूंगा। और हां, मैं इसे अपनी क्षमता और क्षमता के हिसाब से बेहतर करूंगा।
और यहां आपको एक पल के लिए सोचना चाहिए। लेकिन इन समस्याओं को कम आम बनाने के लिए क्या किया जा सकता है? ताकि हमें एक मॉड्यूल को फिर से भरने और एक नई सुविधा विकसित करने के बीच चयन न करना पड़े?
- एक काम करने वाले उत्पाद को जितनी बार संभव हो उतनी बार जारी करना चाहिए।
- एक कार्यशील उत्पाद प्रगति का एक महत्वपूर्ण संकेतक है।
- तकनीकी उत्कृष्टता और गुणवत्ता पर निरंतर ध्यान परियोजना के लचीलेपन को बढ़ाता है।
- सरलता और न्यूनता आवश्यक है।
तकनीकी उत्कृष्टता के बिंदु पर ध्यान दें। कोड को अच्छे (आवश्यक) और पर्याप्त गुणवत्ता में बनाए रखना, हम आवश्यकताओं में परिवर्तन को सहन करना आसान बनाते हैं और तदनुसार, कोड में परिवर्तन करते हैं।
सभी सिद्धांत, मैं आपको याद दिलाता हूं, नकारात्मक नहीं हैं। एक दूसरे को बाहर नहीं करता है। यह प्राथमिकता के बारे में है। सब कुछ महत्वपूर्ण है - उत्पाद, कोड की गुणवत्ता और प्रलेखन। लेकिन क्या चुनना है, कब चुनना है? गुणवत्ता और उत्पाद के बीच एक निश्चित संतुलन में काम करना, उत्पाद को प्राथमिकता में डालना आसान है, बिना गुणवत्ता को नकारे।
अपने जीवन से एक उदाहरण के रूप में, मैं एक रूसी ग्राहक के लिए एक बैंकिंग परियोजना पर काम को याद करता हूं। यह काम विश्लेषकों की भागीदारी के साथ किया गया था और सख्ती से वॉल्यूमेट्रिक टीके पर। हर छह महीने में एक बार, प्रबंधक ग्राहक के मुख्य कार्यालय गया और काम के परिणाम दिखाए। यह अनुमान लगाना आसान है कि, एक नियम के रूप में, परिणाम ग्राहक की अपेक्षाओं से काफी अलग थे। ग्राहक का लेखाकार, जिसने पहली बार नई प्रणाली को देखा था, और आम तौर पर जानता था कि इसे बनाया जा रहा है, वह बहुत ही डरावनी स्थिति में था - नई प्रणाली में उसकी सामान्य कार्य प्रक्रिया जैसा कुछ भी नहीं था। जो हमें अगले विषय पर लाता है।
अनुबंध की शर्तों पर बातचीत करने की तुलना में ग्राहक के साथ सहयोग अधिक महत्वपूर्ण है
आपको इस कथन से बहुत सावधान रहना चाहिए। और फिर, याद रखें कि बयान के सही पक्ष से इनकार नहीं किया गया है। इसके विपरीत, हम कहते हैं कि अनुबंध महत्वपूर्ण है। बस जब हम अनुबंध और सहयोग, सही दीर्घकालिक साझेदारी की शर्तों को तौलते हैं, तो संबंध अधिक महत्वपूर्ण होगा। दूसरे को नकारे बिना। मैं इस ओर ध्यान आकर्षित करता हूं क्योंकि हम वास्तविक दुनिया में रहते हैं और कभी-कभी हमें बहुत अलग ग्राहकों के साथ काम करना पड़ता है। ऐसे मामले हैं जब ग्राहक अपने स्वयं के स्वार्थी उद्देश्यों के लिए भोलेपन का लाभ उठा सकता है और अनुबंध की कीमत पर, उन स्थितियों को हरा सकता है जो डेवलपर्स के लिए अस्वीकार्य हैं।
फिर भी, अगर हम
एक शून्य में एक निश्चित अमूर्त अच्छे ग्राहक के बारे में बात करते हैं, तो एक दीर्घकालिक संबंध बनाए रखना जो नई परियोजनाओं को जन्म देगा, अधिक महत्वपूर्ण है।
पूरे प्रोजेक्ट में उम्मीदों के साथ समझ और अनुपालन कैसे हासिल करें?
- परियोजना के दौरान, कस्टम व्यवसाय के डेवलपर्स और प्रतिनिधियों को रोजाना एक साथ काम करना चाहिए।
- प्रत्यक्ष संचार सबसे व्यावहारिक और प्रभावी है।
उसी समय, किसी को निश्चित रूप से अपनी सुरक्षा के लिए समझौतों की पुष्टि करने के बारे में नहीं भूलना चाहिए। वैसे (सौभाग्य से शायद ही कभी) ग्राहक हैं जो आम तौर पर समझौतों के बाद भुगतान करने से इनकार करते हैं।
जो भी ग्राहक, डेवलपर की गतिविधि हमेशा उपयोगी होती है।
मैं यह भी कहना चाहूंगा कि यह दोनों तरह से काम करना चाहिए।
यह हमें एक तार्किक निरंतरता की ओर ले जाता है - कार्य और योजनाओं में परिवर्तन। यदि आप इसके बारे में सोचते हैं, तो कुछ लोग परिवर्तन करना पसंद करते हैं, यह मनुष्य के स्वभाव में है। कोई भी प्रणाली संतुलन और अपरिवर्तनीयता के एक निश्चित बिंदु के लिए प्रयास करती है। लेकिन यह विकास है जो हमेशा आंदोलन और परिवर्तन से जुड़ा होता है।
मूल योजना का पालन करने की तुलना में परिवर्तन के लिए तैयारी अधिक महत्वपूर्ण है।
इस तरह की योजना के अस्तित्व को नकारा नहीं जाता है। इसके विपरीत, योजना महत्वपूर्ण है। लेकिन इसे बदलने के लिए तैयार होना और भी महत्वपूर्ण है, अगर किसी समय हमें पता चला है कि यह योजना वर्तमान परिवेश में काम नहीं करती है।
मेरे सहयोगियों के अभ्यास से एक उदाहरण सीआईएस देशों में से एक के कर निरीक्षण के लिए एक परियोजना है। राज्य परियोजना, संक्षेप में, टीके, विधान, किसी भी चुस्त के बारे में कोई बात नहीं थी। लेकिन टीम को उस समय लचीलापन दिखाना पड़ा जब ग्राहक के देश में राज्य ने अपना कर कानून बदल दिया ताकि यह परियोजना उस रूप में बिल्कुल भी समझ में न आए जिस रूप में यह योजना बनाई गई थी। मुझे तकनीकी विशिष्टताओं को बदलना पड़ा और लगभग पूरी हो चुकी परियोजना को फिर से तैयार करना पड़ा ताकि ग्राहक इसका उपयोग कर सकें। अन्यथा, काम का कोई मतलब नहीं होगा, ठीक है, सिवाय शायद कमाई के लिए जैसे।
शायद यह सबसे अधिक खुलासा करने वाला उदाहरण नहीं है, क्योंकि बाहरी कारकों द्वारा परिवर्तनों को उकसाया गया था। और दूसरी तरफ, ग्राहक बाहरी कारकों के कारण फिर से, बस बदलती आवश्यकताओं की आवश्यकता पर आ सकता है। अन्यथा, उसे प्रतिस्पर्धात्मक लाभ नहीं मिलेगा।
यह सब मेरे लिए थोड़ा दर्दनाक विषय है। लेकिन क्या होगा अगर हम एक पूरे साल के लिए एक परियोजना कर रहे हैं, और फिर एक साल बाद ग्राहक कहता है - ठीक है, आप महान हैं, और अब हम यह सब संग्रह में डालेंगे, हम इसका उपयोग नहीं करेंगे और हम एक नई परियोजना शुरू करेंगे। मैं इसके बजाय दर्दनाक हूं, मुझे एक समान अनुभव था। लेकिन वास्तव में - क्या हुआ? किए गए कार्य ने ग्राहक को यह समझने में मदद की कि चुना हुआ मार्ग गलत है। या अप्रभावी। एक प्रतिस्पर्धात्मक लाभ प्राप्त करने के लिए, आपको अलग से काम करने की जरूरत है, एक अन्य परियोजना करें। और उसने हमारी सहायता से यह ज्ञान प्राप्त किया।
हमारे काम के किन पहलुओं से इन कोनों को सुचारू बनाने और लचीलेपन को कम करने में मदद मिलेगी?
- नियमित और जल्दी सॉफ्टवेयर वितरण।
- बाद के चरणों में भी परिवर्तन का स्वागत है।
- परिवर्तन ग्राहक को प्रतिस्पर्धा में बढ़त प्रदान करने में मदद करते हैं।
उसी समय, हम वास्तविक दुनिया में रहते हैं, वास्तविक लोगों के साथ, जहां कोई भी निर्णय, इस सहित, को पूर्ण रूप से नहीं उठाया जाना चाहिए। हां, परिवर्तनों का स्वागत है जब वे अंतिम उत्पाद में अतिरिक्त मूल्य का नेतृत्व करते हैं। लेकिन संतुलन बनाए रखना जरूरी है। यदि हम अंतहीन बदलाव करते हैं, तो हम उत्पादन में कभी कोई उत्पाद जारी नहीं करेंगे। इसलिए, कुछ बिंदु पर आपको कहना चाहिए - बंद करो, हम उत्पाद जारी करते हैं, व्यवहार में सब कुछ जांचते हैं, और संस्करण दो बनाना शुरू करते हैं, जिसमें कई बदलाव होंगे। हर बार ग्राहक के साथ स्पष्ट करना - वह इस या उस परिवर्तन में क्या मूल्य देखता है।
मैंने हाल ही में फेसबुक पर वाक्यांश पढ़ा,
यदि आपको अपने उत्पाद पर शर्म नहीं आती है, तो आपने बहुत देर से बाजार में प्रवेश किया
काफी सही ऊपर के सार को दर्शाता है। हमें संतुलन के एक निश्चित बिंदु की तलाश करने की आवश्यकता है, जिसमें परिवर्तन के संदर्भ में उत्पाद अगली रिलीज के लिए पर्याप्त रूप से तैयार हो जाएगा, और जिसमें हमने अभी तक मामूली बदलावों पर बहुत अधिक प्रयास करने के लिए शुरू नहीं किया है।
इसके बजाय संक्षेप में
एजाइल घोषणापत्र के निर्माता किसी भी नियम को नहीं लिखते हैं, और इसके विपरीत भी। लेकिन वे हमारे काम में महत्वपूर्ण मुद्दों को उठाते हैं - लोगों, डेवलपर्स और ग्राहकों की बातचीत, परिवर्तन के लिए तत्परता। ये सिद्धांत प्रकृति में महत्वपूर्ण हैं। प्रलेखन, अनुबंध, प्रक्रियाओं और नियोजन, मानव सहभागिता, मूल्यवान परिवर्तनों के लिए तत्परता और दुनिया के लिए उपयोगी कुछ लाने के निर्विवाद महत्व के साथ सभी अधिक महत्वपूर्ण हैं।