क्या एजाइल डेवलपर्स वास्तव में काम करने के लिए अधिक समय बिताने के लिए मजबूर करता है?


25

सामान्य चंचल प्रथाओं को देखते हुए मुझे ऐसा लगता है कि वे (जानबूझकर या अनजाने में?) डेवलपर्स को अधिक समय बिताने के लिए मजबूर करते हैं, जो वास्तव में ब्लॉग / लेख, चैटिंग, कॉफी विराम और सिर्फ सादा पठन के विरोध के रूप में काम करते हैं।

विशेष रूप से:

1) जोड़ी प्रोग्रामिंग - सबसे बड़ा काम-काज, सिर्फ इसलिए कि जब आप दोनों एक साथ बैठे होते हैं तो यह सब करने में असुविधा होती है।

2) लघु कथाएँ - जब आपके पास काम का एक बड़ा हिस्सा होता है जो एक महीने में किया जाना चाहिए, तो पहले तीन हफ्तों में बंद करना और पिछले एक के लिए OMG DEADLINE मोड पर स्विच करना बहुत आम है।

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

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

4) परीक्षण और प्रतिक्रिया - फिर से, यह आपको "99% तैयार" (जब यह वास्तव में 20% के आसपास है) कार्यों को रखने से रोकता है जब तक कि मृत गति अचानक नहीं हो जाती।

क्या आपको लगता है कि एजाइल के तहत आप "पारंपरिक" कार्यप्रणाली से अधिक काम करते हैं? क्या यह दबाव अधिक आरामदायक वातावरण और वास्तव में जल्दी से सही चीजें प्राप्त करने की भावना से मुआवजा दिया गया है?



3
मुझे लगता है कि फुर्तीले प्रोग्रामर को और अधिक कुशलता से इसे और अधिक खुशी से बनाते हैं। के कारण यह विलंब पर काबू पाने, क्योंकि दो प्रोग्रामर एक दूसरे को देखता है, और कोड विचारों के आदान की भावना पर SE.com ब्लॉग पढ़ते समय, या सवालों का जवाब दे की तुलना में अधिक फायदेमंद है
tactoth

1
तो ऐसा लगता है कि एजाइल प्रोग्रामिंग ईपीआईसी विन है, क्या मैं सही हूं?
एडम अरोल्ड

2
"डेडलाइन प्रभाव" के बारे में सुना है? दक्षता लगभग समय सीमा के करीब दोगुनी हो जाती है - चंचल बोरियत (बेकार-समय) को संतुलित करने के लिए 2 सप्ताह की पुनरावृत्तियां रखता है चिंता के साथ आपको उत्पादक होने के कगार में रखता है!
पीएचडी

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

जवाबों:


38

चुस्त तरीकों के पीछे मुख्य विचार आपको उत्पादक होने में मदद करना है - एक सकारात्मक अर्थ में। अगर आप समय सीमा को पूरा करते हैं तो हर दिन एक घंटा सर्फिंग करने में किसी को कोई परवाह नहीं है। हर कोई पागल हो जाता है अगर आप हर दिन आधे घंटे सर्फ करते हैं लेकिन अपनी समय सीमा याद करते हैं। समाधान: समय सीमा को पूरा करना आपके लिए आसान है।

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

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

नेट परिणाम: मैं बहुत अधिक आराम कर रहा हूं (लगातार पर्यवेक्षण के बावजूद अधिक), टीम का सामंजस्य बहुत बेहतर है, काम अधिक तेज़ी से हो जाता है, लोग कुछ मामूली मुद्दों पर घंटों या दिनों तक नहीं लटकते हैं (क्योंकि कोई और कर सकता है) समस्या को बहुत तेजी से हल करें)।

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

परीक्षणों के लिए, एक मीठा स्थान है जब आपका कोड अचानक "अच्छा" से "पूर्ण" तक गिर जाता है। यही वह क्षण है जब आप देखते हैं कि आपको फीचर X को लागू करने की आवश्यकता है और आपने सोचा कि यह एक बुरा सपना होगा और अचानक महसूस होगा कि कोड लगभग है। बस एक छोटी सी यहाँ और वहाँ refactoring। एक नया वर्ग और किया। चार सप्ताह का काम अचानक एक दिन हो गया। विजय! ट्राइंफ!


20

मैं सहमत हूँ।

जोड़ा प्रोग्राम तैयार करना

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

छोटी कहानियाँ

टीम संचार और सामंजस्य

परीक्षण और प्रतिक्रिया

यस एजाइल और विशेष रूप से स्क्रैम एक विशाल उत्पादकता बूस्टर है। जब सही तरीके से लागू किया जाता है, तो टर्न ओवर 20% तक हो सकता है (5 डेवलपर कंपनी पर 1 डेवलपर)।

