पौराणिक पुरुष माह के प्रभावों को कम करने के तरीके क्या हैं?

ब्रूक्स का नियम: देर से सॉफ्टवेयर प्रोजेक्ट में मैनपावर जोड़ना बाद में बनता है।

उनकी किताब नो सिल्वर बुलेट - एसेन्स एंड एक्सीडेंट्स ऑफ सॉफ्टवेयर इंजीनियरिंग फ्रेडरिक ब्रूक्स में पौराणिक मानव माह की अवधारणा को परिभाषित किया गया है :

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

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

project-management process software-engineering

— जिरी क्लौडा
स्रोत

मैं इस प्रश्न को ऑफ-टॉपिक के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह सॉफ्टवेयर इंजीनियरिंग में बेहतर है। एसई ( softwareengineering.stackexchange.com ), और भी कारण यह सख्ती से DevOps विशिष्ट नहीं है

— Dawny33

यह एक कड़ाई से DevOps विशिष्ट प्रश्न है। यह सॉफ्टवेयर डिलीवरी के आसपास प्रोसेस करने के लिए सीधे संबंधित है। क्या आप वाकई देवओप्स का मतलब समझते हैं?

— जेरी क्लौडा

आप कह रहे हैं DevOps, मुझे नहीं लगता कि इसका मतलब है कि आपको क्या लगता है इसका मतलब है।

— जिरी क्लौडा

@ Dawny33: कृपया, DevOps की एक मूलभूत पुस्तक - द फीनिक्स प्रोजेक्ट पढ़ें। आपको AWS, Docker, Jenkins या किसी अन्य टूल का एक भी उल्लेख नहीं मिलेगा। पूरी पुस्तक प्रक्रिया, संगठनात्मक पदानुक्रम और संरचना, टीमों में काम करने के तरीके के बारे में है। DevOps उन वैज्ञानिक विचारों को लाने का एक तरीका है जिन्होंने जापान और बाद में संयुक्त राज्य अमेरिका में सॉफ्टवेयर विकास की प्रक्रिया में सुधार किया। एडवर्ड डब्ल्यू डेमिंग और एलियाहू एम। गोल्डरेट के काम पर आधारित विचार। आप देवो के रूप में जो देखते हैं, वह सिर्फ सतह, औजार, परिणाम है। इसके अधकचरे हिस्से।

— जिरी क्लौडा

@ Dawny33 यह सवाल सॉफ्टवेयर इंजीनियरिंग के लिए उपयुक्त नहीं है। हालांकि यह सामान्य विषय है, यह सवाल बहुत व्यापक है। यह एक समस्या को हल करने के प्रयास के बजाय राय मांग रहा है। कृपया अन्य समुदायों को सुझाव न दें यदि आप नहीं समझते हैं कि वे किस प्रकार के प्रश्नों को स्वीकार करते हैं। यदि यह प्रश्न सॉफ़्टवेयर इंजीनियरिंग पर पोस्ट किया जाना था, तो यह बहुत तेज़ी से हटाए गए, बंद, और संभावित रूप से हटाए गए वोट होगा। यह एक गरीब उपयोगकर्ता अनुभव की ओर जाता है।

— थॉमस ओवेन्स

जवाबों:

MMM क्या है

पहले मैं ब्रूक के नियम के संदर्भ को समझाना चाहता हूं। 1975 में उसे वापस बनाने के लिए क्या धारणा थी?

एक आदमी-महीना एक काल्पनिक इकाई है जो एक व्यक्ति द्वारा एक महीने में किए गए कार्य का प्रतिनिधित्व करता है; ब्रूक्स का कानून कहता है कि मानव-महीनों में उपयोगी काम को मापना असंभव है।

