यूझर स्टोरीज कशा लिहायच्या (उदाहरणे आणि Acceptance Criteria सह)
यूझर स्टोरी म्हणजे वापरकर्त्याच्या दृष्टीकोनातून फीचरचे छोटे वर्णन: "एक [वापरकर्त्याचा प्रकार] म्हणून, मला [ध्येय] करायचे आहे जेणेकरून [कारण]." त्याखाली acceptance criteria लिहा, म्हणजे स्टोरी पूर्ण झाली असे म्हणण्यासाठी खरे असायला हव्यात अशा काही विशिष्ट अटी. प्रत्येक स्टोरी एका फेरीत बांधता आणि तपासता येईल इतकी छोटी ठेवा, आणि अटी अशा लिहा की कोणीही त्या तपासू शकेल.
यूझर स्टोरीज चपळ (agile) सॉफ्टवेअर टीम्समुळे लोकप्रिय झाल्या, पण तुम्ही AI अॅप बिल्डरसोबत एकटे बांधत असतानाही त्या तितक्याच उपयुक्त आहेत. चांगली स्टोरी हा चांगला प्रॉम्प्ट असतो.
स्वरूप
यूझर स्टोरीचे तीन भाग असतात:
एक [कोण] म्हणून, मला [काय] करायचे आहे जेणेकरून [का] मिळेल.
- कोण म्हणजे वापरकर्त्याचा एक विशिष्ट प्रकार: पहिल्यांदा येणारा अभ्यागत, पैसे भरणारा सदस्य, क्लिनिकचा रिसेप्शनिस्ट, अॅडमिन. "वापरकर्ता" नव्हे.
- काय म्हणजे त्यांना जे करायचे आहे, त्यांच्या शब्दांत. स्क्रीन कशी चालते ते नव्हे.
- का म्हणजे त्यांना ज्या परिणामाची काळजी आहे. हा भाग लोक वगळतात, आणि चुकीचे फीचर बांधण्यापासून तोच थांबवतो.
उदाहरण:
एक जिम सदस्य म्हणून, मला फोनवरून वर्ग बुकिंग रद्द करायचे आहे जेणेकरून वेटलिस्टवरील कोणीतरी माझी जागा घेऊ शकेल आणि माझ्याकडून नो-शो शुल्क आकारले जाणार नाही.
"का" तुम्हाला "काय" न सांगितलेल्या दोन गोष्टी सांगतो: ते फोनवर चालले पाहिजे, आणि वेटलिस्ट व शुल्क नियम यात गुंतलेले आहेत.
Acceptance criteria
स्टोरी काय हवे आहे ते सांगते. Acceptance criteria ते कधी पूर्ण झाले ते सांगतात. त्या इतक्या विशिष्ट असाव्यात की दोन लोक प्रत्येक अट पास झाली का यावर सहमत होऊ शकतील.
त्या लिहिण्याचा सामान्य मार्ग म्हणजे Given / When / Then:
- Given एक सुरुवातीची परिस्थिती
- When वापरकर्ता काहीतरी करतो
- Then हा परिणाम आहे
जिम बुकिंग स्टोरीसाठी:
- Given माझे बुकिंग १२ तासांपेक्षा जास्त दूर आहे, when मी Cancel वर टॅप करतो आणि पुष्टी करतो, then बुकिंग काढले जाते आणि मला "Booking cancelled" दिसते.
- Given मी एक बुकिंग रद्द करतो आणि वर्गाची वेटलिस्ट आहे, when रद्द करणे सेव्ह होते, then वेटलिस्टवरील पहिल्या व्यक्तीला जागा आणि एक ईमेल मिळतो.
- Given बुकिंग १२ तासांच्या आत आहे, when मी Cancel वर टॅप करतो, then पुष्टी करण्यापूर्वी मला दिसते की उशिरा रद्द करण्याचे शुल्क लागू होते.
- Given मी फोन-रुंदीच्या स्क्रीनवर आहे, then Cancel बटण बाजूला स्क्रोल न करता दिसते.
साधी चेकलिस्टही चालते, जोपर्यंत प्रत्येक आयटम तपासता येतो. "रद्द करणे सोपे आहे" तपासता येत नाही. "बुकिंग यादीतून रद्द करायला जास्तीत जास्त दोन टॅप लागतात" तपासता येते.
पायरीनुसार: चांगली स्टोरी लिहिणे
पायरी 1: खऱ्या वापरकर्त्यापासून आणि खऱ्या समस्येपासून सुरुवात करा
एक प्रकारचा वापरकर्ता आणि आज त्यांना जी अडचण येते ती निवडा. ग्राहक मुलाखती घेतल्या असतील तर त्यांचे शब्द वापरा. "मी नेहमी रद्द करायला विसरतो आणि माझ्याकडून पैसे कापले जातात" हे "रद्दीकरण फीचर जोडा" यापेक्षा चांगली सुरुवात आहे.
पायरी 2: एका ओळीची स्टोरी लिहा
टेम्पलेट भरा. जर तुम्हाला पटणारे "जेणेकरून" लिहिता येत नसेल, तर फीचर खरेच हवे आहे का ते विचारा.
पायरी 3: तीन ते सहा acceptance criteria जोडा
आधी मुख्य यशस्वी केस कव्हर करा, मग महत्त्वाचे प्रकार: वेगळी भूमिका, रिकामी स्थिती, एखादी मर्यादा, एखादी एरर. सहापेक्षा जास्त लिहित असाल, तर स्टोरी कदाचित खूप मोठी आहे.
पायरी 4: काय कक्षेबाहेर आहे ते नोंदवा
एक ओळ खूप मागेपुढे होणे वाचवते: "कक्षेबाहेर: सशुल्क वर्गांचे परतावे; अॅडमिनने सदस्यांच्या वतीने रद्द करणे." बांधताना स्टोरी वाढत जाण्यापासून ते थांबवते.
पायरी 5: INVEST विरुद्ध तपासा
INVEST ही चांगल्या स्टोरीजसाठी सामान्य चेकलिस्ट आहे. स्टोरी अशी असावी:
| अक्षर | म्हणजे | झटपट चाचणी |
|---|---|---|
| I | स्वतंत्र (Independent) | दुसऱ्या स्टोरीची वाट न पाहता बांधता येते |
| N | वाटाघाटीयोग्य (Negotiable) | गरज वर्णन करते, ठरलेले डिझाइन नाही |
| V | मौल्यवान (Valuable) | ती प्रकाशित झाली तर वापरकर्त्याच्या लक्षात येईल |
| E | अंदाजयोग्य (Estimable) | ती साधारण किती मोठी आहे याचा अंदाज बांधता येतो |
| S | छोटी (Small) | एका बैठकीत बांधली आणि तपासली जाते |
| T | तपासण्यायोग्य (Testable) | प्रत्येक acceptance criterion तपासता येतो |
प्रत्येक स्टोरीला गुण देण्याची गरज नाही. स्टोरी चुकीची वाटते आणि कारण जाणून घ्यायचे असते तेव्हा हे सर्वात उपयुक्त ठरते.
चांगली आणि वाईट उदाहरणे
| कमकुवत स्टोरी | समस्या | अधिक चांगली स्टोरी |
|---|---|---|
| एक यूझर म्हणून, मला डॅशबोर्ड हवा. | विशिष्ट वापरकर्ता नाही, कारण नाही, तपासता येत नाही | एक दुकान मालक म्हणून, मला आजच्या ऑर्डर्स आणि कमाई एका स्क्रीनवर पाहायची आहे जेणेकरून दिवस चांगला चालला आहे का ते एका नजरेत कळेल. |
| एक अॅडमिन म्हणून, मला डेटाबेसमध्ये status कॉलम हवा. | अंमलबजावणीचे वर्णन, गरजेचे नाही | एक अॅडमिन म्हणून, मला ऑर्डर्स पाठवल्या गेल्या म्हणून चिन्हांकित करायचे आहे जेणेकरून ग्राहक कुठे आहेत हे विचारायला ईमेल करणे थांबेल. |
| एक ग्राहक म्हणून, मला माझे खाते व्यवस्थापित करायचे आहे. | खूप मोठी: अनेक फीचर्स झाकते | एक ग्राहक म्हणून, मला माझा ईमेल पत्ता बदलायचा आहे जेणेकरून पावत्या माझ्या नव्या इनबॉक्सवर जातील. |
| एक अभ्यागत म्हणून, मला साइट जलद हवी. | स्टोरी नाही; प्रत्येकाला हवी असलेली गुणवत्ता | प्रत्येक स्टोरीवर एक criterion म्हणून लिहा, किंवा वेगळे कामगिरी लक्ष्य म्हणून. |
खूप मोठी स्टोरी कशी विभाजित करायची
मोठ्या स्टोरीजमुळेच प्रोजेक्ट्स अडतात. विभाजनाचे सामान्य मार्ग:
- वापरकर्त्याच्या भूमिकेनुसार. सदस्य स्वतःची बुकिंग्ज रद्द करतात; स्टाफ कोणाचीही रद्द करतो.
- प्रवाहातील पायरीनुसार. वर्ग ब्राउझ करा; वर्ग बुक करा; स्मरणपत्र मिळवा.
- आधी साधी केस. आत्ता एक मोफत वर्ग रद्द करा; शुल्क आणि परतावे नंतरच्या स्टोरीत हाताळा.
- डेटाच्या भिन्नतेनुसार. आधी एक ठिकाण सपोर्ट करा, नंतर अनेक.
- यशस्वी मार्ग, मग एरर. ते काम करेल असे आधी बांधा, मग भरलेले वर्ग, संपलेले पास इत्यादींसाठी हाताळणी जोडा.
प्रत्येक तुकडा अजूनही असे काहीतरी असावा जे वापरकर्ता वापरू शकेल आणि लक्षात घेईल.
यूझर स्टोरीज प्रॉम्प्ट्स म्हणून वापरणे
Acceptance criteria असलेली यूझर स्टोरी AI अॅप बिल्डरसाठी चांगल्या प्रॉम्प्टच्या अगदी जवळ असते. ती AI ला कोण, काय, का आणि "पूर्ण" ची व्याख्या देते. प्रत्येक संदेशात एक स्टोरी पाठवा:
एक जिम सदस्य म्हणून, मला फोनवरून वर्ग बुकिंग रद्द करायचे आहे जेणेकरून वेटलिस्टवरील कोणीतरी माझी जागा घेऊ शकेल. Acceptance criteria:
- My Bookings मधील प्रत्येक बुकिंगवर Cancel आहे, पुष्टीकरण पायरीसह.
- वर्गाच्या १२ तास आधीपेक्षा जास्त वेळ आधी रद्द केल्यास फक्त बुकिंग काढले जाते.
- १२ तासांपेक्षा कमी असल्यास, पुष्टी करण्यापूर्वी "A late-cancellation fee of $5 applies" दाखवा, आणि शुल्क बुकिंगवर नोंदवा.
- वर्गाची वेटलिस्ट असल्यास, पहिल्या व्यक्तीला जागा आणि ईमेल मिळतो.
- फोन-रुंदीच्या स्क्रीनवर चालते. कक्षेबाहेर: परतावे, स्टाफने सदस्यांच्या वतीने रद्द करणे. हे बांधा, मग प्रीव्ह्यूमध्ये प्रत्येक criterion तपासा आणि कोणते पास होतात ते सांगा.
तुम्ही AI ला एका ढोबळ कल्पनेवरून स्टोरीज तयार करायलाही सांगू शकता, मग त्या स्वतः संपादित करा:
माझ्या अॅप कल्पनेची ही आहे: [दोन-तीन वाक्ये]. पहिल्या आवृत्तीसाठी यूझर स्टोरीज लिहा, वापरकर्त्याच्या प्रकारानुसार गटबद्ध, प्रत्येकाला ३ ते ५ Given/When/Then acceptance criteria. लॉंचसाठी कोणत्या आवश्यक आहेत आणि कोणत्या नंतर होऊ शकतात ते चिन्हांकित करा.
निकाल नेहमी वाचा आणि संपादित करा. AI ला तुमचे वापरकर्ते माहीत नसतात; तुम्हाला माहीत असतात.
Acceptance criteria तुमची टेस्ट योजना म्हणूनही काम करतात. स्टोरी बांधून झाल्यावर प्रत्येक criterion स्वतः तपासा. लॉंचपूर्वी तुमच्या अॅपची चाचणी यावर आधारित आहे.
यूझर स्टोरीज इतर दस्तऐवजांत कुठे बसतात
- प्रॉडक्ट रिक्वायरमेंट्स डॉक संपूर्ण प्रॉडक्ट वर्णन करतो: समस्या, वापरकर्ते, स्कोप. यूझर स्टोरीज त्यातील तपशीलवार तुकडे आहेत. पहा AI सह PRD कसा लिहायचा.
- बग रिपोर्ट आधीच बांधलेल्या स्टोरीच्या विरुद्ध तुटलेल्या गोष्टीचे वर्णन करतो. पहा चांगला बग रिपोर्ट कसा लिहायचा.
- MVP म्हणजे मुख्य मूल्य देणाऱ्या स्टोरीजचा सर्वात लहान संच. पहा MVP म्हणजे काय.
सामान्य चुका
- "एक यूझर म्हणून…" खूप अस्पष्ट. वापरकर्त्याचा खरा प्रकार नाव द्या.
- "जेणेकरून" वगळणे. कारण नसेल तर योग्य तडजोड करता येत नाही.
- गरज ऐवजी उपाय लिहिणे. "मला ड्रॉपडाउन हवा" हे कोणी विचार करण्याआधीच डिझाइन पक्के करते.
- तपासता न येणारे criteria. "सोपे", "जलद" आणि "सहज समजणारे" या इच्छा आहेत, criteria नाहीत.
- खरे तर epics असलेल्या स्टोरीज. "माझे खाते व्यवस्थापित करा" म्हणजे दहा स्टोरीज.
- सर्व स्टोरीज आधीच लिहिणे. पुढच्या काही तपशिलात लिहा; उरलेल्या तिथे पोहोचेपर्यंत एका ओळीच्या ठेवा.
Mythex मधील स्टोरीज
Mythex मध्ये कल्पनेचे स्टोरीजमध्ये रूपांतर करण्यासाठी Plan मोड चांगली जागा आहे: काहीही संपादित करण्यापूर्वी एजंट दृष्टीकोनावर चर्चा करतो. स्टोरी तयार झाली की Build वर जा आणि ती पेस्ट करा, प्रत्येक संदेशात एक स्टोरी. प्रत्येकानंतर /test प्रीव्ह्यूमधून क्लिक करून प्रवाह तपासू शकतो, आणि चुकीच्या दिशेने गेलेला कोणताही प्रतिसाद Revert to this point ने मागे नेता येतो. डॉक्समधील प्रभावी प्रॉम्प्ट्स आणि AI अॅप बिल्डर्ससाठी प्रॉम्प्ट्स कसे लिहायचे यावरील आमचे मार्गदर्शक पहा.
यूझर स्टोरी चेकलिस्ट
- एक विशिष्ट प्रकारचा वापरकर्ता नाव देतो
- गरज वर्णन करतो, डिझाइन नाही
- खरे "जेणेकरून" कारण समाविष्ट आहे
- तीन ते सहा तपासता येण्याजोगे acceptance criteria आहेत
- किमान एक एज केस किंवा एरर कव्हर करतो
- काय कक्षेबाहेर आहे ते नमूद केले आहे
- एका फेरीत बांधता आणि तपासता येईल इतकी छोटी आहे
- बांधल्यानंतर criteria एक-एक करून तपासले आहेत
प्रश्न
यूझर स्टोरीचे स्वरूप काय आहे?
सामान्य टेम्पलेट असे आहे: एक [वापरकर्त्याचा प्रकार] म्हणून, मला [काही ध्येय] करायचे आहे जेणेकरून [काही कारण] मिळेल. त्यानंतर acceptance criteria येतात, म्हणजे स्टोरी पूर्ण झाली असे म्हणण्यासाठी खरे असायला हव्यात अशा अटींची छोटी यादी.
Acceptance criteria म्हणजे काय?
Acceptance criteria म्हणजे विशिष्ट, तपासता येण्याजोग्या अटी ज्या ठरवतात की यूझर स्टोरी कधी पूर्ण झाली. त्या अनेकदा Given / When / Then स्वरूपात लिहिल्या जातात: दिलेल्या सुरुवातीच्या परिस्थितीत, जेव्हा वापरकर्ता काहीतरी करतो, तेव्हा ठराविक परिणाम घडतो.
यूझर स्टोरी किती मोठी असावी?
एका बैठकीत बांधता आणि तपासता येईल इतकी छोटी, आणि तरीही स्वतःहून उपयुक्त. स्टोरीत पाच-सहापेक्षा जास्त acceptance criteria असतील किंवा अनेक स्क्रीन्स व्यापत असतील, तर ती वापरकर्त्याच्या भूमिकेनुसार, प्रवाहातील पायरीनुसार, किंवा आधी साध्या केससाठी आणि नंतर एज केसेससाठी विभागा.
AI सह बांधताना यूझर स्टोरीज उपयोगी आहेत का?
हो. acceptance criteria असलेली यूझर स्टोरी जवळजवळ आदर्श प्रॉम्प्ट असते: ते फीचर कोणासाठी आहे, त्यांना काय हवे आहे आणि ते योग्य काम करते हे नेमके कसे तपासायचे, हे सांगते. प्रत्येक संदेशात एक स्टोरी पाठवल्याने AI चे बदल लहान आणि तपासण्यास सोपे राहतात.