क्या स्क्रम स्प्रिंट का मतलब सबसे तेज गति से काम करना है?

Question

मैंने हाल ही में कुछ कंपनियों के साथ साक्षात्कार किया है जो एजाइल करते हैं, स्क्रैम अधिक सटीक होते हैं और कुछ चीजें हैं जो मुझे काफी फुर्तीली नहीं लगती हैं। मैं एक ऐसा मामला उठाऊंगा जिसमें विशेष रूप से मेरे हित हैं, जो कि स्क्रैम स्प्रिंट का है।

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

अब, मैंने अब तक एजाइल नहीं किया है (वित्तीय और सरकारी संस्थानों के साथ काम किया है जो अभी भी सबसे अधिक झरना पसंद करते हैं) लेकिन मेरी समझ यह है कि:

• स्प्रिंट में स्प्रिंट एजाइल में सामान्य पुनरावृत्ति के लिए नाम है;
• टीम को एक स्थायी गति से काम करना चाहिए और लंबे समय तक ओवरटाइम से बचने की कोशिश करनी चाहिए क्योंकि कम समय पर ही प्रभाव पड़ता है और प्रभाव उन समस्याओं से बौना हो जाता है जो वे लंबे समय में उत्पन्न करते हैं।

क्या मेरे कथन सही हैं? और, क्या मुझे प्रबंधक की प्रस्तुति को लाल झंडे के रूप में लेना चाहिए?

Comments

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

— एंड्रियास

@gnat मुझे लगता है कि सवाल भी अलग हैं

— एंड्रियास

"... आप घर नहीं जाते हैं जब काम के घंटे खत्म हो जाते हैं, आप घर जाते हैं जब काम पूरा हो जाता है, चाहे कितना भी समय लगे ..."। हवा की तरह चला। वह एक बेवकूफ है।

— J .Mᴇᴇ

मैंने इस प्रश्न को फिर से खोलने के लिए मतदान किया। प्रस्तावित डुप्लीकेट -एजाइल- ऑफ -द-न्यू-माइक्रोमेनरेशन का प्रश्न इस प्रश्न के साथ सामान्य रूप से है, कि प्रबंधक कुछ "घबराहट" कहता है और पूछने वाला जानना चाहता है कि क्या यह वास्तव में घोटाला है। यह सवाल "ओवरटाइम" के बारे में है "प्रस्तावित के बारे में" इसे अन्य विकासशील लोगों से बात करने की अनुमति नहीं है।

— k3b

"... जब आप घर नहीं जाते हैं जब काम के घंटे खत्म हो जाते हैं, तो आप घर जाते हैं जब काम पूरा हो जाता है, कोई फर्क नहीं पड़ता कि कितना समय लगता है" स्थायी गति की प्रमुख अवधारणा के साथ एक सीधा संघर्ष जैसा लगता है - मैं अगर मुझे टेबल पर खाना रखना हो तो वहां काम करो। HST, यदि यह समय-समय पर होता है, तो मुझे इससे कोई समस्या नहीं है। कभी-कभी, हर प्रयास के बावजूद, एक संकट होता है, और ग्राहक पहले आता है। लेकिन वह इसे एक नियमित घटना की तरह आवाज देती है, और यह सराहनीय है। इसका मतलब यह है कि वे यह समझने के लिए मूल कारण नहीं कर रहे हैं कि यह क्यों हो रहा है और अंतर्निहित समस्या को ठीक कर रहा है।

— डॉन ब्रैनसन

Answer 1

आपको यह देखने के लिए दूर नहीं जाना पड़ेगा कि ये प्रथाएं एजाइल के पीछे के सिद्धांतों के विपरीत हैं। एजाइल मेनिफेस्टो के पीछे सिद्धांतों में से एक है:

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

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

परिवर्तन दुरुपयोग के कारण आता है, जो कि आपके द्वारा वर्णित रवैये के अभाव-रहित घर-घर जैसा लगता है। विकास में, टीमों के नियंत्रण के बाहर कई कारक हैं जो वे नहीं कर सकते हैं - एक मौसम सादृश्य का उपयोग करने के लिए, आप "कमिट" नहीं कर सकते हैं कि कल बारिश होगी।

अपने सवालों के सीधे जवाब देने के लिए:

• हाँ, स्प्रिंट स्क्रेम में एक पुनरावृत्ति का नाम है , अंतर के लिए इस उत्तर को देखें
• हां, टीमों को एक स्थायी गति से काम करना चाहिए। ओवरटाइम की एकमात्र निश्चितता यह है कि यह टीमों की उत्पादकता को लंबे समय तक कम कर देगा ।
• हाँ, यह एक लाल झंडा है!

Answer 2

हाँ, आप सही कह रहे हैं, और अगर मुझे बताया गया था कि आपको क्या बताया गया था, तो मैं वहाँ से भाग सकता था। वे सिर्फ एक बहाने के रूप में चुस्त का उपयोग कर रहे हैं। क्लासिक डेथ मार्च की तरह लगता है।

