📽️ 🔒 ⚕️ SCRUM गाइड में लेखकों के छिपे हुए अर्थ क्या हैं। भाग 1. प्रक्रिया के बारे में 🤚🏻 🧘🏻 🔚

जादू और यूनिकॉर्न के बारे में बात करें SCRUM-a?

यह कोई रहस्य नहीं है कि कई ने अपने घरों में एससीआरयूएम को लागू करने की कोशिश की, लेकिन हर कोई सफल नहीं हुआ, और कई को समझ नहीं आया कि जादू कहां से आ सकता है।

तुरंत सहमत हूं, एससीआरयूएम के लिए एकमात्र मैनुअल स्क्रैम गाइड है , यह बदलता है और अपडेट होता है, इसलिए मैं आपको नियमित रूप से फिर से पढ़ने की सलाह देता हूं।

लेखों की यह श्रृंखला मैनुअल के पढ़ने की जगह नहीं लेगी, बल्कि लेखक के कुछ व्यक्तिगत परिवर्धन के साथ मार्गदर्शिका के अतिरिक्त होगी।

और हम संभवतः मैनुअल के अंतिम पृष्ठ पर लिखे गए से शुरू करेंगे:

स्करम की भूमिकाएँ, घटनाएँ, कलाकृतियाँ और नियम अपरिवर्तनीय हैं और हालाँकि स्क्रम के केवल कुछ हिस्सों को लागू करना संभव है, परिणाम स्करम नहीं है।

(स्क्रम भूमिकाओं, घटनाओं, कलाकृतियों और नियमों को अपरिवर्तित किया जाता है । और हालांकि स्क्रम के कुछ हिस्सों की शुरूआत संभव है, लेकिन परिणाम स्करम नहीं होगा।)

यह मेरे बारे में क्या बताता है, जिसके पास पहले से ही कंपनी के 4 परिवर्तनों के बाद, जिस रेक से हम हमला कर रहे थे, उसके माथे पर कालस है।

उसके बारे में - अगर हम A95 गैसोलीन प्राप्त करना चाहते हैं, तो हमें संभवतः उत्पादन मानकों का कड़ाई से पालन करने की आवश्यकता है, अनुसमर्थन स्तंभ में तेल को कड़ाई से परिभाषित तापमान पर गरम करें, एक निश्चित ऊंचाई पर वाष्प लें, "आँख से नहीं" घटकों को जोड़ें, लेकिन अंतिम बिंदु का निरीक्षण करें। उसकी मां! तकनीकी प्रक्रिया। अंतिम परिणाम के लिए A95 होना चाहिए, न कि किसी तरह का शरीर का वजन जो आपकी कार को बर्बाद कर देगा।

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

// SCRUM है - समझने में सरल

तो मेरा यही मतलब है। SCRUM से अधिक सरल क्या हो सकता है: नियोजन करें, सुबह पांच मिनट बिताएं, और 2 सप्ताह बाद, सभी को इकट्ठा करें और उन्हें परिणाम (आमतौर पर अब जरूरत नहीं) दिखाने दें, और उस उत्पाद की प्रतीक्षा करें जो सभी के लिए धन, आनंद और गर्व लाता है! सीधे शब्दों में? चलो लागू करते हैं, प्रबंधकों का कहना है!

यह "हुक" आमतौर पर युवा और अनुभवी नहीं होता है, क्योंकि अनुभवी (पाठक) पहले से ही जानते हैं कि यह इतना सरल नहीं है।

// SCRUM मास्टर करना मुश्किल है

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

हर कोई जानता है कि खराब (जिसके साथ टीम अपमानजनक है) प्रबंधक है:

प्रतिनिधि नहीं कर सकते
वह कार्य को स्वयं वितरित करता है, वह परिणाम को स्वीकार करता है
दैनिक मॉनिटर
इसके लिए निरंतर रिपोर्टिंग, दस्तावेज़ीकरण, समय शील्ड्स भरने (उपस्थिति कार्यक्रम) की आवश्यकता होती है
टीम पर भरोसा नहीं करता
अपने फैसले थोपता है

(मुझे आशा है कि किसी ने खुद को यहां नहीं पहचाना)

यह वही "हाइपर चिंता" है, या क्या यह "बड़े", "माता-पिता", "सबसे अधिक जिम्मेदार", "मुझे केवल इसकी आवश्यकता है" की भावना है।

आदेश के साथ, यह आवश्यक रूप से बुरा जादू करता है:

