औसत स्प्रिंट की तुलना में 50% खराब से कैसे निपटें?


14

अगर मैं स्क्रैम को सही ढंग से समझता हूं, तो यह है कि मैं यह निर्धारित करता हूं कि मेरी टीम अगले स्प्रिंट में क्या काम कर सकती है:

  1. मैं पिछले कई स्प्रिंट के लिए पूर्ण किए गए अंकों की संख्या को औसत करता हूं।

  2. यह मात्रा हमारा औसत वेग है। आगे स्प्रिंट, हम उस कहानी के कई बिंदुओं को लेते हैं।

यह एक औसत है , इसलिए यदि इतिहास खुद को दोहराता है, तो यह स्प्रिंट 50% संभावना है कि हम बहुत कम कहानी अंक ले रहे हैं, और 50% संभावना है कि हम बहुत अधिक कहानी बिंदुओं पर ले रहे हैं।

50% मामले में हमने कई कहानी बिंदुओं पर लिया है:

  • स्प्रिंट को पूरा करने में विफल। इसका मतलब है कि हम आधे समय में अपनी स्प्रिंट प्रतिबद्धता को पूरा करने में विफल रहेंगे

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


क्या औसत वेग और स्प्रिंट प्रतिबद्धताओं की मेरी समझ सही है?

यदि हां, तो 50% स्प्रिंट के लिए हमें क्या करना चाहिए जहां हम औसत से पीछे हैं?

यदि नहीं, तो मैंने क्या गलत किया है?


10
सैद्धांतिक रूप से, सब कुछ का 50% औसत से नीचे होगा, परिभाषा के अनुसार। (खैर, "औसत" की परिभाषाओं में से एक, कम से कम।) यह उम्मीद की जानी है, और चिंता करने के लिए कुछ नहीं है। यदि आप औसत से बुरी तरह से नीचे हैं, तो यह केवल एक गंभीर समस्या है ।
मेसन व्हीलर

8
मैं @MasonWheeler से सहमत हूं। आपको औसत से कम औसत स्प्रिंट के लिए क्या करना चाहिए ... जीवन के साथ चलें। यह ऐसी समस्या नहीं है जिसे हल करने की आवश्यकता है। मुझे "स्प्रिंट में विफल" और "स्प्रिंट प्रतिबद्धता" जैसी शब्दावली बहुत पसंद नहीं है। स्प्रिंट प्रतिबद्धता यह है कि आप उतने ही काम करेंगे जितना आप जिम्मेदारी से कर सकते हैं । सिर्फ इसलिए कि आप अनुमानित अंकों का 100% पूरा नहीं करते हैं, इसका मतलब यह नहीं है कि आप "स्प्रिंट में विफल" हैं।
एरिक किंग

1
हां, @EricKing ने क्या कहा, विशेष रूप से प्रसिद्ध तथ्य के प्रकाश में जो लोग अनुमान लगाने पर चूसते हैं।
मेसन व्हीलर


1
@MasonWheeler: क्या औसत से 50% नीचे है, वास्तव में औसत की परिभाषा पर निर्भर नहीं करता है, लेकिन संभावना वितरण पर, विशेष रूप से यह हमेशा सच है जब वितरण सममित है। जिस चीज़ की परिभाषा से 50% नीचे है, उसे माध्यिका कहा जाता है।
माइकल बोर्गवर्ड

जवाबों:


12

क्या औसत वेग और स्प्रिंट प्रतिबद्धताओं की मेरी समझ सही है?

हाँ, आप इसे का सार है।

यदि नहीं, तो मैंने क्या गलत किया है?

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

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

इसलिए जब आप समय के 50% से अधिक का अनुमान लगाएंगे और 50% समय का अनुमान लगाएंगे, तो इसका मतलब यह नहीं है कि आप स्प्रिंट को विफल करने जा रहे हैं या ओवरटाइम काम करना है । इसका मतलब है कि आपके पास इस विविध कार्य को करने के लिए बहुत समय नहीं होगा (जब तक कि आप वास्तव में अपने अनुमानों को याद नहीं करते हैं)। लेकिन यह एक बड़ी बात नहीं है, क्योंकि विविध कार्य समय के प्रति संवेदनशील नहीं होते हैं, और चीजें लंबे समय में भी बाहर हो जाएंगी।


