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