SCRUM की शुरुआत करते समय आपने क्या देखा है?

20

जब आपकी कंपनी ने SCRUM के साथ वर्तमान प्रक्रियाओं को बदलने का फैसला किया तो विफलता का एक ही बिंदु क्या था?

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

मैं कार्यान्वयन विवरणों के बारे में फैसलों पर लापता प्रलेखन के बारे में बहुत कुछ सुनता हूं , और कहानी के आकार और कहानियों के विस्तार के स्तर के बारे में।

scrum failure

— चापलूसी
स्रोत

14

सबसे बड़ी समस्या गलतफहमी है। सामान्य विफलताएँ हैं:

केवल एक टीम स्क्रैम कर रही है लेकिन कंपनी के बाकी (बिक्री, प्रबंधन, मानव संसाधन सहित) अभी भी पुराने तरीके से सोचते हैं। उदाहरण:

ग्राहक और ग्राहक की भागीदारी के साथ निरंतर सहभागिता बहुत महत्वपूर्ण है।

एचआर को यह समझना होगा कि टीम का प्रदर्शन अधिक महत्वपूर्ण है तो व्यक्तियों का प्रदर्शन। KPI को बदलना होगा।

फ़ीचर डेफ़िनेशन निरंतर प्रक्रिया है। ग्राहक की प्रतिक्रिया द्वारा विकास के दौरान परियोजना की परिभाषा विकसित होगी। उस परियोजना की समय सीमा के कारण, आवश्यक बजट या परिणाम सुविधा सेट बदल सकता है (हितधारक द्वारा अनुमोदन के बाद)।

परिवर्तन प्रक्रिया का हिस्सा है।

अनुमान निरंतर प्रक्रिया है जिसे आप परियोजना की शुरुआत में नहीं कह सकते हैं कि आपको 5 महीने के भीतर सभी सुविधाओं (शुरुआत में उनमें से कई अज्ञात) के साथ किया जाएगा।

टीम को निर्णय लेने का अधिकार है। टीम अगली स्प्रिंट के दौरान वितरित सुविधाओं की मात्रा के लिए प्रतिबद्धता बनाती है। यह मांग या आज्ञा नहीं दी जा सकती।

स्प्रिंट टीम के लिए सुरक्षित क्षेत्र है। एक बार टीम कुछ परिभाषित उपयोगकर्ता कहानियों के लिए आने के बाद प्रतिबद्धता टीम के बाहर संशोधित नहीं किया जा सकता है।

