घोटाले के बारे में शॉर्ट्स

लचीला सरोगेट

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

दर्शन की तुलना में रूपरेखा बहुत सरल है। मुख्य बात यह है कि लक्ष्य को सरल किया गया है, या बाहर फेंक दिया गया है।

दर्शन का उद्देश्य: परिणामों की उपलब्धि में तेजी लाना। इसके अलावा, कई बार। पुस्तक में 8 गुना त्वरण उदाहरण हैं।

फ्रेमवर्क का लक्ष्य स्क्रम है। ऐसा कहता है: निर्देशों के अनुसार करें - आपके पास स्क्रम है, निर्देशों का उल्लंघन करें - आपके पास स्क्रम नहीं है।

फ्रेमवर्क सामान्य रूप से, परिणाम की उपलब्धि को तेज नहीं करता है।

जो लोग स्क्रैम को सिखाते हैं या कार्यान्वित करते हैं वे रूपरेखा के साथ काम करते हैं। वे बात करते हैं और एक एल्गोरिथ्म को लागू करते हैं जो "अब हमारे पास स्क्रैम है" के अलावा किसी भी परिणाम का नेतृत्व नहीं करता है।

बात साफ है। दर्शन को बेचना बहुत मुश्किल है। ढांचा सरल है।

एक फ्रेमवर्क एक उत्पाद है। उन्होंने उम्मीद के मुताबिक, "पैकेजिंग" पास की। यह सरल, समझने योग्य है, समर्थन और कई विशेषज्ञ हैं। क्या यह कुछ भी समान है?

परिणाम के अलावा सब कुछ अच्छा है - यह नहीं है।

यदि ग्राहक स्क्रैम दर्शन से परिचित नहीं है, तो रूपरेखा का कार्यान्वयन उसे पूरी तरह से सूट करेगा।
यदि ग्राहक स्क्रैम दर्शन से परिचित है, तो वह रूपरेखा के कार्यान्वयन से निराश होगा - परिणाम प्राप्त करने में कोई त्वरण नहीं होगा।

यह शांत, फैशनेबल, आधुनिक होगा, लेकिन कोई व्यावसायिक लक्ष्य हासिल नहीं किया जाएगा ("कुछ नया" के लिए बजट के विकास को छोड़कर)।

कैसे हो? स्करम के दर्शन को जानें। यह गुणवत्ता प्रबंधन के जापानी दर्शन पर आधारित है, जिसका सार है: माप और अंतहीन सुधार।

दुर्भाग्य से, वहाँ आपको सोचना, प्रयोग करना, निरीक्षण करना और, बहुत काम करना है। यदि यह आपके अनुरूप नहीं है, तो रूपरेखा लें।
habr.com/ru/post/345540

चर वातावरण

प्रोग्रामर की एक टीम की दक्षता बढ़ाने के लिए, आपको एक पारस्परिक वातावरण की आवश्यकता है। टीम में पहले से ही किसी तरह का माहौल है - हमें इसे परिवर्तनशील बनाने की जरूरत है।

एक परिवर्तनशील वातावरण औपचारिक, अनुमोदित कार्य एल्गोरिदम की कमी है।

प्रोग्रामर एल्गोरिथम पर काम करना पसंद करते हैं, क्योंकि वे स्वयं एल्गोरिदम के निर्माण में लगे हुए हैं।
एक परिवर्तनशील वातावरण डीबगिंग का एक प्रकार है, यह प्रोग्राम एल्गोरिथ्म नहीं है जो डीबगिंग है, बल्कि टीम का काम है।

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

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

यह, मोटे तौर पर बोल रहा है, कैसे प्रोग्राम कोड को तुरंत लिखना है, एक भी शुरुआत के बिना। नहीं, कभी-कभी मज़े करना संभव है, लेकिन सभ्य कार्यों पर यह दृष्टिकोण काम नहीं करता है - आपको बहुत स्मार्ट होना चाहिए। परस्पर वातावरण में डिबगिंग करना बहुत आसान है।
habr.com/ru/post/345830

स्क्रम गुरु

पुस्तक में वर्णित क्लीन स्क्रैम, जब सही तरीके से लागू किया जाता है, तो टीम की दक्षता 2 गुना बढ़ जाती है। यह अभ्यास में परीक्षण किया गया है।

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

