Scrum और SAFe के संदर्भ में Cumulative Flow के उपयोग का अभ्यास

इस लेख में मैं यह बताने की योजना बना रहा हूँ कि अपने अभ्यास में हम SAFe फ्रेमवर्क के अनुसार काम करने की प्रक्रिया में Scrum में Cumulative Flow Chart का उपयोग कैसे करते हैं SAFe

मैं शायद ऐसे लेख के लिंक से शुरू करूँगा - यहाँ, मेरी राय में, इसका मानक रूप में उद्देश्य अच्छी तरह वर्णित है, मेरा लेख पढ़ने से पहले इसे अध्ययन करने की सलाह देता हूँ। नीचे मैं बताऊँगा कि हमने इसे Scrum-प्रक्रिया के लिए कैसे अनुकूलित किया (मूल रूप से यह Kanban में उपयोग होता है) और स्प्रिंट में काम करते समय यह हमें किन समस्याओं को हल करने में मदद करता है।

पहले, Burn Down Charts के बारे में लेख में मैंने पहले ही कहा था कि वहाँ हम नए काम के आने और पुराने के जलने को देखते हैं। Burn Down Chart की समस्या यह है कि, Cumulative Flow Chart के विपरीत, उस पर हम उपयोगकर्ता कहानियों की स्थितियों के अनुसार गति नहीं देखते। जब हम Cumulative Flow Chart में स्थितियों के अनुसार गति देखना शुरू करते हैं, तो हम दैनिक परिवर्तन देखना शुरू करते हैं (Burn Down Chart कई दिनों तक नहीं बदल सकता और कुछ संदर्भों में यह पूरी तरह सामान्य हो सकता है) और हम अधिक सूक्ष्म समस्याओं को नोटिस कर सकते हैं।

यह गतिशीलता में कैसा दिख सकता है (छवि में वास्तविक डेटा पर बनाया गया आरेख है)।

इस उदाहरण में हम निम्नलिखित देखते हैं

• स्प्रिंट के पहले 7 दिनों में परीक्षण में बहुत कम मात्रा में काम है और यह नहीं बदलता
• DOR (यहाँ यह ड्राफ्ट है) से काम में उपयोगकर्ता कहानियाँ काफी समान रूप से जाती हैं - यह अच्छा है।
• Burn Down की तरह ही, हम देखते हैं कि प्रवृत्ति के अनुसार उपयोगकर्ता कहानियाँ स्प्रिंट के अंत तक पूरी नहीं होंगी

ये 3 अवलोकन मिलकर निम्नलिखित निष्कर्ष पर ले जाते हैं। यहाँ स्पष्ट रूप से अभी भी प्रारंभिक चरणों में (लगभग स्प्रिंट के दूसरे-तीसरे दिन) Scrum Master को "परीक्षण" परत पर ध्यान देना चाहिए था, जो बहुत छोटी है और काफी लंबे समय तक नहीं बदलती (कारण सुनिश्चित करें)। यह माना जा सकता है कि परीक्षण के लिए तैयार काम की मात्रा किसी कारण से परीक्षण नहीं की जा सकती, लेकिन तब इसका मतलब है कि परीक्षक खाली बैठे हैं, और इसका मतलब है कि कम से कम निकटतम स्टैंडअप में उन्हें अधिक ध्यान से सुनना चाहिए।

यदि उपयोग के अभ्यास की बात करें, तो उदाहरण के लिए, मैं प्रतिदिन टीम चैट में स्टैंडअप से पहले सभी मेट्रिक्स प्रकाशित करता हूँ और पूरी टीम का उल्लेख करता हूँ।

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