पुराने संगठन के ढांचे का एक हिस्सा यह समझ में नहीं आता है कि स्क्रम में जाते समय। स्क्रम तीन भूमिकाओं को परिभाषित करता है: स्क्रम मास्टर, उत्पाद मालिक, टीम। अन्य भूमिकाएँ हैं लेकिन ये तीनों आमतौर पर आवेदन देने के लिए पर्याप्त हैं। सामान्य गैर-समझदार व्यक्ति के पास स्क्रैम मास्टर, टीम लीडर, उत्पाद के मालिक और एक या अधिक प्रोजेक्ट मैनेजर हैं। प्रोजेक्ट मैनेजर और टीम लीडर स्क्रेम में बेमानी भूमिकाएँ हैं।
लड़के को सौंपा गया स्क्रैम मास्टर की भूमिका स्क्रैम मास्टर नहीं कर रहा है। स्क्रम मास्टर बाधाएं हल करता है। जो भी टीम को परेशान करता है, वह बाधा है जिसे ASAP द्वारा हल किया जाना चाहिए। सबसे आम विफलता स्क्रेम के साथ किसी भी पिछले अनुभव के बिना डेवलपर को यह भूमिका सौंप रही है। यह भूमिका आंशिक रूप से आम परियोजना प्रबंधक की जगह लेती है, लेकिन स्क्रैम मास्टर टीम के ऊपर शक्ति के बिना है और स्क्रैम मास्टर किसी भी सुविधाओं को लागू करने की मांग नहीं करता है। स्क्रैम मास्टर उत्पाद मालिक के खिलाफ भी टीम को अवास्तविक आवश्यकताओं के साथ गार्ड करता है।
लड़के को सौंपा गया उत्पाद स्वामी की भूमिका उत्पाद स्वामी नहीं कर रहा है। उत्पाद के मालिक के पास उत्पाद के लिए वित्तीय जिम्मेदारी है। यह बहुत विशिष्ट है और सफलता के लिए एक महत्वपूर्ण भूमिका है। भूमिका में विश्लेषणात्मक, परियोजना प्रबंधक और उत्पाद प्रबंधक के साथ सामान्य रूप से कुछ है। उत्पाद स्वामी आवश्यकताओं को इकट्ठा करता है और बनाए रखता है (आमतौर पर उपयोगकर्ता कहानियों के रूप में)। उनकी जिम्मेदारी टीम को जानकारी प्रदान करना और उपयोगकर्ता कहानियों की प्राथमिकता को परिभाषित करना है। उसे टीम के साथ साइट पर होना चाहिए क्योंकि पीओ और टीम के बीच सहयोग निरंतर है।
प्रक्रिया का नाम स्क्रम में बदलना लेकिन अधिकांश प्रक्रिया को छोड़ देना क्योंकि यह पुराने तरीके से थी। सबसे आम परिदृश्य यह है कि आप जलप्रपात से स्क्रैम में बदल जाएंगे और सबसे महत्वपूर्ण परिवर्तन यह है कि आप विश्लेषण और प्रलेखन किसी भी अधिक नहीं करते हैं और आप कहते हैं कि आप स्क्रैम।
आवश्यकताएं / उपयोगकर्ता कहानियां पूरी हो चुकी हैं - बहुत आम हैं। यदि आपके पास किए गए (स्वीकृति मानदंड) की परिभाषा नहीं है, तो आप स्प्रिंट प्लानिंग के दौरान उपयोगकर्ता कहानी की जटिलता के बारे में कोई धारणा नहीं बना सकते हैं। यदि आपके पास स्प्रिंट के दौरान उनके पास नहीं है, तो आप उपयोगकर्ता कहानी को पूरा नहीं कर सकते क्योंकि आप इसे मान्य नहीं कर सकते।
गुणवत्ता को वैकल्पिक माना जाता है। स्क्रम में गुणवत्ता प्रथम श्रेणी का नागरिक है। हम कह सकते हैं कि प्रत्येक स्वीकृति मानदंड को स्वचालित एंड-टू-एंड टेस्ट द्वारा कवर किया जाना चाहिए। एक बार जब आप गुणवत्ता को कम करना शुरू कर देते हैं और अप्रयुक्त सुविधाओं को जोड़ना शुरू कर देते हैं, तो आप उत्पाद पर नियंत्रण खो देते हैं क्योंकि किए गए सुविधाओं को प्रतिगमन के कारण किसी भी समय काम करना बंद कर सकते हैं।
स्प्रिंट के परिणाम को उत्पाद में shippable वृद्धि (= काम और परीक्षण) किया जाना चाहिए।

संपादित करें:

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

— लादिस्लाव मृंका
स्रोत

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

— चापलूसी

1

प्रलेखन और विश्लेषण को निरंतर संपर्क और संचार के साथ बदल दिया जाता है। आप एक को हटा नहीं सकते हैं और दूसरे को पेश नहीं कर सकते हैं - यह वास्तव में लापता विवरण और गलत निर्णय का कारण होगा।

— लादिस्लाव मृका

The most basic approach is including analysis and documentation in acceptance criteria for user stories.वह मेरी प्रारंभिक प्रतिक्रिया भी है। यदि कहानी में स्वीकृति मानदंड हैं, तो आपके पास सबसे अच्छा दस्तावेज हो सकता है। लेकिन अगर टीम कुछ अतिरिक्त दस्तावेज बनाने का निर्णय लेती है (ट्रंक में READMEs के बारे में सोचें या उपयोगी जानकारी के साथ विकि), तो मुझे कोई समस्या नहीं दिखती है। मुझे लगता है कि लोगों को डर है कि SCRUM = कुछ भी कभी भी नीचे नहीं लिखा गया है।

— चापलूसी

10

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

मैंने देखा है कि टीमें पहले से ही किताबों से ज्यादा सफल होती हैं, जब वे उन किताबों की तुलना में करते हैं, जो उन टीमों की तुलना में बदलती हैं, जो अभी तक "नहीं" पाती हैं।