टीम सोचने की क्षमता खो देती है। (आप प्रबंधक यहां दार्शनिकता को रोकते हैं, लेकिन मुझे बताएं कि क्या करना है)
टीम कार्यों पर काम करती है, परिणाम नहीं, कभी-कभी सक्रिय होने का "दिखावा" करती है। (हम कार्य 1, कार्य 2, कार्य 3 करते हैं, और उत्पाद गिर गया है, मान लेते हैं / समझ जाते हैं।)
टीम रिपोर्टिंग, प्रलेखन में व्यस्त है, लेकिन काम नहीं कर रही है। (मैं सोमवार और शुक्रवार को आधे दिन की रिपोर्ट लिखता हूं, मैं कार्य नहीं करता हूं।)
टीम किसी भी नवाचार का विरोध करती है। (ऑटो टेस्ट क्या हैं? चलो काम पूरा कर लेते हैं।)

यह अजीब नहीं है, लेकिन SCRUM "सीनियर पैरेंट" द्वारा ऐसे "हाइपर कंट्रोल" से टीम को "सीमित" कर देता है।

प्रमाण चाहिए? यह सब स्क्रम गाइड के अनुसार रखें:

स्टैंडअप, केवल विकास टीम के लिए!

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

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

(डेली स्क्रम डेवलपमेंट टीम की आंतरिक बैठक है। यदि वहाँ है।
कोई और व्यक्ति है, स्क्रम मास्टर यह सुनिश्चित करता है कि वे बैठक में हस्तक्षेप न करें)

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

उत्पाद स्वामी के साथ बैठकों में, टीम के पास समय का 10% से अधिक नहीं है, और एक मिनट से अधिक नहीं

(मेरा मतलब है कि जिन लोगों पर पीओ मौजूद है, टीम हमेशा पीओ की ओर मुड़ सकती है, अगर उन्हें इसकी आवश्यकता हो)

क्योंकि 2 सप्ताह के स्प्रिंट के लिए, इन पर 3 बैठकों को सख्ती से विनियमित किया जाता है:

स्प्रिंट प्लानिंग पर 4 घंटे अधिकतम
स्प्रिंट rewiew पर अधिकतम 2
और 1.5 घंटे स्प्रिंट रेट्रो

और यह सब, 2 सप्ताह में उत्पाद मालिक, नियमों के अनुसार, केवल 7.5 घंटे हैं, जिस पर "सहायता" के लिए बिल्कुल समय नहीं है। शेष 90% समय टीम स्प्रिंटिंग के लक्ष्य पर काम करती है। (लेकिन क्या आपने इस बात पर विचार किया है कि आपकी टीम वास्तव में कितना कोड कर सकती है?)

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

टीम को ग्राहक की जरूरतों को लागू करना चाहिए, उत्पाद स्वामी के व्यक्तिगत लक्ष्यों को नहीं।

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

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

SCRUM के 3 सिद्धांत: पारदर्शिता, अनुसंधान, अनुकूलन

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

नहीं, SCRUM एक शास्त्रीय प्रबंधक के लिए एक भयानक सपना है, और लोग "प्रक्रियाओं" में रहते थे।

इसलिए, वे आमतौर पर इस पूरी SCRUM प्रक्रिया को तोड़ने, अधिक नियंत्रण, कम पारदर्शिता और कोई अनुकूलन, विकास जोड़ने की कोशिश करते हैं।

सारांश के रूप में: SCRUM को दफनाने का सबसे अच्छा तरीका है उत्पाद स्वामी, पूर्व परियोजनाओं या अपने स्वयं के प्रबंधकों को नियुक्त करना।

पीओ, नेता नहीं।
पीओ को अद्वितीय क्षमताओं वाला व्यक्ति होना चाहिए - स्टैकर को देखने के लिए जहां अन्य उसे नहीं देखते हैं।
PO को यह समझना चाहिए कि कहाँ अधिक और कहाँ कम धन / मान और प्राथमिकता।
पीओ टीम को स्टैकर लाने में सक्षम होना चाहिए, जहां टीम खुद ही अपना उत्पाद बेच देगी।

और आगे

— ? , Scrum , , .

अच्छे लोगों को अच्छे लेख पढ़ने दें :)

SCRUM गाइड में लेखकों के छिपे हुए अर्थ क्या हैं। भाग 1. प्रक्रिया के बारे में

// SCRUM है - समझने में सरल

// SCRUM मास्टर करना मुश्किल है

स्टैंडअप, केवल विकास टीम के लिए!

उत्पाद स्वामी के साथ बैठकों में, टीम के पास समय का 10% से अधिक नहीं है, और एक मिनट से अधिक नहीं

टीम को ग्राहक की जरूरतों को लागू करना चाहिए, उत्पाद स्वामी के व्यक्तिगत लक्ष्यों को नहीं।

More articles: