"कोड के रूप में प्रलेखन" की अवधारणा का क्षेत्र अध्ययन

सभी को नमस्कार! मेरा नाम डेनिस ओलेनिक है, मैं 1Service में तकनीकी निदेशक के रूप में काम करता हूं।

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

यह रेखा कनफ्लुएंस में दर्ज आवश्यकताओं और जीरा में उनके कार्यान्वयन के कार्यों के बीच कहीं है। परीक्षण उपकरण में परीक्षण मामलों और कॉन्फ्लुएंस में समान आवश्यकताओं के बीच एक और रेखा जीरा में कार्यों के साथ जुड़े कोड पर नजर रखती है। प्रश्नों के स्पष्ट उत्तर की कमी: "हमने ऐसा क्यों / क्यों किया" या "क्या हमने वह सब कुछ किया जो ग्राहक हमसे चाहते थे" - जिससे हमें चिंता होती थी।

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

आवश्यक शर्तें

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

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

ठीक है, हाँ - सबसे पहले, यह "असुविधाजनक, प्रिय, सूखा," और दूसरा, तकनीकी चिप्स "एक कपड़े के साथ कवर" प्रलेखन अद्यतन करने की समस्या। एक सामान्य रूढ़िवादिता है: "हम अजेल द्वारा हैं - लेकिन हमें अजेल में प्रलेखन की आवश्यकता नहीं है!" हल्के ढंग से कहने के लिए, यह पूरी तरह से सच नहीं है। मैं कार्ल विगर्स की उत्कृष्ट पुस्तक "सॉफ्टवेयर रिक्वायरमेंट्स डेवलपमेंट" [4] से यूज़ केस और यूजर स्टोरी दृष्टिकोण की तुलना करके इस त्रुटि का खंडन करना पसंद करता हूं। अगर हम यूजर स्टोरीज के आधार पर डेवलपमेंट अप्रोच को एजाइल कार्यप्रणाली से संबंधित करते हैं, तो विगर्स इस तरह से यूजर स्टोरीज पर आधारित आवश्यकताओं के विकास को तैयार करते हैं:

उपयोगकर्ता इतिहास → (चर्चाएँ) → अद्यतन उपयोगकर्ता इतिहास (स्वीकृति मानदंडों के साथ) → (चर्चाएँ) → स्वीकृति परीक्षण

(पी। 169, अंजीर। 8-1)। इस प्रकार, चुस्त विकास परियोजनाओं में प्रारंभिक आवश्यकताओं के विकास के परिणामस्वरूप आउटपुट प्रलेखन स्वीकृति परीक्षण है। आज, स्वीकृति परीक्षण के आयोजन के लिए एक काफी सामान्य तकनीक तथाकथित फीचर-फाइलों (सरल, पाठ) में संग्रहीत, गेरकिन भाषा [5] में लिखित परीक्षण लिपियों का उपयोग करना है।

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

अनुसंधान उपकरण वास्तुकला

इसलिए, कोई उपकरण नहीं है, लेकिन मैं अवधारणा का पता लगाना चाहता हूं। आशाहीनता से, हमें इसे विकसित करना पड़ा। यदि इस तरह के एक उपकरण (चलो इसे स्टोरीमैपर कहते हैं) पहले से ही मौजूद था, तो विकास प्रक्रिया के मौजूदा पारिस्थितिकी तंत्र में, न्यूनतम तनाव के साथ, इसे किस तरह की वास्तुकला का इस्तेमाल किया जाना चाहिए? यदि यह पहले से ही एक निर्मित विकास प्रक्रिया है, तो CI / CD लूप शायद पहले से ही इसमें चल रहा होगा, और संस्करण नियंत्रण प्रणाली, सबसे अधिक संभावना गिट-आधारित, निश्चित रूप से उपयोग किया जाएगा। इस मामले में, नीचे दिए गए आरेख में विकास प्रक्रिया के दौरान StoryMapper का स्थान दिखाया गया है:


अंजीर। विकास प्रक्रिया की संरचना में स्टोरीमापर उपकरण का 1 स्थान

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

आपको यह समझना होगा कि StoryMapper को शायद ही "अभी तक एक और घेरकिन-संपादक" के शीर्षक का दावा करना है। हां, फीचर फ़ाइलों को संपादित करने की मूल क्षमता रखी जानी चाहिए, लेकिन हम स्पष्ट रूप से जानते हैं कि अगर बीए या क्यूए ने वीएससी, उदात्त, नोटपैड ++ या यहां तक ​​कि vi (क्यों नहीं?) के पक्ष में अपनी पसंद बनाई, तो उन्हें केवल स्टोरीमापर में आवश्यकताओं के लिए काम करने के लिए मना लें? कार्य कृतघ्न नहीं है, बल्कि गलत है। इसलिए, हम मानते हैं कि StoryMapper के विविध उपयोग की संभावना रखी जानी चाहिए, विशेष रूप से: आपके पसंदीदा संपादक में सुविधाओं का विकास, और StoryMapper का उपयोग तैयार किए गए फ़ीचर-फ़ाइलों को तैयार करने के लिए किया जाता है। अनुसंधान दिशाओं पर अनुभाग में इस पर अधिक।

