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