क्या किसी और को लगता है कि स्क्रैम चुस्त नहीं है?


41

मैं फुर्तीले विकास का एक बड़ा प्रशंसक हूं और कुछ साल पहले एक बहुत ही सफल प्रोजेक्ट पर XP का इस्तेमाल किया। मैं इसके बारे में सब कुछ प्यार करता था, पुनरावृत्त विकास दृष्टिकोण, एक परीक्षण के आसपास कोड लिखना, जोड़ी प्रोग्रामिंग, साइट पर एक ग्राहक द्वारा चीजों को चलाने के लिए। यह एक बहुत ही उत्पादक काम का माहौल था और मुझे ऐसा कभी नहीं लगा कि मैं दबाव में हूं।

हालाँकि पिछले कुछ स्थानों पर मैंने स्क्रैम का उपयोग / उपयोग किया है। मुझे पता है कि यह इन दिनों चुस्त विकास के लिए पोस्टर बच्चा है लेकिन मैं 100% आश्वस्त नहीं हूं कि यह चुस्त है। नीचे दो मुख्य कारण दिए गए हैं कि यह मेरे लिए चुस्त महसूस नहीं करता है।

प्रोजेक्ट मैनेजर्स लव इट

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

मेरी राय में यह एक चुस्त प्रक्रिया के लिए बहुत अधिक प्रलेखन / समय पर नज़र रखने का तरीका है। मैं यह अनुमान लगाने में समय क्यों बर्बाद करूंगा कि कोई कार्य मुझे कितना समय लगने वाला है जब मैं केवल कार्य के साथ काम कर सकता हूं। या इसी तरह मैं क्यों समय बर्बाद कर रहा हूँ जब मैं अगले काम को हाथ में ले जा सकता हूं, तो यह दर्ज करने में कितना समय लगेगा।

स्टैंडअप मीटिंग

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

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

निष्कर्ष

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

विचार किसी को?


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

7
हाँ। यहां तक ​​कि फुर्तीले के "पिता" में से कोई भी सहमत नहीं है कि स्क्रैम वास्तव में चुस्त है: youtube.com/watch?v=hG4LH6P8Syk
व्यंग्यात्मक

18
तो आप जो कह रहे हैं कि आप स्क्रैम नहीं कर रहे हैं, और आप इसके बारे में जानते हैं, लेकिन फिर आप आश्चर्यचकित हैं कि Notscrum भी Notagile है?
पीडीआर

2
मैंने कभी भी बैठकों में अधिक समय नहीं बिताया है, हर एक "फुर्तीली" टीम की तुलना में प्रक्रिया के बारे में बात कर रहा हूं। लेकिन मुझे अभी भी यह विकल्प की तुलना में बहुत अच्छा लगता है।
रोब

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

जवाबों:


25

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

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

मैं इस पर जोर नहीं दे सकता: यदि आप स्क्रैम करना चाहते हैं, तो आपको सक्षम प्रशिक्षकों की आवश्यकता है जो आपको रास्ता दिखा सकें। यह आवश्यक स्कैम पढ़ने के लिए पर्याप्त नहीं है और फिर देखें कि यह आपको कहां मिलता है ...


16
किस तरह से दैनिक स्टैंडअप माइक्रोप्रैनरेशन से अलग हैं?
जियोर्जियो

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

10
@Georgio: इस बात पर निर्भर करता है कि आप माइक्रोएनरेशन से क्या मतलब रखते हैं। SCRUM में एक दैनिक स्टैंडअप का लक्ष्य सभी को सूचित करना है कि हर कोई क्या कर रहा है, कि अनुमानों को पूरा न करने के लिए एक परियोजना प्रबंधक को लोगों का पीछा करने का अवसर प्रदान करना। वास्तव में, SCRUM में कोई परियोजना प्रबंधक नहीं है , अनुमानों को ट्रैक करना और समायोजित करना टीम का काम है, और यदि वे पूछने के लिए प्रश्न नहीं मिले हैं, तो "क्या कारण है और हम भविष्य में इससे कैसे बच सकते हैं या इसकी अनुमति दे सकते हैं?" "," किसकी गलती है और हम उसे कितना बुरा महसूस कर सकते हैं? "
माइकल बोर्गवर्ड

