सॉफ्टवेयर इंजीनियरिंग एक जटिल विषय हो सकता है। यह निश्चित रूप से उद्यमों के लिए है और यह कोई रहस्य नहीं है कि यह जल्दी से अत्यधिक जटिल हो सकता है।

इसमें अधिक समय नहीं लगता है: एक और एकीकरण आवश्यकता, एक कठिन परिश्रम को स्वचालित करना, केवल एक और हानिरहित छोटे व्यवसाय की आवश्यकता को पूरा करना... यह जल्द ही बढ़ जाता है।

और वह सिर्फ सॉफ्टवेयर ही है। किसी एप्लिकेशन के चारों ओर लपेटने के लिए हम जो कुछ भी पसंद करते हैं/चाहते/चाहते हैं, उसके बारे में क्या? SDLC दूर करने के लिए ढेर सारी जटिलताएँ पेश करता है और कभी-कभी, यह सब थोड़ा भारी लग सकता है।

यहां किंगफिशर में, हमारे पास वर्तमान में 60 से अधिक स्क्रम टीमें और ~1100 इंजीनियर हैं, जो हमारे "डिजिटल एस्टेट" में योगदान दे रहे हैं और इसके अलावा, हम एक देव (सेक) ऑप्स परिवर्तन के माध्यम से प्रगति कर रहे हैं। कभी-कभी, मैं ईमानदार रहूंगा, ऐसा महसूस होता है कि हम एक घातीय जटिलता वृद्धि वक्र पर हैं।

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

पार्श्वभूमि

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

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

• एक उत्पाद प्रबंधक,
• एक टेक लीड और
• एक डिलीवरी लीड

लेकिन, जैसा कि आप जानेंगे कि एक पढ़े-लिखे पेशेवर होने के नाते, इसमें शासन की एक परत जोड़ने के अलावा भी बहुत कुछ है।

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

विकास

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

यह, फिर से, कोई नया या अनूठा समाधान नहीं है। यह पता लगाने में ज्यादा समय नहीं लगता है कि यह तेजी से एक सर्वव्यापी उद्योग भूमिका बन रहा है (यदि यह पहले से नहीं है)। हमारे लिए, हमारे कार्यक्रम प्रबंधकों और उत्पाद नेतृत्व के साथ, एक PSE कार्यक्रम स्तर पर बैठता है। हमारी भूमिका, अनिवार्य रूप से, हमारे कार्यक्रमों के भीतर और भीतर निरंतरता का स्तर लाने और बनाए रखने और हमारी भविष्य की दिशा को और अधिक समेकित रूप से परिभाषित करने में मदद करना है।

पहली गतिविधियों में से एक जिसे हमने महसूस किया कि आचरण करना विवेकपूर्ण था, वांछित व्यवहारों को चलाने में मदद करने के लिए हमारे सिद्धांतों को परिभाषित करना और हमारे विभाग को समग्र रूप से पालन करने के लिए एक सुसंगत ढांचा प्रदान करना था।

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

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

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

हम कल्पना करते हैं और आशा करते हैं कि समय के साथ ये सिद्धांत बदलेंगे और संख्या में कम हो जाएंगे क्योंकि उनमें से कुछ हमारी टीमों के काम करने के साझा तरीकों और प्राकृतिक व्यवहारों में शामिल हो गए हैं।

हमने जो अगला निर्णय लिया वह हमारे सिद्धांतों को चार तार्किक समूहों में वर्गीकृत करना था:

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

हमने तब पाया कि हम प्रत्येक श्रेणी के सिद्धांतों को समूहबद्ध कर सकते हैं ताकि प्रमुख विषयों को कॉल आउट करने में मदद मिल सके कि हमने प्रत्येक सिद्धांत को क्यों निर्धारित किया है।

अंत में, हमारी टीमों को प्रत्येक सिद्धांत के उद्देश्य और लाभों को समझने में मदद करने के लिए, हमने TOGAF से प्रेरणा ली है और प्रत्येक के लिए एक कथन और तर्क प्रदान किया है।

हमारे सिद्धांत तब, हमारे तर्कों के रक्तमय विवरण के बिना:

मैं एक छवि की सराहना करता हूं जिसमें बहुत अधिक एम्बेडेड टेक्स्ट सभी के लिए सुलभ नहीं है और मैं इसके लिए क्षमा चाहता हूं।

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

यदि आप हमारी यात्रा में शामिल होने में रुचि रखते हैं, तो कृपया हमारे करियर पेज को देखें ।

पढ़ने के लिए धन्यवाद!