User Stories எழுதுவது எப்படி (உதாரணங்களும் acceptance criteria-உடன்)
User story என்பது பயனரின் பார்வையில் ஒரு அம்சத்தின் சுருக்கமான விளக்கம்: "[பயனர் வகை] ஆக, நான் [இலக்கு] விரும்புகிறேன், அதனால் [காரணம்]." அதன் கீழ் acceptance criteria எழுதுங்கள், story முடிந்ததாகக் கருதப்பட வேண்டுமானால் உண்மையாக இருக்க வேண்டிய சில குறிப்பிட்ட நிபந்தனைகள் அவை. ஒவ்வொரு story-யையும் ஒரே முறையில் உருவாக்கி சோதிக்குமளவு சிறியதாக வையுங்கள், யார் வேண்டுமானாலும் சரிபார்க்கும் வகையில் criteria-ஐ எழுதுங்கள்.
User stories agile மென்பொருள் குழுக்களால் பிரபலமானவை, ஆனால் AI app builder மூலம் நீங்களே கட்டும்போதும் அவை அதே அளவு பயனுள்ளவை. நல்ல story என்பது நல்ல prompt.
வடிவம்
User story-க்கு மூன்று பகுதிகள் உள்ளன:
As a [யார்], I want [என்ன] so that [ஏன்].
- யார் என்பது ஒரு குறிப்பிட்ட வகைப் பயனர்: முதல் முறை வருபவர், பணம் செலுத்தும் உறுப்பினர், ஒரு கிளினிக் receptionist, ஒரு admin. "பயனர்" என்பது அல்ல.
- என்ன என்பது அவர்கள் செய்ய விரும்புவது, அவர்களின் சொற்களில். திரை எப்படி வேலை செய்கிறது என்பது அல்ல.
- ஏன் என்பது அவர்கள் அக்கறை கொள்ளும் விளைவு. மக்கள் பெரும்பாலும் தவிர்க்கும் பகுதி இதுதான், தவறான ஒன்றை உருவாக்குவதிலிருந்து உங்களைத் தடுப்பதும் இதுதான்.
உதாரணம்:
ஒரு ஜிம் உறுப்பினர், நான் என் மொபைலில் இருந்து ஒரு வகுப்பு முன்பதிவை ரத்து செய்ய விரும்புகிறேன், அதனால் காத்திருப்புப் பட்டியலில் உள்ள ஒருவர் என் இடத்தை எடுக்கலாம், நான் வராத கட்டணம் செலுத்த வேண்டியதில்லை.
"ஏன்" என்பது "என்ன" சொல்லாத இரண்டு விஷயங்களைச் சொல்கிறது: அது மொபைலில் வேலை செய்ய வேண்டும், காத்திருப்புப் பட்டியல் மற்றும் கட்டண விதிகள் இதில் சம்பந்தப்பட்டவை.
Acceptance criteria
Story என்ன வேண்டும் என்று சொல்கிறது. Acceptance criteria எப்போது முடிந்தது என்று சொல்கின்றன. ஒவ்வொன்றும் தேறுகிறதா என்பதில் இரண்டு பேர் ஒத்துக்கொள்ளுமளவு குறிப்பிட்டதாக இருக்க வேண்டும்.
அவற்றை எழுதுவதற்கு பொதுவான வழி Given / When / Then:
- Given ஒரு தொடக்க நிலை
- When பயனர் ஏதாவது செய்கிறார்
- Then இதுவே முடிவு
ஜிம் முன்பதிவு story-க்கு:
- Given எனக்கு 12 மணி நேரத்துக்கு மேல் தொலைவில் ஒரு முன்பதிவு உள்ளது, when நான் Cancel-ஐத் தட்டி உறுதிப்படுத்துகிறேன், then முன்பதிவு நீக்கப்பட்டு "Booking cancelled" என்று பார்க்கிறேன்.
- Given நான் ஒரு முன்பதிவை ரத்து செய்கிறேன், வகுப்புக்கு காத்திருப்புப் பட்டியல் உள்ளது, when ரத்து சேமிக்கப்படுகிறது, then காத்திருப்புப் பட்டியலில் முதலில் உள்ளவருக்கு இடமும் ஒரு email-உம் கிடைக்கும்.
- Given ஒரு முன்பதிவு 12 மணி நேரத்துக்குள் உள்ளது, when நான் Cancel-ஐத் தட்டுகிறேன், then உறுதிப்படுத்துவதற்கு முன் தாமத ரத்துக் கட்டணம் பொருந்தும் என்று பார்க்கிறேன்.
- Given நான் மொபைல் அகலத் திரையில் இருக்கிறேன், then Cancel பொத்தான் பக்கவாட்டில் ஸ்குரோல் செய்யாமல் தெரிகிறது.
ஒவ்வொரு உருப்படியும் சோதிக்கக்கூடியதாக இருந்தால் ஒரு எளிய சரிபார்ப்புப் பட்டியலும் வேலை செய்யும். "ரத்து செய்வது எளிது" என்பது சோதிக்கக்கூடியது அல்ல. "முன்பதிவுப் பட்டியலிலிருந்து ரத்து செய்ய அதிகபட்சம் இரண்டு தட்டுகள்" சோதிக்கக்கூடியது.
படிப்படியாக: ஒரு நல்ல story எழுதுவது
படி 1: உண்மையான பயனரும் உண்மையான பிரச்சினையும் என்பதில் தொடங்குங்கள்
ஒரு வகைப் பயனரையும் அவர்கள் இன்று சிரமப்படும் ஒன்றையும் தேர்ந்தெடுங்கள். வாடிக்கையாளர் நேர்காணல்கள் செய்திருந்தால், அவர்களின் சொற்களைப் பயன்படுத்துங்கள். "ரத்து செய்ய மறந்துவிட்டு கட்டணம் வசூலிக்கப்படுகிறேன்" என்பது "ரத்து அம்சத்தைச் சேர்" என்பதை விட சிறந்த தொடக்கம்.
படி 2: ஒரு வரி story எழுதுங்கள்
டெம்ப்ளேட்டை நிரப்புங்கள். நம்பத்தகுந்த "அதனால்" பகுதியை எழுத முடியவில்லை என்றால், அம்சம் தேவையா என்று கேளுங்கள்.
படி 3: மூன்று முதல் ஆறு acceptance criteria சேருங்கள்
முதலில் முக்கிய வெற்றி நிகழ்வை மூடுங்கள், பின்னர் முக்கியமான மாறுபாடுகள்: வேறு பாத்திரம், காலி நிலை, ஒரு வரம்பு, ஒரு பிழை. ஆறுக்கு மேல் எழுதினால், story பெரும்பாலும் மிகப் பெரியது.
படி 4: எல்லைக்கு வெளியே உள்ளதைக் குறியுங்கள்
ஒரு வரி நிறைய பின்னும் முன்னுமான பேச்சைத் தவிர்க்கும்: "எல்லைக்கு வெளியே: கட்டண வகுப்புகளுக்கான refunds; உறுப்பினர்கள் சார்பாக admins ரத்து செய்வது." நீங்கள் உருவாக்கும்போது story வளர்வதை அது நிறுத்தும்.
படி 5: INVEST-உடன் சரிபாருங்கள்
நல்ல stories-க்கான பொதுவான சரிபார்ப்புப் பட்டியல் INVEST. ஒரு story இருக்க வேண்டியது:
| எழுத்து | பொருள் | விரைவுச் சோதனை |
|---|---|---|
| I | Independent (சுயாதீனம்) | வேறொரு story-க்குக் காத்திருக்காமல் உருவாக்க முடியும் |
| N | Negotiable (பேசித் தீர்மானிக்கக்கூடியது) | நிலையான வடிவமைப்பு அல்ல, தேவையை விவரிக்கிறது |
| V | Valuable (மதிப்புள்ளது) | அனுப்பினால் ஒரு பயனர் கவனிப்பார் |
| E | Estimable (மதிப்பிடக்கூடியது) | அது எவ்வளவு பெரியது என்று தோராயமாக ஊகிக்க முடியும் |
| S | Small (சிறியது) | ஒரே அமர்வில் உருவாக்கி சோதிக்கலாம் |
| T | Testable (சோதிக்கக்கூடியது) | ஒவ்வொரு acceptance criterion-ஐயும் சரிபார்க்கலாம் |
ஒவ்வொரு story-க்கும் மதிப்பெண் போட வேண்டியதில்லை. ஒரு story தவறாகத் தோன்றி ஏன் என்று தெரிந்துகொள்ள விரும்பும்போதுதான் இது மிகவும் பயனுள்ளது.
நல்ல மற்றும் மோசமான உதாரணங்கள்
| பலவீனமான story | பிரச்சினை | சிறந்த story |
|---|---|---|
| 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. | Story அல்ல; எல்லோருக்கும் தேவைப்படும் ஒரு தரம் | ஒவ்வொரு story-யிலும் ஒரு criterion-ஆக எழுதுங்கள், அல்லது தனி செயல்திறன் இலக்காக. |
மிகப் பெரிய story-ஐ எப்படிப் பிரிப்பது
திட்டங்கள் தேங்குவது பெரிய stories-இல்தான். பொதுவான பிரிக்கும் வழிகள்:
- பயனர் பாத்திரத்தின்படி. உறுப்பினர்கள் தங்கள் முன்பதிவுகளை ரத்து செய்கிறார்கள்; ஊழியர்கள் யாருடையதையும் ரத்து செய்கிறார்கள்.
- பணிப்பாய்வின் படியின்படி. வகுப்புகளை உலாவுவது; ஒரு வகுப்பை முன்பதிவு செய்வது; நினைவூட்டல் பெறுவது.
- எளிய நிகழ்வு முதலில். இலவச வகுப்பை இப்போது ரத்து செய்வது; கட்டணங்களையும் refunds-ஐயும் பின்னர் ஒரு story-யில் கையாளுவது.
- தரவு மாறுபாட்டின்படி. முதலில் ஒரு இடத்தை ஆதரிப்பது, பின்னர் பலவற்றை.
- சரியான வழி முதலில், பிழைகள் பின்னர். முதலில் அது வேலை செய்யுமாறு உருவாக்குங்கள், பின்னர் நிரம்பிய வகுப்புகள், காலாவதியான pass போன்றவற்றுக்கான கையாளுதலைச் சேருங்கள்.
ஒவ்வொரு துண்டும் இன்னும் ஒரு பயனர் பயன்படுத்தி கவனிக்கக்கூடியதாக இருக்க வேண்டும்.
User stories-ஐ prompts ஆகப் பயன்படுத்துவது
Acceptance criteria உள்ள user story, AI app builder-க்கான நல்ல prompt-க்கு மிக அருகில் உள்ளது. அது AI-க்கு யார், என்ன, ஏன், முடிவின் வரையறை ஆகியவற்றைத் தருகிறது. ஒரு செய்திக்கு ஒரு story அனுப்புங்கள்:
ஒரு ஜிம் உறுப்பினராக, நான் என் மொபைலில் இருந்து ஒரு வகுப்பு முன்பதிவை ரத்து செய்ய விரும்புகிறேன், அதனால் காத்திருப்புப் பட்டியலில் உள்ள ஒருவர் என் இடத்தை எடுக்கலாம். Acceptance criteria:
- My Bookings-இல் உள்ள ஒவ்வொரு முன்பதிவிலும் Cancel இருக்கும், உறுதிப்படுத்தல் படியுடன்.
- வகுப்புக்கு 12 மணி நேரத்துக்கு முன் ரத்து செய்தால், முன்பதிவு மட்டும் நீக்கப்படும்.
- 12 மணி நேரத்துக்குள் என்றால், உறுதிப்படுத்துவதற்கு முன் "A late-cancellation fee of $5 applies" என்று காட்டி, முன்பதிவில் கட்டணத்தைப் பதிவு செய்யுங்கள்.
- வகுப்புக்கு காத்திருப்புப் பட்டியல் இருந்தால், முதலில் உள்ளவருக்கு இடமும் email-உம் கிடைக்கும்.
- மொபைல் அகலத் திரையில் வேலை செய்ய வேண்டும். எல்லைக்கு வெளியே: refunds, உறுப்பினர்கள் சார்பாக ஊழியர்கள் ரத்து செய்வது. இதை உருவாக்குங்கள், பின்னர் preview-வில் ஒவ்வொரு criterion-ஐயும் சரிபார்த்து எவை தேறுகின்றன என்று சொல்லுங்கள்.
ஒரு தோராய யோசனையிலிருந்து stories வரைவைக்கும்படியும் AI-யிடம் கேட்கலாம், பின்னர் நீங்களே திருத்தலாம்:
என் app யோசனை: [இரண்டு அல்லது மூன்று வாக்கியங்கள்]. முதல் பதிப்புக்கான user stories-ஐ பயனர் வகையின்படி தொகுத்து எழுதுங்கள், ஒவ்வொன்றுக்கும் 3 முதல் 5 Given/When/Then acceptance criteria. Launch-க்கு அவசியமானவற்றையும் பின்னர் காத்திருக்கக்கூடியவற்றையும் குறியுங்கள்.
எப்போதும் முடிவைப் படித்துத் திருத்துங்கள். உங்கள் பயனர்களை AI அறியாது; நீங்கள் அறிவீர்கள்.
Acceptance criteria உங்கள் சோதனைத் திட்டமாகவும் செயல்படும். Story உருவானதும், ஒவ்வொரு criterion-ஐயும் நீங்களே சரிபாருங்கள். வெளியீட்டுக்கு முன் உங்கள் app-ஐ சோதிப்பது எப்படி என்ற எங்கள் வழிகாட்டி இதன் மேல் கட்டப்பட்டது.
User stories மற்ற ஆவணங்களுடன் எங்கே பொருந்துகின்றன
- Product requirements document முழு productஐ விவரிக்கிறது: பிரச்சினை, பயனர்கள், scope. User stories அதற்குள் உள்ள விரிவான துண்டுகள். AI மூலம் PRD எழுதுவது எப்படி பார்க்கவும்.
- Bug report ஏற்கனவே உருவாக்கப்பட்ட ஒரு story-க்கு எதிராக உடைந்த ஒன்றை விவரிக்கிறது. நல்ல bug report எழுதுவது எப்படி பார்க்கவும்.
- MVP என்பது மையமான மதிப்பை வழங்கும் மிகச் சிறிய stories தொகுப்பு. MVP என்றால் என்ன பார்க்கவும்.
பொதுவான தவறுகள்
- "As a user…" மிகவும் தெளிவற்றது. உண்மையான பயனர் வகையைப் பெயரிடுங்கள்.
- "so that" ஐ விட்டுவிடுவது. காரணம் இல்லாமல், நியாயமான சமரசங்களைச் செய்ய முடியாது.
- தேவைக்குப் பதிலாக தீர்வை எழுதுவது. "எனக்கு ஒரு dropdown வேண்டும்" என்பது யாரும் சிந்திப்பதற்கு முன்பே வடிவமைப்பை உறுதி செய்கிறது.
- சோதிக்க முடியாத criteria. "எளிது", "வேகமானது", "உள்ளுணர்வு" ஆகியவை criteria அல்ல, விருப்பங்கள்.
- உண்மையில் epics ஆன stories. "என் கணக்கை நிர்வகிக்க" என்பது பத்து stories.
- எல்லா stories-ஐயும் முன்கூட்டியே எழுதுவது. அடுத்த சிலவற்றை விரிவாக எழுதுங்கள்; மற்றவற்றை அதற்கு வரும்வரை ஒரு வரியாக வையுங்கள்.
Mythex-இல் stories
Mythex-இல் ஒரு யோசனையை stories ஆக மாற்ற Plan பயன்முறை நல்ல இடம்: எதையும் திருத்துவதற்கு முன் agent அணுகுமுறையைப் பற்றி விவாதிக்கும். ஒரு story தயாரானதும், Build-க்கு மாறி அதை ஒட்டுங்கள், ஒரு செய்திக்கு ஒரு story. ஒவ்வொன்றுக்கும் பிறகு, /test preview-வில் கிளிக் செய்து flow-வைச் சரிபார்க்கும், தவறாகப் போனால் எந்தப் பதிலையும் Revert to this point மூலம் திரும்பப் பெறலாம். Docs-இல் பயனுள்ள prompts மற்றும் எங்கள் AI app builders-க்கு prompts எழுதுவது எப்படி வழிகாட்டியையும் பாருங்கள்.
User story சரிபார்ப்புப் பட்டியல்
- ஒரு குறிப்பிட்ட வகைப் பயனரைப் பெயரிடுகிறது
- ஒரு வடிவமைப்பை அல்ல, ஒரு தேவையை விவரிக்கிறது
- உண்மையான "so that" காரணத்தை உள்ளடக்குகிறது
- மூன்று முதல் ஆறு சோதிக்கக்கூடிய acceptance criteria உள்ளன
- குறைந்தது ஒரு எல்லை நிலை அல்லது பிழையை உள்ளடக்குகிறது
- எல்லைக்கு வெளியே உள்ளதைக் குறிப்பிடுகிறது
- ஒரே முறையில் உருவாக்கி சோதிக்குமளவு சிறியது
- உருவாக்கிய பின் criteria ஒவ்வொன்றாகச் சரிபார்க்கப்பட்டது
கேள்விகள்
User story-யின் வடிவம் என்ன?
பொதுவான டெம்ப்ளேட்: As a [பயனர் வகை], I want [ஒரு இலக்கு] so that [ஒரு காரணம்]. அதைத் தொடர்ந்து acceptance criteria வரும், அதாவது story முடிந்ததாகக் கருதப்பட வேண்டுமானால் உண்மையாக இருக்க வேண்டிய நிபந்தனைகளின் சிறு பட்டியல்.
Acceptance criteria என்றால் என்ன?
User story எப்போது முழுமையானது என்று வரையறுக்கும் குறிப்பிட்ட, சோதிக்கக்கூடிய நிபந்தனைகள் acceptance criteria. இவை பெரும்பாலும் Given / When / Then என்று எழுதப்படுகின்றன: ஒரு தொடக்க நிலை கொடுக்கப்பட்டால், பயனர் ஏதாவது செய்தால், ஒரு குறிப்பிட்ட முடிவு நடக்கும்.
User story எவ்வளவு பெரியதாக இருக்க வேண்டும்?
ஒரே அமர்வில் உருவாக்கி சோதிக்கக்கூடிய அளவு சிறியதாக, ஆனால் தனியாகவும் மதிப்புள்ளதாக. Story-யில் ஐந்து அல்லது ஆறுக்கு மேல் acceptance criteria இருந்தாலோ பல திரைகளை உள்ளடக்கினாலோ, பயனர் பாத்திரம், பணிப்பாய்வின் படி, அல்லது எளிய நிகழ்வு முதலிலும் எல்லை நிலைகள் பின்னர் என்று பிரியுங்கள்.
AI மூலம் உருவாக்கும்போது user stories பயனுள்ளதா?
ஆம். Acceptance criteria உள்ள user story ஒரு சிறந்த prompt-க்கு மிக அருகில் உள்ளது: அம்சம் யாருக்கானது, அவர்களுக்கு என்ன தேவை, அது வேலை செய்கிறதா என்று எப்படிச் சரிபார்ப்பது என்பதை அது சொல்கிறது. ஒரு செய்திக்கு ஒரு story அனுப்புவது AI மாற்றங்களையும் சிறியதாகவும் சோதிக்க எளிதாகவும் வைத்திருக்கிறது.