अगर मैं आपको सही तरीके से समझूं, तो क्या सभी कहानियों को केवल 50% समय समाप्त करना ठीक है?
पॉल ड्रेपर

@PaulDraper - नहीं, मैं कह रहा हूं कि आपको अपनी सभी कहानियों को 100% समय समाप्त करना चाहिए ... मुझे संपादित करने दें और देखें कि क्या मैं अधिक सहायक नहीं हो सकता हूं।
तेलस्तीन

1
@PaulDraper - मैं जो प्रमुख बात कह रहा हूं, वह यह है कि उन सभी कहानी बिंदुओं को पूरा करने में पूरे 10 दिन नहीं लगे । जब काम समाप्त होता है और स्प्रिंट समाप्त होता है, तो हमेशा एक बफर होता है। यह एक बफर है जो आपके काम को उम्मीद से अधिक समय तक समायोजित करेगा।
तेलस्तीन

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

3
AAAAGH! नहीं! "यदि आप इसे सही कर रहे हैं, तो परीक्षण करते समय आपके डेवलपर्स निष्क्रिय हो जाएंगे" गलत है! अब आप मिनी वाटरफॉल कर रहे हैं! उच्च प्रदर्शन करने वाली टीमों में, डेवलपर्स कहानियों को छोटे कार्यात्मक टुकड़ों में तोड़ते हैं जिन्हें 1-3 दिनों में पूरा किया जा सकता है। आप परीक्षण और अनुमोदन के लिए बहने वाले कार्यात्मक कोड को जल्द से जल्द चाहते हैं। "बेकार डेवलपर्स" के लिए कोई EXCUSE नहीं है। तो आपके पास 100% इष्टतम स्वचालित इकाई, एकीकरण, एएएटी, लोड / प्रदर्शन परीक्षण हैं? आपके पास स्वचालित बिल्ड, स्वचालित तैनाती, सही देव-ऑप्स और CICD मॉडल है? यदि नहीं, तो काम करने के लिए बहुत कुछ है!
कर्टिस ने

3

क्या औसत वेग और स्प्रिंट प्रतिबद्धताओं की मेरी समझ सही है?

दुर्भाग्य से, आपको स्क्रम में स्प्रिंट योजना के बारे में कुछ बातों के बारे में गलत जानकारी दी गई है। सबसे पहले, विकास टीम (डीटी) है

... अपने काम को व्यवस्थित और प्रबंधित करने के लिए संगठन द्वारा संरचित और सशक्त। - स्क्रम गाइड

इसके लिए शब्द आत्म-आयोजन है। इसमें कार्य का पूर्वानुमान लगाने का कार्य शामिल है जो किसी दिए गए स्प्रिंट में किया जाएगा। डीटी को यह नहीं बताया गया है कि यह प्रत्येक स्प्रिंट पर क्या काम करेगा, बल्कि इसे अपने काम को चुनने के लिए सशक्त बनाया गया है। DT को पूर्वानुमान बनाने के लिए ऐतिहासिक वेग, एक अच्छी तरह से परिष्कृत उत्पाद बैकलॉग और अगली स्प्रिंट की डीटी क्षमता जैसी जानकारी की आवश्यकता हो सकती है। अंततः, यह डीटी का दृढ़ संकल्प है जो स्प्रिंट में उनके पूर्वानुमान में प्रबल हो सकता है और पूरा नहीं किया जा सकता है; उन्हें यह नहीं बताया जाना चाहिए कि वे कितना काम करेंगे।

नोटिस, पूर्वानुमान और प्रतिबद्धता भी नहीं सी-शब्द को स्क्रम गाइड से हटा दिया गया था क्योंकि इसका उपयोग विकास टीम का दुरुपयोग करने के लिए किया जा रहा था। पूर्वानुमान पसंदीदा शब्द है।

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

