యూజర్ స్టోరీలు ఎలా రాయాలి (ఉదాహరణలు మరియు అంగీకార ప్రమాణాలతో)
యూజర్ స్టోరీ అనేది యూజర్ దృష్టికోణం నుండి ఒక ఫీచర్ యొక్క చిన్న వివరణ: "As a [యూజర్ రకం], I want [లక్ష్యం] so that [కారణం]." దాని కింద మీరు అంగీకార ప్రమాణాలు రాస్తారు, అంటే స్టోరీ పూర్తయిందని లెక్కించాలంటే నిజం కావాల్సిన కొన్ని నిర్దిష్ట షరతులు. ప్రతి స్టోరీని ఒకేసారి నిర్మించి పరీక్షించగలిగేంత చిన్నదిగా ఉంచండి, మరియు ప్రమాణాలను ఎవరైనా తనిఖీ చేయగలిగేలా రాయండి.
యూజర్ స్టోరీలు ఎజైల్ సాఫ్ట్‌వేర్ టీమ్‌ల ద్వారా ప్రాచుర్యం పొందాయి, కానీ AI యాప్ బిల్డర్‌తో మీరే నిర్మించేటప్పుడు కూడా అవి అంతే ఉపయోగకరం. మంచి స్టోరీ మంచి ప్రాంప్ట్.
ఫార్మాట్
యూజర్ స్టోరీకి మూడు భాగాలు ఉంటాయి:
As a [ఎవరు], I want [ఏమి] so that [ఎందుకు].
- ఎవరు అనేది ఒక నిర్దిష్ట రకమైన యూజర్: మొదటిసారి వచ్చే సందర్శకుడు, చెల్లించే సభ్యుడు, క్లినిక్ రిసెప్షనిస్ట్, అడ్మిన్. "the user" కాదు.
- ఏమి అనేది వారు చేయాలనుకునే పని, వారి స్వంత మాటల్లో. స్క్రీన్ ఎలా పని చేస్తుందో కాదు.
- ఎందుకు అనేది వారు పట్టించుకునే ఫలితం. ఇది చాలా మంది వదిలేసే భాగం, మరియు తప్పు విషయాన్ని నిర్మించకుండా ఆపేది ఇదే.
ఉదాహరణ:
As a జిమ్ సభ్యుడు, I want నా ఫోన్ నుండి క్లాస్ బుకింగ్‌ను రద్దు చేయడానికి so that వెయిట్‌లిస్ట్‌లో ఉన్న ఎవరో నా స్థానాన్ని తీసుకోగలరు, మరియు నాకు no-show రుసుము ఛార్జ్ కాదు.
"ఎందుకు" అనే భాగం "ఏమి" చెప్పని రెండు విషయాలు చెబుతుంది: ఇది ఫోన్‌లో పని చేయాలి, మరియు వెయిట్‌లిస్ట్ మరియు రుసుము నియమాలు ఇందులో ఉన్నాయి.
అంగీకార ప్రమాణాలు
స్టోరీ ఏమి కావాలో చెబుతుంది. అంగీకార ప్రమాణాలు అది ఎప్పుడు పూర్తయిందో చెబుతాయి. ప్రతి ఒక్కటి పాస్ అయిందా లేదా అని ఇద్దరు వ్యక్తులు అంగీకరించేంత నిర్దిష్టంగా ఉండాలి.
వీటిని రాయడానికి ఒక సాధారణ మార్గం Given / When / Then:
- Given ఒక ప్రారంభ పరిస్థితి
- When యూజర్ ఏదైనా చేస్తాడు
- Then ఇది ఫలితం
జిమ్ బుకింగ్ స్టోరీకి:
- Given నాకు 12 గంటల కంటే ఎక్కువ దూరంలో ఒక బుకింగ్ ఉంది, when నేను Cancel నొక్కి నిర్ధారిస్తాను, then బుకింగ్ తొలగించబడుతుంది మరియు "Booking cancelled" కనిపిస్తుంది.
- Given నేను ఒక బుకింగ్‌ను రద్దు చేస్తాను మరియు క్లాస్‌కు వెయిట్‌లిస్ట్ ఉంది, when రద్దు సేవ్ అవుతుంది, then వెయిట్‌లిస్ట్‌లో మొదటి వ్యక్తికి స్థానం మరియు ఇమెయిల్ వస్తాయి.
- Given 12 గంటల లోపు బుకింగ్, when నేను Cancel నొక్కుతాను, then నేను నిర్ధారించే ముందు ఆలస్య-రద్దు రుసుము వర్తిస్తుందని నాకు కనిపిస్తుంది.
- Given నేను ఫోన్-వెడల్పు స్క్రీన్‌పై ఉన్నాను, then Cancel బటన్ పక్కకు స్క్రోల్ చేయకుండానే కనిపిస్తుంది.
ప్రతి అంశం పరీక్షించదగినదైతే సాదా చెక్‌లిస్ట్ కూడా పని చేస్తుంది. "రద్దు చేయడం సులభం" పరీక్షించదగినది కాదు. "బుకింగ్ జాబితా నుండి రద్దు చేయడానికి గరిష్టంగా రెండు ట్యాప్‌లు" పరీక్షించదగినది.
దశలవారీగా: మంచి స్టోరీ రాయడం
దశ 1: ఒక నిజమైన యూజర్ మరియు ఒక నిజమైన సమస్య నుండి మొదలు పెట్టండి
ఒక రకమైన యూజర్‌ను మరియు వారు ఈరోజు ఇబ్బంది పడుతున్న విషయాన్ని ఎంచుకోండి. మీరు కస్టమర్ ఇంటర్వ్యూలు చేసి ఉంటే, వారి మాటలు వాడండి. "నేను ఎప్పుడూ రద్దు చేయడం మర్చిపోతాను, ఛార్జ్ అయిపోతుంది" అనేది "cancellation feature జోడించు" కంటే మంచి ప్రారంభ బిందువు.
దశ 2: ఒక-లైన్ స్టోరీ రాయండి
టెంప్లేట్ నింపండి. మీరు ఒప్పించే "so that" రాయలేకపోతే, ఆ ఫీచర్ అసలు అవసరమా అని అడగండి.
దశ 3: మూడు నుండి ఆరు అంగీకార ప్రమాణాలు జోడించండి
ముందు ప్రధాన విజయ కేసును కవర్ చేయండి, తర్వాత ముఖ్యమైన వైవిధ్యాలు: వేరే పాత్ర, ఖాళీ స్థితి, పరిమితి, లేదా లోపం. ఆరు కంటే ఎక్కువ రాస్తుంటే, స్టోరీ బహుశా చాలా పెద్దది.
దశ 4: ఏది పరిధిలో లేదో గమనించండి
ఒక్క లైన్ చాలా ముందుకు వెనుకకు చర్చలను ఆదా చేస్తుంది: "పరిధి వెలుపల: చెల్లించిన క్లాసులకు రీఫండ్లు; అడ్మిన్‌లు సభ్యుల తరపున రద్దు చేయడం." మీరు నిర్మించేటప్పుడు స్టోరీ పెరగకుండా ఇది ఆపుతుంది.
దశ 5: INVEST తో తనిఖీ చేయండి
INVEST మంచి స్టోరీల కోసం ఒక సాధారణ చెక్‌లిస్ట్. ఒక స్టోరీ ఇలా ఉండాలి:
| అక్షరం | అర్థం | త్వరిత పరీక్ష |
|---|---|---|
| I | Independent (స్వతంత్రం) | మరో స్టోరీ కోసం వేచి ఉండకుండా నిర్మించవచ్చా |
| N | Negotiable (చర్చించదగినది) | అవసరాన్ని వివరిస్తుంది, స్థిర డిజైన్‌ను కాదు |
| V | Valuable (విలువైనది) | షిప్ అయితే యూజర్ గమనిస్తాడు |
| E | Estimable (అంచనా వేయదగినది) | అది ఎంత పెద్దదో సుమారుగా ఊహించగలరు |
| S | Small (చిన్నది) | ఒక సిట్టింగ్‌లో నిర్మించి పరీక్షించవచ్చు |
| T | Testable (పరీక్షించదగినది) | ప్రతి అంగీకార ప్రమాణాన్ని తనిఖీ చేయవచ్చు |
ప్రతి స్టోరీకీ స్కోర్ చేయాల్సిన అవసరం లేదు. స్టోరీ తప్పుగా అనిపించి, ఎందుకో తెలుసుకోవాలనుకున్నప్పుడు ఇది ఎక్కువ ఉపయోగపడుతుంది.
మంచి మరియు చెడు ఉదాహరణలు
| బలహీనమైన స్టోరీ | సమస్య | మెరుగైన స్టోరీ |
|---|---|---|
| As a user, I want a dashboard. | నిర్దిష్ట యూజర్ లేరు, కారణం లేదు, పరీక్షించలేము | As a shop owner, I want to see today's orders and revenue on one screen so that I know at a glance if the day is going well. |
| As an admin, I want the database to have a status column. | అమలును వివరిస్తుంది, అవసరాన్ని కాదు | As an admin, I want to mark orders as shipped so that customers stop emailing to ask where they are. |
| As a customer, I want to manage my account. | చాలా పెద్దది: అనేక ఫీచర్లను కవర్ చేస్తుంది | As a customer, I want to change my email address so that receipts go to my new inbox. |
| As a visitor, I want the site to be fast. | స్టోరీ కాదు; ప్రతి ఒక్కరికీ అవసరమైన నాణ్యత | దీన్ని ప్రతి స్టోరీపై ఒక ప్రమాణంగా రాయండి, లేదా ప్రత్యేక పనితీరు లక్ష్యంగా. |
చాలా పెద్ద స్టోరీని ఎలా విభజించాలి
పెద్ద స్టోరీలే ప్రాజెక్ట్‌లు ఆగిపోయే చోటు. సాధారణ విభజన మార్గాలు:
- యూజర్ పాత్ర వారీగా. సభ్యులు తమ స్వంత బుకింగ్‌లను రద్దు చేస్తారు; స్టాఫ్ ఎవరి బుకింగ్‌నైనా రద్దు చేస్తారు.
- ప్రవాహంలో దశ వారీగా. క్లాసులు బ్రౌజ్ చేయండి; క్లాస్ బుక్ చేయండి; రిమైండర్ పొందండి.
- ముందు సరళమైన కేసు. ఇప్పుడు ఉచిత క్లాస్‌ను రద్దు చేయండి; రుసుములు మరియు రీఫండ్‌లను తర్వాతి స్టోరీలో నిర్వహించండి.
- డేటా వైవిధ్యం వారీగా. ముందు ఒక లొకేషన్‌కు మద్దతు ఇవ్వండి, తర్వాత అనేకం.
- హ్యాపీ పాత్, తర్వాత లోపాలు. పనిచేసేలా ముందు నిర్మించండి, తర్వాత నిండిన క్లాసులు, గడువు ముగిసిన పాస్‌లు మొదలైన వాటి హ్యాండ్లింగ్ జోడించండి.
ప్రతి భాగం ఇప్పటికీ ఒక యూజర్ ఉపయోగించి గమనించగలిగేదిగా ఉండాలి.
యూజర్ స్టోరీలను ప్రాంప్ట్‌లుగా ఉపయోగించడం
అంగీకార ప్రమాణాలతో కూడిన యూజర్ స్టోరీ మంచి AI యాప్ బిల్డర్ ప్రాంప్ట్‌కు చాలా దగ్గరగా ఉంటుంది. అది AIకి ఎవరు, ఏమి, ఎందుకు మరియు పూర్తయిందని నిర్వచనం ఇస్తుంది. ఒక్కో సందేశంలో ఒక స్టోరీ పంపండి:
నేను జిమ్ సభ్యుడిని, నా ఫోన్ నుండి క్లాస్ బుకింగ్‌ను రద్దు చేయాలనుకుంటున్నాను, తద్వారా వెయిట్‌లిస్ట్‌లో ఉన్న ఎవరో నా స్థానాన్ని తీసుకోగలరు. అంగీకార ప్రమాణాలు:
- My Bookings లోని ప్రతి బుకింగ్‌పై Cancel ఉంటుంది, నిర్ధారణ దశతో.
- క్లాస్‌కు 12 గంటల కంటే ఎక్కువ ముందు రద్దు చేస్తే, బుకింగ్ తొలగించబడుతుంది.
- 12 గంటల కంటే తక్కువ ముందు అయితే, నిర్ధారించే ముందు "A late-cancellation fee of $5 applies" అని చూపించండి, మరియు బుకింగ్‌పై రుసుమును నమోదు చేయండి.
- క్లాస్‌కు వెయిట్‌లిస్ట్ ఉంటే, మొదటి వ్యక్తికి స్థానం మరియు ఇమెయిల్ వస్తాయి.
- ఫోన్-వెడల్పు స్క్రీన్‌పై పని చేస్తుంది. పరిధి వెలుపల: రీఫండ్లు, స్టాఫ్ సభ్యుల తరపున రద్దు చేయడం. దీన్ని నిర్మించండి, తర్వాత ప్రివ్యూలో ప్రతి ప్రమాణాన్ని తనిఖీ చేసి ఏవి పాస్ అయ్యాయో నాకు చెప్పండి.
ముడి ఆలోచన నుండి స్టోరీలు రూపొందించమని AIని కూడా అడగవచ్చు, తర్వాత మీరే సవరించండి:
ఇదే నా యాప్ ఆలోచన: [రెండు లేదా మూడు వాక్యాలు]. మొదటి వెర్షన్ కోసం యూజర్ స్టోరీలు రాయండి, యూజర్ రకం వారీగా గ్రూప్ చేయండి, ప్రతిదానికి 3 నుండి 5 Given/When/Then అంగీకార ప్రమాణాలతో. లాంచ్‌కు ఏవి తప్పనిసరో, ఏవి తర్వాత చేయవచ్చో గుర్తించండి.
ఫలితాన్ని ఎల్లప్పుడూ చదవండి మరియు సవరించండి. AIకి మీ యూజర్లు తెలియదు; మీకు తెలుసు.
అంగీకార ప్రమాణాలు మీ టెస్ట్ ప్లాన్‌గా కూడా పని చేస్తాయి. స్టోరీ నిర్మించిన తర్వాత, ప్రతి ప్రమాణాన్ని మీరే ఒక్కొక్కటిగా తనిఖీ చేయండి. దీని ఆధారంగా లాంచ్ ముందు మీ యాప్‌ను ఎలా పరీక్షించాలి గైడ్ ఉంది.
ఇతర డాక్యుమెంట్లతో యూజర్ స్టోరీలు ఎక్కడ సరిపోతాయి
- ప్రోడక్ట్ రిక్వైర్‌మెంట్స్ డాక్యుమెంట్ మొత్తం ప్రోడక్ట్‌ను వివరిస్తుంది: సమస్య, యూజర్లు, పరిధి. యూజర్ స్టోరీలు దానిలోని వివరమైన భాగాలు. AI తో PRD ఎలా రాయాలి చూడండి.
- బగ్ రిపోర్ట్ ఇప్పటికే నిర్మించిన స్టోరీకి విరుద్ధంగా విరిగిన దాన్ని వివరిస్తుంది. మంచి బగ్ రిపోర్ట్ ఎలా రాయాలి చూడండి.
- MVP అనేది ప్రధాన విలువను అందించే అతి చిన్న స్టోరీల సమూహం. MVP అంటే ఏమిటి చూడండి.
సాధారణ తప్పులు
- "As a user…" చాలా అస్పష్టం. యూజర్ యొక్క అసలు రకాన్ని పేర్కొనండి.
- "so that" వదిలేయడం. కారణం లేకుండా, సహేతుకమైన ట్రేడ్-ఆఫ్‌లు చేయలేరు.
- అవసరానికి బదులుగా పరిష్కారాన్ని రాయడం. "I want a dropdown" ఎవరూ ఆలోచించకముందే ఒక డిజైన్‌ను ఖరారు చేస్తుంది.
- పరీక్షించలేని ప్రమాణాలు. "సులభం", "వేగంగా" మరియు "అంతర్ దృష్టికి అనుగుణంగా" కోరికలు, ప్రమాణాలు కాదు.
- నిజానికి ఎపిక్‌లైన స్టోరీలు. "నా ఖాతాను నిర్వహించు" అంటే పది స్టోరీలు.
- ప్రతి స్టోరీని ముందే పూర్తిగా రాయడం. తదుపరి కొన్నింటిని వివరంగా రాయండి; మిగిలినవి అక్కడికి వచ్చే వరకు ఒక-లైన్లుగా ఉంచండి.
Mythex లో స్టోరీలు
Mythex లో, Plan మోడ్ ఒక ఆలోచనను స్టోరీలుగా మార్చడానికి మంచి చోటు: ఏదైనా ఎడిట్ చేయకముందే ఏజెంట్ విధానాన్ని చర్చిస్తుంది. స్టోరీ సిద్ధమైనప్పుడు, Build కు మారి దానిని పేస్ట్ చేయండి, ఒక్కో సందేశంలో ఒక స్టోరీ. ప్రతిదాని తర్వాత, /test ప్రివ్యూలో క్లిక్ చేస్తూ ఫ్లోను తనిఖీ చేయగలదు, మరియు ఏదైనా తప్పుగా వెళ్తే Revert to this point తో ఏదైనా ప్రతిస్పందనను వెనక్కి తీసుకోవచ్చు. డాక్స్‌లో సమర్థవంతమైన ప్రాంప్ట్‌లు చూడండి, మరియు AI యాప్ బిల్డర్‌ల కోసం ప్రాంప్ట్‌లు ఎలా రాయాలి గైడ్ చూడండి.
యూజర్ స్టోరీ చెక్‌లిస్ట్
- ఒక నిర్దిష్ట రకమైన యూజర్‌ను పేర్కొంటుంది
- డిజైన్ కాకుండా అవసరాన్ని వివరిస్తుంది
- నిజమైన "so that" కారణాన్ని కలిగి ఉంటుంది
- మూడు నుండి ఆరు పరీక్షించదగిన అంగీకార ప్రమాణాలు ఉన్నాయి
- కనీసం ఒక ఎడ్జ్ కేసు లేదా లోపాన్ని కవర్ చేస్తుంది
- ఏది పరిధి వెలుపల ఉందో పేర్కొంటుంది
- ఒకేసారి నిర్మించి పరీక్షించగలిగేంత చిన్నది
- నిర్మించిన తర్వాత ప్రమాణాలను ఒక్కొక్కటిగా తనిఖీ చేస్తారు
ప్రశ్నలు
యూజర్ స్టోరీ ఫార్మాట్ ఏమిటి?
సాధారణ టెంప్లేట్: As a [యూజర్ రకం], I want [ఒక లక్ష్యం] so that [ఒక కారణం]. దాని తర్వాత అంగీకార ప్రమాణాలు వస్తాయి, అంటే స్టోరీ పూర్తయిందని లెక్కించాలంటే నిజం కావాల్సిన షరతుల చిన్న జాబితా.
అంగీకార ప్రమాణాలు అంటే ఏమిటి?
అంగీకార ప్రమాణాలు నిర్దిష్టమైన, పరీక్షించదగిన షరతులు, ఇవి ఒక యూజర్ స్టోరీ ఎప్పుడు పూర్తవుతుందో నిర్వచిస్తాయి. వీటిని తరచుగా Given / When / Then గా రాస్తారు: ఒక ప్రారంభ పరిస్థితి ఇచ్చినప్పుడు, యూజర్ ఏదైనా చేసినప్పుడు, ఒక నిర్దిష్ట ఫలితం జరుగుతుంది.
యూజర్ స్టోరీ ఎంత పెద్దదిగా ఉండాలి?
ఒకే సిట్టింగ్‌లో నిర్మించి పరీక్షించగలిగేంత చిన్నదిగా, అయినా అది స్వయంగా విలువైనదిగా ఉండాలి. స్టోరీలో ఐదు లేదా ఆరు కంటే ఎక్కువ అంగీకార ప్రమాణాలు ఉంటే, లేదా అనేక స్క్రీన్లను కవర్ చేస్తే, దానిని యూజర్ పాత్ర వారీగా, ప్రవాహంలో దశ వారీగా, లేదా ముందు సరళమైన కేసు మరియు తర్వాత ఎడ్జ్ కేసుల వారీగా విభజించండి.
AI తో నిర్మిస్తున్నప్పుడు యూజర్ స్టోరీలు ఉపయోగకరమా?
అవును. అంగీకార ప్రమాణాలతో కూడిన యూజర్ స్టోరీ ఆదర్శవంతమైన ప్రాంప్ట్‌కు దగ్గరగా ఉంటుంది: ఫీచర్ ఎవరి కోసమో, వారికి ఏమి కావాలో, మరియు అది పని చేస్తుందో ఎలా తనిఖీ చేయాలో అది చెబుతుంది. ఒక్కో సందేశంలో ఒక స్టోరీ పంపడం వల్ల AI మార్పులు చిన్నవిగా మరియు పరీక్షించడానికి సులభంగా ఉంటాయి.