बुक स्क्रम में तीन स्तर शामिल हैं:

• शिउ की स्थिति ("अनुपालन") नियमों से विचलित किए बिना पहला चरण, ट्रेन, दोहराना, है;
• स्टेट हा ("के माध्यम से तोड़") - हम नियमों को बदलना शुरू करते हैं, सुधार;
• री राज्य ("अलग") - हम नियमों से मुक्त हो जाते हैं और निर्माण करना शुरू करते हैं।

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

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

पहले स्तर पर, स्क्रैम मास्टर के पास पूरी तरह से अलग जिम्मेदारियां हैं। इंटरनेट पर जाँच करें, सूची कुछ इस तरह होगी:

ओह

• रैलियों का आयोजन और आयोजन;
• घोटाले के सिद्धांतों का अनुपालन;
• सहयोग का माहौल बनाता है;
• संघर्ष को हल करता है और टीम की सुरक्षा करता है।

दक्षता में सुधार के बारे में एक शब्द भी नहीं। बस निर्देशों का पालन कर रहा हूं।

यदि आप तार्किक रूप से सोचते हैं, तो अगर टीम लगातार समान नियमों के अनुसार काम कर रही है, तो दक्षता कैसे बढ़ सकती है? कुछ बदलने के लिए, आपको कुछ बदलने की जरूरत है। लेकिन आप ऐसा नहीं कर सकते - निर्देशों के अनुसार इसकी अनुमति नहीं है। इसलिए, पहले स्तर पर दक्षता नहीं बढ़ती है।

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

निर्देश जारी करना और इसके कार्यान्वयन की निगरानी करना बहुत आसान है। खैर, कभी-कभी सुविधा के लिए (जो भी इसका मतलब है)।

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

एक स्कैम मास्टर की भूमिका एक प्रोग्रामर के समान होती है, जो किसी एप्लिकेशन के प्रदर्शन का अनुकूलन करता है। केवल यहां की प्रणाली जीवित है, लोगों से बाहर है।
habr.com/ru/post/346158

सिस्टम जमा करना

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

हमारे देश में, अवज्ञा को हमारे राज्य के सदियों पुराने इतिहास की बदौलत विकसित किया गया है।

प्रणालीगत अवज्ञा से अजीब प्रतिक्रिया होती है: नए नियम और कानून इस तथ्य को ध्यान में रखते हुए बनाए जाते हैं कि कोई भी उनका अनुपालन नहीं करेगा।

यह संगठनात्मक परिवर्तन के लिए विशेष रूप से सच है। उनका लेखक इस विकल्प पर भी विचार नहीं करता है कि लोग प्रस्तावित नियमों के अनुसार काम करेंगे। इसलिए, यह नियमों की प्रवर्तनीयता और पर्याप्तता के बारे में परेशान नहीं करता है।

हालाँकि, सफलतापूर्वक लागू किए गए परिवर्तनों के उदाहरण हैं। चौराहों पर एक ही वीडियो कैमरा लें।

औपचारिक रूप से, चौराहे पर ड्राइविंग के लिए जुर्माना, जिस पर यातायात जाम है, लंबे समय से मौजूद है। लेकिन यह नियम व्यावहारिक रूप से नहीं देखा गया था।

अब यह पूरी तरह से अलग चौराहों पर मनाया जाता है। उन पर जहां वीडियो कैप्चर कैमरे लगे हैं।

कैमरा सिर्फ सिस्टम सबमिशन प्रदान करता है। जैसे ही लोगों ने नियम का पालन करना शुरू किया, यह स्पष्ट हो गया कि नियम ही काफी काम करने वाला था। एक ही नियम जो एक साथ हुआ करता था उसे किसी प्रकार का बकवास माना जाता था।

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

सिस्टम सबमिशन प्रदान करना बहुत सरल है। आपको खुद से शुरुआत करनी होगी। यह प्रणालीगत आत्म-प्रस्तुत होगा।

अपनी टीम पर स्क्रैम का परिचय? बिना किसी अपवाद के, सभी घोषित नियमों का पालन करें। हर दिन, बिना पास के।

आप तुरंत कार्यप्रणाली के फायदे और नुकसान देखेंगे - यह, और कोई भी।

यदि सफलता है, तो आप कारण होंगे। यदि विफलता है, तो आप कारण होंगे।
habr.com/ru/post/346712