Taiga में नया product शुरू करें

एक स्पष्ट परिणाम तैयार करें

यह scenario काल्पनिक equipment request service का है। Manager कर्मचारी का equipment request और निर्णय दर्ज करता है। Employee self-service बाद का विस्तार है। सीखने के दौरान synthetic records इस्तेमाल करें। Scenario वास्तविक personnel data की अनुमति नहीं देता।

Product बनाने से पहले पुष्टि करें कि organization और संबंधित shared context तैयार हैं। Service के परिणाम का जिम्मेदार व्यक्ति और operating environment की जिम्मेदार team पहचानें।

शुरुआती सीमा लिखें: पहला version requests और decisions दर्ज करता है। वह equipment order नहीं करता, खर्च अपने आप मंजूर नहीं करता और payroll records नहीं बदलता।

Product शुरू करने का तरीका चुनें

इस नई service के लिए Start from scratch चुनें। मौजूदा repository से शुरुआत तय करनी हो तो Import codebase इस्तेमाल करें। Import product creation के समय का विकल्प है, इसलिए सोचकर चुनें।

Creation में यह भी पूछा जाता है कि Taiga Infrastructure code और CI/CD pipelines लिखे या नहीं। ये अलग जिम्मेदारियाँ हैं। Platform team पहले से कोई हिस्सा देती हो, तो उसका generation option बंद करें और बताएँ कि काम अभी कैसे होता है।

उदाहरण: “हमारा platform मौजूदा repository pipeline से reviewed container images deploy करता है। उसकी workload identity और environment configuration इस्तेमाल करें।” भरोसा करने से पहले विवरण सही होने की पुष्टि करें।

Conversation से पहले context दें

Discovery Context से शुरू होती है। Conversation से पहले product की संबंधित reference सामग्री और स्थायी instructions जोड़ें। कई products में साझा नियम organization या factory स्तर पर रखें।

Equipment service के उपयोगी context में employee identity का तरीका, स्वीकृत data services और manager access का नियम हैं। अनसुलझे प्रश्न स्पष्ट बताएँ। Form भरने के लिए retention period न गढ़ें।

फिर conversation में service बताएँ। Users, इच्छित परिणाम, सीमाएँ और दायरे से बाहर की बातें समझाएँ। काम के दौरान specification draft के रूप में save होती है।

उद्देश्य का review करके publish करें

Specification में implementation बदलने वाली धारणाएँ पढ़ें। इस scenario में जाँचें कि manager सभी employees के requests देख सकता है या केवल अपनी team के। इस अंतर से permissions, data flow और tests प्रभावित होते हैं।

सामग्री आगे के काम के लिए उपयुक्त हो तो specification publish करें। फिर publish करने तक draft changes published version की जगह नहीं लेते। जरूरी documents में आगे बढ़ें और उनकी धारणाएँ review करें। Discovery पाठ dependencies और पुराने documents समझाता है।

सभी आठ जरूरी documents publish होने के बाद Discovery finish करें और initiatives plan करें। Generated sequence ऐसा proposal है जिसे आप देख और बदल सकते हैं।

वास्तविक delivery target जोड़ें

विस्तृत initiative planning से पहले repository connect करें। इच्छित environments भी उसी समय तय करें, भले ही planning शुरू करने के लिए environment जरूरी नहीं है।

Environment का विवरण cloud access नहीं देता। आपकी pipeline deployment करती है। जिम्मेदार team के साथ repository branch, identity, infrastructure की जिम्मेदारी और जरूरी setup tasks जाँचें।

इस scenario का उपयोगी परिणाम तय product और वास्तविक delivery environment पर आधारित review योग्य काम है। Taiga workflow simulation में decisions के क्रम का अभ्यास करें।