जब आपको "पहला स्प्रिंट" जैसी चीजें मिलेंगी, तो हम सभी आवश्यकताओं को पूरा करेंगे। दूसरा स्प्रिंट सभी डिज़ाइन, आदि, अंतिम स्प्रिंट, सभी परीक्षण। जिसे झरना के नाम से भी जाना जाता है। या यहां तक कि सरल चीजें जैसे "चलो वैसे भी बैठो, इस स्टैंडअप व्यवसाय के साथ क्या है?"।

शुहारी के साथ कुछ करना ( http://c2.com/cgi/wiki?ShuHaRi )।

— जूलियो
स्रोत

9

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

एक अन्य संबंधित समस्या वास्तव में हर किसी को इस बात से अवगत करा रही है कि वास्तविक वास्तविक क्या है और क्या नहीं है।

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

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

— इस इन डी होल
स्रोत

1

सिर्फ बैड बैक बॉय को बात करते समय खड़े होने के लिए कहें। यदि वह अभी भी शिकायत करता है, तो एक घोषणा करें कि रसोई में डोनट्स हैं।

— जेएफओ

management has actually taken this as a ticket to come directly to developersयह उस स्थिति का एक अच्छा उदाहरण है जहां SCRUM प्रक्रिया समझ में नहीं आती है, है ना? कि टीम स्प्रिंट के बीच में नई कहानियों को स्वीकार नहीं कर सकती है।

— चापलूसी

@ क्रिंग, हाँ ... बिल्कुल

— ऐसिन्थेहोल

2

क्या यह वास्तव में मायने रखता है कि कोई व्यक्ति स्टैंड के बजाय बैठता है? गंभीरता से? यही कारण है कि चुस्त तरीके काम नहीं करते हैं - लोग पुरानी प्रक्रिया से भरे तरीकों की तुलना में शीर्ष नियमों का पालन करते हैं!

— gbjbaanb

1

@gbjbaanb अंततः यह कोई फर्क नहीं पड़ता। क्या आप जानते हैं कि खड़े होने से क्या होता है? और यदि हां, तो आप इसे रोकने की कोशिश कैसे करते हैं? और क्या यह आपके लिए काम कर रहा है?

— जूलियो

6

जिस कोड को हम एक ही स्प्रिंट में विकसित कर रहे थे, उसके लिए सभी विश्लेषण करने की कोशिश कर रहे थे।

— केविन डी
स्रोत

और आपको विश्लेषण की आवश्यकता थी क्योंकि कहानी आवश्यक विवरण के बिना थी? या क्योंकि कोड पर्याप्त स्पष्ट नहीं था और / या परीक्षण के साथ दस्तावेज नहीं था?

— चापलूसी

1

प्रभावी रूप से कहानियां उस बिंदु पर अविश्वसनीय रूप से उच्च स्तर थीं जहां उत्पाद के मालिक (मेरी शब्दावली मुझे यहां विफल कर रही है) को यह भी नहीं पता था कि वे क्या चाहते थे।

— केविन डी

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

— कार्रा

4

हम थोड़ी देर पहले घोटालों में चले गए, और स्पष्ट रूप से चल रहे प्रबंधन ने प्रत्येक घोटाले को 2-सप्ताह के जलप्रपात प्रक्रिया के रूप में माना। घोटाले के नियमों का ऐसा पालन किया गया जो अपने आप में एक प्रक्रिया बन गया है!

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

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

अंत में, बस आधे-अधूरे चुस्त घोषणापत्र को याद करें ।

— gbjbaanb
स्रोत

1

"2-सप्ताह के जलप्रपात प्रक्रिया के रूप में स्क्रैम" के लिए +1। दुर्भाग्य से ऐसा लगता है कि वास्तव में आम है

— DPD

4

सबसे बड़ी समस्या यह है कि आपके ग्राहक को SCRUM प्रक्रिया को स्वीकार करने के साथ-साथ चुस्त बनने की भी जरूरत है। अधिकांश ग्राहक परियोजना की शुरुआत में इसे सुनना चाहते हैं:

इसमें कितना खर्च होगा
यह कैसा दिखेगा
यह कब किया जाएगा

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

— ओन्दीजे मिर्तेस
स्रोत

1

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

— लादिस्लाव मृका

लेकिन यह एक बड़ी समस्या है जब आप SCRUM में भी जाते हैं। लोग इस सवाल और जवाब के लिए इतने अभ्यस्त हैं कि उनमें से अधिकांश को अब यह एहसास नहीं है कि ज्यादातर समय अंत में गलत होते हैं। यदि ग्राहक उत्पाद की किसी न किसी दृष्टि के साथ आता है, तो वह पूछेगा how much will it cost?और वे एक विस्तृत जवाब की उम्मीद करते हैं। इस चिंता का मेरा जवाब हमेशा "यदि आप वास्तव में जानते हैं कि आप आखिर में क्या चाहते हैं, तो आपको फुर्तीली की जरूरत नहीं है। बस इसे नीचे कोड करें।" लेकिन हम सभी जानते हैं कि ऐसा नहीं होने वाला है। ;-)

