"सर्जिकल टीम" पैटर्न का "माइथिकल मैन-मंथ" से क्या हुआ?

164

वर्षों पहले, जब मैंने द मैथिकल मैन-मंथ पढ़ा, तो मुझे बहुत सारी चीजें मिलीं, जो मुझे पहले से ही अन्य स्रोतों से पता थीं। हालाँकि, वहाँ भी नई चीजें वहाँ थीं, जबकि पुस्तक 1975 से थी। उनमें से एक थी:

सर्जिकल टीम

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

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

ऐसा क्यों है?

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

development-process patterns-and-practices

— VOG
स्रोत

12

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

— व्योम

43

एक संभावित समस्या जिसे मैं देखता हूं जब आप जानबूझकर एक टीम को व्यवस्थित करने का प्रयास करते हैं, तो यह है कि सर्जन कौन होना चाहिए।

— बार्ट वैन इनगेन शेनौ

9

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

— कोड_ड्रेड

7

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

— alephzero

6

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

— डेमॉन

103

"द मैथिकल मैन-मंथ" उस साल बाहर आया था जब मैंने कॉलेज शुरू किया था और वर्तमान वर्नाक्यूलर, UUUGE का उपयोग करने के लिए था! :-) आपको जिस चीज़ को समझने की ज़रूरत है, वह इस बात में अंतर है कि सॉफ़्टवेयर को अब बनाम कैसे विकसित किया गया था। बैक इन द डे (tm) पहले बहुत सारे कोडिंग कागज़ों पर किया गया था, फिर इसे कीपंच किया गया (आपने अनुमान लगाया) कार्ड चिपकाए गए, फिर इनको पढ़ा गया, संकलित किया गया, लिंक किया गया, निष्पादित किया गया, परिणाम प्राप्त किए गए, और इस प्रक्रिया को दोहराया गया। सीपीयू का समय महंगा थाऔर सीमित संसाधन और आप इसे बर्बाद नहीं करना चाहते थे। Ditto और इसी तरह डिस्क स्थान, टेप ड्राइव समय, आदि, blah। एक कंपाइल पर पूरी तरह से अच्छा CPU समय बर्बाद करना, जिसके परिणामस्वरूप (शॉक और हॉरर!) त्रुटियां थीं ... ठीक है, पूरी तरह से अच्छा सीपीयू समय की बर्बादी। और यह 1975 में था। उस समय जब फ्रेड ब्रुक्स अपने विचारों को विकसित कर रहे थे, जो 1960 के दशक के मध्य तक था, सीपीयू और भी अधिक थामहंगी, मेमोरी / डिस्क / जो कुछ भी अधिक सीमित था, आदि, सर्जिकल टीम के पीछे का विचार यह सुनिश्चित करना था कि वन सुपर ग्रेट रॉकस्टार डेवलपर को डेस्क-चेकिंग कोड, कीपंचिंग जैसे सांसारिक कार्यों पर एचआईएस समय बर्बाद नहीं करना था। परिणाम के लिए (कभी-कभी घंटों के लिए) प्रतीक्षा करते हुए, नौकरी सबमिट करना। रॉकस्टार ड्यूड डेवलपर मैन को CODE लिखा जा रहा था। गुटों / क्लर्कों / कनिष्ठ डेवलपर्स के अपने दिग्गजों को सांसारिक सामान करना चाहिए था।

समस्या यह थी कि ब्रूक्स की पुस्तक के 2 वर्षों के भीतर सर्जिकल टीम के पीछे मूल विचारों को प्रकाशित किया जा रहा था:

