संघांना अधिक आत्मविश्वासाने पाठवण्यास मदत करण्यासाठी उत्तम सॉफ्टवेअर उत्पादने तयार करण्यासाठी वापरकर्ता कथा मार्गदर्शक

या मार्गदर्शकामध्ये, आम्ही वापरकर्त्याच्या कथा काय आहेत, त्या का महत्त्वाच्या आहेत, त्या योग्यरित्या कशा लिहायच्या आणि वितरण सुरळीतपणे होईल याची खात्री करण्यासाठी स्वीकृती निकषांचा कोणता भाग आहे ते पाहू.

वापरकर्ता कथा काय आहेत?

वापरकर्ता कथा हे सॉफ्टवेअर क्षमतेचे संक्षिप्त, सरळ वर्णन असते, जे अंतिम वापरकर्त्याच्या दृष्टीकोनातून लिहिलेले असते. तांत्रिक बिल्डचे स्पष्टीकरण देण्याऐवजी, हे वैशिष्ट्य कोणाला आवश्यक आहे, त्यांना कशाची आवश्यकता आहे आणि त्यांना त्याची आवश्यकता कारणावर केंद्रित आहे. नेहमीचे टेम्पलेट असे दिसते: एक (वापरकर्त्याचा प्रकार) म्हणून, मला (ध्येय) हवे आहे जेणेकरून (लाभ).

उदाहरण:

• एक ग्राहक म्हणून, मला माझे पेमेंट तपशील जतन करायचे आहेत जेणेकरून मी भविष्यातील खरेदी जलद पूर्ण करू शकेन.
• प्रशासक म्हणून, मला वापरकर्ता संकेतशब्द रीसेट करायचे आहेत जेणेकरुन मी वापरकर्त्यांना त्यांच्या खात्यांमध्ये पुन्हा प्रवेश मिळवण्यास मदत करू शकेन.
• एक विद्यार्थी म्हणून, मला अभ्यासक्रमाचे साहित्य डाउनलोड करायचे आहे जेणेकरुन गरज असेल तेव्हा मी ऑफलाइन अभ्यास करू शकेन.
• हे टेम्पलेट तांत्रिक गुंतागुंतीपेक्षा वापरकर्त्याच्या मूल्यावर लक्ष ठेवण्यास मदत करते.

वापरकर्ता कथा का महत्त्वाच्या

जुनी शाळा सॉफ्टवेअर आवश्यकता मोठ्या तांत्रिक दस्तऐवजांमध्ये बदलू शकतात, जे भागधारकांना समजणे खूप कठीण आहे. वापरकर्ता कथा संप्रेषण सुलभ करतात कारण ते साध्या भाषेत वैशिष्ट्यांचे वर्णन करतात.

काही सर्वात मोठ्या लाभांमध्ये हे समाविष्ट आहे, मुळात:

तुम्हाला वापरकर्त्याच्या गरजा चांगल्या प्रकारे समजतात.

वापरकर्ता कथा केवळ कार्यक्षमतेच्या भागावर झूम इन न करता वापरकर्त्याच्या दृष्टीकोनातून गोष्टींकडे पाहण्यासाठी कार्यसंघाला प्रवृत्त करतात. परिणामी, तुमच्याकडे अशी उत्पादने आहेत जी खरोखरच वास्तविक समस्यांचे निराकरण करतात, आणि केवळ अतिरिक्त वैशिष्ट्यांवर लक्ष ठेवत नाहीत ज्यासाठी कोणीही विचारले नाही.

उत्तम टीमवर्क आणि सामायिक संदर्भ.

वापरकर्ता कथा सोप्या भाषेत लिहिल्या जात असल्यामुळे, विकासक, डिझायनर, परीक्षक, उत्पादन व्यवस्थापक आणि अगदी क्लायंटसाठी ते अनुसरण करणे सोपे आहे. यामुळे वेगवेगळ्या संघांमध्ये संवाद अधिक सुरळीत होतो आणि प्रामाणिकपणे कमी “मला वाटले की तुम्हाला X म्हणायचे आहे” परिस्थिती. हे चपळ विकासासह चांगले कार्य करते. चपळ संपूर्ण प्रकल्पाला लहान, नियंत्रण करण्यायोग्य कार्यांमध्ये मोडते जे लहान विकास चक्रांमध्ये केले जाते, ज्याला स्प्रिंट म्हणतात. वापरकर्ता कथा थेट या नित्यक्रमात सरकतात कारण प्रत्येक कार्यक्षमतेच्या वेगळ्या ब्लॉकप्रमाणे असते.

प्राधान्य देणे खूप सोपे होते.

