मैं कुछ पहलुओं को स्पष्ट करने की कोशिश करूंगा जिन्हें अन्य उत्तरों से संबोधित नहीं किया गया है और आईएमओ महत्वपूर्ण हैं।
मूल मुद्दा यह है: कुछ डेवलपर्स मुख्य रूप से मुश्किल काम का एक टुकड़ा लेने की खुशी से प्रेरित होते हैं, एक डिजाइन के माध्यम से सोच रहे हैं, संभावित मुद्दों के माध्यम से सोच रहे हैं, फिर समस्या का समाधान टुकड़ा द्वारा, दूसरों के साथ केवल न्यूनतम बातचीत के साथ बढ़ाया गया है समय की अवधि। वे आम तौर पर उच्च स्तर की गुणवत्ता और समय पर तरीके से काम पूरा करते हैं; उनका काम बनाए रखने योग्य है और समग्र वास्तुकला के साथ फिट बैठता है।
इस तरह के डेवलपर्स को फुर्तीले वातावरण के अनुकूल होना मुश्किल हो सकता है और उनके रवैये को अक्सर "परिवर्तन के लिए अनिच्छा" के रूप में खारिज कर दिया जाता है, संभवतः अहंकार से संबंधित या पुराने जमाने से संबंधित है।
अक्सर जो नजरअंदाज किया जाता है वह यह है कि जटिल समस्याओं को हल करने के लिए किसी को बहुत सारी जानकारी को संभालने की आवश्यकता होती है, और इसके लिए बहुत विश्लेषण, सोच, कोशिश, एक समाधान को स्केच करना, इसे फेंकना, एक और प्रयास करना पड़ सकता है। इस तरह की एक जटिल समस्या को कुछ घंटों से लेकर कुछ हफ्तों के केंद्रित काम की आवश्यकता हो सकती है जब तक कि आपके पास एक तैयार समाधान न हो।
एक दृष्टिकोण यह है कि एक डेवलपर समस्या विनिर्देश लेता है, उसके कमरे में जाता है, और समाधान के साथ दो / तीन सप्ताह बाद वापस आता है। किसी भी समय (जब आवश्यक हो), डेवलपर टीम के अन्य सदस्यों के साथ या हितधारकों (विशिष्ट मुद्दों पर सवाल पूछते हुए) के साथ कुछ बातचीत शुरू कर सकता है, लेकिन अधिकांश काम डेवलपर द्वारा किया जाता है जिसे कार्य सौंपा जाता है।
फुर्तीले परिदृश्य में क्या होता है? एक त्वरित विश्लेषण (संवारने) के बाद टीम समस्या को छोटे-छोटे खंडों (उपयोगकर्ता कहानियों) में तोड़ देती है। उम्मीद यह है कि उपयोगकर्ता कहानियां एक-दूसरे से स्वतंत्र होती हैं, लेकिन अक्सर ऐसा नहीं होता है: वास्तव में स्वतंत्र विखंडू में एक जटिल समस्या को तोड़ने के लिए आपको एक ज्ञान की आवश्यकता होगी जो आपको सामान्य रूप से कई दिनों तक काम करने के बाद ही मिलती है। दूसरे शब्दों में, यदि आप एक जटिल समस्या को छोटे स्वतंत्र भागों में तोड़ने में सक्षम हैं, तो इसका मतलब है कि आपने मूल रूप से इसे पहले ही हल कर लिया है और आपके पास केवल परिश्रम का काम बाकी है। एक समस्या के लिए, तीन सप्ताह के काम की आवश्यकता होती है, यह संभवतः दूसरे सप्ताह के दौरान होगा, न कि कुछ घंटों के बाद स्प्रिंट की शुरुआत में।
इसलिए, स्प्रिंट की योजना बनाई जाने के बाद, टीम एक समस्या के विभिन्न हिस्सों पर काम करती है जो संभवतः एक-दूसरे के बीच निर्भरता होती है। यह बहुत सारे संचार ओवरहेड उत्पन्न करता है जो विभिन्न समाधानों को एकीकृत करने की कोशिश करता है जो समान रूप से अच्छे हो सकते हैं लेकिन एक दूसरे से अलग हैं। मूल रूप से, एक अतिरिक्त संचार ओवरहेड (चतुष्कोणीय वृद्धि) के साथ शामिल सभी टीम के सदस्यों पर परीक्षण और त्रुटि कार्य वितरित किया जाता है। मुझे लगता है कि इनमें से कुछ समस्याओं को पॉल ग्राहम ने इस लेख में बहुत अच्छी तरह से चित्रित किया है, विशेष रूप से 7 अंक में।
बेशक, टीम के सदस्यों के बीच काम साझा करने से परियोजना छोड़ने वाले एक टीम के सदस्य से संबंधित जोखिम कम हो जाता है। दूसरी ओर, कोड के बारे में ज्ञान का अन्य तरीकों से संचार किया जा सकता है, जैसे कोड समीक्षा का उपयोग करना या सहयोगियों को तकनीकी प्रस्तुतियाँ देना। इस संबंध में, मुझे नहीं लगता कि सभी स्थितियों के लिए मान्य एक चांदी की गोली है: साझा कोड स्वामित्व और जोड़ी प्रोग्रामिंग एकमात्र विकल्प नहीं है।
इसके अलावा, "कम अंतराल के भीतर काम करने की कार्यक्षमता का वितरण" कार्य प्रवाह में रुकावट पैदा करता है। यह ठीक हो सकता है यदि कार्यक्षमता का हिस्सा "लॉगिन पृष्ठ में एक रद्द करें बटन जोड़ें" है जो एक स्प्रिंट के अंत तक पूरा हो सकता है, लेकिन जब आप एक जटिल कार्य पर काम कर रहे हैं तो आप इस तरह के व्यवधान नहीं चाहते हैं: यह ऐसा है जितनी जल्दी हो सके, यह जांचने के लिए हर 5 मिनट में जितनी जल्दी हो सके 100 किमी की कार चलाने की कोशिश करें। यह केवल आपको धीमा करने वाला है।
बेशक, लगातार चौकियों का मतलब किसी परियोजना को अधिक पूर्वानुमानित करना होता है, लेकिन कुछ मामलों में रुकावट बहुत निराशाजनक हो सकती है: व्यक्ति मुश्किल से गति प्राप्त कर सकता है कि यह पहले से ही कुछ को रोकने और प्रस्तुत करने का समय है।
इसलिए, मुझे नहीं लगता कि प्रश्न में वर्णित दृष्टिकोण केवल अहंकार या परिवर्तन के प्रतिरोध से संबंधित है। यह भी हो सकता है कि कुछ डेवलपर्स ऊपर वर्णित समस्या-समाधान के दृष्टिकोण को अधिक प्रभावी मानते हैं क्योंकि यह उन्हें उन समस्याओं की बेहतर समझ रखने की अनुमति देता है जो वे हल कर रहे हैं और जिस कोड को वे लिख रहे हैं। ऐसे डेवलपर्स को एक अलग तरीके से काम करने के लिए मजबूर करने के परिणामस्वरूप उनकी उत्पादकता में कटौती हो सकती है।
इसके अलावा, मुझे नहीं लगता कि टीम के कुछ सदस्य विशिष्ट, कठिन समस्याओं पर काम करते हैं, फुर्तीले मूल्यों के खिलाफ हैं। आखिरकार, टीमों को स्वयं-संगठित होना चाहिए और उस प्रक्रिया का उपयोग करना चाहिए जो उन्होंने वर्षों में सबसे प्रभावी पाया है।
बस मेरे 2 सेंट।
There’s a great story of a manager of a Coca-Cola plant whose numbers were far better than his peers. When asked what his “secret” was, he said simply that rather than take a best practice and modify it to meet what the plant did, he instead modified the plant to match the best practice.आप तब तक फुर्तीले नहीं होते, जब तक आप यह नहीं समझते कि आप ऐसा क्यों कर रहे हैं।