CRT टर्मिनल और डिस्क फाइलें कीपंच और कार्ड डेक को बदलने के लिए शुरू हुईं। कंप्यूटर का समय कम खर्चीला हो गया, कई कंप्यूटर उपलब्ध हो गए और नौकरी बदलने का समय नाटकीय रूप से कम हो गया। जब मैं कॉलेज गया (मियामी विश्वविद्यालय, ऑक्सफोर्ड, ओहियो, '79 का वर्ग, पूछने के लिए धन्यवाद) अच्छानौकरी में करीब एक घंटे का समय था। फाइनल सप्ताह के दौरान - चार घंटे, शायद, कभी-कभी छह। (हमने व्यावसायिक कंपनियों और विश्वविद्यालयों के एक समूह के साथ सीपीयू समय के लिए प्रतिस्पर्धा की - और वाणिज्यिक उपयोगकर्ताओं को पहली प्राथमिकता मिली)। मेरे वरिष्ठ वर्ष के दौरान, जिस बिंदु से मियामी ने अपने "साझा कंप्यूटर" व्यवस्था से बाहर निकल गए थे, परिसर में अपना स्वयं का आईबीएम 370/145 स्थापित किया था, और एक अच्छा एचपी मिनी था मैंने उस पर काम किया था जो एक आरजेई स्टेशन के रूप में काम करता था जिसे हम मेनफ्रेम कर सकते थे। पाँच मिनट या उससे कम में नौकरी। HP पर अपना कोड धमाका करने के लिए अब यह उचित था कि HP से मेनफ्रेम में भेजें, अपने अंगूठे / सिगरेट को सुखाएं और अपने कोड को डेस्क-चेक करने से पहले अपना आउटपुट वापस पाएं।
सर्जिकल टीम के मूल आधार के रूप में यह विचार है कि आप (या "प्रबंधन", ईश्वर हम सभी की मदद) रॉकस्टार सर्जिकल डेवलपर दोस्त की पहचान कर सकते हैं। वास्तव में, मुझे संदेह है कि यह संभव है। वहाँ रहे हैं रॉकस्टार डेवलपर्स, हर कोई यह जानता है - पढ़ाई के रूप में ज्यादा के रूप में 2000% का सबसे अच्छा और सबसे खराब डेवलपर्स के बीच उत्पादकता में अंतर से पता चला है - लेकिन यह है कि व्यक्ति की पहचान करने के लिए उन्हें समय की एक लंबी अवधि में कोड लिखने के बिनासबसे अधिक संभावना असंभव है। यह जानने का एकमात्र तरीका है कि अगर कोई रॉकस्टार डेवलपर है तो उन्हें वास्तव में कोड विकसित करना होगा - लेकिन यदि वे रॉकस्टार सर्जिकल डेवलपर यार नहीं हैं तो वे अपने कोड की डेस्क-चेकिंग, कार्ड पर कीपंचिंग जैसे रोमांचक काम करेंगे, और जॉब एंट्री डिपार्टमेंट के लिए पंच किए गए कार्ड के बॉक्स को खोलना, फिर परिणामों के इंतजार में खड़े रहना ताकि वे उन्हें श्री रॉकस्टार सर्जिकल डेवलपर डूड पर वापस जाने के बजाय केवल उसी तरह से कोड करने के लिए सीख सकें जो वास्तव में काम करता है - कोड, डिबेट कोड लिखकर। और आदि बैक इन द डे (टीएम) में कोई प्रोग्रामिंग प्रतियोगिता नहीं थी, कोई स्टैक ओवरफ्लो नहीं था, आपके पास एक पीसी नहीं था जब भी आप ऐसा महसूस करते हैं, तो आप कोड लिख सकते हैं। इडियट्स किताबों के लिए कोई एल्गोरिदम नहीं थे - प्रोग्रामिंग सीखने का एकमात्र तरीका स्कूल जाना था और उस चीज़ में प्रमुख था जहां आपको थोड़ी प्रोग्रामिंग करनी थी। लेकिन प्रोग्रामिंगप्रति se को गंभीरता से नहीं लिया गया था, और यह माना जाता था कि कुछ लोग ऐसा नहीं करना चाहते थे । मेरे पहले कॉलेज के पाठ्यक्रम में (SAN151 - परिचय टू सिस्टम एनालिसिस, डॉ। टॉम शेबर - धन्यवाद, टॉम :-) हमें प्रशिक्षक द्वारा बताया गया था कि "... हमें सिर्फ इस तथ्य का सामना करना पड़ा था कि हमें खर्च करना होगा प्रोग्रामर के रूप में कुछ साल पहले हम सिस्टम एनालिस्ट बन सकते हैं ”। "दो साल?", मैंने सोचा। "मैं केवल दो साल के लिए ऐसा करना चाहता हूँ?"? मैं गंभीर रूप से चकरा गया था । शुक्र है कि वह गलत था और मैं तब से बहुत कोडिंग कर रहा हूं। :-)
सर्जिकल टीम मानती है कि प्रोग्रामर अपेक्षाकृत दुर्लभ संसाधन हैं। यह वास्तव में कुछ और साल लग गए, लेकिन 80 के दशक की शुरुआत में पीसी के आगमन के साथ कुछ ऐसा हो गया कि कोई भी गीक इसमें शामिल हो सकता है। कंप्यूटर की कीमत गिरना शुरू हो गई, विकास उपकरण की कीमत गिरना शुरू हो गई, और यह सब हो गया। ओलों टर्बो पास्कल - आज के मानकों से यह बहुत ज्यादा नहीं था, लेकिन उस समय यह लगभग 40 रुपये के लिए एक पूर्ण पास्कल आईडीई था, जो बिल्कुल पागल था! अब कोई भी प्रोग्रामिंग में शामिल हो सकता है - यदि आप एक कंप्यूटर का खर्च उठा सकते हैं, और जब आईबीएम ने पीसीआरआर (हां) रखने का फैसला किया, तो मेरा पहला पीसी आईबीएम की सबसे बड़ी गलतियों में से एक था :) बिक्री पर लगभग $ 500 में उन टर्की से छुटकारा पाने के लिए, नकद हर जगह गिरे हुए शिकारों ने एक महीने के लिए अपने किराए के भुगतान को छोड़ दिया ("हाँ, उह, मुझे पता है, लेकिन मैं, उह ... मेरी उवुला को तोड़ दिया और सर्जरी करनी थी और .. .उह ... हाँ, अगले हफ्ते, कोई समस्या नहीं, धन्यवाद, आदमी ...) और चूसा 'उन्हें आग-बिक्री की कीमतों पर। फिर हमने इसे उपयोग करने योग्य बनाने के लिए कंप्यूटर पर ऐड-ऑन के लिए अधिक भुगतान किया। ("हाँ, यार, अगले हफ्ते, पक्का, शायद ..." :-)

जो बात मुझे बहुत दुखी करती है, वह यह है कि आज भी अगर आप लोगों से पूछते हैं कि क्या उन्होंने कभी "द मैथिकल मैन-मंथ" पढ़ा है या इसके प्रमुख पाठ को समझते हैं ("किसी लेट प्रोजेक्ट में संसाधनों को जोड़ना बाद में बनता है") तो वे आपको एक रिक्तता प्रदान करते हैं। घूरना - और फिर ठीक वैसी ही त्रुटियां करने के लिए आगे बढ़ें, जैसा कि ओएस / 360 के विकास के दौरान ऑल वे इयर्स एगो बनाया गया था। सभी पुराना अब फिर से नया है... :-}