इसके अलावा, एक स्प्रिंट केवल "रद्द" हो सकता है; यह कभी विफल नहीं हो सकता। स्प्रिंट तभी रद्द किया जाता है जब स्प्रिंट का लक्ष्य पूरी तरह से अप्रचलित और अप्रासंगिक हो जाता है। ऐसा बहुत कम ही होता है। यदि कोई पूर्वानुमान गलत है, तो आप बस शांत रहते हैं और स्क्रैम ऑन करते हैं। क्या आप पूर्वव्यापी हैं? अगले स्प्रिंट, आपके पूर्वानुमान बेहतर होंगे :)।


3

सबसे पहले, आपका वेग आपके पिछले स्प्रिंट से है, या कभी-कभी कुछ हाल के स्प्रिंट्स (कल का मौसम) के औसत से है, और पिछले सभी स्प्रिंटों का औसत नहीं है। बेशक, यदि आपके पास अपनी टीम या कंपनी से कोई ऐतिहासिक डेटा नहीं है, तो आपको अपने पहले स्प्रिंट के लिए उचित मूल्य के साथ आने की आवश्यकता है। अपने दूसरे स्प्रिंट पर, आप पूर्ण कहानी बिंदुओं को स्प्रिंट में लेते हैं। यदि आप इसे ग्राफ करने के लिए थे, तो आप पहले कुछ स्प्रिंट पर विविधता देख सकते हैं (उदाहरण के लिए, पहले स्प्रिंट में 17, दूसरे में 22, तीसरे में 26, चौथे में 24)। यह उम्मीद की जानी चाहिए कि आप अपनी टीमवर्क और अनुमान प्रक्रिया को सामान्य करेंगे, साथ ही परियोजना (प्रौद्योगिकी, डोमेन) की बेहतर समझ प्राप्त करेंगे।

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

जहां तक ​​क्या करना है, "स्प्रिंट को पूरा करने में विफल" से अलग है "हमने सभी कहानियों को पूरा नहीं किया"। मेरे लिए, एक स्प्रिंट की विफलता का मतलब है कि आपने अंत में एक संभावित shippable उत्पाद का उत्पादन नहीं किया है - आपकी कोई भी कहानी पूरी नहीं हुई है, आपके पास कोई बिल्ड नहीं है, आप ग्राहक या किसी भी अतिरिक्त मूल्य को प्रदर्शित नहीं कर सकते हैं उपयोगकर्ताओं।

आप जो भी करते हैं, आपको समय के साथ देर से या अत्यधिक काम नहीं करना चाहिए। इसे स्थायी गति ( एजाइल अलायंस , स्क्रैम अलायंस ) कहा जाता है ।

संकेतक हो सकते हैं कि समस्याएँ हैं:

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

1

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

सभी ने कहा, ऐसा लगता है कि आप अपने स्प्रिंट लक्ष्यों को पूरा नहीं कर रहे हैं, या जब आप एक गलत अनुमान लगाते हैं तो क्या होता है। मुझे लगता है कि इस प्रकार की चिंता और दृष्टिकोण आम है, लेकिन यह विशेष रूप से महत्वपूर्ण नहीं है। चंचल, सब से ऊपर, एक सॉफ्टवेयर विकास प्रणाली है जो कुछ चीजें करती है:

  1. डेवलपर्स को चालू रखता है
  2. पारदर्शिता बढ़ाता है
  3. प्रतिबिंब और क्रमिक प्रक्रिया में सुधार के लिए अनुमति देता है

दिन के अंत में, यदि आप किसी स्प्रिंट का गलत अनुमान लगाते हैं, या स्प्रिंट को विफल करते हैं, तो यह वास्तव में एक सौदे का बड़ा हिस्सा नहीं है। जो लोग आपकी कंपनी में आपकी टीम से ऊपर हैं, वे अधिक चिंतित हैं कि आपकी टीम लगातार आगे बढ़ रही है, और परियोजनाओं को उनके तार्किक पूर्ण होने के लिए लाया जा रहा है।

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


0

क्या औसत वेग और स्प्रिंट प्रतिबद्धताओं की मेरी समझ सही है?

आपका औसत वेग हाजिर है। मेरे अनुभव में यह पूर्ण होने के दीर्घकालिक अनुमानों के लिए बहुत उपयोगी है - यह मानते हुए कि आपके पास एक बड़ा बैकलॉग है; लेकिन स्प्रिंट योजना प्रतिबद्धताओं के लिए उतना उपयोगी नहीं है।

