घोटाले पर प्रतिबंध

कस्टम विकास में, हमेशा कई विशेषताएं और अप्रत्याशित समस्याएं होती हैं। मैं Scrum और Kanban तकनीकों के संयोजन से व्यावहारिक अनुभव साझा करूंगा। मैं आपको बताता हूं कि हमने उनका उपयोग कैसे किया, उन्हें अनुकूलित किया, विशिष्ट लक्ष्यों को प्राप्त करने के लिए उन्हें अनुकूलित किया, इसकी आवश्यकता क्यों थी और इसके कारण क्या हुआ।

वर्तमान कार्य में, हम परंपरागत रूप से स्क्रैम का उपयोग करते हैं। उपकरणों का यह प्रभावी सेट हमेशा एक नई विशिष्ट परियोजना के आगमन तक सभी कठिनाइयों का सामना करता है:

स्रोत डेटा:
विशिष्ट विशेषताएं थीं:

• परियोजना को अपनाने के समय, यह दो साल से अधिक समय से विकास में था;
• कार्यक्षमता का एक प्रभावशाली हिस्सा लागू किया गया है;
• दोनों की बहुत मांग और प्रासंगिक समाधान विकसित नहीं किए गए हैं।

हमारी टीम को परियोजना के अंतिम चरण को पूरा करना था।

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

हालत:

1. योजना
नियोजन प्रक्रिया में (नियोजन पोकर, श्रम इनपुट एस, एम, एल, एक्स्ट्रा लार्ज, XXL के नक्शे और रिश्तेदार इकाइयों के साथ), इस तथ्य के बावजूद कि कार्यों पर विस्तार से काम किया गया था और गठित आवश्यकताओं ने कोई अतिरिक्त प्रश्न नहीं उठाया था, व्यावहारिक मूल्यांकन पारदर्शी से दूर हो गया। निम्नलिखित स्थितियों ने पहली समस्या बनाई:

समस्या नंबर 1 - योजना, जो तेजी से अपनी प्रासंगिकता खो रही है:

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

नियोजन तर्कसंगत नहीं है, क्योंकि विरासत में मिले कोड और सैकड़ों निर्भरता में छिपे "नुकसान" कोड के साथ काम करने के प्रारंभिक चरणों में नहीं देखे जा सकते हैं।

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

समस्या संख्या 2 - कई आवश्यक कार्य शेड्यूल नहीं किए गए हैं

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

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

समस्या संख्या 3 - पुनरावृत्ति के दौरान कार्य प्राथमिकताओं में परिवर्तन।

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

आपातकालीन स्थितियों की प्रचुरता अनिश्चित है, यह काम करना अधिक कठिन हो जाता है, उत्पादकता घट जाती है, इसके अलावा, पुनरावृत्तियों की सफलता का कोई भी पर्याप्त मूल्यांकन देना लगभग असंभव है। रेट्रोस्पेक्ट में, सवाल उठता है कि हम प्रक्रिया को कैसे व्यवस्थित करते हैं।

समाधान:

ऐसा करने के लिए, दो चुस्त तरीकों (स्क्रम और कानबन) को साधने के लिए, केवल आवश्यक रूप से लेने, विकास को कन्वेयर पर लाने का फैसला किया गया था।

उन्होंने कानबन कार्यप्रणाली द्वारा प्रस्तावित विकास प्रक्रिया को व्यवस्थित करने का तरीका अपनाया, और किए गए कार्यों के विश्लेषण की पारदर्शिता के लिए स्क्रैम से कई उपकरण छोड़े:

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

इस परियोजना में हमारे द्वारा उपयोग किए जाने वाले मुख्य उपकरण:

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

तदनुसार, परिवर्तनों ने कई तकनीकी मुद्दों को जन्म दिया: मुझे "परीक्षण", "हटाने के लिए तैयार", "प्रस्तुत", आदि की स्थिति की पारदर्शिता के लिए बगट्रैकर में स्थिति प्रणाली को संशोधित करना था, साथ ही साथ संस्करण नियंत्रण प्रणाली में कार्यों को बनाए रखने के नियमों को निर्धारित करना था। ।

परिणाम:

तकनीक ने पहले पुनरावृत्ति पर अपने परिणाम दिखाए:

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

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

निष्कर्ष:

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

लेखक: बोरिस सिरोवतिन - / परीक्षण इंजीनियर / सॉफ्टलाइन विकास विभाग