— बॉब जार्विस
स्रोत

20

यदि इसे पढ़ने वाले किसी व्यक्ति के पास पुस्तक की 20 वीं वर्षगांठ का संस्करण है, तो यह नए प्रस्तावना और नए अध्याय 19 को पढ़ने के लायक है। जबकि 20 वीं वर्षगांठ का संस्करण 2017 तक 20 वर्ष से अधिक पुराना है, लेखक ने इसमें कई कथनों का उल्लेख किया है। इस उत्तर को जो अक्सर पूरी पुस्तक को संक्षेप में प्रस्तुत करने की हड़बड़ी में नजरअंदाज कर दिया जाता है क्योंकि "पहले से ही देर से परियोजना में इंजीनियरों को जोड़ने से यह और भी देर हो जाती है।"

1

दुनिया में "UUGE" का क्या मतलब है? शानदार जवाब, वैसे।

— वेन कॉनराड

5

@WayneConrad विशाल के लिए शानदार ।

— zzzzBov 16

1

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

— जो मैकमोहन

1

बार-बार एक ही तरह की त्रुटियां करने के बारे में आपकी टिप्पणी के जवाब में, पुस्तक के विकिपीडिया लेख में आपके द्वारा पसंद किए जाने वाले लेखक का एक उद्धरण है: परियोजना विकास में प्रबंधकों द्वारा इस तरह की त्रुटियों को दोहराने की प्रवृत्ति ने ब्रुक्स को चुटकी ली कि उनकी पुस्तक कहा जाता है "सॉफ्टवेयर इंजीनियरिंग की बाइबिल", क्योंकि "हर कोई इसे उद्धृत करता है, कुछ लोग इसे पढ़ते हैं, और कुछ लोग इसके द्वारा जाते हैं"।

— रयान

87

उस अवधारणा के कुछ पहलू हैं जिन्हें कभी-कभी आज भी लागू किया जाता है, अन्य पहलू भी हैं जिनसे बचा जाता है ।

