نوشتن User Story با هوش مصنوعی؛ پرامپت‌های آماده و قاعدهٔ INVEST

نوشتن User Story با هوش مصنوعی از موضوعات کلیدی در مدیریت پروژه و کار تیمی است. User Story خوب نوشتن سخت‌تر از آنچه به نظر می‌رسد: فرمولش ساده است («به‌عنوان [کاربر]، می‌خواهم [کار] تا [هدف]») ولی خروجی خوب نیاز به فهم کاربر، مرزبندی اسکوپ و معیار پذیرش دقیق دارد. AI این سه را سریع‌تر می‌کند — به‌خصوص وقتی باید ۵۰ Story برای یک Epic بنویسید یا Storyهای بد نوشته‌شده را اصلاح کنید.

این مقاله روش عملی نوشتن User Story با AI را می‌آموزد: پرامپت‌های آماده برای تولید، اصلاح و معیار پذیرش، قاعدهٔ INVEST برای ارزیابی کیفیت و اشتباه‌های رایج خروجی مدل.

AI برای User Story دقیقاً چه می‌کند؟ (پاسخ سریع)

سه کار: ۱) تقسیم — یک Epic بزرگ («سیستم تیکتینگ») را به ۸–۱۵ Story کوچک و مستقل تقسیم می‌کند؛ ۲) نگارش — هر Story را با فرمول استاندارد و لحن یکنواخت می‌نویسد؛ ۳) معیار پذیرش — برای هر Story، شرایط Given/When/Then مشخص می‌کند که تست‌پذیر باشد. خروجی را تیم محصول بازبینی می‌کند — Storyهای نهایی باید بر اساس نیاز واقعی کاربر باشند، نه فقط منطق متن.

پرامپت آماده: تولید Story از Epic

Epic: «[عنوان Epic]» — [توضیح ۲–۳ خطی]
پرسونای کاربر: [کی است، چه می‌خواهد، چه درد دارد]
کانتکست محصول: [نوع محصول، کاربران، محدودیت‌ها]

از این Epic، User Storyهای ریز بده که:
- هر Story کوچک و مستقل باشد (۱–۳ روز توسعه)
- فرمول: «به‌عنوان [نقش کاربر]، می‌خواهم [کار] تا [نتیجهٔ کسب‌وکاری]»
- برای هر Story: ۳–۵ معیار پذیرش به فرمت Given/When/Then
- Storyهای فنی (Infrastructure) و Storyهای کاربری را جدا علامت بزن

خروجی: جدول با ستون‌های Story, Acceptance Criteria, Type (User/Technical), Estimate پیشنهادی (S/M/L)

پرامپت آماده: اصلاح Story ضعیف

User Story زیر ضعیف نوشته شده — آن را اصلاح کن:

Story فعلی: «[متن فعلی]»

مشکل‌ها که باید حل شود:
- نقش کاربر مشخص نیست یا غلط است
- «چرا» (Benefit) کسب‌وکاری نیست
- Story بزرگ است و باید تقسیم شود
- معیار پذیرش تست‌پذیر نیست

قاعدهٔ INVEST را اعمال کن:
- Independent, Negotiable, Valuable, Estimable, Small, Testable

قاعدهٔ INVEST برای ارزیابی خروجی AI

هر Story باید این شش معیار را داشته باشد:

خطاهای رایج خروجی AI

• Storyهای بدون «چرا»: فرمول «به‌عنوان کاربر می‌خواهم دکمه سبز» بدون Benefit واقعی — AI گاهی «تا تجربهٔ کاربری بهتر شود» می‌نویسد که ارزش نیست. Benefit مشخص بخواهید («تا نرخ تبدیل افزایش یابد»).
• Storyهای بیش از حد فنی: «به‌عنوان سیستم می‌خواهم دیتابیس بهینه شود» — Story باید از زبان کاربر باشد؛ کارهای فنی را به Task تغییر دهید نه Story.
• Epic که Story می‌نامند: «به‌عنوان مدیر می‌خواهم سیستم گزارش‌گیری» — این Epic است و باید تقسیم شود. معیار: اگر نمی‌شود در یک اسپرینت تمام کرد، Story نیست.
• معیار پذیرش کلی: «باید درست کار کند» — معیار پذیرش باید مشخص و تست‌پذیر باشد: «Given کاربر مهمان، When دکمهٔ دانلود را می‌زند، Then فایل PDF بدون ورود دانلود می‌شود».

جمع‌بندی

نوشتن User Story با AI سه کاربرد دارد: تقسیم Epic به Storyهای ریز، اصلاح Storyهای ضعیف، و تولید معیار پذیرش Given/When/Then. پرامپت کلیدی باید پرسونا، کانتکست، Epic و قاعدهٔ INVEST را داشته باشد. AI در ۱۵ دقیقه خروجی می‌دهد که تیم در ۲ ساعت می‌نوشت — ولی بازبینی تیمی برای اولویت واقعی و مرزهای کاربر لازم است.

مطالب مرتبط

• User Story چیست؟ فرمول نوشتن داستان کاربر + مثال
• Feature یا User Story؟ تفاوت و نحوه شکستن نیازمندی‌ها
• کتابخانه پرامپت برای مدیران پروژه؛ ۵۰ پرامپت آماده

اگر موضوع نوشتن User Story با هوش مصنوعی برایتان مفید بود، پیشنهاد می‌کنیم نحوه استفاده از گانت چارت در ابزار مدیریت پروژه و Asana یا Trello؟ مقایسه برای تیم‌های کوچک و متوسط را هم بخوانید.