क्या चुस्त नया micromanagement है?


80

यह प्रश्न मेरे सिर में कुछ समय से पक रहा है, इसलिए मैं उन लोगों से पूछना चाहता था जो अपने विकास के वातावरण में चुस्त-दुरूह व्यवहार कर रहे हैं।

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

हाल ही में, मैंने उन डेवलपर्स से बात की जो इस पहल का हिस्सा हैं; वे मुझे बताते हैं कि यह मजेदार नहीं है। उन्हें अपने स्क्रम मास्टर द्वारा अन्य डेवलपर्स से बात करने की अनुमति नहीं है और कार्य क्षेत्र में किसी भी फोन कॉल को लेने की अनुमति नहीं है (जो शायद एक हद तक ठीक है)। उदाहरण के लिए, यदि मैं अपने मित्र से किक्स के लिए बात करना चाहता हूं, जो फुर्तीली टीम में है, तो मुझे स्क्रैम मास्टर की स्वीकृति के बिना अनुमति नहीं है; जो फुर्तीली टीम के ठीक बगल में बैठा है।

यह सब या चुस्त विचार किसी भी रुकावट से चुस्त डेवलपर्स के लिए एक पूर्ण वैक्यूम प्रदान करना है और उन्हें अच्छे 6+ उत्पादक घंटों में रखना है। ठीक है, दोस्तों, मैं कोई फुर्तीला गुरु नहीं हूं, लेकिन मैंने याहू एगाइल रोलआउट दस्तावेज और अन्य संगठनों के समान क्या पढ़ा है, यह मुझे यह एहसास दिलाता है कि चुस्त सस्ता नहीं है। टीमों में फुर्ती लाने और उन्हें वापस पटरी पर लाने के लिए सही मुद्दे पर संसाधनों और बजट की आवश्यकता होती है।

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

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

कृपया मुझे बताएं, अगर यह अधिक डॉलर के लिए स्वार्थी लाभ के उद्देश्य से इस्तेमाल की जाने वाली अच्छी प्रथाओं में से एक है? या हो सकता है, यह सिर्फ हम जैसे डेवलपर्स ही हैं और इस फुर्तीली टीम को लगता है कि वे ऐसे माहौल में काम करना पसंद नहीं करते जहाँ वे केवल इसलिए काम करते हैं क्योंकि वे काम पर हैं।


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

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

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

वे अपनी 5 मिनट की दैनिक बैठक कर रहे हैं। लेकिन उनकी टीम के बाहर किसी के साथ बातचीत या बातचीत करने की अनुमति नहीं है। सारा फोकस काम पर है।


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

28
ठीक है, आप फुर्तीली नहीं कर रहे हैं ...
CaffGeek

13
यह वास्तव में एक भाषण है। सवाल नहीं है।
JohnFx

8
प्रमाणित स्कैम मास्टर कोर्स में 2 दिन प्रबंधक को एक स्कैम मास्टर नहीं बनाते हैं, जैसे 24 घंटे खुद को 24 घंटे में पढ़ाने के साथ 24 घंटे आपको सक्षम सी ++ प्रोग्रामर नहीं बनाते हैं। वे सिर्फ गलत कर रहे हैं।
मैट

9
आवश्यक पढ़ना: अर्ध-सशस्त्र चंचल घोषणापत्र "हमने सलाहकारों को भुगतान करके और गार्टनर रिपोर्ट पढ़कर सॉफ़्टवेयर विकसित करने के नए तरीकों के बारे में सुना है ..."
gnat

जवाबों:


89

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


7
केवल एक चीज जो मुझे मिल सकती थी वह थी टॉप 12 चीजों पर एक "जोएल ऑन सॉफ्टवेयर" पोस्ट जो हर कंपनी को अपने प्रोग्रामर के लिए प्रदान करनी चाहिए। 12 में से एक काम करने के लिए एक शांत जगह थी। मुझे संदेह है कि जोएल स्पोल्स्की का यह मतलब था, हालांकि।
बेरिन लोरिट्श

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

5
@ केविन कैथार्ट, हम उस एक पर हिंसक समझौते में हैं। अब, मैं एक ऐसी कंपनी में हूं, जहां विपरीत सच था। हम खुली मेज और कोई क्यूब्स के साथ एक बुलपेन में ~ 40 लोग थे। एकमात्र टीम जो कुछ भी कर सकती थी, वह वही थी जिसने बहुमत का शोर मचाया। पर्यावरण का वह प्रकार जिससे आप बचाव करना चाहते हैं।
बेरिन लोरिट्श