Comments

आमतौर पर एक मृत्यु मार्च का अंत नहीं होगा? यह परियोजना एक शाश्वत नरक की तरह लगती है अगर यह है कि वे स्प्रिंट के बाद स्प्रिंट कैसे काम करते हैं।

— DXM

नहींं, डेथ मार्च में हमेशा "हमें अगले संस्करण पर ध्यान देने की आवश्यकता है, फिर हम बग को ठीक कर सकते हैं और ठीक कर सकते हैं! उफ़, हमने ग्राहक को दो महीने में अगले अगले संस्करण का वादा किया, बस अगले अगले पर धकेलने की जरूरत है!" संस्करण! " और इसी तरह, आपको यह विचार मिलता है।

— मिकी वाट्स

@DXM का अंत तब होता है जब हर कोई शांत हो जाता है। डेथ मार्च प्रोजेक्ट्स पिछले साल हो सकते हैं।

— 5

जब आप मर जाते हैं तो @DXM मृत्यु मार्च समाप्त हो जाता है।

— डेव हिलियर

हम्म, मुझे लगता है कि मैं अपने स्वयं के अनुभव को प्रस्तुत कर रहा था। किसी तरह मेरे मन में कुप्रबंधित परियोजनाएं मौत के एक मार्च के संयोजन के बाद महीनों की अनिर्णय के बाद जहां आगे जाना है। हमारी टीम सबसे लंबे समय तक खाली बैकलॉग के साथ अपने अंगूठे पर बैठी थी। फिर हमें "हम एक वार्षिक रिलीज चक्र पर हैं" बयान के साथ 4-6 महीने दिए जाएंगे

— DXM

Answer 3

एक महत्वपूर्ण बात यह है कि यह स्वीकार्य हो सकती है: टीम स्प्रिंट के दायरे को स्वीकार करती है।

स्क्रम में, टीमों को केवल काम सौंपा नहीं जाता है। उत्पाद स्वामी उत्पाद कार्य और तकनीकी (ऋण) कार्य को प्राथमिकता देने के लिए टीम के साथ बातचीत करता है। प्रोजेक्ट मैनेजर, प्रोडक्ट ओनर और टीम तब बातचीत करते हैं कि स्प्रिंट में क्या खींचा जाता है और उस काम की गुंजाइश क्या है।

इस दुनिया में, टीम अनिवार्य रूप से कह रही है "हम एक्स काम कर सकते हैं, परीक्षण और इस यात्रा को भेज दिया"। इसलिए मुझे उम्मीद है कि इन प्रतिबद्धताओं को पूरा करने के लिए एक टीम कभी-कभार काम करेगी।

उस ने कहा, इतनी सारी जगह चुस्त-दुरस्त है - और बहुत कम टीम लीडर्स ऐसे लोगों से प्रभावी ढंग से बातचीत कर सकते हैं, जो आमतौर पर उनके बॉस होते हैं ... मैं इसे एक बड़े लाल झंडे के रूप में लेता हूं।

Comments

"कभी-कभी इन ( गलत तरीके से अनुमानित ) प्रतिबद्धताओं को पूरा करने के लिए ओवरटाइम काम करते हैं " => एक आदत में गलत अनुमान लगाते हुए

— gnat

@ नागात - pssh अनुमान कभी-कभी उच्च होते हैं। अनुमान कभी-कभी कम होते हैं। अगर कम करके आंका जाता है, तो यह निश्चित रूप से एक समस्या है। लेकिन मोटे तौर पर क्यों पुनरावृत्तियों मौजूद हैं: आकलन को परिष्कृत करने में मदद करने के लिए।

— तेलस्टिन

प्रोग्रामिंग स्वेटशोप आम तौर पर श्रमिकों द्वारा बातचीत को स्वीकार नहीं करते हैं।

— maple_shaft

@gnat: यदि आप पाते हैं, एक टीम के रूप में, कि आप आदतन काम को कम आंक रहे हैं, तो आपको अगले स्प्रिंट में कम काम करना चाहिए।

— बार्ट वैन इनगेन शनाउ

जब प्रबंधन लक्ष्य जितना संभव हो उतना काम पूरा करना है, भले ही काम के घंटे की सीमा की परवाह किए बिना (और अनुभव यह बताता है कि यह अधिकांश मामलों में सच है), और कर्मचारी के लक्ष्यों को भुगतान किए गए काम को पार किए बिना सबसे अधिक काम करना है। घंटे (मैं मानता हूं कि कुछ प्रबंधकों का तर्क हो सकता है कि यह आशावादी है), फिर अनुमान में निहित त्रुटि की परवाह किए बिना, शेड्यूलिंग हमेशा> = काम के घंटे के लिए रुझान देगा। तार्किक विस्तार यह है कि कर्मचारी के लक्ष्यों को कम करके आंका जाना चाहिए। @BartvanIngenSchenau यह है कि यह आदत स्वाभाविक रूप से कैसे विकसित होती है।