स्प्रिंट प्लानिंग के लिए मैंने जो प्रक्रिया देखी है वह बैकलॉग के ऊपर से कहानियों को खींचने के लिए है और टीम को तय करने दें कि क्या वे उन्हें हासिल कर सकते हैं। टीमों ने यह तय किया है कि आंत का अनुभव, 1/2 दिन के कार्यों को तोड़ना, उत्पाद स्वामी से दबाव, एक स्प्रिंट लक्ष्य के साथ संरेखण, सबसे अच्छा अनुमान (वेग के आधार पर) या उन सभी का कुछ संयोजन।

कभी-कभी उत्पाद मालिक ने एक-दो वस्तुओं को छोड़ देने की अनुमति दी है, ताकि अधिक जोड़े जा सकें।

कभी-कभी टीम और उत्पाद स्वामी आगे बढ़ने के लिए स्ट्रेच आइटम से सहमत होते हैं।


0

यह एक उत्कृष्ट प्रश्न है और टीमों में सुधार के लिए बहुत महत्वपूर्ण है। विषय भ्रामक है और व्यापक रूप से गलत समझा गया है। कहानी को इंगित करने का मूल उद्देश्य कहानियों में परिभाषित कार्यक्षमता को पूरा करने के लिए आवश्यक स्तर ऑफ एफर्ट (एलओई) का आकलन करने का एक त्वरित और स्वीकार्य सटीक तरीका खोजना था। समग्र उद्देश्य: टीमों को फोरकास्टिंग या भविष्यवाणी करने की एक विधि दें, जो एक प्रयास (जैसे परियोजना) को पूरा करने में कितना समय लेगी। वेग की आपकी समझ सही है: यह स्प्रिंट प्रति पूर्णतया (सही मायने में) प्राप्त किया गया अंक है। इसलिए यदि आपके पास वितरित करने के लिए एक परियोजना है, और यह 250 अंक है, और आपकी टीम प्रति स्प्रिंट औसतन 25 अंक लेती है, तो परियोजना लगभग 10 स्प्रिंट, प्लस या शून्य से कुछ बफर समय लेगी।

केन श्वाबेर जैसे कुछ प्रकाशकों का सुझाव है कि वेग और बिंदुओं का उपयोग केवल मध्य से दीर्घकालिक पूर्वानुमान के लिए किया जाता है। वे एक स्प्रिंट में वास्तव में क्या किया जा सकता है, इस पर एक दूसरे "पवित्रता जांच" के रूप में कार्य के घंटे का उपयोग करने का सुझाव देते हैं। इसलिए प्रत्येक स्प्रिंट में अंकों की मात्रा क्षमता के आधार पर भिन्न हो सकती है। अन्य (स्वयं सहित), यह मानते हैं कि एक परिपक्व टीम एक बहुत सुसंगत आकार देने वाले पैटर्न में बस जाएगी जो क्षमता की सटीक भविष्यवाणी कर सकती है, और अंततः कार्य के घंटे एक अतिरिक्त अतिरिक्त बोझ बन जाते हैं। (नई टीम के लिए कम से कम 6 से 12 स्प्रिंट, IMHO के लिए प्रदर्शन करना महत्वपूर्ण है, जब तक कि टीम की समझ बिंदुओं और कहानी के आकार के बारे में सटीक न हो।)

आपकी पहली छोटी त्रुटि यह है कि आपने कहा कि टीम को वेग जानना चाहिए और कई कहानी बिंदुओं को लाना चाहिए। वास्तव में, कोच टीमों को 10% से 20% तक की कटौती करने के लिए प्रोत्साहित करते हैं और इसके बजाय उस स्तर पर * प्रतिबद्ध होते हैं। यदि आपकी टीम प्रति स्प्रिंट 25 अंक पूरा करने के लिए जाती है, तो स्प्रिंट को 25 अंक तक न भरें, बल्कि 20 से 22 अंक पर रोकें। याद रखें: अन्य काम होने पर कहानियों में लाना पूरी तरह से ठीक है। तो आप 22 बिंदुओं पर "कमिट" कर सकते हैं और 28 को पूरा कर सकते हैं। यह बहुत अच्छा है। बस टीम को "सैंडबैग" के लिए प्रोत्साहित न करने और लगातार कमिट करने के लिए सावधान रहें। अगर हम और अधिक कर सकते हैं, तो यह देखने के लिए कुछ भी गलत नहीं है।

