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