یوزر استوری با هوش مصنوعی؛ معیار پذیرش و مثال

یوزر استوری با هوش مصنوعی زمانی قابل استفاده است که نقش کاربر، نیاز و ارزش آن روشن باشد و معیار پذیرش رفتار قابل مشاهده را توضیح دهد. از مدل بخواهید داستان بزرگ را به بخش‌های کوچک تقسیم کند و ابهام‌ها را جدا نگه دارد. در این آموزش قابلیت بازیابی سبد خرید را به داستان کاربر، معیار پذیرش و موارد مرزی تبدیل می‌کنیم.

یوزر استوری چیست؟#

داستان کاربر توضیح کوتاهی از نیاز یک نقش در یک موقعیت است. قالب «به‌عنوان ... می‌خواهم ... تا ...» به روشن شدن نقش، خواسته و ارزش کمک می‌کند، اما صرف پر کردن سه جای خالی کیفیت نمی‌سازد. «به‌عنوان کاربر می‌خواهم سیستم خوب کار کند تا راضی باشم» هنوز قابل برنامه‌ریزی یا آزمون نیست.

در راهنمای داستان کاربر Atlassian، داستان‌ها به نیاز و ارزش کاربر وصل می‌شوند. مثال این مقاله مستقل و آموزشی است. محصول واقعی باید با شناخت کاربران و گفت‌وگوی تیم، داستان‌های مناسب خودش را بنویسد.

مثال ضعیف را به داستان روشن تبدیل کنیم#

مثال مبهم: «به‌عنوان خریدار می‌خواهم سبد ذخیره شود تا تجربه بهتر شود.» معلوم نیست کدام خریدار، چه زمانی و در چه دستگاهی منظور است. نسخه روشن‌تر: «به‌عنوان خریدار واردشده می‌خواهم در مراجعه بعدی اقلام سبد حسابم را ببینم تا انتخاب‌ها را دوباره از ابتدا انجام ندهم.»

این نسخه هنوز به معیار پذیرش نیاز دارد. قیمت و موجودی هنگام مراجعه بعدی ممکن است عوض شده باشند. آیا سبد قدیمی نشان داده می‌شود یا وضعیت تازه؟ رفتار برای حساب دوم چیست؟ AI باید این سؤال‌ها را مطرح کند، نه اینکه از روی یک جمله، سیاست محصول را قطعی اعلام کند.

بریف ورودی برای تولید داستان#

بهتر است داستان را به نیازمندی شناسه‌دار سند محصول وصل کنید. اگر منبع داستان فقط پیشنهاد مدل است، آن را ایده معرفی کنید. داستان مصوب باید معلوم کند چه نیازی قرار است ساخته شود و چه کسی درباره ابهام‌ها تصمیم گرفته است.

معیار پذیرش با Given، When و Then#

این قالب وضعیت اولیه، اقدام و نتیجه را جدا می‌کند. لازم نیست همه تیم‌ها حتماً همین نگارش را استفاده کنند، اما تفکیک سه بخش کمک می‌کند معیار از جمله مبهم فاصله بگیرد. داده لازم را به اندازه‌ای بنویسید که رفتار قابل آزمون باشد.

این معیارها فرض آموزشی‌اند. درباره هم‌زمانی دو دستگاه، پایان زمان نگهداری و برخورد با تعداد بیش از موجودی، تصمیم‌های بیشتری لازم است. آن‌ها را به فهرست سؤال باز اضافه کنید و پیش از اجرای بخش وابسته پاسخ دهید.

پرامپت آماده نوشتن یوزر استوری#

نیازمندی، نقش‌ها و تصمیم‌های مصوب را در ادامه می‌دهم. داستان کاربر کوتاه با نقش، نیاز و ارزش بنویس. برای هر داستان، معیار پذیرش قابل مشاهده در قالب وضعیت، اقدام و نتیجه بده. فرض جدید را وارد معیار نکن. ابهام‌ها را جدا فهرست کن. داستان‌های بزرگ را به برش‌هایی تقسیم کن که هرکدام ارزش قابل نمایش داشته باشند. کار فنی را از داستان کاربر جدا نشان بده و ارتباط هر داستان با شناسه نیازمندی را حفظ کن.

برای نقد پاسخ بپرسید: «کدام معیار می‌تواند با دو رفتار متناقض پذیرفته شود؟ آن را با یک مثال دقیق روشن کن.» مثلاً «قیمت صحیح نمایش داده شود» بدون تعیین قیمت جاری یا ذخیره‌شده، دو پیاده‌سازی متفاوت را قابل قبول نشان می‌دهد.

داستان بزرگ را چگونه تقسیم کنیم؟#

تقسیم صرفاً بر اساس لایه فنی، مانند «ساخت جدول»، «نوشتن سرویس» و «ساخت دکمه»، ارزش قابل نمایش برای کاربر را جدا نمی‌کند. این کارها می‌توانند زیرکار باشند، اما داستان باید یک نتیجه قابل مشاهده بسازد. در نمونه ما بازیابی برای یک حساب در یک محیط کنترل‌شده، برش اولیه احتمالی است.

بعد می‌توان رفتار کالای ناموجود و تغییر قیمت را تکمیل کرد؛ ترتیب باید با ریسک و نیاز محصول هماهنگ باشد. جداسازی حساب‌ها را نباید صرفاً برای کوچک شدن داستان به آینده نامعلوم موکول کرد. از تیم بخواهید کوچک‌ترین محدوده‌ای را انتخاب کند که رفتار لازم و قیود مهم را حفظ می‌کند.

معیار پذیرش با تست کیس و تعریف پایان فرق دارد#

معیار پذیرش می‌گوید چه رفتاری برای این داستان لازم است. تست کیس مراحل و داده اجرای یک بررسی را مشخص می‌کند. تعریف پایان تیم می‌تواند شامل بازبینی کد، مستندات یا کنترل‌های مشترک همه کارها باشد. مخلوط کردن این سه، داستان را طولانی و مسئولیت را نامعلوم می‌کند.

از AI بخواهید معیار AC02 را به دو تست تبدیل کند: یک قلم ناموجود در میان چند قلم و سبدی که تمام اقلامش ناموجودند. نتیجه طراحی باید به همان رفتار مصوب وفادار بماند. اگر مدل پیشنهاد رفتار تازه داد، آن را به سؤال محصول تبدیل کنید، نه تست قطعی.

چک‌لیست بازبینی داستان‌ها#

نقش مشخص است؟ نیاز از نگاه کاربر نوشته شده؟ ارزش بدون وعده اغراق‌آمیز توضیح دارد؟ معیارهای مرزی و خطا آمده‌اند؟ موارد خارج از محدوده روشن‌اند؟ داده نمونه به محصول واقعی نسبت داده نشده؟ برای هر پاسخ منفی، داستان هنوز به گفت‌وگو نیاز دارد.

برای پیوند با تصمیم‌های بالادستی، نمونه PRD با هوش مصنوعی را بخوانید. برای تبدیل انتظار به مراحل اجرا، نوشتن تست کیس و برای زمان‌بندی، برنامه‌ریزی پروژه مکمل‌اند. در GPT Plus می‌توانید یک نیازمندی ساختگی را تمرین کنید و سپس معیارها را با تیم محصول بازبینی کنید.