3
@ErikReppen जैसा कि यह किसी भी चीज़ के बारे में है, आपके पास ऐसे लोगों का एक छोटा समूह है जो एक योग्य सुधार के साथ आते हैं और फिर आपको एक बड़ा समूह मिलता है जो इसे मुद्रीकृत करना चाहता है और आम तौर पर इसे पूरी तरह से नष्ट कर देता है: - लेकिन मैं अपने आप को स्क्रैम एलायंस और इसके प्रमाणन व्यवसाय से पूरी तरह से दूर करता हूं।
स्टीफन बिलियट

8
@jessehouwing: हाँ, लेकिन एक परिपक्व टीम पर बैठकें आयोजित करना किसी ऐसे व्यक्ति के ऊपर जाने के लिए है जो पूरी तरह से चल सकता है और उन्हें बता सकता है: देखो, तुम्हें कोई समस्या है, तुम नहीं चल सकते, मैं तुम्हें ठीक से चलना सिखाऊंगा। ये लोग आपको देखेंगे और खुद से पूछेंगे: अरे, यह आदमी मुझसे क्या चाहता है? बेशक मैं चल सकता हूं। इसलिए, एक परिपक्व, स्व-आयोजन टीम पर दैनिक बैठकों को लागू करना केवल उनके काम के प्रवाह को परेशान करता है: यह सिर्फ बेकार है। इस तरह के निर्णय को या तो अक्षम प्रबंधन द्वारा या टीम के काम करने के तरीके को देखने / नियंत्रित करने की इच्छा से समझाया जा सकता है।
जियोर्जियो

20

हाँ। यहां तक ​​कि फुर्तीले के "पिता" में से कोई भी सहमत नहीं है कि स्क्रैम वास्तव में चुस्त है: youtube.com/watch?v=hG4LH6P8Syk - यूफोरिक

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


2
यह (आपने जो लिखा है, चाचा बॉब ने नहीं कहा था) एक गैर-अनुक्रमिक है। सिर्फ इसलिए कि कुछ प्रबंधन प्रक्रिया है, यह स्वाभाविक रूप से गैर-चुस्त नहीं है।
डेव हिलियर

9
आपके पास भूरे रंग की बिल्लियों और भूरे कुत्ते हो सकते हैं, लेकिन एक भूरे रंग की बिल्ली कभी भी भूरे रंग का कुत्ता नहीं हो सकती है। यह नहीं है क्योंकि यह भूरा नहीं है, यह इसलिए है क्योंकि यह कुत्ता नहीं है। इसी तरह एक फुर्तीली प्रबंधन प्रक्रिया एक चुस्त सॉफ्टवेयर विकास प्रक्रिया नहीं हो सकती है, इसलिए नहीं कि यह चुस्त नहीं है, बल्कि इसलिए कि यह एक सॉफ्टवेयर विकास प्रक्रिया नहीं है, जिसके बारे में हम बात कर रहे हैं।
15

1
तब आप अपने प्रश्न को अपडेट करना चाह सकते हैं, जिसका शीर्षक है, "क्या किसी और को लगता है कि स्क्रैम चुस्त नहीं है?"
डेव हिलियर

वीडियो साझा करने के लिए धन्यवाद। मुझे यह वास्तव में ज्ञानवर्धक लगा।
मिकज

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

13

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

हां, प्रोजेक्ट प्रबंधक किसी उत्पाद बैकलॉग का उपयोग कर सकते हैं, विशेष रूप से एक जिसे डिजीटल किया गया है, मैट्रिक्स से बाहर निकालने के लिए ऐसी प्रणालियों को इकट्ठा करता है। लेकिन विकास दल और स्क्रम मास्टर को उसे नहीं करने देना चाहिए। वैसे भी एक प्रोजेक्ट मैनेजर क्या कर रहा है? उत्पाद स्वामी नहीं होना चाहिए ?