अब, स्प्रिंट के बीच विचरण के बारे में आपकी बात। यह एक बहुत ही सामान्य (लेकिन वैकल्पिक नहीं) पैटर्न है जो एक टीम को देखता है जो 20 अंक एक स्प्रिंट को पूरा करता है, फिर 50, फिर 22, फिर 45, फिर 15, फिर 60। यदि आप विचलन की गणना करते हैं, तो यह 50% के झूलों को दिखा सकता है। स्प्रिंट के बाद 100% स्प्रिंट। एक स्प्रिंट में टीम केवल 15 अंक क्यों पूरी करती है, और फिर अगले में 60?

इसका मतलब यह हो सकता है कि टीम वास्तव में नहीं जानती है कि वे क्या कर सकते हैं। (अरे, हमने पिछले स्प्रिंट के 50 अंक पूरे किए, हम इसे फिर से इस स्प्रिंट कर सकते हैं)।

या, यह संकेत दे सकता है कि उत्पाद के मालिक टीम को कमिट करने के लिए मजबूर कर रहे हैं, या स्प्रिंट शुरू होने के बाद काम जोड़ रहे हैं, आदि ये कुछ ANTI-PATTERNS हैं जो पूर्ण बिंदुओं में इस जंगली स्विंग का कारण बन सकते हैं।

घबराहट करने वाले उस्तादों के लिए यह महत्वपूर्ण उपाय है कि वे टीम के ध्यान में आएं। अधूरे काम की रोलिंग लहर अक्सर, कारण वे एक स्प्रिंट में कुछ बिंदुओं को पूरा करते हैं, और फिर अगले स्प्रिंट में कई बिंदुओं को मैं "रोलिंग वेव ऑफ इनकमप्ले वर्क" कहता हूं। यहाँ एक बहुत ही सामान्य पैटर्न है:

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

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

उत्पाद के मालिक उत्साहित हैं और इसलिए वे फिर से अपना लोड बढ़ाते हैं। इस स्प्रिंट के अंत में, उनके पास अधूरे काम की एक बड़ी मात्रा है, और काम की निराशाजनक राशि है।

यहां आपको स्प्रिंट के बाद डोन्ट बनाम अपूर्ण अपूर्ण स्प्रिंट के WAVES दिखाई देने लगते हैं। यदि टीमों को पता नहीं है कि क्या हो रहा है, तो यह पैटर्न महीनों तक जारी रह सकता है। लेकिन औसतन, वे प्रति स्प्रिंट लगभग 24 अंक पूरा करते हैं। तो जब वे ओवर-कमेटिंग छोड़ देते हैं तो क्या होता है?

आप ध्यान देंगे कि वे अभी भी 24 से 26 अंक पूरे करते हैं, लेकिन कैरी-ओवर का काम कम हो जाता है। अब, काम की एक असंभव राशि को पूरा करने की कोशिश में अभिभूत होने के बजाय, जो टीम के मनोबल को भी नष्ट कर देता है, टीम अपनी प्रक्रियाओं में सुधार करना शुरू कर सकती है।

समय के साथ, डोन-बनाम-अधूरे काम में विशाल झूलों के बिना, वेग बढ़ना शुरू हो जाएगा।

यदि आप टीम को कुछ "सुस्त समय" की अनुमति नहीं देते हैं, तो उनके पास काम करने का समय नहीं होगा जो उन्हें दुबला, तेज, बेहतर बना देगा। उदाहरण के लिए, देव-ऑप्स नहीं हो सकता। टेस्ट स्वचालन - उस के लिए समय कौन है !? लेकिन ये ठीक ऐसी चीजें हैं जिनके लिए टीमों को काम करने की आवश्यकता है ताकि वे वेग बढ़ा सकें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.