— स्टीवन एवर्स

Answer 4

स्क्रम स्प्रिंट में टूट गया है जहां आप उस स्प्रिंट की अवधि में पूरा होने वाले कार्यों का एक सेट का अनुमान लगाते हैं (आमतौर पर 2 सप्ताह, लेकिन मैंने 1 दिन से 4 सप्ताह तक कहीं भी देखा है)। मुझे लगता है कि यह गलत कार्यों के लिए एक प्रोत्साहन बनाता है। POs (उत्पाद स्वामी) प्रति स्प्रिंट के लिए एक बड़ा कमीशन प्राप्त करने के लिए कम अनुमान चाहते हैं। टीम ने पीएम को देखने के लिए अच्छे बंडाउन चार्ट बनाने के लिए बड़े अनुमान लगाए हैं। बेशक, ये एक भद्दे संगठन के संकेत हैं। आप वास्तव में सटीक अनुमान प्राप्त करना चाहते हैं और डरते नहीं हैं कि या तो कम पड़ें और अगले स्प्रिंट पर कहानियों को ले जाएं या जल्दी खत्म करें और बैकलॉग से अतिरिक्त कार्यों को खींचें। मुझे लगता है कि "स्प्रिंट" शब्द तेजी से काम करने वाले लोगों की इस छवि को बनाता है।

Comments

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

— 22

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

— जियोर्जियो

टीम को चाहिए, लेकिन जैसा मैंने कहा, उनके पास पैड अनुमानों के लिए एक प्रोत्साहन है। यदि पीओ एक भुगतानकर्ता है, तो वे अधिक आक्रामक तरीके से अनुमान लगाने के लिए दबाव लागू कर सकते हैं। पृष्ठभूमि के लिए, मैं परामर्श में काम करता हूं, इसलिए स्क्रैम टीम मेरे सह-कार्यकर्ता हैं, जबकि पीओ आमतौर पर बाहरी है और हमारे फुलाए हुए बिल दर का भुगतान कर रहा है :)

— जिगी

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

— क्रिस

Answer 5

नहीं: scrum sprints एक टाइमबॉक्स है, कुछ ज्यादा नहीं, कुछ कम नहीं। स्प्रिंट / पुनरावृत्ति की शुरुआत में, टीम कहानी के बिंदुओं की मात्रा का अनुमान लगाती है जो वे मानते हैं कि वे प्राप्त कर सकते हैं, पिछले प्रदर्शन, उपलब्धता, आगामी घटनाओं, खुली बाधाओं, आदि जैसी चीजों के आधार पर वे उत्पाद के मालिक के साथ बातचीत करते हैं। जिसके बारे में उपयोगकर्ता कहानियाँ स्प्रिंट में डालते हैं। वह है (या था? अन्य जवाब देखें) उत्पाद के मालिक द्वारा टीम को दी गई प्रतिबद्धता ।

विकास के दौरान, अगर यह पता चलता है कि चीजें वास्तव में अनुमानित नहीं हैं (यह सब के बाद सॉफ्टवेयर विकास है) और एक जोखिम है कि टीम प्रतिबद्धता को पूरा नहीं करेगी, तो वे उत्पाद के मालिक को सूचित करते हैं कि जोखिम एक या अधिक कहानियां हैं पूरा नहीं हुआ।

और यह ठीक है। यकीन है, यह बुरा लगता है, स्प्रिंट के अंत में स्वीकार करना है कि स्प्रिंट विफल हो गया, लेकिन यह हार नहीं है, यह सुधार का अवसर है। क्योंकि नए के स्प्रिंट / शुरुआत के अंत में, आपको स्प्रिंट रेट्रोस्पेक्टिव करने के लिए मिलता है, और पहली बात जो कोई भी पूछेगा वह यह है कि 'हमने इस स्प्रिंट को क्यों विफल किया, और हमें इसे फिर से विफल नहीं करने के लिए क्या करने की आवश्यकता है ? '। एक विकल्प कम प्रतिबद्धता को छोड़ना होगा (= कम कहानी अंक लेना)।

tl; डॉआर: सस्टेनेबल पेस। घोटाला ताल के बारे में है, कुछ टीम अनिश्चितकालीन स्प्रिंट के आधार पर अनिश्चित काल तक रख सकती है। ओवरटाइम काम नहीं कर रहा है; टीम ओवरवर्क हो जाएगी, काम मैला हो जाएगा, सदस्य बीमार या पूरी तरह से फोन करेंगे, और फिर आपको एक असफल स्प्रिंट की तुलना में पूरी बड़ी समस्या है।

Answer 6

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

चंचल मेनिफेस्टो लोगों से

हर समय काम करना मेरे लिए टिकाऊ नहीं लगता।

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

Answer 7

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

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

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

मुझे लगता है, आप जवाब जानते हैं ... ;-)