چطور یوزر استوری بنویسیم (با مثال و معیارهای پذیرش)
یوزر استوری توضیح کوتاهی از یک قابلیت از دید کاربر است: «به‌عنوان [نوع کاربر]، می‌خواهم [هدف] تا [دلیل].» زیر آن معیارهای پذیرش می‌نویسید؛ چند شرط مشخص که باید برقرار باشند تا استوری «انجام‌شده» حساب شود. هر استوری را آن‌قدر کوچک نگه دارید که بشود یک‌جا ساختش و تستش کرد، و معیارها را طوری بنویسید که هر کسی بتواند بررسی‌شان کند.
یوزر استوری‌ها را تیم‌های نرم‌افزاری چابک (agile) محبوب کردند، اما وقتی خودتان با یک ابزار ساخت اپلیکیشن با هوش مصنوعی کار می‌کنید هم به همان اندازه مفیدند. یک استوری خوب، یک پرامپت خوب است.
قالب
یک یوزر استوری سه بخش دارد:
به‌عنوان [چه کسی]، می‌خواهم [چه چیزی] تا [چرا].
- چه کسی نوع مشخصی از کاربر است: یک بازدیدکننده‌ی اولین‌بار، یک عضو پولی، یک منشی کلینیک، یک ادمین. نه «کاربر» به‌طور کلی.
- چه چیزی کاری است که کاربر می‌خواهد انجام دهد، با همان زبانی که خودش به کار می‌برد. نه اینکه صفحه از نظر فنی چطور کار می‌کند.
- چرا نتیجه‌ای است که کاربر به آن اهمیت می‌دهد. این بخشی است که معمولاً حذف می‌شود، و همین بخش جلوی ساختن چیز اشتباه را می‌گیرد.
مثال:
به‌عنوان عضو باشگاه ورزشی، می‌خواهم رزرو کلاسم را از گوشی لغو کنم تا نفر بعدی لیست انتظار جای من بیاید و جریمه‌ی عدم حضور به من تعلق نگیرد.
بخش «چرا» دو چیز را به شما می‌گوید که بخش «چه چیزی» نمی‌گفت: این قابلیت باید روی گوشی کار کند، و قوانین لیست انتظار و جریمه هم درگیرند.
معیارهای پذیرش
استوری می‌گوید چه چیزی خواسته شده. معیارهای پذیرش می‌گویند کی کار تمام است. آن‌ها باید آن‌قدر مشخص باشند که دو نفر بتوانند توافق کنند هر کدام قبول است یا نه.
یک روش رایج نوشتنشان Given / When / Then است:
- Given یک وضعیت شروع
- When کاربر کاری انجام می‌دهد
- Then این نتیجه است
برای استوری رزرو باشگاه:
- Given رزروی دارم که بیش از ۱۲ ساعت تا آن فاصله دارد، when روی لغو بزنم و تأیید کنم، then رزرو حذف می‌شود و «رزرو لغو شد» را می‌بینم.
- Given رزروی را لغو می‌کنم و کلاس لیست انتظار دارد، when لغو ذخیره شود، then نفر اول لیست انتظار جای خالی را می‌گیرد و یک ایمیل دریافت می‌کند.
- Given رزروی که کمتر از ۱۲ ساعت تا آن مانده، when روی لغو بزنم، then پیش از تأیید می‌بینم که جریمه‌ی لغو دیرهنگام اعمال می‌شود.
- Given روی صفحه‌ای با عرض گوشی هستم، then دکمه‌ی لغو بدون اسکرول افقی دیده می‌شود.
فهرست ساده‌ی چک‌باکسی هم جواب می‌دهد، به شرطی که هر مورد قابل آزمایش باشد. «لغو کردن آسان است» قابل آزمایش نیست. «لغو از فهرست رزروها حداکثر با دو تپ انجام می‌شود» قابل آزمایش است.
قدم‌به‌قدم: نوشتن یک استوری خوب
قدم ۱: از یک کاربر واقعی و یک مشکل واقعی شروع کنید
یک نوع کاربر و چیزی را انتخاب کنید که امروز با آن دست‌وپنجه نرم می‌کند. اگر با مشتریان مصاحبه کرده‌اید، از کلمات خودشان استفاده کنید. «همیشه یادم می‌رود لغو کنم و هزینه کسر می‌شود» نقطه‌ی شروع بهتری است تا «افزودن قابلیت لغو».
قدم ۲: استوری یک‌خطی را بنویسید
قالب را پر کنید. اگر نمی‌توانید «تا»ی قانع‌کننده‌ای بنویسید، از خودتان بپرسید آیا اصلاً این قابلیت لازم است.
قدم ۳: سه تا شش معیار پذیرش اضافه کنید
اول حالت موفقیت اصلی را پوشش دهید، بعد تغییرات مهم: یک نقش متفاوت، یک حالت خالی، یک محدودیت، یک خطا. اگر بیش از شش مورد می‌نویسید، احتمالاً استوری بیش از حد بزرگ است.
قدم ۴: خارج از محدوده را یادداشت کنید
یک خط وقت زیادی از رفت‌وآمدهای بعدی را می‌گیرد: «خارج از محدوده: استرداد وجه برای کلاس‌های پولی؛ لغو رزرو توسط ادمین به‌جای عضو.» این جلوی بزرگ شدن استوری در حین ساخت را می‌گیرد.
قدم ۵: با INVEST بسنجیدش
INVEST یک چک‌لیست رایج برای استوری خوب است. یک استوری باید این ویژگی‌ها را داشته باشد:
| حرف | یعنی | آزمون سریع |
|---|---|---|
| I | مستقل (Independent) | بدون منتظر ماندن برای استوری دیگر ساخته شود |
| N | قابل مذاکره (Negotiable) | نیاز را توصیف کند، نه یک طراحی ثابت |
| V | ارزشمند (Valuable) | اگر منتشر شود کاربر متوجهش شود |
| E | قابل تخمین (Estimable) | بتوانید تقریباً حدس بزنید چقدر بزرگ است |
| S | کوچک (Small) | در یک نشست ساخته و تست شود |
| T | قابل آزمایش (Testable) | هر معیار پذیرش را بشود بررسی کرد |
لازم نیست هر استوری را امتیاز دهید. وقتی استوری‌ای درست به نظر نمی‌رسد و می‌خواهید بدانید چرا، بیشترین کاربرد را دارد.
نمونه‌های خوب و بد
| استوری ضعیف | مشکل | استوری بهتر |
|---|---|---|
| به‌عنوان یک کاربر، می‌خواهم یک داشبورد داشته باشم. | کاربر مشخص نیست، دلیل ندارد، قابل آزمایش نیست | به‌عنوان صاحب فروشگاه، می‌خواهم سفارش‌ها و درآمد امروز را در یک صفحه ببینم تا با یک نگاه بفهمم روز خوبی است یا نه. |
| به‌عنوان ادمین، می‌خواهم دیتابیس یک ستون وضعیت داشته باشد. | پیاده‌سازی را توصیف می‌کند، نه نیاز را | به‌عنوان ادمین، می‌خواهم سفارش‌ها را «ارسال‌شده» علامت بزنم تا مشتری‌ها دیگر برای پرسیدن وضعیت سفارش ایمیل نزنند. |
| به‌عنوان مشتری، می‌خواهم حساب کاربری‌ام را مدیریت کنم. | خیلی بزرگ است: چند قابلیت را پوشش می‌دهد | به‌عنوان مشتری، می‌خواهم نشانی ایمیلم را عوض کنم تا رسیدها به صندوق جدیدم برسند. |
| به‌عنوان بازدیدکننده، می‌خواهم سایت سریع باشد. | استوری نیست؛ کیفیتی است که همه لازم دارند | آن را به‌عنوان یک معیار روی هر استوری، یا به‌عنوان یک هدف عملکردی جداگانه بنویسید. |
چطور استوری بزرگ را تقسیم کنیم
پروژه‌ها معمولاً روی استوری‌های بزرگ گیر می‌کنند. روش‌های رایج تقسیم:
- بر اساس نقش کاربر. اعضا رزرو خودشان را لغو می‌کنند؛ کارکنان رزرو هر کسی را.
- بر اساس مرحله‌ای از جریان. مرور کلاس‌ها؛ رزرو یک کلاس؛ دریافت یادآوری.
- حالت ساده اول. لغو یک کلاس رایگان همین حالا؛ جریمه و استرداد را در استوری بعدی بگنجانید.
- بر اساس تنوع داده. اول از یک مکان پشتیبانی کنید، بعداً چند مکان.
- مسیر موفق، بعد خطاها. اول آن را کار کنان بسازید، بعد مدیریت حالت‌هایی مثل کلاس پرظرفیت یا پاس منقضی را اضافه کنید.
هر قسمت باید هنوز چیزی باشد که کاربر بتواند استفاده کند و متوجهش شود.
استفاده از یوزر استوری به‌عنوان پرامپت
یک یوزر استوری با معیارهای پذیرش خیلی نزدیک به یک پرامپت خوب برای ابزار ساخت اپلیکیشن است. به هوش مصنوعی می‌گوید برای چه کسی است، چه می‌خواهد، چرا، و تعریف «کامل» چیست. در هر پیام یک استوری بفرستید:
به‌عنوان عضو باشگاه، می‌خواهم رزرو کلاسم را از گوشی لغو کنم تا نفر لیست انتظار بتواند جای من بیاید. معیارهای پذیرش: ۱. لغو کنار هر رزرو در «رزروهای من» باشد، همراه با مرحله‌ی تأیید. ۲. لغو بیش از ۱۲ ساعت قبل از کلاس فقط رزرو را حذف کند. ۳. کمتر از ۱۲ ساعت قبل، پیش از تأیید پیام «جریمه‌ی لغو دیرهنگام ۵ دلار اعمال می‌شود» نشان داده شود و جریمه روی رزرو ثبت شود. ۴. اگر کلاس لیست انتظار دارد، نفر اول جای خالی و یک ایمیل را دریافت کند. ۵. روی صفحه‌ای با عرض گوشی کار کند. خارج از محدوده: استرداد، لغو توسط کارکنان برای اعضا. این را بساز، سپس هر معیار را در پیش‌نمایش بررسی کن و بگو کدام‌ها قبول شدند.
می‌توانید از هوش مصنوعی بخواهید از یک ایده‌ی خام، استوری‌ها را پیش‌نویس کند، و بعد خودتان ویرایششان کنید:
ایده‌ی اپلیکیشنم این است: [دو یا سه جمله]. برای نسخه‌ی اول، یوزر استوری‌ها را بر اساس نوع کاربر دسته‌بندی کن و هر کدام ۳ تا ۵ معیار پذیرش به شکل Given/When/Then داشته باشد. مشخص کن کدام‌ها برای راه‌اندازی ضروری‌اند و کدام‌ها می‌توانند صبر کنند.
همیشه نتیجه را بخوانید و ویرایش کنید. هوش مصنوعی کاربران شما را نمی‌شناسد؛ شما می‌شناسید.
معیارهای پذیرش همزمان نقش برنامه‌ی تست شما را هم دارند. وقتی استوری ساخته شد، معیارها را یکی‌یکی خودتان امتحان کنید. راهنمای ما درباره‌ی تست اپلیکیشن قبل از انتشار روی همین اصل ساخته شده است.
جای یوزر استوری در میان سایر اسناد
- یک سند نیازمندی‌های محصول (PRD) کل محصول را توصیف می‌کند: مسئله، کاربران، محدوده. یوزر استوری‌ها قطعات جزئی داخل آن هستند. راهنما: چطور PRD را با هوش مصنوعی بنویسیم.
- یک گزارش باگ چیزی را توصیف می‌کند که در برابر استوری‌ای که قبلاً ساخته شده خراب است. راهنما: چطور یک گزارش باگ خوب بنویسیم.
- یک MVP کوچک‌ترین مجموعه استوری‌ای است که ارزش اصلی را تحویل می‌دهد. راهنما: MVP چیست.
اشتباهات رایج
- «به‌عنوان کاربر…» خیلی مبهم است. نوع واقعی کاربر را نام ببرید.
- حذف «تا». بدون دلیل، نمی‌توانید مصالحه‌های منطقی انجام دهید.
- نوشتن راه‌حل به‌جای نیاز. «می‌خواهم یک منوی کشویی» طراحی را قبل از فکر کردن قفل می‌کند.
- معیارهایی که قابل آزمایش نیستند. «آسان»، «سریع» و «شهودی» آرزو هستند، نه معیار.
- استوری‌هایی که در واقع اپیک‌اند. «مدیریت حساب کاربری‌ام» ده استوری است.
- نوشتن همه‌ی استوری‌ها از پیش. چند تای بعدی را با جزئیات بنویسید و بقیه را تک‌خطی نگه دارید تا به آن‌ها برسید.
استوری در Mythex
در Mythex، حالت Plan جای خوبی برای تبدیل یک ایده به استوری است: عامل قبل از ویرایش هر چیزی درباره‌ی رویکرد بحث می‌کند. وقتی استوری آماده شد، به Build بروید و آن را جایگذاری کنید، یک استوری در هر پیام. بعد از هر کدام، /test می‌تواند پیش‌نمایش را کلیک کند و جریان را بررسی کند، و اگر پاسخی اشتباه پیش رفت، با Revert to this point می‌توانید به آن نقطه برگردید. برای پرامپت‌های مؤثر مستندات را ببینید، و راهنمای ما درباره‌ی نوشتن پرامپت برای ابزارهای ساخت اپلیکیشن با هوش مصنوعی.
چک‌لیست یوزر استوری
- یک نوع مشخص از کاربر را نام می‌برد
- یک نیاز را توصیف می‌کند، نه یک طراحی را
- یک دلیل واقعی با «تا» دارد
- سه تا شش معیار پذیرش قابل آزمایش دارد
- حداقل یک لبه (edge case) یا خطا را پوشش می‌دهد
- می‌گوید چه چیزی خارج از محدوده است
- آن‌قدر کوچک است که در یک نشست ساخته و تست شود
- معیارها بعد از ساخت، یکی‌یکی بررسی شده‌اند
پرسش‌ها
قالب یوزر استوری چیست؟
قالب رایج این است: به‌عنوان [نوع کاربر]، می‌خواهم [هدفی] تا [دلیلی]. بعد از آن معیارهای پذیرش می‌آیند، فهرست کوتاهی از شرایطی که باید برقرار باشند تا استوری «انجام‌شده» حساب شود.
معیارهای پذیرش چه هستند؟
معیارهای پذیرش شرایط مشخص و قابل آزمایشی هستند که تعیین می‌کنند یک یوزر استوری کی کامل شده است. اغلب به شکل Given / When / Then نوشته می‌شوند: با فرض یک وضعیت شروع، وقتی کاربر کاری انجام می‌دهد، آنگاه یک نتیجه مشخص رخ می‌دهد.
یک یوزر استوری باید چقدر بزرگ باشد؟
آن‌قدر کوچک که بشود در یک نشست ساخته و تست شود، و در عین حال به‌تنهایی ارزشمند باشد. اگر استوری بیش از پنج یا شش معیار پذیرش دارد یا چند صفحه را پوشش می‌دهد، آن را بر اساس نقش کاربر، بر اساس مرحله‌ای از جریان، یا بر اساس حالت ساده اول و لبه‌ها (edge cases) بعداً تقسیم کنید.
آیا یوزر استوری وقتی با هوش مصنوعی می‌سازید مفید است؟
بله. یوزر استوری همراه با معیارهای پذیرش تقریباً یک پرامپت ایده‌آل است: می‌گوید قابلیت برای چه کسی است، چه نیازی دارد و دقیقاً چطور باید بررسی شود که درست کار می‌کند. فرستادن یک استوری در هر پیام هم تغییرات هوش مصنوعی را کوچک و آزمایش‌پذیر نگه می‌دارد.