8
@ केविन - मेरा विकास विभाग एक खुला क्यूबिकल फार्म है, जो "बिक्री", "बड़ी बिक्री" और "विशाल बिक्री" नामक तीन घंटियों की एक सरणी के ठीक बगल में है। दिन में कुछ बार, सेल्स वाले लोग रिंग करते हैं और "wooooo!" चिल्लाते हैं। : - \
डैन रे

2
@ मैं कुछ साल पहले साक्षात्कार का एक तार था, जहां तीन स्टार्टअप ने मुझे बताया था कि उन्हें बिक्री के लोगों को देवों से दूर ले जाना होगा क्योंकि वे भी थे! @ # $ जोर से आईएनजी।
एरिक रेपेने

46

उन्हें अपने स्क्रम मास्टर द्वारा अन्य डेवलपर्स से बात करने की अनुमति नहीं है और कार्य क्षेत्र में किसी भी फोन कॉल को लेने की अनुमति नहीं है

यह वास्तव में चंचल प्रथाओं का हिस्सा नहीं है - और एक अलग मुद्दा।

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


29
यह एजाइल मेनिफेस्टो के बहुत पहले सिद्धांत के खिलाफ है: "प्रक्रियाओं और उपकरणों पर व्यक्ति और बातचीत"। अधिक जानकारी के लिए agilemanifesto.org देखें ।
बेरिन लोरिट्श

"यह <XXX> घोषणापत्र" के पहले सिद्धांत के बिल्कुल खिलाफ है; XXX के लिए कुछ भी बदलें, और आपके पास अपनी पसंद का पंथ होगा। ;-) गंभीरता से, यह आपको आश्चर्य नहीं करता है?
सेसरगॉन

5
@ केसरगॉन, इस मामले में हम उन सिद्धांतों के बारे में बात कर रहे हैं जो चुस्त काम करते हैं। यदि आप चुस्त के मूल सिद्धांतों को नहीं लिख सकते हैं, तो शायद आप चुस्त नहीं हैं। बहुत साधारण। मैं यह नहीं कह रहा हूं कि "विश्वास में परिवर्तित करें", मैं कह रहा हूं "आप जो कहते हैं वह आप विश्वास करते हैं"। गंभीरता से, यह नहीं है कि आपको आश्चर्यचकित?
बेरिन लोरिट्श

1
@ केसरगोन, ओपी ने जो वर्णन किया है, वह उस दिशानिर्देश के इरादे के विपरीत है जो आपको मिल सकता है। आप अपने मध्य स्वर को किस बिंदु पर पर्याप्त मानते हैं? जिस तरह से आप बात कर रहे हैं, वह लगता है कि टन के बीच 95% अंतर काफी करीब है। चलो। और मुझे कुछ श्रेय दो। मैं लंबे समय से निगमों में वास्तविक दुनिया में काम कर रहा हूं और प्रक्रियाओं को परिभाषित कर रहा हूं। मैं अच्छी तरह से समझता हूं कि क्या पर्याप्त है - और ओपी ने जो वर्णन किया है, वह नहीं है।
बेरिन लोरिट्श

2
@ बरीन लोरिट्सच: मैं आपको श्रेय देता हूं; अन्यथा प्रकट होना मेरा उद्देश्य नहीं था। पंथ के बारे में मेरी प्रारंभिक टिप्पणी ने वास्तव में आंशिक रूप से मजाक करने की कोशिश की। मैं जिस बिंदु को बनाने की कोशिश कर रहा हूं, वह यह है कि हमें किसी चीज़ का बचाव करने के लिए घोषणापत्र पर कुछ पंक्तियों की आवश्यकता नहीं है, जो सामान्य ज्ञान के विरुद्ध है। ओपी एक ऐसी स्थिति का वर्णन करता है जो सभी अलार्मों की अंगूठी बनाती है। मुझे आशा है कि आप इसे अच्छी तरह से लेंगे; क्षमा करें यदि मैं बहुत कठोर था। :-)
सीजरगॉन

31

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


24

आप जिस वातावरण का वर्णन करते हैं, वह बगीचे की किस्म छद्म-फुर्तीली फुदकती है