जिस तरह एक्सपी बुरी तरह से किया जा सकता है, और कुछ और कठोर प्रक्रियाएं बहुत तरल पदार्थ महसूस कर सकती हैं (निरंतर एकीकरण, तैनाती के साथ, लेकिन अभी भी बहुत योजनाबद्ध संचालित), स्क्रैम सिर्फ एक रूपरेखा है। यह अच्छे लोगों को लेता है जो मूल्यों और प्रक्रिया को अच्छी तरह से समझते हैं। यह लेता है एक सुधार सीखने सतत वहाँ पहुँचने के लिए।


12

आप शायद उम्मीद कर रहे हैं कि एक, लेकिन सिर्फ इसलिए कि कुछ (कई?) लोग एक अन-फुर्तीले तरीके से स्क्रम का दुरुपयोग करते हैं, इसका मतलब यह नहीं है कि स्क्रम एक शांत नहीं है।

प्रोजेक्ट मैनेजर : स्क्रैम टीम में ऐसी कोई भूमिका नहीं है। स्क्रैम मास्टर बजट या समय सीमा की बैठक के लिए जिम्मेदार नहीं है। वह उस टीम की मदद करने और उसके द्वारा किए गए लक्ष्य के लिए अपने रास्ते पर खड़े किसी भी बाधा को हटाने के लिए जिम्मेदार है। आप जो वर्णन करते हैं, उससे लगता है कि आपका पीएम स्कैम को खुद के लिए अपहृत करने के लिए अपहृत कर लेता है जो आम तौर पर टीम और उत्पाद स्वामी के पास जाते हैं, जो पिछली कमांड और नियंत्रण की आदतों को बनाए रखते हैं।

समय की ट्रैकिंग : स्क्रम ने शेष समय को ट्रैक करने और स्प्रिंट की स्थिति का निर्धारण करने के लिए इसकी सिफारिश की है , व्यक्तिगत टीम के सदस्यों द्वारा खर्च किए गए समय पर नहीं । यह एक विस्तार लग सकता है, लेकिन दोष-उन्मुख संस्कृति और लक्ष्य-उन्मुख दृष्टिकोण के बीच सभी अंतर बनाता है।

से स्क्रम गाइड :

मॉनिटरिंग स्प्रिंट प्रगति

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


यह एक दोष-उन्मुख संस्कृति बनने के लिए अपरिहार्य है, यहां तक ​​कि स्क्रम भी सिद्धांत में 100% राजनीतिक सही है।
प्यार

2

scrum एक परियोजना प्रबंधन पद्धति है

फुर्तीली एक सॉफ्टवेयर विकास पद्धति (-ish) है

scrum + फुर्तीली बहुत अच्छी तरह से काम करती है

फुर्तीले के बिना ... इतना नहीं


3
यह दिलचस्प है कि स्क्रैम एक सॉफ्टवेयर डेवलपमेंट मेथडोलॉजी हुआ करता था, लेकिन समय के साथ एक प्रोजेक्ट मैनेजमेंट कार्यप्रणाली में विकसित हुआ।
विजेता मरियम

2
मुझे लगता है कि यह अपरिहार्य है। देवों के पास प्रक्रिया में स्वामित्व की भावना नहीं है (इसे नहीं चाहिए)। हाल ही में एक स्प्रिंट रिव्यू में, मैंने टीम के उद्देश्य पर सवाल उठाया: सॉफ्टवेयर लिखें, या बोझिल चार्ट को अच्छा बनाएं। मैंने अपनी बात रखी, लेकिन तब कमरे के सभी पीएम को ब्ला ब्ला ब्ला के महत्व पर जोर देने के लिए बड़ी लंबाई में जाना पड़ा। जबरदस्त हंसी!
रोब

2
@ टी-फलक: इससे भी अधिक दिलचस्प बात यह है कि स्क्रैम को मूल रूप से एक नए-उत्पाद विकास पद्धति के रूप में प्रस्तावित किया गया था - hbr.org/1986/01/the-new-new-product-development-game/ar/1
स्टीवन / लो

2
@ StevenA.Lowe आह स्क्रम, यह आत्म-खोज की यात्रा पर है।
विजेताराम

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