2009-07-23 12 views
24

मेरी टीम धीरे-धीरे अधिक से अधिक हल्के तरीके से अपनाने जा रही है, जो स्क्रम से लीन/कानबान तक जा रही है जहां कम और कम औपचारिक प्रक्रिया है। किसी बिंदु पर हम काउबॉय कोडिंग पर वापस आ जाएंगे; वास्तव में मुझे डर है कि हम सीमा रेखा पर पहले से ही हो सकते हैं।दुबला प्रोग्रामिंग काउबॉय कोडिंग कैसे रोकें?

लाइन बहुत हल्के दुबला और फुर्तीली प्रक्रिया और अराजकता के बीच कहां खींची जा सकती है? जब हम लाइन पार कर चुके हैं तो हम कैसे जानेंगे? और हम खुद को लाइन पार करने से कैसे रोक सकते हैं?

प्रश्न को भी phrased किया जा सकता है, 'अपशिष्ट को खत्म करने के लिए लीन के ड्राइव में कौन सी प्रक्रियाओं को सुरक्षित रूप से समाप्त नहीं किया जा सकता है'?

उत्तर

24

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

+21

देखो: "इस कार्यक्रम के हम दोनों के लिए काफी बड़ा नहीं है" – dwarring

+5

+1 "आप पानी के फव्वारे पर उच्च दोपहर में मुलाकात करें": काउबॉय कोडिंग == अकेले कोडिंग। एक दुबला वातावरण में रोकने के लिए आसान है। किसी को भी अकेले काम न करने दें। –

4

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

अन्य चेतावनी के संकेत है कि मैं ध्यान दें चाहते हैं के एक जोड़े हैं:

  • टीम एक कोडन मानक और उस स्तर को बनाए रखने के लिए एक प्रतिबद्धता है?
  • क्या एक व्यक्ति से "रिफैक्टरिंग" करने वाले कोड में कोड परिवर्तन का एक गुच्छा है जो कोई और सोचता है वह सार्थक नहीं है?
3

मुझे लगता है कि अगर आप किसी प्रकार की कोड समीक्षा रखते हैं, तो यह इस तरफ बहुत गलत नहीं हो सकता है। यदि कोई भी नहीं जानता कि अन्य प्रोग्रामर क्या कर रहे हैं और वे इसे कैसे कर रहे हैं, तो हो सकता है कि आप इस लाइन को पार कर चुके हों।

2

शायद चेतावनी संकेतों की कोई निश्चित सूची नहीं है, यदि आप देखते हैं कि आप काउबॉय क्षेत्र में हैं। निजी तौर पर, अगर लोग अवांछित कोड जारी कर रहे हैं, तो उन विशेषताओं को विकसित करना जो निश्चित रूप से समझ में नहीं आते हैं, या फिर भी काम को घुमाते हैं या चेतावनी संकेतों को अनदेखा करते हैं, मैं चिंतित हूं।

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

1
  1. अपने स्वचालित इकाई परीक्षणों को कभी न भूलें।
  2. अपने कार्यात्मक परीक्षण कभी न भूलें।
  3. अपने परीक्षण कभी न भूलें।

(मैं दोषी किया गया है)

0

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

+0

हालांकि यह चीजों को डालने का एक मजेदार तरीका है, लेकिन यह वास्तव में – BobMcGee

14

मुमकिन है आप प्रभाव चरवाहे कोडिंग के बारे में चिंतित हैं:

  • कोई आवश्यकताओं
  • कोई डिजाइन
  • कोई परीक्षण
  • उपयोगकर्ताओं से कोई प्रतिक्रिया
  • कोई शेड्यूल
  • अनजान
  • बस कारक
  • ...

जब तक आप एक योजना/तंत्र/प्रक्रिया इन बुरे प्रभावों से बचने के लिए है, तो आप ठीक कर रहे हैं के रूप में; सही?

1

कम और कम औपचारिक प्रक्रिया है। कुछ बिंदु पर हम काउबॉय कोडिंग पर वापस आ जाएंगे ...

Agile/Lean/Scrum "प्रक्रिया" की विडंबना यह है कि कम औपचारिक प्रक्रिया काउबॉय प्रोग्रामिंग का कारण नहीं बनती है।

इन तरीकों को पसंद करते हैं "प्रक्रिया से अधिक लोगों को" हालांकि, इस प्रक्रिया को पूरी तरह से छोड़ नहीं है; प्रबंधन अभी भी आवश्यक है। एक दिन के अंत में आप अभी भी अपने ग्राहकों और समय सीमा के प्रति प्रतिबद्धता रखते हैं। गायों में इन प्रतिबद्धताओं को फिर से बनाना चाहिए।

-1

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

+0

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

0

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

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

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

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

1

"सुरक्षित रूप से करने के झुक ड्राइव में समाप्त अपशिष्ट को समाप्त क्या प्रक्रियाओं नहीं किया जा सकता?"

यह एक बहुत ही सामान्य प्रश्न है जिसे सटीक रूप से जवाब देना मुश्किल है।

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

2

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

एग्इल का "स्व-संगठन" अक्सर इस शब्द को अधिक अर्थहीन रूप से प्रस्तुत करने के बिंदु से दुर्व्यवहार किया जाता है क्योंकि विकास दल अवसरवादी रूप से इसका अर्थ "आत्म-निर्धारण" का अर्थ देते हैं।

प्रबंधन के लिए एक लीन संगठनात्मक दृष्टिकोण हमारे द्वारा उपयोग किए जाने वाले कार्यों से एक महत्वपूर्ण अंतर हो सकता है - यहां तक ​​कि Agile टीमों से भी। और यह संगठन और दिशा और इसके संगठनात्मक यांत्रिकी का यह मुद्दा है जो सभी अंतर बनाता है।

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

लीन Agile से कहीं अधिक संगठनात्मक परिवर्तन है। यदि आप संगठन में निदेशकों की भूमिका नहीं बदलते हैं, तो आप शायद लीन के सबसे अधिक सामग्री और यांत्रिक पहलुओं तक पहुंचने की संभावना समाप्त कर सकते हैं, और संभवतः सबसे बेवकूफ तरीकों से।

किसी भी संगठन में किसी भी संगठन को बदनाम होने से रोकने के लिए, उन्हें अपेक्षाओं को पूरा करने के लिए निर्देशित करने की आवश्यकता है। एक दुबला संगठन में निदेशक की भूमिका सिर्फ एक धमकी नहीं है, हालांकि। एक दुबला संगठन (विकास दल, आदि) में एक निदेशक भी एक कुशल कार्यकर्ता है और दूसरों को उन उम्मीदों को पूरा करने के लिए आवश्यक कौशल को पढ़ाने में सक्षम है जिन्हें उन्होंने जिम्मेदारी स्वीकार कर ली है।

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

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

-1

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

0

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

यदि आप उन प्रक्रियाओं का उपयोग करना बंद कर देते हैं जो आपको कुशलतापूर्वक मूल्य का उत्पादन करने में मदद करते हैं, तो आप या तो कम मूल्य उत्पन्न करेंगे या मूल्य कम उत्पादन करेंगे।

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

यदि आप मूल्य की अपनी डिलीवरी को मापने के लिए वेग या चक्र समय का उपयोग नहीं कर रहे हैं, तो आप पहले ही लाइन पार कर चुके हैं! जैसे बयानों के लिए

संबंधित मुद्दे