— चापलूसी

2

हमारे पास SCRUM के पहले दो बड़े मुद्दे थे:

1) हमारे पास वास्तव में कोई उत्पाद स्वामी नहीं है। हमारे बॉस को भूमिका निभानी थी क्योंकि कोई भी व्यक्ति जो उत्पाद का मालिक होना चाहिए था वह ऐसा करने के लिए सहमत होगा। इस तरह की बातों में एक ऐंठन डाल दिया क्योंकि वह वास्तव में हमेशा जवाब नहीं जानता था।

2) बाहरी घटकों के लिए लेखांकन में हम खराब थे। हमारे पहले कुछ स्प्रिंट में पूर्ण स्वचालित परीक्षण शामिल है और चल रहा है, और हम बार-बार उन सिमुलेटरों को स्वचालित करने में परेशानी में पड़ गए जो हम उपयोग कर रहे थे। किसी भी तरह हमें यह महसूस करने में कभी कोई बेहतर नहीं हुआ कि यह होने वाला था।

— माइकल कोहेन
स्रोत

"उत्पाद स्वामी नहीं होने" के लिए +1। हम एक ही समस्या में भाग गए - कभी-कभी यह अपरिहार्य है, लेकिन आपको इसे स्वीकार करना चाहिए और उसी के अनुसार योजना बनानी चाहिए।

— sleske

2

मेरी परियोजना में जो बड़ी समस्या है, वह यह है कि अगले स्प्रिंट के लिए अनुमान लगाने के बाद आवश्यकता एकत्रित होती है। हम अनुमान मानदंड के आधार पर अनुमान लगाते हैं। आवश्यकता एकत्र करने के दौरान हमें पता चलता है कि ठीक ट्यून वाला एसी बहुत बड़ा है इसलिए 8 घंटे के लिए अनुमानित कार्य का समय वास्तव में 24 घंटे है! तो क्या मैं अपने स्प्रिंट बैकलॉग को बदल सकता हूं और मेरी कहानियों को कम करने वाले अनुमानों को संशोधित कर सकता हूं? नहीं साहब! फुर्तीली बैकलॉग को बदल नहीं सकते हैं कि फुर्तीली रिक्रिएशन! मेरे टीएल क्या कहते हैं। इसलिए मुझे मूल स्वीकृति मानदंड के अनुसार कोडिंग नहीं करनी चाहिए जिसके लिए मैंने 8 घंटे के रूप में समय का अनुमान लगाया था! परमेश्वर! नहीं! आप ऐसा नहीं कर सकते! यह चुस्त नहीं होगा, यह होगा!

— डीपीडी
स्रोत

आपने इसे कैसे ठीक किया? या क्या यही कारण था कि SCRUM का पूरा परिचय विफल हो गया? मैंने सोचा कि अगर टीम को स्प्रिंट प्लानिंग का अधिक अनुभव हो जाता है और अनुमान लगाया जाता है कि पोकर जल्दी से लापता आवश्यकताओं को प्रकट कर देगा और अनुमान बेहतर और बेहतर हो जाएगा।

— चापलूसी

हमने इसे अभी तक ठीक किया है। और हम अभी भी SCRUM का उपयोग कर रहे हैं। अंतर केवल इतना है कि यदि हम कहते हैं कि अतिरिक्त काम बहुत अधिक है और टीएल इससे सहमत है, तो हम कहानी को अलग रख सकते हैं। हम अधिक घंटों में डालते हैं।

— डीपीडी