👩‍🏭 🐷 👩🏿‍🎨 आईटी दुनिया से प्रकट होने का चयन 🗾 🍽️ 📼

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

लेख का वर्णन है:

Agile Software Development के लिए मेनिफेस्टो
एजाइल मैनिफेस्टो - आईबीएम संस्करण
मोरेगाइल मैनिफेस्टो
चंचल घोषणापत्र २.१
अर्ध-सशस्त्र चुस्त सॉफ्टवेयर विकास के लिए मैनिफेस्टो
अन्योन्याश्रय की घोषणा
प्रोग्रामिंग, मदफुकर
सॉफ्टवेयर शिल्प कौशल घोषणापत्र
DevOps Manifesto

Agile Software Development के लिए मेनिफेस्टो

http://agilemanifesto.org

मूल्यों के अलावा, मैं सिद्धांतों की सूची पढ़ने की सलाह देता हूं: http://agilemanifesto.org/principles.html

विरोध प्रदर्शन

एजाइल पर बहस सबसे हॉट में से एक है और अब तक नहीं थमी है। मेरा सुझाव है कि किसी एक विशिष्ट व्यक्ति को देखें: http://habrahabr.ru/post/142412/#comment_4768622 । टिप्पणी धागा के अलावा, AgileRussia समूह में भी इसी विवाद की चर्चा है ।

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

प्रतिबंध

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

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

मेरा सुझाव है कि आप उन सीमाओं को देखें जिनके द्वारा आप यह मूल्यांकन कर सकते हैं कि एजाइल आपके लिए सही है या नहीं:

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

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

एजाइल मैनिफेस्टो - आईबीएम संस्करण

चपलता @ स्केल: चंचल सॉफ्टवेयर विकास स्केलिंग के लिए रणनीतियाँ

व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत
व्यापक प्रलेखन पर काम कर समाधान
अनुबंध वार्ता पर हितधारक सहयोग
एक योजना के बाद बदलने का जवाब

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

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

मोरेगाइल मैनिफेस्टो

http://blog.xebia.com/2010/12/23/moreagile-manifesto

यह घोषणापत्र मूल AgileManifesto के बाएँ हाथ की ओर ले जाता है और प्रत्येक कथन को एक नए के साथ विपरीत करता है। परिवर्तनों का इतिहास इस बात को बताता है

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

मेरे लिए व्यक्तिगत रूप से, इस घोषणापत्र ने चेतना में क्रांति नहीं की, लेकिन केवल कुछ जोड़ दिए।

चंचल घोषणापत्र २.१

http://agilescout.com/agile-manifesto-2-1-moreagile-manifesto

यह घोषणा पत्र पिछले वाले का एक छोटा संशोधन है। अंतर नगण्य है, विचारों का सार पिछले एक से लिया गया है।

अर्ध-सशस्त्र चुस्त सॉफ्टवेयर विकास के लिए मैनिफेस्टो

http://www.halfarsedagilemanifesto.org

यह घोषणापत्र रॉन जेफ्रीज़ के एक लेख " बियॉन्ड एजाइल: न्यू प्रिंसिपल्स? " के साथ शुरू हुआ। यह घोषणापत्र जोड़ के साथ मूल की एक प्रति है जो समझाती है कि वास्तव में मूल्यों का 100% पालन नहीं होता है। उदाहरण के लिए इस तथ्य को लें कि हम योजनाओं में बदलाव के लिए तैयार हैं, लेकिन पहले हमें खुद एक योजना बनाने की जरूरत है, जिसे हम भविष्य में बदल देंगे।

मुझे यह विकल्प पसंद है क्योंकि फुर्तीली कार्यप्रणाली के कट्टरपंथियों पर इसका प्रभाव पड़ता है।

अन्योन्याश्रय की घोषणा

http://pmdoi.org

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

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

डीओआई के विचारों के बारे में अधिक जानकारी के लिए, आधुनिक प्रबंधन या डीओआई पर निर्भरता की घोषणा देखें।

प्रोग्रामिंग, मदफुकर

http://programming-motherfucker.com

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

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

"वे वास्तव में मूल्य" स्तंभ एक तसलीम है। भाग में, आप उनके साथ सहमत हो सकते हैं, लेकिन मुझे लगता है कि वे एक और भी कट्टरपंथी चरम दिखाते हैं, प्रभावी प्रबंधकों की दुनिया के बिल्कुल विपरीत।

मेनिफेस्टो, ब्ल @ टी!

लिखने कोड-blyat.rf

पिछले प्रकट का स्थानीयकृत संस्करण। इसके अलावा, चित्र भी स्थानीयकृत है। अंग्रेजी संस्करण में, फिल्म पल्प फिक्शन के चरित्र का उपयोग किया गया था, हमारे पास एक लोकप्रिय मेम है जो अपनी मुट्ठी एक आदमी को लहराती है ।

सॉफ्टवेयर शिल्प कौशल घोषणापत्र

http://manifesto.softwarecraftsmanship.org

सॉफ्टवेयर शिल्प कौशल इंजीनियरों से समर्थन करने के लिए एक चुस्त कार्यप्रणाली के उद्भव के लिए एक डेवलपर प्रतिक्रिया है। इसे घोषणापत्र "प्रोग्रामिंग, मदफुकर" का पर्याप्त संस्करण माना जा सकता है।

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

DevOps Manifesto

https://sites.google.com/a/jezhumble.net/devops-manifesto

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

इस विषय पर, मैं वीडियो को देखने की सलाह देता हूं लोग, प्रक्रिया, उपकरण - देवता का सार ।

अधिक घोषणापत्र चाहिए

निश्चित रूप से आपके पास अपने पसंदीदा घोषणापत्र की एक जोड़ी है, शायद आपने अपना खुद का लिखा है। मुझे इन घोषणापत्र को टिप्पणियों में देखकर खुशी होगी।

विचार के लिए कुछ और घोषणापत्र:

सॉफ्टवेयर टीम लीडर मैनिफेस्टो , रॉय ओशेरोव
मेरा प्रोग्रामिंग मैनिफेस्टो , जेरेमी मिलर
कोड ऑफ ऑनर
अपने आप में प्रोग्रामर को मार डालो

आईटी दुनिया से प्रकट होने का चयन