मैं एजाइल से पहले ही एजाइल से जुड़ गया था। लगभग 2000 मैं कोडिंग पर जल रहा था, चरम प्रोग्रामिंग के बारे में सुना, इसे आज़माया, और इसे पसंद किया। इसने मुझे एक डेवलपर के रूप में एक संदर्भ दिया जहां ठोस सॉफ़्टवेयर का निर्माण सबसे महत्वपूर्ण बात थी, और इसने मुझे बहुत सारे बकवास को कम करने के लिए उपकरण दिए जो मुझे पागल बना रहे थे। मैं इसे प्यार करता था।

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

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

तो आपके सवाल का सीधा जवाब देने के लिए: चुस्त नया micromanagement नहीं होना चाहिए। यह वास्तविक काम कर रहे लोगों को सशक्त बनाने के बारे में होना चाहिए। लेकिन आपके मामले में, फुर्तीला लगता है कि नवीनतम झूठ वे आपको बता रहे हैं, जबकि वे अपनी बुरी प्रवृत्ति को भोगते हैं। जिसके लिए मुझे वास्तव में खेद है।


4
+1। Agile / scrum / xp या जो भी हैं वो सिर्फ "mumbo jumbo" शब्द हैं IT दुकानों के लिए जो वास्तविक सॉफ्टवेयर कंपनियां नहीं हैं। जैसा कि आपने कहा, इन प्रथाओं के साथ रेत में अपने सिर को दफनाने के दौरान कोई भी मौलिक परिवर्तन नहीं करता है। सभी को पढ़ने की जरूरत है यह महान लीन सॉफ्टवेयर डेवलपमेंट: ए एजाइल टूलकिट है और सभी बीएस को पीछे छोड़ दिया है। ये प्रैक्टिस आईटी की दुकानों के लिए नहीं है मेरा निष्कर्ष है।
स्मिथ जेम्स

23

यह फुर्तीली नहीं है।

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

ठीक है, रेंट ओवर!

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

मुझे ऐसा लगता है कि कोई तीसरा होना चाहिए। वहाँ नहीं है


-1, मैं सहमत नहीं हूँ। फुर्तीली विकास का अर्थ यह भी है कि आप प्रक्रियाओं को शुद्ध और सहज करते हैं और परिवर्तनों के अनुकूल होने की क्षमता भी। जो होता है ठीक वैसा ही होता है जैसे स्क्रैम के बारे में। Scrum भी आवश्यकताओं और योजना के बारे में है, बस अलग तरीके से।
फाल्कन

6
एह, c'mon, यह 2012 है। उद्धरण केंट बेक के सार्वजनिक लेखन या इसे छोड़ दें। इससे कोई फर्क नहीं पड़ता कि वह आपके सोफे पर फ्लैट है।
nes1983

6
@ nes1983: मैंने लिखा था कि 2011 में। चीजें तब अलग थीं।
टॉम एंडरसन

3
मैंने कभी भी "तकनीकी ऋण" शब्द नहीं सुना, जब तक कि मेरे रडार पर घोटाला नहीं हुआ। मैं ट्रेनिंग के लिए गया हूं। आसानी से बेचे जाने वाले स्नेक ऑइल का मतलब लंबे समय तक उत्पाद की गुणवत्ता के विचारों की कीमत पर प्रबंधन से अपील करना था। 100% बकवास। हालांकि मैं पूरी तरह से इसे निगल लूंगा अगर स्क्रैम मास्टर्स को उन लोगों को बर्बाद करने के लिए कॉनन-शैली की तलवार ले जाना पड़ा, जिन्होंने प्रक्रिया की अखंडता के लिए खतरा पैदा किया।
एरिक रिपेन

2
स्क्रम रैंट के लिए +1। मुझे लगता है कि स्क्रैम को उन लोगों के लिए "फुर्तीली" पद्धति के रूप में देखा जाता है जो झरना पसंद करते हैं, वे इसे हर दो सप्ताह में करना चाहते हैं।
क्लेरासेला

16

स्क्रैम एजाइल का हरामी बच्चा है। इसकी सभी फुर्तीली कार्यप्रणाली का सबसे झरना शैली है, और यही कारण है कि प्रबंधकों के बीच यह सबसे लोकप्रिय है।

सभी चुस्त तरीके रास्ते में हो रही बकवास के बिना काम कर कोड के उत्पादन के बारे में हैं। उसे फिर से पढ़ें। और फिर।

