SAFe और Scrum के संदर्भ में Burn Down Charts के उपयोग का अभ्यास

इस लेख में मैं बताने की योजना बना रहा हूं कि अपने अभ्यास में हम SAFe पद्धति के अनुसार काम की प्रक्रिया में बर्न डाउन चार्ट (Burn Down Chart) का उपयोग कैसे करते हैं

मैं शायद सबसे दिलचस्प चीज़ से शुरू करूंगा। यानी इस बात से कि SAFe में इस चार्ट का उपयोग करने में SCRUM में इस चार्ट के उपयोग की तुलना में कोई विशिष्टता नहीं होनी चाहिए। या होनी चाहिए?

हमारे यहां SAFe में RTEजैसी भूमिका होने से अंतर है, SCRUM के विपरीत जहां यह नहीं होती। Burn Down Chart स्प्रिंट में काम की मात्रा को ट्रैक करने का एक उपकरण है और यह सबसे पहले SCRUM टीम के लिए आवश्यक है, बाहर के किसी के लिए नहीं, है ना?

इस प्रकार, फिर भी मैं इस बात पर आता हूं कि हम Burn Down Chart का उपयोग कैसे करते हैं, चाहे कुछ भी हो, और अभी भी SAFe फ्रेमवर्क के भीतर रहते हुए।

मैं Scrum Master की भूमिका में हूं और इस चार्ट को प्रतिदिन पूरी Dev Teamके लिए दिखाने का प्रयास करता हूं। जो साधन मैं उपयोग करता हूं वह है टीम चैट, "@" के माध्यम से पूरी टीम का उल्लेख, चार्ट की वर्तमान स्थिति का स्क्रीनशॉट। पूरी टीम का उल्लेख एक काफी सूक्ष्म उपकरण है और इसे यथासंभव कम उपयोग करना महत्वपूर्ण है (आखिरकार, हम, स्क्रम मास्टर्स, को टीम को आराम से और न्यूनतम संभव ध्यान भटकाव के साथ काम करने में मदद करनी चाहिए, है ना?)

परिणामस्वरूप टीम प्रतिदिन स्प्रिंट की वर्तमान स्थिति देखती है और निम्नलिखित घटनाओं को ट्रैक कर सकती है

• अनियोजित काम का प्रकट होना
• अपूर्ण स्थिति में कार्यों का लंबे समय तक अटका रहना
• जोखिमों का अत्यधिक आरक्षण
• यह समझना - कि काम सही गति से चल रहा है या नहीं

आगे मैं इनमें से प्रत्येक घटना को उजागर करने का प्रयास करूंगा और अपने अभ्यास से उदाहरण दूंगा।

अनियोजित काम का प्रकट होना

इस चार्ट पर बहुत अच्छी तरह से दिखाई देता है कि नया काम कैसे प्रकट होता है (दो सप्ताह के स्प्रिंट के दूसरे मंगलवार को)।

अभ्यास से उदाहरण: "एक डेवलपर, agile के सिद्धांतों को साझा करने वाली scrum-टीम के सदस्य के रूप में, Product के साथ सीधे बहुत अच्छी तरह से बातचीत करता है। Product उससे कहता है कि यह चीज़ जल्दी से कर देनी चाहिए, तुम खुद समझते हो, यहां जल्दी है और जोखिम न्यूनतम हैं।

डेवलपर बहुत अच्छा है, वह agile के बारे में और व्यावसायिक मूल्य की डिलीवरी के महत्व के बारे में सब कुछ जानता है, जाकर बोर्ड पर बैकलॉग से एक कहानी डालता है, टीम ने उसे 6 sp में आंका है।

टीम का बाकी हिस्सा (डेवलपर और Product के अलावा) यह सुबह के चार्ट अपडेट पर नोटिस करता है। स्टैंडअप पर टीम इस स्थिति के बारे में क्या करना है इसका निर्णय लेती है। सबसे संभावित रूप से, कहानी को स्प्रिंट से बाहर निकाल दिया जाता है, Product और डेवलपर को टीम यह समझा देती है कि ऐसा नहीं करना चाहिए, Product आवश्यकता होने पर इस कहानी को अगले स्प्रिंट में डाल सकता है।

