गैर-तकनीकी बिल्डरों के लिए गाइड

तय करें कि आपके पहले ऐप को क्या साबित करना है।

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

01 - एक व्यक्ति और एक कार्य का वर्णन करें

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

  • वर्णन करें कि व्यक्ति आज क्या करता है और क्या कठिन है।
  • वह क्रिया चुनें जिसे आप स्पष्ट या आसान बनाना चाहते हैं।
  • यदि पहला संस्करण काम करता तो आप क्या देखते, इसे लिखें।

02 - कागज पर यात्रा करें

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

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

03 - एक ऑपरेटिंग सेवा से एक डेमो को अलग करें

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

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

04 - संक्षेप में परिणाम की समीक्षा करें

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

  • कार्य को आज़माने के विचार से अपरिचित किसी व्यक्ति से पूछें।
  • अधिक सुविधाओं का अनुरोध करने से पहले भ्रमित करने वाले चरणों को रिकॉर्ड करें।
  • एक केंद्रित परिवर्तन करें और वही जांच दोहराएं।
  • दायरा तभी बढ़ाएं जब पहली यात्रा में आपके मूल प्रश्न का उत्तर मिल जाए।

एक प्रारंभिक बिंदु

संक्षिप्त को विशिष्ट बनाएं।

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

प्रथम-संस्करण स्कोप वर्कशीट इसका उपयोग करने वाले व्यक्ति: ___ समस्या जिसका वे आज सामना करते हैं: ___ एक कार्य जो उन्हें पूरा करना चाहिए: ___ उस कार्य के लिए आवश्यक पृष्ठ: ___ दिखाई गई या दर्ज की गई जानकारी: ___ मुख्य कार्रवाई के बाद क्या होता है: ___ क्या केवल नमूना रहता है: ___ विशेषताएं बाद के लिए छोड़ दी जाती हैं: ___ जब मैं देख सकता हूं तो पहला संस्करण पास हो जाता है: ___

जब आपको अगले चरण की आवश्यकता हो

उत्पाद दस्तावेज़ीकरण का पालन करें।

शुरू करने से पहले।

क्या मुझे पहले एक प्रोग्रामिंग भाषा चुनने की ज़रूरत है?

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

पहले संस्करण में कितनी सुविधाएँ शामिल होनी चाहिए?

सबसे छोटे सेट का उपयोग करें जो आपको एक पूरी यात्रा का निरीक्षण करने देता है। कोई सार्वभौमिक सुविधा गणना नहीं है. एक सुविधा पहले संस्करण में आती है जब इसके बिना कार्य का सार्थक परीक्षण नहीं किया जा सकता है।

एक उपयोगी कार्य से शुरुआत करें

कुछ ऐसा बनाएं जिसकी आप समीक्षा कर सकें।