न्यूनतम आवश्यक कार्यक्षमता

चूंकि StoryMapper वर्तमान में MVP राज्य में है, ये बहुत न्यूनतम आवश्यकताएं हैं जो हमने इसके लिए बनाई थीं ताकि यह वास्तव में उपयोग करना शुरू कर सके:

• गिट-आधारित कहानी मानचित्रण;
• खीरा-संपादक,
• परिदृश्य परीक्षण की शुरूआत (मैन्युअल रूप से और अनुसूची के अनुसार);
• उपयोगकर्ता कहानियों के नक्शे पर परिदृश्य परीक्षण के परिणामों का प्रतिबिंब।

मैं टूल की कार्यक्षमता पर ध्यान केंद्रित नहीं करूंगा, क्योंकि इस लेख का विषय ऑपरेशन का कोर्स है, न कि सर्जन के स्केलपेल।

अनुसंधान क्षेत्र

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

तो, StoryMapper एक उपकरण है, यह केवल सही उपयोग के मामले को विनियमित नहीं करता है। इसके विपरीत, प्रत्येक संभावित उपयोगकर्ता टूल का उपयोग करने के लिए अपने विकल्प देख सकता है। हमने तीन मुख्य क्षेत्रों पर ध्यान केंद्रित किया:

• लचीला विकास: एक कहानी के नक्शे से स्वीकृति परीक्षणों तक;
• फ़ीचर फ़ाइलों का एक संग्रह संरचना और कल्पना;
• उत्पादकता की निगरानी।

नीचे मैं विस्तार से वर्णन करूंगा कि हमने प्रत्येक दिशा में क्या परिणाम प्राप्त किए हैं।

लचीला विकास: कहानी कार्ड से स्वीकृति परीक्षणों तक

इस दिशा में एक नए उत्पाद का विकास या किसी मौजूदा को परिष्कृत करना शामिल है। इस दिशा में काम कोड नाम "BDDSM" के तहत हुआ: स्टोरी मैपिंग तकनीक और बीडीडी विकास पद्धति के संयोजन के रूप में। और जड़ हो गया।

तो, शुरुआत के लिए, फीचर फाइलों के लिए एक git रिपॉजिटरी बनाई जाती है, StoryMapper के साथ बातचीत के लिए इसमें एक शाखा आवंटित की जाती है। StoryMapper में एक प्रोजेक्ट बनाया गया है, यह व्यवसाय विश्लेषकों से जुड़ा है जो प्रोजेक्ट पर काम करेंगे। हितधारकों के साथ संवाद करते हुए, व्यापार विश्लेषक उत्पाद की एक सामान्य दृष्टि तैयार करना शुरू करते हैं और इसे उपयोगकर्ता कहानी के नक्शे के कंकाल के रूप में ठीक करते हैं [1,2], पहले स्तर के यूएफ का एक स्केच:


अंजीर। उपयोगकर्ता कहानियों के नक्शे के 6 ऊपरी स्तर के कंकाल (क्लिक करने योग्य)

और फिर धीरे-धीरे उपयोगकर्ता गतिविधियों के दूसरे स्तर को भरना:

अंजीर। 7 उपयोगकर्ता कहानियों के नक्शे का दूसरा स्तर कंकाल

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


अंजीर। यूएफ स्तर पर 8 गेरकिन सिंटैक्स-फ्री आवश्यकताएँ पाठ

इसके बाद, व्यापार विश्लेषकों को पता चलता है कि उपयोगकर्ता की कहानियों में उपयोगकर्ता की गतिविधियों को कैसे विघटित किया जाए, और StoryMapper - US में एक तीसरा मानचित्र स्तर बनाया जाए। यूएस का अलगाव स्वीकृति मानदंडों के निर्माण से जुड़ा हुआ है, अर्थात, "यदि आप किसी को कुछ चाहते हैं," तो हम इस तथ्य के बाद जांच करेंगे कि आपने इसे प्राप्त किया था [3]। शुरुआत के लिए स्वीकृति मानदंड अमेरिका में भी फ्लैट पाठ के रूप में तय किए जा सकते हैं।