बेशक, आदर्श रूप से टीम को चार्ट के बिना भी स्टैंडअप पर नए काम के प्रकट होने को नोटिस करना चाहिए। लेकिन चार्ट एक अच्छा संकेतक है जो पूरी टीम के लिए इस महत्वपूर्ण परिवर्तन को नोटिस न करने के जोखिमों को न्यूनतम कर देता है।

यहां यह समझना महत्वपूर्ण है कि परिदृश्य टीम के स्तर के आधार पर अलग-अलग तरीके से आगे बढ़ सकता था। शानदार टीमों में उत्पाद स्वामी शायद ऐसा नहीं करता, और अगर करता भी, तो इस तर्क से नहीं कि «इसे जल्दी से कर देना चाहिए», बल्कि इस तर्क से कि «मैं 55% संभावना का अनुमान लगाता हूं कि अगर इसे अभी किया जाए, तो अगले महीने हमारा लाभ 20% बढ़ सकता है» या किसी अन्य मापने योग्य मीट्रिक से।

अपूर्ण स्थिति में कार्यों का लंबे समय तक अटका रहना

यहाँ हम देखते हैं कि बहुत लंबे समय तक काम पूरा नहीं होता, यहाँ तक कि आंशिक रूप से भी नहीं। यह विभिन्न समस्याओं का संकेत दे सकता है, उनमें से कुछ मैं सूचीबद्ध करता हूँ

• कार्यों का खराब विभाजन

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

• गैर-इष्टतम रूप से तैयार किया गया DOD

  DOD (Definition of Done) - स्प्रिंट में User Story की तैयारी के मानदंडों का विवरण। कभी-कभी वे बिल्कुल नहीं होते या बहुत अमूर्त रूप से वर्णित होते हैं। यह वास्तव में एक समस्या हो सकती है, जिसे हल करने में निश्चित रूप से स्क्रम मास्टर को मदद करनी चाहिए

जोखिमों का अत्यधिक आरक्षण

इस मामले में हम ऐसी स्थिति देखते हैं जहाँ टीम ने जोखिमों को अधिक आरक्षित कर लिया है।

संभवतः, किसी कहानी का अधिक अनुमान लगाया गया था। संभवतः, यह अधिक प्रणालीगत समस्या है और स्प्रिंट की योजना बनाते समय काम की मात्रा बढ़ानी आवश्यक है। किसी भी स्थिति में, यह स्थिति सही नहीं है। आखिरकार, व्यवसाय ने योजना बनाई थी कि स्प्रिंट के कार्य ही लागू किए जाएंगे और ठीक स्प्रिंट के अंत तक। इस पर निर्भर करते हुए कि निर्भरताओं की योजना कैसे बनाई गई थी, यहाँ सबसे अधिक संभावना है कि अपेक्षाओं को समायोजित करने के लिए बैठकें आयोजित करनी होंगी।

मेरे अनुभव में ऐसा तब हुआ जब अनुमान के दौरान चर्चा किए गए समाधान से अधिक तेज़ समाधान मिल गया। पूरी टीम ने चर्चा की कि स्प्रिंट के अंत तक कौन सी कहानी बंद कर पाएंगे और रेट्रोस्पेक्टिव में सहमति बनी कि हम ग्रूमिंग के दौरान कोड देखने का प्रयास करेंगे। पता चला कि यह समझने के लिए कि समाधान बहुत सरल है, बस कोड में झांकना पर्याप्त था।

समझ - क्या काम सही गति से चल रहा है

यहाँ मैं Burn Down Chart को ग्राफ़िक रूप से दिखाने के असफल तरीकों पर ध्यान आकर्षित करना चाहूँगा

छवि के ऊपरी भाग में दो कारणों से सबसे सफल ग्राफ़िकल कार्यान्वयन का उदाहरण नहीं दिया गया है, जिन्हें मैं नीचे बताऊंगा।

• स्प्रिंट में नए SP का जुड़ना ध्यान देने योग्य नहीं है

  यहाँ, ऊपरी आरेख में, लगभग ध्यान देने योग्य नहीं है कि अनियोजित कार्य जोड़ा गया है। निचले में यह अधिक स्पष्ट है।

• काम के सापेक्ष शेष का गलत प्रदर्शन

  ऊपरी आरेख के अनुसार अभी 3 दिन और काम करना बाकी है। वास्तव में वे 2 हैं, छुट्टी के दिन, संभवतः, कोई आराम करने की योजना बना रहा है।

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