टीमों को छोटा रखना चंचल तरीकों की बुनियादी विशेषताओं में से एक है, लेकिन चंचल के बाहर भी अभ्यास किया जाता है।

क्रॉस-फ़ंक्शनल टीमें भी एजाइल का एक प्रधान है, लेकिन एजाइल के बाहर भी आम है।

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

इसी तरह, एक सिस्टम एडमिनिस्ट्रेटर की भूमिका (मिल्स सर्जिकल टीम का हिस्सा नहीं है, लेकिन पिछले वर्षों की एक विशिष्ट क्रॉस-फंक्शनल टीम का हिस्सा) को DevOps जैसी अवधारणाओं द्वारा पालन किया जा रहा है (सॉफ्टवेयर इंजीनियर की भूमिका में Sysadmin की भूमिका को अवशोषित) , प्लेटफार्म-ए-ए-सर्विस, इन्फ्रास्ट्रक्चर-ए-सर्विस, और यूटिलिटी कंप्यूटिंग (Sysadmin की भूमिका (किसी और की समस्या है)), या इन्फ्रास्ट्रक्चर-अस-कोड (सॉफ्टवेयर इंजीनियरिंग में सिस्टम प्रशासन मोड़)।

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

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

इसलिए, संक्षेप में: मुझे नहीं लगता कि यह अवधारणा बिल्कुल वर्णित के रूप में लागू की गई है, लेकिन इसके कुछ पहलुओं को निश्चित रूप से लागू किया गया है, कुछ पहलुओं को अवांछनीय और सक्रिय रूप से परहेज के रूप में देखा जाता है, कुछ अप्रचलित हैं, और कुछ संभवतः अच्छे विचार हैं ™, लेकिन कोई नहीं करता है।

— जोर्ग डब्ल्यू मित्तग
स्रोत

1

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

— बार्ट वैन इनगेन शेनौ

15

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

— माइल्स रुट

9

"पूरी टीम के पास खुद के लिए एक कंप्यूटर होगा ... एक खिंचाव था" - 1980 के दशक की शुरुआत में ऑर्गेनिक में मिनीकंप्यूटर + टर्मिनल-आधारित सिस्टम होगा, इसलिए जब यह एक ही कंप्यूटर था, तब भी उपयोगकर्ताओं को इसके बराबर पहुंच होती थी। आधार और अपने स्वयं के कार्यक्रमों को चलाने की क्षमता (सभ्य उपयोगकर्ता अलगाव और सुरक्षा मौजूद है)।

— दाई

2

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

— थियोडोर नॉरवेल

1

पुन: स्मालटाक - न केवल प्रत्येक देव और प्रत्येक उपयोगकर्ता के पास अपना स्वयं का कंप्यूटर होना चाहिए, उन कंप्यूटरों को भी बहुत सारे मेमोरी और जीयूआई के साथ शक्तिशाली कंप्यूटर माना जाता था । "पीसी" के बजाय "वर्कस्टेशन" सोचें। मूल आईबीएम पीसी में स्मॉलटाक चलाने की हॉर्सपावर नहीं है। एक शर्म की बात है, मेरी राय में ...

— बॉब जार्विस

20

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

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

8: 2 समर्थन के अर्थशास्त्र: इंजीनियर अनुपात का कोई मतलब नहीं है। इंजीनियरों को अपना समर्थन होना चाहिए। एक आधुनिक मानव पर्याप्त शिक्षा और कौशल के साथ एक विकास टीम से जुड़े होने के लिए प्रभावी है, कुछ प्रकार के अपने स्वयं के विकास नहीं करने के लिए बहुत महंगा है।

(संबंधित अर्थशास्त्र शब्द "सेवा क्षेत्र की लागत बीमारी है।")

— जॉन वाटे
स्रोत

5

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

— रिबॉल्डएडीडी

2

@RibaldEddie सम्मान के साथ क्या? यदि आप जीवित रहने की लागत के खिलाफ श्रम बेंचमार्क करते हैं, तो यह घट रहा है; 1969 में 19 घंटे

— k_g

3