स्वीकृति मानदंड स्थापित होने और हितधारकों के साथ सहमत होने के बाद, व्यापार विश्लेषकों ने उन्हें गेरकिन भाषा में लिपियों के रूप में रखा। वास्तव में, पाठ "परिदृश्य: केपी-नो" को प्रत्येक स्वीकृति मानदंड से जोड़ा जाता है, जो कि हिस्टेरो अमूर्त उपयोगकर्ता कहानी को एक फीचर फाइल में बदल देता है।


अंजीर। 8.1 घेरकिन पर स्क्रिप्ट के रूप में उपयोगकर्ता कहानियों के लिए स्वीकृति मानदंड

उसके बाद, प्रत्येक परिदृश्य को कई बढ़े हुए चरणों से वंचित किया जाता है जो यह बताता है कि एक विशिष्ट स्वीकृति मानदंड की जाँच कैसे की जाएगी। इसके अलावा, इन चरणों को या तो डेवलपर्स द्वारा प्रोग्राम किया जाता है या उपयोग किए गए गेरकिन ढांचे के चरणों के पुस्तकालय से टाइप किया जाता है और निर्यात स्क्रिप्ट का निर्यात किया जाता है।

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


अंजीर। 9 स्क्रिप्टिंग परिणामों के साथ उपयोगकर्ता कहानियों का मानचित्र

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

साथ ही, असेंबली लाइन के अंतिम चरणों में से एक में, ऑटो-प्रलेखन बनाया जाता है। आप सहकर्मियों के साथ इसके बारे में अधिक पढ़ सकते हैं। यह एकमात्र विकल्प नहीं है, हम अपने टूल में अचार पैकेज को शामिल करने की योजना बनाते हैं - "लाइव प्रलेखन" की दुनिया में वास्तविक मानक।

फ़ीचर फ़ाइलों के संग्रह को संरचित और विज़ुअलाइज़ करना

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

इसलिए, यह उपयोग मामला "अलग-अलग सुविधाओं, अलग-अलग प्रलेखन" से "दस्तावेज़ एक कोड है" से स्विच करने के लिए आपके दस्तावेज़ को साफ करने की इच्छा का अर्थ है। जब इस तरह का भंडार स्टोरीमैपर से जुड़ा होता है, तो सभी फीचर फाइलें UF0 और UA0 के तहत पहले कॉलम में आती हैं। संरचना में अगला कदम संरचना के कंकाल की रचना करना है। StoryMapper में, ये सभी एक ही UF और UA हैं , लेकिन कोई भी इस कोण से इन पर विचार करने पर जोर नहीं देता है। उन्हें केवल पदानुक्रम के 2 स्तरों के रूप में माना जा सकता है, जिसके तहत पहले से असंरचित फीचर फ़ाइलों को रखना संभव है। संरचना सेट होने के बाद, पहले कॉलम से फीचर-फाइल्स को संबंधित यूए के तहत अलग से खींचा जाता है। निस्संदेह, इस प्रक्रिया में प्रतिबिंब और सुविधाओं को फिर से संगठित करने का हमला होता है, क्योंकि जैसे ही आप खींचते हैं, उनके प्रारंभिक लेखन के दौरान हुई अराजकता की पूरी गहराई स्पष्ट हो जाती है। कभी-कभी यह स्क्रिप्ट को एक फ़ाइल से दूसरी फ़ाइल में स्थानांतरित करने के लिए पर्याप्त होता है, कभी-कभी सिमेंटिक कनेक्टिविटी को पुनर्स्थापित करने के लिए एक बड़ी फ़ाइल को कई में विभाजित करता है, और कभी-कभी इसे कूड़ेदान में फेंक देता है, क्योंकि प्राचीन अप्राप्य पांडुलिपियाँ रिपॉजिटरी में पड़ी थीं।

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

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

उत्पाद की निगरानी

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

जैसा कि हम देखते हैं। एक सरल विकल्प: कार्यात्मक परीक्षणों के सेट से, गैर-संशोधित डेटाबेस परीक्षणों का एक निश्चित सबसेट चुना जाता है जो फ्रंट-एंड की जांच करता है। : , -, , , -, , . , . StoryMapper Allure, , — , , , IT- .

, , . , , , , - .

, , :

• , ;
• , , ;
• StoryMapper ;
• StoryMapper .

विकास के निर्देश

, StoryMapper MVP. , « », , , , . , , « ». , :

• « », « — »;
• (, etc. );
• / / Excel;
• - Jira ( , ).

, , , . , .

( ), , ( !) — telegram , .

1. , . , ., , 2017.
2. , . , .-.-, , 2012.
3. Gojko Adjic, Specification by Example, NY, Manning Publication, 2011.
4. , , , .: ; .: -, 2014.
5. BDD «What's in a story»
6. « — » «Write the docs»
7. « — » " docToolchain "