"फुर्तीले नियमों" की परवाह किए बिना उस लक्ष्य के रास्ते में जो कुछ भी मिलता है, वह बुरा है। यदि नियम रास्ते में मिलते हैं, तो f * * नियम बदलें ! यह चुस्त तरीका है, यही इसे प्रासंगिक और प्रभावी बनाता है।

इसका सबसे अच्छा उदाहरण एलिस्टेयर कॉकबर्न (चुस्त घोषणापत्र के प्रवर्तकों में से एक) द्वारा दिया गया है:

“4-6 लोगों को एक कमरे में रखें जिसमें वर्कस्टेशन और व्हाइटबोर्ड हों और उपयोगकर्ताओं तक पहुँच हो। उन्हें हर एक या दो महीने में उपयोगकर्ताओं को रनिंग, टेस्टेड सॉफ़्टवेयर वितरित करें, और अन्यथा उन्हें अकेला छोड़ दें। ”

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

आप कर रहे हैं चुस्त की तरह एक प्रतिक्रिया है। यही तो। इसे प्रिंट करें और इसे तब कहीं पिन अप करें जब कोई और आसपास नहीं है और उन्हें इसे खुद के लिए खोजने दें।


क्या उन्होंने उपयोगकर्ताओं को हर 2/3 सप्ताह में रनिंग, टेस्टेड सॉफ्टवेयर दिया है, आपका मतलब है?
user272671

2
@ user272671 सं। उन्हें नियमित रूप से उपयोगकर्ता के लिए चल रहे, परीक्षण किए गए सॉफ़्टवेयर वितरित करें। 2 या 3 सप्ताह की तरह एक मूर्खतापूर्ण मनमाने समय पर नहीं। यदि उपयोगकर्ता या सॉफ्टवेयर जटिलता ऐसी है कि 6 सप्ताह का चक्र काम करता है, तो 6 सप्ताह करें। यदि यह "जब पूरा हुआ" पर किया जा सकता है तो ऐसा करें। कृत्रिम बाधाओं के साथ अपने आप को बाधा न दें। ऐसा चुस्त नहीं है।
gbjbaanb

11

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

यह तुम्हारी समस्या है। प्रबंधन कुछ चपलता चाहते हैं, वे वास्तव में नहीं जानते कि यह क्या है, और वे इसे टीमों को देते हैं। जब आप अपने डेवलपर्स की उत्पादकता में काफी कमी करना चाहते हैं, तो यह बहुत अधिक है;)

नई प्रक्रिया का प्रस्ताव डेवलपर्स से आना चाहिए। या कम से कम समीक्षा और उनके द्वारा अनुमोदित किया जाना चाहिए अगर यह एक प्रबंधन का विचार है।

किसी भी मामले में, यदि डेवलपर्स इसे मना करते हैं, तो इसे लागू न करें ! या यह आपके द्वारा वर्णित आपदा होगी।


9

"फुर्तीली" और हर दूसरे "प्रबंधन पद्धति" को अक्सर लोगों पर micromanagement मजबूर करने के लिए दुरुपयोग किया जाता है। OTOH यह कभी-कभी खराब कारीगरी का बचाव करने के लिए भी दुर्व्यवहार किया जाता है।

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

पाठ्यक्रम के दो अक्सर प्रत्यक्ष विरोधाभास में हैं, और एक ही परियोजना पर हो सकता है।


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

1
जब भी मुझे सामना करना पड़ा है तो इसे पेश किया गया था क्योंकि एक प्रबंधक (आमतौर पर परियोजना प्रबंधक से अधिक) ने इसके बारे में "बात" होने के रूप में सुना था।
jwenting

7

आपके मूल प्रश्न का उत्तर देने के लिए, नया माइक्रो प्रबंधन चुस्त है, मैं कहूंगा कि नहीं।

सबसे पहले, इसे पढ़ें (एजाइल मैनिफेस्टो) और आप देखेंगे कि आपके सह-डेवलपर्स से बात नहीं करना सूचीबद्ध नहीं है।

वास्तव में "व्यक्ति और सहभागिता" आपके सह-डेवलपर्स से बात नहीं करने के बिल्कुल विपरीत है।


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

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

2

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

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