@k_g अच्छी तरह से यह स्थान पर निर्भर करता है। मुद्रास्फीति के संदर्भ में, अमेरिका में अधिकांश स्थानों पर, आप 1969 की तुलना में आज मुद्रास्फीति-समायोजित डॉलर में कम के लिए एक डेवलपर को नियुक्त कर सकते हैं। संदर्भ के लिए, ब्रूक्स पुस्तक में 20k के लिए सुझाव देते हैं कि आज हम एक वरिष्ठ देव वास्तुकार के रूप में क्या विचार करेंगे। और मिल प्रोग्रामर के एक रन के लिए 10k जो काम करता है। आज के डॉलर में, वह 10k लगभग 65k है। आज 65k कमाने वाले आपकी टीम में अधिकांश देव बहुत अच्छी कीमत हैं।

— रिबॉल्डएड्डी

3

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

— रिबेल्डिदेई

11

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

— रिबेल्डएडीडी

13

यह पैटर्न मुझे बहुत पसंद है जैसे मोब प्रोग्रामिंग:

पूरा समूह (क्यूए, डेवलपर्स और यहां तक कि उत्पाद स्वामी यदि आवश्यक हो) एक ही समस्या में एक ही समय में काम कर रहा है। कोई स्टैंड अप, उच्च संचार, सीधे लाइव में तैनात नहीं।

से http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

भीड़ प्रोग्रामिंग की मूल अवधारणा सरल है: पूरी टीम उस समय एक कार्य पर एक टीम के रूप में काम करती है। वह है: एक टीम - एक (सक्रिय) कीबोर्ड - एक स्क्रीन (निश्चित रूप से प्रोजेक्टर)। यह पूरी टीम की जोड़ी प्रोग्रामिंग करने जैसा है।

इसे यहां देखें: https://www.youtube.com/watch?v=dVqUcNKVbYg

— Chococroc
स्रोत

वह उद्धरण मूल रूप से मैं क्या सोच रहा था: यह जोड़ी प्रोग्रामिंग की तरह लगता है, जहां "सर्जन" वह है जिसे हमने "ड्राइवर" कहा है, एक अलग पैमाने पर छोड़कर।

— इज़्काता

7

यह मुझे लगता है कि बहिर्मुखी लोगों को उन्मुख सक्षम सॉफ्टवेयर डेवलपर्स की आवश्यकता होगी। इसके साथ शुभकामनाएँ।

— बॉब जार्विस

यह कहने के लिए यहां आया था; या टीम आत्म संगठन के विभिन्न रूपों।

— मार्सिन

2

@ गोबरजविस मैं असहमत हूं। मुझे इंट्रोवर्ट्स की टीमों में काम करने में बड़ी सफलता मिली है (और मुझे लगता है कि इसमें कुछ ऐसे भी शामिल हैं जो एक्सट्रोवर्ट्स भी शामिल हैं)। कुंजी एक ऐसी जगह बना रही है, जहां लोग योगदान देने के लिए सुरक्षित और खुला महसूस करते हैं, और समूह के लाभ के लिए एक समय के लिए अपने प्राकृतिक झुकाव को खींचने के लिए तैयार हैं। सुज़ैन कैन की क्विट अलग-अलग स्वभाव के साथ अच्छी तरह से काम करने के तरीके को समझने में बहुत बड़ी मदद थी: ted.com/talks/susan_cain_the_power_of_introverts

— David

12

इस टीम के मॉडल का उल्लेख फिर से रैपिड डेवलपमेंट - Taming Wild Software Schedules द्वारा Steve McConnell द्वारा 305 पेज पर किया गया है। इसे चीफ-प्रोग्रामर टीम कहा जाता है।

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

अन्य संदर्भ:

बेकर, एफ। टेरी। "मुख्य प्रोग्रामर टीम मैनेजमेंट ऑफ़ प्रोडक्शन प्रोग्रामिंग," आईबीएम सिस्टम्स जर्नल, वॉल्यूम। 11, नहीं। 1, 1972, पीपी। 56-73।

बेकर, एफ। टेरी और हैरलान डी। मिल्स। "मुख्य प्रोग्रामर टीमें।" डाटामेशन, वॉल्यूम 19, संख्या 12 (दिसंबर 1973), पीपी। 58-61।

— मैट एवरसन
स्रोत

9

मेरा अनुमान है कि अधिकांश छोटी आत्म-आयोजन टीमें वैसे भी एक डी-फैक्टो सर्जिकल टीम मॉडल में व्यवस्थित होंगी।

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

