हम हर स्प्रिंट पर बार-बार एक ही वास्तुकला संबंधी चर्चा क्यों कर रहे थे? (Same Architecture Debate Every Sprint)

हम हर स्प्रिंट पर बार-बार एक ही वास्तुकला संबंधी चर्चा क्यों कर रहे थे?

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

मैंने सुना और यह सरल प्रश्न पूछा: "तो वास्तुशिल्प आरेख कहां है? हम इन निर्णयों का दस्तावेजीकरण कहां करते हैं?"

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

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

##पारंपरिक कंपनियों के "आदिवासी ज्ञान" की जिद

इस अव्यवस्था को देखने के बाद, मेरे हर साक्षात्कार में मेरा पहला सवाल था: "आपकी परियोजना प्रबंधन प्रक्रिया क्या है और आप तकनीकी निर्णय कैसे लेते हैं?"

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

भले ही नियुक्ति स्वीकृत हो गई हो, मैंने उस क्षण उस प्रस्ताव को अस्वीकार कर दिया। क्योंकि किसी प्रोजेक्ट की वास्तुकला और नियति को किसी की मीटिंग बुक की फीकी स्याही के हवाले नहीं किया जा सकता।

निर्णय थियेटर और परिचालन अराजकता

बाद में, मैं एक बड़े लॉजिस्टिक्स परिवर्तन प्रोजेक्ट में शामिल हुआ। जब मैंने सिस्टम में प्रवेश किया तो मुझे यह समझने में ही पूरा एक महीना लग गया कि कौन क्या कर रहा है। परियोजना प्रबंधन शून्य था, तकनीकी मेमोरी शून्य थी।

मैंने तुरंत अपनी आस्तीनें ऊपर कर लीं। मैंने एजाइल बिजनेस मॉडल पेश किया, 2-सप्ताह के स्प्रिंट की स्थापना की, जीरा को एकीकृत किया और दैनिक स्टैंड-अप की शुरुआत की। सब कुछ बढ़िया चल रहा था. लेकिन निजी क्षेत्र में एक वास्तविकता है: जब आप सिस्टम में पारदर्शिता और संस्थागत स्मृति लाते हैं, तो जो लोग "आदिवासी ज्ञान" (रहस्य केवल वे जानते हैं) से शक्ति प्राप्त करते हैं उन्हें खतरा महसूस होता है।

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

तभी मुझे एहसास हुआ: केवल एक उपकरण (जीरा, एडीआर) का उपयोग करना पर्याप्त नहीं है। आपको उस टूल को कंपनी के लक्ष्य (ओकेआर) नसों में इंजेक्ट करना होगा।

वह प्रणाली जो परियोजना की अराजकता को समाप्त करती है: एडीआर (आर्किटेक्चर निर्णय रिकॉर्ड)आज, हम इस प्रणाली को वैश्विक ई-कॉमर्स प्लेटफ़ॉर्म बुनियादी ढांचे में त्रुटिहीन रूप से संचालित करते हैं जिसे मैं लीड डेवलपर (6-7 लोगों की टीम के साथ) के रूप में प्रबंधित करता हूं। जब मैंने परियोजना शुरू की, तब भी भ्रम था; GitLab में मुद्दे खोले जा रहे थे, लेकिन "हम ऐसा क्यों कर रहे हैं?" सवाल का कोई जवाब नहीं था.

मैंने टीम में चुस्त भावना पैदा की और सबसे महत्वपूर्ण बात यह है कि मैंने माइकल न्यागार्ड के एडीआर (आर्किटेक्चरल डिसीजन रिकॉर्ड) सिद्धांतों को सीधे वार्षिक तिमाही (क्यू1, क्यू2, क्यू3, क्यू4) लक्ष्यों पर मैप किया।

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

जब हम अभी कोई निर्णय लेते हैं, तो हम इसे इस सरल लेकिन घातक प्रभावी टेम्पलेट के साथ रिकॉर्ड करते हैं:

प्रसंग: हम किस समस्या का सामना कर रहे हैं? (उदाहरण: बास्केट क्वेरीज़ डेटाबेस को थका देती हैं।)

निर्णय: हम क्या कर रहे हैं? (उदाहरण: हम रेडिस कैश का उपयोग करेंगे।)

विकल्प (उपेक्षा): हमने क्या ख़त्म किया? (उदाहरण के लिए: हमने लागत के कारण डेटाबेस स्केल-अप को समाप्त कर दिया।)

परिणाम/परिणाम: हम क्या जोखिम उठाते हैं? (उदाहरण: डेटा विलंबता कम हो जाएगी, लेकिन कैश-अमान्यीकरण जटिलता जोड़ दी जाएगी।)

परिणाम: अब और नहीं "क्यों?" हम नहीं पूछते

आज स्प्रिंट बैठकों या प्रबंधन प्रस्तुतियों में, कोई नहीं पूछता कि "हमने इसे इस तरह क्यों किया?" यह नहीं कहता. क्योंकि हर लक्ष्य के नीचे एक दरवाजे की तरह एक एडीआर छिपा होता है।

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

प्रिय सॉफ्टवेयर आर्किटेक्ट और टेक लीड मित्रों; आपकी परियोजनाओं में, क्या निर्णय विकी रेगिस्तान में खो जाते हैं, या क्या वे कोड के केंद्र में रहते हैं?

आर्किटेक्चर प्लेबुक श्रृंखला

#1: हम हर स्प्रिंट पर बार-बार एक ही वास्तुकला संबंधी चर्चा क्यों कर रहे थे? (यह लेख आप पढ़ रहे हैं)

#2: इंजीनियरिंग सिद्धांत एक सॉफ्टवेयर आर्किटेक्ट ने अनुभव से सीखे (अगली पोस्ट)