^{स्रोत: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

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

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

लेकिन क्या वास्तव में इस तरह से होना है? क्या हमें मोनोलिथ लिखना है और संचार चैनलों को रखना है n(n − 1) / 2जहां nडेवलपर्स की संख्या है?

हम जानते हैं कि ऐसी कंपनियां हैं जहां हजारों डेवलपर बड़ी परियोजनाओं पर काम कर रहे हैं ... और यह काम करता है। इसलिए ऐसा कुछ होना चाहिए जो 1975 से बदल गया हो।

MMM को कम करने की संभावना

2015 में, PuppetLabs और IT Revolution ने 2015 स्टेट ऑफ डेवप्स रिपोर्ट के परिणाम प्रकाशित किए । उस रिपोर्ट में, उन्होंने उच्च प्रदर्शन करने वाले संगठनों बनाम गैर-उच्च प्रदर्शन के बीच अंतर पर ध्यान केंद्रित किया।

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

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

यह उस रिपोर्ट का ग्राफ है -

जबकि कम प्रदर्शन करने वाले संगठन पौराणिक पुरुष महीने की धारणाओं के साथ संरेखित करते हैं। उच्च प्रदर्शन करने वाले संगठन, डेवलपर्स की संख्या के साथ रेखीय रूप से तैनाती / दिन / देव की संख्या को स्केल कर सकते हैं।

जीन किम द्वारा DevOpsDays लंदन 2016 में एक उत्कृष्ट प्रस्तुति इन निष्कर्षों के बारे में बात करती है।

यह कैसे करना है

पहला, उच्च प्रदर्शन करने वाला संगठन कैसे बने? ऐसी कुछ किताबें हैं जो इस बारे में बात करती हैं, इस जवाब में पर्याप्त जगह नहीं है इसलिए मैं सिर्फ उनसे लिंक करूंगा।

गुड टू ग्रेट: क्यों कुछ कंपनियां लीप बनाती हैं ... और अन्य लोग जिम कॉलिन्स द्वारा नहीं
हाई-वेलोसिटी एज: स्टीवन स्पीयर द्वारा प्रतिस्पर्धा को कैसे हराया जाए, मार्केट लीडर्स ने लीवरेज ऑपरेशनल एक्सिलेंस को कैसे आगे बढ़ाया
डब्ल्यू एडवर्ड्स डेमिंग द्वारा उद्योग, सरकार, शिक्षा के लिए नया अर्थशास्त्र

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

उदाहरण के लिए वार्ड कनिंघम तकनीकी ऋण की व्याख्या करता है क्योंकि सभी चीजें जिन्हें हम छोड़ देने की अनुमति देते हैं उन्हें अधूरा छोड़ दिया जाता है। यह प्रबंधन द्वारा स्वीकार किया जाता है क्योंकि यह हमेशा एक वादा के साथ आता है कि यह समय होने पर तय होने वाला है।

पर्याप्त समय नहीं है, और तकनीकी ऋण बस बदतर और बदतर हो जाता है।

ये कौन सी चीजें हैं जो तकनीकी ऋण को बढ़ने का कारण बनती हैं?

लीगेसी कोड
पर्यावरण का मैनुअल विन्यास
मैनुअल परीक्षण
मैनुअल तैनाती

लिगेसी कोड जैसा कि माइकल फेदर द्वारा लिगेसी कोड के साथ प्रभावी रूप से कार्य करने में परिभाषित किया गया है, वह कोई भी कोड है जिसका स्वचालित परीक्षण नहीं होता है।

कोड प्राप्त करने के लिए किसी भी समय शॉर्टकट का उपयोग किया जाता है; परिचालन इस ऋण के रखरखाव के लिए हमेशा के लिए बोझ है। फिर तैनाती की प्रक्रिया लंबी और लंबी हो जाती है।

जीन एक कंपनी के बारे में अपनी प्रस्तुति में एक कहानी बताती है, जिसकी छह सप्ताह की लंबी तैनाती है। 400 लोगों को बांधते हुए, दसियों हज़ार अति त्रुटि वाले थकाऊ कदमों को शामिल करना और वे हर साल ऐसा चार बार करेंगे।

DevOps के सिद्धांतों में से एक यह है कि विश्वसनीयता छोटे तैनाती को अधिक बार करने से आती है।

उदाहरण

2011 में जॉन जेनकिन्स वेलोसिटी : अमेज़न 15k डिप्लॉय / दिन कर रहे हैं
AWS समिट 2015 में केन एक्सनर : Amazon 136k deploys / day कर रहे हैं

ये दो प्रस्तुतियां उन सभी चीजों को दिखाती हैं जो अमेज़ॅन ने उत्पादन में कोड को तैनात करने में लगने वाले समय को कम करने के लिए किया था।

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

इसका मतलब यह है कि कुछ शर्तों के तहत, सही आर्किटेक्चर, सही तकनीकी प्रथाओं, सही सांस्कृतिक मानदंडों के साथ, डेवलपर उत्पादकता बढ़ सकती है क्योंकि डेवलपर्स की संख्या बढ़ जाती है। और DevOps निश्चित रूप से इस सब के बीच में है।

— एव्जेनी
स्रोत

मैंने जो किया है (और यह केवल व्यक्तिपरक है) इस प्रकार है:

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

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

कोड लिखने की प्रक्रिया धीमी होती है, लेकिन लिखते समय अपरिहार्य समीक्षा के कारण परीक्षण करते समय कम टाइपो / लाइनिंग और बग होते हैं। मुझे लगता है कि समग्र कोड की गुणवत्ता भी थोड़ी बेहतर है, लेकिन उस दावे का समर्थन करने के लिए मेरे पास कोई मीट्रिक नहीं है।

— Tensibai
स्रोत

मुझे जोड़ी प्रोग्रामिंग आइडिया पसंद है। यह वास्तव में कुछ है जो मदद कर सकता है। मैं समझा सकता हूं कि बाद में मैं जिस सिद्धांत पर काम कर रहा था, उसके आधार पर क्यों।

— जिरी क्लौडा

कृपया, इसके लिए इंतजार कर!

— पीटर मुर्सकिन

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

इस संबंध में पारंपरिक CI सिस्टम में एक स्केलेबिलिटी समस्या है: टूटने / प्रतिगमन / रुकावट की संभावना एकीकरण की गति को धीमा कर देती है और छोटी टीमों को तोड़ने और बाल शाखाओं (यानी आगे की मंदी) के लिए आगे बढ़ने के लिए आमंत्रित करती है। देखें कि बहुत बड़ी परियोजनाओं / टीमों के लिए निरंतर एकीकरण पैमाना कैसे हो सकता है? । यह Mythical Man Month अवधारणा के साथ ही खेलता है।

उस प्रश्न के उत्तर में मेरा जो समाधान सुझाया गया है, वह एक उच्च मापनीय CI प्रणाली है जो संपूर्ण CI के लिए माइग्रेशन - सिंगल ब्रांच / ट्रंक आधारित एकीकरण (यहां तक कि विशाल आकारों के साथ) के लिए माइग्रेशन को सक्षम करेगा।

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

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

इन सभी को देखा जा सकता है, मेरा मानना है, पौराणिक मानव महीना अवधारणा प्रभाव को सुखदायक के रूप में।

— डैन कोर्निलेस्कु
स्रोत

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

— एवगेनी

Having them all communicate via a single integration branch is an anti-pattern- क्यों? यदि वे इस अर्थ में डिकॉय कर रहे हैं कि उन्हें अब अपने काम को एकीकृत करने की आवश्यकता नहीं होगी, तो वे शाखा को गैर-अतिव्यापी / गैर-परस्पर विरोधी तरीके से स्पर्श करेंगे। यदि उनके काम को अभी भी एकीकृत करने की आवश्यकता है, तो अतिरिक्त शाखाओं पर जाने से बस देरी होगी और सीआई कार्यप्रणाली से विचलन करके और इसके सभी फायदे खो कर एकीकरण को जटिल करेगा।

— दान कॉर्निलस्कु

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

— एवगेनी

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

— दान कॉर्निलेस्कु

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

— एवगेनी