कारण सरल है: स्क्रम अधिक उत्पादकता प्रदान नहीं करता है, it provides the whole company with much more visibility on what's going on(पाठ्यक्रम के प्रबंधन सहित)।

  • यह एक डेवलपर के लिए सिर्फ नंगे न्यूनतम करने के लिए असंभव बनाता है। नंगे मिनियम अब टीम औसत है!

  • यह प्रबंधन के लिए ठीक से सहयोग नहीं करने के लिए असंभव बनाता है।

यही कारण है कि मैंने कहा (इसी तरह के प्रश्नों में मेरे अन्य उत्तरों में), कि एजाइल हर संगठन (और सभी के लिए) के लिए नहीं है।

उदाहरण के लिए, सार्वजनिक क्षेत्र वास्तव में एजाइल के लिए अनुकूल नहीं है।

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


7
पुन: थकावट। हम अपने कार्यालय में जोड़ी प्रोग्रामिंग करते हैं। यह 8 घंटे का सुपर गहन सामान है .... और फिर आप बस घर जा सकते हैं। सिलिकॉन वैली के केंद्र में 40 घंटे का कार्य-सप्ताह। (बर्नआउट को रोकने में मदद करता है)।

2
+1 "फुर्तीली हर संगठन के लिए नहीं है"।
रयान हेस

अच्छा जवाब। क्या आपके पास इसके लिए एक स्रोत भी है ("5 कंपनी पर 1 डेवलपर)"। पूरी कहानी पढ़ना दिलचस्प होगा।
Jan_V

@ जान_वी: केन श्वाबेर खुद (2008 में)। दुर्भाग्य से, यह दर्ज नहीं किया गया था।

+1: बहुत अच्छा जवाब। फुर्तीली विकास को अधिक सटीक रूप से पालन करने की अनुमति देता है लेकिन जरूरी नहीं कि वह उत्पादकता को बढ़ावा दे। कई प्रोग्रामर को प्रेरित करने के लिए जोड़ी प्रोग्रामिंग की आवश्यकता नहीं होती है: एक दिलचस्प समस्या उन्हें पंक्ति में 10 घंटे तक रखने के लिए पर्याप्त हो सकती है। कुछ स्थितियों में, SCRUM उत्पादकता में 50% या उससे अधिक की गिरावट कर सकता है। लेकिन इन सभी कहानियों को हमेशा समझाया जाता है: "आप इसे सही तरीके से नहीं कर रहे हैं।"
जियोर्जियो

8

क्या आपको लगता है कि एजाइल के तहत आप "पारंपरिक" कार्यप्रणाली से अधिक काम करते हैं? क्या यह दबाव अधिक आरामदायक वातावरण और वास्तव में जल्दी से सही चीजें प्राप्त करने की भावना से मुआवजा दिया गया है?

यह मुझे अधिक काम करता है, लेकिन सबसे बढ़कर, यह मुझे सही काम करने पर मजबूर करता है। किसी भी समय मुझे पता है कि मुझे क्या करना चाहिए

यह एक तरह का सकारात्मक दबाव है। यह कुछ बाहरी से काफी अलग है "आप पहले से ही कार्यक्रम के पीछे हैं, अधिक काम करते हैं, कोड ओवरटाइम!" -प्रेशर का दबाव।


7

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

फुर्तीली, मैं जो कुछ भी बनाता हूं, वह कुछ वितरण हैं।


4

हमारी कंपनी में,

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

लघु कथाएँ - फिर 3 सप्ताह के लिए बंद (लगभग 5-6 घंटे प्रति दिन) और अंतिम क्षण में (लगभग 12 से 14 घंटे प्रति दिन) एक डेवलपर के रूप में भागते हुए, एक डेवलपर के रूप में मुझे अपने काम के बोझ में दोलन करना पसंद नहीं है। प्रति दिन लगभग 8 घंटे काम करें और अपना शेड्यूल स्थिर रखें और यह हमेशा COOL दिखता है।

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

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

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


4

क्या आपको लगता है कि एजाइल के तहत आप "पारंपरिक" कार्यप्रणाली से अधिक काम करते हैं?

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

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

अब तक, मैंने दो स्क्रैम टीमों में भाग लिया, जो विभिन्न कंपनियों में काफी अलग-अलग परियोजनाएं बना रही हैं। दोनों टीमों में मैंने अपनी आदतों में कोई बदलाव नहीं देखा, जैसे कि जलप्रपात / पुनरावृत्ति।

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


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

@ जियोर्जियो हाँ मेरा मतलब कुछ ऐसा था कि जब "टीम काम करे तो ... अच्छा नहीं है" चुस्त पसंद करने का एक अच्छा कारण हो सकता है। मैं केवल यह नोट करना चाहता हूं कि तब भी, चुस्त होने की उम्मीद करते हुए उन्हें "अधिक काम" करने के लिए मजबूर करना स्वप्नलोक की तरह है ... या अधिक अच्छी तरह से काम करने के लिए थोड़ा बहुत सीधा। मैंने देखा है यह सफलतापूर्वक इस्तेमाल करने के लिए सिखाने के काम और योजना बेहतर / अधिक करने के लिए अनुभवहीन डेवलपर्स और बुरा योजनाकारों
कुटकी

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

@ जियोर्जियो सहमत हैं। जहाँ तक मैं आपको बता सकता हूँ कि मेरा रूपक बिलकुल सही है :)
gnat