बेजोस के दो-पिज्जा शासन के बारे में सोचें। वहीं आपकी सेल्फ-ऑर्गनाइजिंग सर्जिकल टीम है।

— RibaldEddie
स्रोत

1

इसलिए मूल रूप से, इसके लिए कुछ नहीं हुआ। +

— गोर्डी

1

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

— रिबॉल्ड एडिडी

मैं "सबसे" को "कुछ" में बदल दूंगा। यह वास्तव में टीम की गतिशीलता पर निर्भर करता है। और यह निश्चित रूप से व्यवस्थित रूप से बढ़ना है अगर एक सर्जन परिणाम के ऊपर से तय किया गया है तो आत्म संगठित के लिए सबटाइमल होगा +1।

— पीटर

2

सॉफ्टवेयर के ताओ से बातें: #IV - टीमवर्क का ताओ: अच्छा सॉफ्टवेयर तेजी से काम करने वाली छोटी टीमों द्वारा लिखा गया है। खराब सॉफ्टवेयर धीरे-धीरे काम करने वाली बड़ी टीमों द्वारा लिखा जाता है। कोरोलरीज: - एक टीम का इष्टतम आकार 1 है; - टीम के आकार के लिए अधिकतम व्यावहारिक मूल्य 3 है; - टीम के आकार के लिए> 3, (गलत) संचार एक गंभीर मुद्दा बन जाता है; - टीम के आकार> 6 के लिए, प्रोजेक्ट पूरा होने पर गंभीरता से समझौता किया जाता है। समय सीमा पर परियोजना के पूरा होने की संभावना है। इस तरह के मामलों में होशियार डेवलपर्स दरवाजे का उपयोग करेंगे ... इस प्रकार यह लिखा है ... ( BWOOoooonnnggggg !!! )

— बॉब जार्विस

6

एचपी से बाहर एक पेपर था जो कुछ इसी तरह का सुझाव देता था:

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

पेपर प्री-वेब दिनों में था, और समय-समय पर इसे मजाकिया रूप में लाया जाता था। हर साल इसे लाया गया, कमेंटरी "इतनी हास्यास्पद" से हास्यास्पद रूप से "शायद हमें ऐसा करना चाहिए" से थोड़ा अधिक चली गई।

वास्तविक परीक्षण डिजाइन करने के लिए कुख्यात हैं, इसलिए यह संभवतः राय बनी हुई है। कुछ परियोजनाओं के सर्वेक्षण और उनकी पूर्णता दर मौजूद हो सकती है।

— चार्ल्स मरियम
स्रोत

9

वह हिस्सा जो मुझे मुस्कुराता है (?) है "... कई प्रबंधक ..." बात। उत्पादकता कम करने के लिए एक प्रबंधक पर्याप्त से अधिक है। कई प्रबंधक डेवलपर्स को या तो आत्महत्या (अंतर्मुखी) या हत्या (एक्सट्रूवर) के विचारों के लिए प्रेरित कर सकते हैं।

— बॉब जार्विस

4

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

— रोब क्रॉफर्ड

1

जाहिर है कि आप बहिर्मुखी हैं। तो ... पागलपन रक्षा? मेक्सिको? या… न्यायप्रिय गृहण ..? :-)

— बॉब जार्विस

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

— राबर्ट बैरन

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

— चार्ल्स मेरियम

2

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

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

— गौरव
स्रोत

1

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

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

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

— JeffO
स्रोत

0

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

मेरे अनुभव में, भक्त दर्शन कि हर व्यक्ति को हर कार्य में सक्षम होना चाहिए, हॉग-बटरिंग मॉडल पर वापसी है (यह कहने के लिए नहीं कि यह बुरा है, बस अलग है)।

— माइक औंस्वर्थ
स्रोत

2

यह निश्चित रूप से DevOps मॉडल नहीं है।

— RibaldEddie

5

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

— रिबेल्डैडी

1

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

— माइक ऑन्सवर्थ

1

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

— माइक ऑन्सवर्थ

1

@MikeOunsworth: क्रॉस-functionals :-D की एक टीम है

— Jörg डब्ल्यू Mittag

0

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

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

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

तो हां, मुझे लगता है कि यह भूमिका आज भी बहुत जीवंत है, हालांकि माना जाता है कि यह उस समय से विकसित हुआ था जब यह वापस आ गया था।

— Newtopian
स्रोत