सह-विकास संचालन

निर्माता-परिभाषित परियोजनाओं और फ्यूजन टीमों में निरंतरता और दोहराव सुनिश्चित करने के लिए एक प्रभावी सह-विकास प्रशासन ढांचा स्थापित करना एक महत्वपूर्ण हिस्सा है। यह आलेख एक शासन फ़्लोचार्ट को परिभाषित करने के लिए एक दृष्टिकोण का वर्णन करता है।

एंड-टू-एंड प्रक्रिया को परिभाषित करना

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

बैकलॉग में सुविधाएँ जोड़ें

बैकलॉग आपको समग्र अनुभव को संचालित करने वाली सुविधाओं को जोड़कर अपनी परियोजना की योजना बनाने में सक्षम बनाता है। बैकलॉग समग्र रोडमैप भी प्रदान करता है जिसे टीम वितरित करना चाहती है।

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

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

कार्यक्षेत्र संरेखण बैठक

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

बैकलॉग में कहानियां और स्टोरीबोर्ड जोड़ें

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

निम्न आंकड़ा एक बैकलॉग में जोड़ी गई एक नमूना उपयोगकर्ता कहानी दिखाता है।

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

समीक्षा का अनुभव लें

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

कहानी का इतिहास जोड़ें

एक सामान्य उपयोगकर्ता कहानी जोड़ने में निम्नलिखित जानकारी शामिल हो सकती है:

1. शीर्षक : <persona> के तौर पर, मैं <do something> कर सकता हूँ ताकि<impact/priority/value>
2. विवरण : विवरण में कुछ प्रमुख विवरण शामिल हैं (हालाँकि यह इन्हीं तक सीमित नहीं है), जैसे:
   • उस परिदृश्य का संक्षिप्त विवरण जो वांछित परिणाम का सार प्रस्तुत करता है
   • कथा - उन कार्यों का वर्णन करता है जो उपयोगकर्ता नेविगेट करने और परिदृश्य को पूरा करने के लिए करेंगे
   • वैकल्पिक कथा - अन्य तरीकों का वर्णन करती है कि उपयोगकर्ता समान परिणाम प्राप्त कर सकते हैं
   • डिज़ाइन नोट्स - उपयोगकर्ता कहानी से जुड़े निकाय, फ़ील्ड, दृश्य, मॉकअप स्क्रीन और व्यावसायिक नियमों को रिकॉर्ड करता है
   • सुरक्षा भूमिकाएँ प्रभावित - प्रभावित या उपयोगकर्ता कहानी के लिए प्रासंगिक सभी सुरक्षा भूमिकाओं को सूचीबद्ध करता है।

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

कहानी की समीक्षा

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

कार्य जोड़ें और मामलों का परीक्षण करें

कहानियों की समीक्षा करने के बाद, टीम के सदस्य Azure DevOps में कार्य बनाते हैं। कार्यों और परीक्षण मामलों को जोड़ने की समग्र प्रक्रिया इस प्रकार है:

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

कार्यों और परीक्षण मामलों को जोड़ने के बाद, आप स्प्रिंट क्षमता निर्धारित करने के लिए आगे बढ़ सकते हैं।

कार्यों को जोड़ने के बारे में अधिक जानकारी के लिए, स्प्रिंट योजना का समर्थन करने के लिए कार्यों को बैकलॉग में जोड़ें आइटम देखें।

समाधान तैयार करें

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

महत्वपूर्ण

रिलीज की योजना के दौरान, आपके प्रोजेक्ट में समाधान प्रबंधन के लिए रणनीति निर्धारित करें। अपने प्रोजेक्ट को प्रबंधित करने के लिए समाधानों का उपयोग करें और अन्य परिवेशों में वितरित करने के लिए आपके द्वारा बनाए गए घटकों को आसानी से खोजें।

परिनियोजन

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

Power Platform परिवेश

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

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

स्रोत नियंत्रण

स्रोत कोड कंट्रोल सिस्टम जैसे कि Azure DevOps को अपनाने पर विचार करें. Azure DevOps, कार्य की योजना बनाने, कोड के विकास पर सहयोग करने और एप्लिकेशन बनाने और परिनियोजित करने में टीम की मदद करने के लिए डेवलपर सेवाएं प्रदान करता है.

अपने विकास परिवेश से ऐसा समाधान निर्यात करें जिसमें ऐप्स और अनुकूलन हैं, अपना समाधान अनपैक करें, और अपनी स्रोत नियंत्रण प्रणाली में घटकों को संग्रहीत करें.

उन्नत विषय: पुल अनुरोध (पीआर) समीक्षा

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

पीआर शासन प्रक्रिया को स्वचालित करने से समाधान संस्करणों जैसे बुनियादी जांचों की मैन्युअल समीक्षा की आवश्यकता के बिना कोड गुणवत्ता सुनिश्चित करने में मदद मिलती है।

नोट

पुल अनुरोध जाँच प्रक्रिया को स्वचालित करने के लिए पीआर चेकर टूल उपयोग करें।

टेम्पलेट और स्टैंडर्डाइज़ेशन

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

एक प्रभावी समर्थन मॉडल लागू करना

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

सेवा स्तर अनुबंध बनाना

किसी भी समर्थन मॉडल में एक महत्वपूर्ण कारक सर्विस लेवल एग्रीमेंट (SLA) की परिभाषा है। SLA एक औपचारिक दस्तावेज होना चाहिए जिसे टीम तैयार करती है जिसमें निम्नलिखित मदों को शामिल करने वाले अनुभाग होते हैं:

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

SLA को टीम के दस्तावेज़ीकरण पोर्टल में संग्रहित किया जाना चाहिए और आवश्यकतानुसार अद्यतन किया जाना चाहिए।

अनुप्रयोग समर्थन डिलिवर करना

SLA में निर्दिष्ट एप्लिकेशन समर्थन देने के लिए सबसे अच्छा तरीका उस टीम के लिए है जिसने समाधान बनाया है और इसके समर्थन के लिए भी जिम्मेदार है। इस प्रणाली के फायदे हैं:

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

निगरानी आवेदन संतुष्टि और प्रयोज्य

समर्थन प्रयास का अंतिम भाग परिनियोजित ऐप की संतुष्टि और उपयोगिता की निगरानी और आकलन करना है। मतदान और प्रश्नावली जैसे अधिक पारंपरिक तरीकों के साथ-साथ मेट्रिक्स यहां उपयोगी हैं। ऐप के उपयोग की निगरानी के बारे में अधिक जानकारी के लिए, Power Apps के लिए व्यवस्थापक विश्लेषिकी देखें.

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

सारांश

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

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

अगला कादम: सामुदायिक समाधान और टूल आज़माएं