2

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


2
प्रशस्ति पत्र की जरूरत। यह एक साहसिक दावा है; मैंने "फुर्तीले" वातावरण में बहुत व्यस्त काम देखा है।

2

जब आप दोनों एक साथ बैठे हों, तो यह सब करने में असुविधा होती है।

मैं असहमत हूं। मैंने धूम्रपान करने वालों के एक समूह के साथ काम किया और वे सभी विस्तारित अवधि के लिए एक साथ अपना ब्रेक लेने में कामयाब रहे क्योंकि "हर कोई ऐसा कर रहा था।"

पहले तीन हफ्तों में सुस्त होना

यह कार्यप्रणाली की परवाह किए बिना खराब प्रबंधन का संकेत है। यहां तक ​​कि अगर एक महीने में एक बहुत बड़ा हिस्सा है, तो मैं पहले सप्ताह के अंत में कुछ देखने की उम्मीद करूंगा।

आपको यह कहने के लिए कुछ भी नहीं है कि आप वास्तव में शर्म महसूस कर सकते हैं।

यदि आप तीन सप्ताह के लिए झटका देना चाहते हैं, तो आप कहने के लिए कुछ बकवास सोचेंगे।

4) परीक्षण और प्रतिक्रिया - फिर से, यह आपको "99% तैयार" (जब यह वास्तव में 20% के आसपास है) कार्यों को रखने से रोकता है जब तक कि मृत गति अचानक नहीं हो जाती।

झरना परियोजनाओं में परीक्षण और दैनिक बिल्ड हो सकते हैं।

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


1

एजाइल डेवलपर्स को अधिक काम करने के लिए बाध्य नहीं करता है , लेकिन अधिक कुशलता से काम करने के लिए


1
और अधिक उत्पादक, जो शब्दार्थ रूप से अधिक महत्वपूर्ण है।

हालांकि यह करता है?
केसी

0

इस सवाल का कि 'डेवलपर्स को और अधिक काम करने के लिए मजबूर करना' थोड़ा नकारात्मक है, लेकिन निश्चित रूप से यह सकारात्मक है अगर हम वास्तव में अधिक काम करते हैं और शिथिलता कम करते हैं?

उस ने कहा, यह एक अच्छी बात है। मैं इस साल चुस्त-दुरूस्त महसूस कर रहा हूं, लेकिन यह एक बड़ा अलिखित लाभ है जिसे मैं स्वीकार नहीं कर रहा था।

मैं सहमत हूँ कि चुस्त डेवलपर्स को और अधिक उत्पादक बना सकता है। दृश्यता, जवाबदेही, और कम करने की प्रवृत्ति के बारे में आपके बिंदु सभी बहुत सही हैं।

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


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

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

0

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

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

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


-2

"बंदूकें लोगों को नहीं मारतीं। लोग लोगों को मारते हैं!" एजिल के साथ भी ऐसा ही है। फुर्तीले लोगों को अधिक काम नहीं करते हैं, प्रबंधक लोगों को अधिक काम करते हैं।


2
प्रबंधक लोगों को अधिक काम नहीं करते। स्पष्ट दृश्यता और तेजी से प्रतिक्रिया से लोग अधिक काम करना चाहते हैं, इसलिए वे ऐसा करते हैं।
शॉन मैकमिलन

हां, लेकिन किस बात तक? एक स्प्रिंट में आप 10 कहानियां उठाते हैं, अगला स्प्रिंट: 15, अगला स्प्रिंट: 20, अगला स्प्रिंट: 25। कितने समय पहले टीम अपनी मानवीय सीमा तक पहुंचती है और वास्तव में फुर्तीले प्रबंधक इसे अधिक लेने का फैसला करते हैं। शायद आपने ऐसी स्थिति का सामना नहीं किया है। वास्तव में फुर्तीली परियोजना में आप अपनी टीमों के वेग को स्प्रिंट प्रगति के रूप में खोजते हैं। आप सबसे अधिक 10% मार्जिन के साथ काम करने में सक्षम हो सकते हैं। और कुछ नहीं।
डीपीडी

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

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