फुर्तीली टीमों को ऐसा महसूस नहीं करना चाहिए कि दिन-प्रतिदिन के काम को पदानुक्रम से प्रबंधित किया जाता है। यदि किसी पदानुक्रमित संगठन के शीर्ष पर किसी व्यक्ति द्वारा फैसले किए जाते हैं, तो यह निर्णय लेने के विकेंद्रीकरण का समय है! कुछ लोगों और कुछ संगठनों के लिए, यह बहुत दूर का पुल हो सकता है। यदि निम्नलिखित आपके संगठन का सच नहीं है:

एजाइल मैनिफेस्टो को जीते हैं

"हम सॉफ्टवेयर के विकास के बेहतर तरीकों को उजागर कर रहे हैं और इसे करने में दूसरों की मदद कर रहे हैं।"

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

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


1

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

जिन टीमों में मैंने काम किया है, हम सदस्यों के भीतर कामरेडरी को बेहतर बनाने के लिए काम के घंटों के बाद टीम गेम खेलने के लिए प्रोत्साहित होते हैं। मैंने उन विचारों को यहाँ एकत्र किया है


1
काम के बाद काम रिश्तों को विकसित करें, हमें काम के बाद अपने अक्सर उपेक्षित दोस्त और पारिवारिक रिश्तों को विकसित करना चाहिए। सह-श्रमिकों को ध्यान में रखते हुए शायद ही कभी दोस्त होते हैं, और दूसरों के खर्च पर खुद की मदद करने के लिए सबसे अधिक अवसर लेते हैं। कंपनी हां-मेन, क्रोनियों और टूल्स को इसका अहसास नहीं है, क्योंकि अवसर अनंत हैं। XP का कुछ मूल्य हो सकता है, मुझे अन्यथा कहने का कोई अनुभव नहीं है। कम से कम 3 या तो कंपनियों को पता है कि मैं इसे जानता हूं, स्क्रम माइक्रोमैनेजिंग का अलग संस्करण बन गया है। .... हां पता है, मैं कॉर्पोरेट अमेरिका से बहुत ज्यादा नफरत करता हूं, यहां तक ​​कि थोड़ा उद्देश्य भी।
जेएम बेकर

0

आपके प्रश्न का उत्तर देने के लिए: नहीं। चुस्त नहीं है। लेकिन किसी भी टूल की तरह, लोग इसका गलत तरीके से इस्तेमाल कर सकते हैं। चंचलता ठीक से लागू होने पर और जब लोग इसके अनुरूप होते हैं तो अद्भुत होता है।

"किसी से बात नहीं कर रहे हैं, लेकिन स्वामी गुरु" विषय पर मेरे विचार:

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

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

अन्यथा, देव एक दूसरे से बात कर रहे होंगे। हमेशा। यह आपको समस्याओं को तेज़ी से काम करने, टीम के रूप में करीब आने और तेज़ी से वितरित करने में मदद करता है।

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

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


-1

मूल लेखक स्मिथ जेनेस ने अनुभव दिया होगा। लेकिन ये सामान्य समस्याएं हैं जो मुझे एजाइल परियोजना में मिली थीं।

  1. अधिकांश संगठनों, डेवलपर्स को कई प्रोजेक्ट में काम करने के लिए माना जाता है, एजाइल / स्क्रैम में .. स्प्रिंट्स को कभी भी इस तथ्य पर विचार नहीं किया जाता है। आपके स्क्रम मास्टर का मानना ​​है कि आपको स्प्रिंट के अंत में अपनी कहानियों के साथ किया जाना चाहिए .. आपका स्क्रम मास्टर केवल एक परियोजना के लिए समर्पित हो सकता है, लेकिन डेवलपर्स नहीं .. इस कारण - केवल एक फोन कॉल लेने की आवश्यकता नहीं है या फोन कॉल की अनुमति देता है।
  2. मैंने फुर्तीली परियोजनाओं को देखा है जहाँ स्प्रिंट की योजना बनाई गई है, स्प्रिंट में शामिल कहानियां, बगैर हिले-डुले..फिरों के आधे रास्ते या बीच में .. डेवलपर्स आश्रितों को हल नहीं, आवश्यकताओं या कहानी को पूरा नहीं किया गया है ..... सबसे चुस्त परियोजनाओं में दुर्व्यवहार में से एक है।
  3. परीक्षण: टीटीडी .. हाँ यह बहुत अच्छा है .. लेकिन मैंने देखा है कि ज्यादातर एजाइल प्रोजेक्ट पूरी तरह से टीटीडी पर निर्भर हैं ... फ़ंक्शनल या ह्यूमन टेस्टिंग के लिए कोई स्कोप या समय की अनुमति नहीं है .. एक और एब्यूज़ ... लॉट ऑफ़ स्क्रैम मास्टर्स भी कार्यात्मक परीक्षण के महत्व को नहीं जानते या समझते हैं। हो सकता है कि आपका टुकड़ा सही काम कर रहा हो, अगर वह व्यापार की जरूरत को पूरा नहीं करता है .. तो इसका कोई फायदा नहीं है .. यह तब होता है जब व्यापार आगे अच्छी तरह से भाग नहीं लेता है .. या भागीदारी होती है ... लेकिन व्यवसाय निर्णय लेने को प्रतिबिंबित नहीं करता है .. अंत में, डेवलपर्स को दोषी ठहराया जाता है, आपने कार्यक्षमता को वितरित नहीं किया था..इसके साथ अंतिम मिनट में बदलाव होगा ... अतिरिक्त लंबे घंटे क्योंकि आपके स्कैम मास्टर को कहानी पूरी नहीं होने का दोष नहीं लेना है।