प्रत्येक वापरकर्ता कथा स्वतःचे मूल्य देत असल्याने, उत्पादन मालक व्यावसायिक उद्दिष्टांच्या आधारे पुढे काय तयार करायचे ते रँक करू शकतात, तसेच ग्राहकांना सध्या काय हवे आहे.

चांगल्या वापरकर्ता कथेची वैशिष्ट्ये

उच्च-गुणवत्तेच्या वापरकर्त्याच्या कथा सहसा गुंतवणूक तत्त्वाचे पालन करतात:

स्वतंत्र

कथा शक्य तितक्या स्वयंपूर्ण असाव्यात. हे मदत करते कारण तुम्ही इतर वैशिष्ट्यांवरील अवलंबित्व कमी करता.

निगोशिएबल

वापरकर्त्याच्या कथेने कठोर, न बदलता येणाऱ्या ब्ल्यूप्रिंटप्रमाणे वागण्याऐवजी संभाषण सुरू केले पाहिजे. विकासादरम्यान, कार्यसंघाने दृष्टिकोन समायोजित करण्यासाठी खुले असले पाहिजे.

मौल्यवान

वापरकर्त्यांसाठी किंवा व्यवसायासाठी प्रत्येक कथेला खरा अर्थ द्यावा लागतो.

अंदाजे

कथा पूर्ण करण्यासाठी आवश्यक असलेल्या कामाचा अंदाज बांधण्यात टीम सक्षम असावी, जरी ती सुरुवातीला अगदी अचूक नसली तरीही.

लहान

कथा एका स्प्रिंटमध्ये पूर्ण करण्यासाठी इतक्या लहान असाव्यात. अन्यथा ते गोंधळलेले आणि मंद होतात.

चाचणी करण्यायोग्य

स्वीकृतीचे स्पष्ट निकष असावेत जेणेकरुन परीक्षक हे वैशिष्ट्य योग्यरितीने केले आहे की नाही याची पुष्टी करू शकतील.

प्रभावी वापरकर्ता कथा लिहिणे

फक्त टेम्पलेट भरणे आणि पुढे जाण्यापेक्षा हे खरोखरच अधिक क्लिष्ट आहे. हे केवळ चेकबॉक्स शैलीच नव्हे तर व्यावहारिक, थोडेसे मानवी वाटेल अशा प्रकारे करण्यात मदत करते.

वापरकर्ता ओळखा

वैशिष्ट्यातून नेमके कोणाला मूल्य मिळते हे स्पष्टपणे परिभाषित करून प्रारंभ करा.

सामान्य उदाहरणे आहेत:

• ग्राहक
• कर्मचारी
• प्रशासक
• शिक्षक
• विद्यार्थी
• अतिथी वापरकर्ता

ध्येय परिभाषित करा

पुढे, वापरकर्ता काय साध्य करण्याचा प्रयत्न करीत आहे ते स्पष्ट करा. विशिष्ट व्हा, कारण “मला चांगली सुरक्षा हवी आहे” फक्त तिथे तरंगते, एक प्रकारची अस्पष्ट.

त्याऐवजी असे काहीतरी लिहा

“मला द्वि-घटक प्रमाणीकरण हवे आहे.”

जेव्हा उद्दिष्टे खुसखुशीत असतात, तेव्हा विकासाच्या चर्चा कमी गुंफतात.

फायदा समजावून सांगा

नंतर “त्यामुळे” भाग समाविष्ट करा, जे मुळात वैशिष्ट्य का महत्त्वाचे आहे हे सांगते.

उदाहरणार्थ: “एक ऑनलाइन खरेदीदार म्हणून, मला माझी ऑर्डर ट्रॅक करायची आहे जेणेकरून ती कधी येईल हे मला कळेल.” तो फायदा संघाला संदर्भ देतो आणि त्यामुळे कामाला खऱ्या गरजांशी जोडलेले वाटते.

स्वीकृती निकष काय आहेत?

स्वीकृती निकष म्हणजे अशा अटी ज्या वापरकर्त्याची कथा प्रत्यक्षात पूर्ण झाली असे समजण्यापूर्वी पूर्ण करणे आवश्यक आहे.

ते विकसक आणि परीक्षक दोघांसाठी स्पष्ट अपेक्षा सेट करून अनिश्चितता कमी करतात.

उदाहरण:

वापरकर्ता कथा

एक ग्राहक म्हणून, मला माझा पासवर्ड रीसेट करायचा आहे जेणेकरून मला माझ्या खात्यात पुन्हा प्रवेश मिळू शकेल.

स्वीकृती निकष:

• वापरकर्ते त्यांचे नोंदणीकृत ईमेल वापरून पासवर्ड रीसेट करण्याची विनंती करू शकतात.
• रिसेट लिंक एका मिनिटात पाठवली जाते.
• लिंक 30 मिनिटांनंतर कालबाह्य होईल.
• नवीन पासवर्ड सुरक्षा आवश्यकता पूर्ण करणे आवश्यक आहे.
• वापरकर्त्यांना त्यांचा पासवर्ड यशस्वीरित्या बदलल्यानंतर पुष्टीकरण मिळते.

स्वीकृती निकष प्रश्नाचे उत्तर देण्यात मदत करतात

“हे वैशिष्ट्य योग्यरित्या कार्य करते हे आम्हाला कसे कळेल?”

स्वीकृती निकष लिहिण्यासाठी सर्वोत्तम पद्धती

स्वीकृती निकष चांगले असले पाहिजेत, खरोखर चांगले. जसे की, ते स्पष्ट असणे आवश्यक आहे परंतु अशा प्रकारे अस्पष्ट देखील नाही की ज्यामुळे अर्थ लावण्यासाठी जागा मिळेल. ते सर्वोत्तम असतात जेव्हा ते असतात:

साफ

“सहज” किंवा “जलद” सारख्या अस्पष्ट गोष्टी टाळा कारण त्या शब्दांचा अर्थ वेगवेगळ्या लोकांसाठी भिन्न असू शकतो.

मोजता येण्याजोगा

जेव्हाही तुम्हाला शक्य असेल तेव्हा विशिष्ट आचरण जोडा. उदाहरणार्थ

“पृष्ठ तीन सेकंदात लोड होते.”

चाचणी करण्यायोग्य

प्रत्येक आयटम केवळ गृहीत धरून न करता चाचणीद्वारे पडताळण्यायोग्य असावा.

वापरकर्ता-केंद्रित

स्वीकृती निकष वापरकर्त्याच्या परिणामांकडे निर्देशित केले पाहिजेत, तांत्रिक बिल्ड तपशीलांकडे नाही.

टाळण्याच्या सामान्य चुका

खूप मोठ्या असलेल्या कथा

एक वाईट उदाहरण:

“एक ग्राहक म्हणून, मला ऑनलाइन खरेदी प्रणाली हवी आहे.”

हे एकाच वेळी डझनभर गोष्टी संपते. त्याऐवजी, ते लहान तुकड्यांमध्ये विभाजित करा जसे:

• उत्पादने शोधा
• कार्टमध्ये उत्पादने जोडा
• पूर्ण पेमेंट
• ऑर्डर इतिहास पहा

तांत्रिक अंमलबजावणी रेंगाळणे

वापरकर्ता कथा कोडिंग सोल्यूशन्सपासून दूर राहिले पाहिजे. त्याऐवजी:

“SQL डेटाबेस अनुक्रमणिका लागू करा.”

प्रयत्न करा:

“एक वापरकर्ता म्हणून, मला शोध परिणाम लवकर दिसावेत असे वाटते.”

मग विकासक सर्वोत्तम अभियांत्रिकी मार्ग शोधू शकतात.

गहाळ स्वीकृती निकष

स्वीकृती निकष समाविष्ट नसल्यास, भिन्न कार्यसंघ सदस्य समान आवश्यकता वेगळ्या पद्धतीने वाचू शकतात. ते गैरसमजांमध्ये बदलू शकते आणि शेवटी, महागड्या पुनर्कार्यात बदलू शकते.

वास्तविक-जगाचे उदाहरण

अन्न वितरण अनुप्रयोगाचा विचार करा.

वापरकर्ता कथा

“ग्राहक म्हणून, मला एकापेक्षा जास्त डिलिव्हरी पत्ते जतन करायचे आहेत जेणेकरुन मी वेगवेगळ्या ठिकाणी अन्न ऑर्डर करू शकेन.”

स्वीकृती निकष

• वापरकर्ते 10 पत्ते जतन करू शकतात.
• वापरकर्ते विद्यमान पत्ते संपादित करू शकतात.
• वापरकर्ते जतन केलेले पत्ते हटवू शकतात.
• एक पत्ता डीफॉल्ट म्हणून चिन्हांकित केला जाऊ शकतो.
• चेकआउट दरम्यान डीफॉल्ट पत्ता स्वयंचलितपणे निवडला जातो.

परिणाम

हे सेटअप विकसकांना स्पष्ट सीमा देते, तर परीक्षकांना तपासण्यासाठी आणि पुष्टी करण्यासाठी मोजता येण्याजोग्या परिस्थिती मिळतात.