यहां दुर्व्यवहार ... या तो व्यापार की कम भागीदारी या प्रतिभागी पूरी तरह से जानकार नहीं है या व्यवसायी व्यक्ति स्प्रिंट के बीच में बाहर निकल रहा है।

  1. सभी परियोजनाएं फुर्तीली के लिए उपयुक्त नहीं हैं ... अधिकांश प्रबंधकों या स्क्रैम मास्टर्स को यह पता नहीं है .. रखरखाव परियोजनाएं .. एक दोष शुरू में माना जा सकता है 8 घंटे में किया जा सकता है, स्प्रिंट में स्वीकार किया जाता है। 4 घंटे खर्च करने के बाद, यह जावा / एक अन्य उत्पाद है ... (मैंने हाल ही में क्वार्ट्ज शेड्यूलर से संबंधित हमारी परियोजना से संबंधित दोष का सामना किया है) और इस दोष के कारण उत्पाद / पैकेज का उन्नयन हो सकता है। नौकरशाही, अनुमोदन के साथ संपर्क करें, फंडिंग, नए वर्जन या अपग्रेड को इंटरनल इंजीनियरिंग आदि द्वारा अनुमोदित किया जाना चाहिए। 5. रिट्रोस्पेक्शन: केवल मुट्ठी भर चपल प्रोजेक्ट्स ही यह कदम उठाते हैं।
  2. जोड़ीदार .. बहुत सारे डेवलपर्स सहकर्मियों के साथ दुर्व्यवहार करने के लिए स्थल के रूप में व्यवहार करते हैं .. अन्य डिजाइन, कोडिंग प्रथाओं की आलोचना करते हैं .. टीम वर्क के रूप में इलाज करने वाले रैटर। एक-दूसरे से सीखें ... दुर्व्यवहार करने का दूसरा तरीका / स्क्रम।

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


इस लिंक को देखें .. फुर्तीली परियोजनाएं क्यों विफल होती हैं .. brIIIubpm.com/agile/55778-why-do-agile-projects-fail
mukunda

मैं उस लेख में प्रस्तुत जानकारी से भी सहमत हूँ। मैं समझता हूं कि ऐसे लोग हैं जो सोचते हैं कि एजाइल अचूक है, लेकिन वास्तविकता यह है कि नए और अधिक प्रभावी विचारों की शुरूआत के लिए एजाइल बहुत कम या कोई जगह नहीं छोड़ता है। is..brIIIubpm.com / agile / 55778-Why-do-चुस्त-प्रोजेक्ट-विफल
user272671

-3

चंचल भेस में micromanagement है। एजाइल में पहल या रचनात्मकता के लिए कोई स्थान नहीं है, इसने प्रोग्रामिंग से मज़ा को अक्षम प्रबंधकों को तकनीकी दृष्टिकोण से नियंत्रण के बिना भी नियंत्रण रखने की अनुमति देने के लिए हटा दिया है।


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

आपके दावा (जो मेरे लिए कुछ समझ में आता है लेकिन यह है कि कोई फर्क नहीं पड़ता) का समर्थन करने के लिए कुछ तर्क जोड़ सकते हैं और मैं downvote हटा देंगे
कुटकी

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