چطور یک یوزر استوری موثر بنویسیم

یوزر استوری یا داستان کاربر چیست؟

هر یوزر استوری درواقع توضیحی کوتاه از یک ویژگی محصول (product feature) است. یوزر استوری معمولا در قالب مشخصی به شکل زیر بیان می‌شود:

من به عنوان <نقش کاربر>، <ویژگی یا هدف> را می‌خواهم به دلیل <حداقل یه دلیل>

شکل کلی فرمول بالا قابل تغییر است. اما سه بخش نقش کاربر، چیزی که به آن نیاز دارد و چرایی این نیاز همواره ثابت هستند.

چند نمونه یوزر استوری

بهرتین راه برای درک اینکه یوزر استوری چیست دیدن چند مثال است.

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

داستان کاربر (user story) یک نیازمندی ساده شده است

هر داستان کاربر یا یوزر استوری در واقع یک نیازمندی است که بصورت خلاصه بیان می‌شود. یوزر استوری همه اجزای نیازمندی را در خود ندارد. به دلیل خلاصه بودن نمی‌تواند به تمام سوالات پاسخ دهد. (its not a bog. its a feature). به عنوان مثال یکی از داستان‌های کاربر بالا در نظر بگیریم

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

اگر در یک جلسه برنامه‌ریزی اسپرینت این یوزر استوری را به تیم فنی نشان دهید حتما برای تیم سوالاتی بوجود خواهد آمد. مثلا ممکن است بپرسند:

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

همانطور که دیدیم تیم در مواجهه با یوزر استوری سوالاتی دارد که صرفا از خود یوزر استوری نمی‌توان به آنها جواب داد. ای خبر خوبی است. چرا؟

1. این موضوع باعث می‌شود تیم با هم حرف بزنند.
2. یوزر استوری از دیدگاه یوزر نوشته می‌شود. درنتیجه جزدیات فنی را ندارد. باید هدف کاربر از یوزر استوری را درک کنیم. گاهی ممکن است تیم ویژگی بهتری در راستای همان هدف کاربر پیشنهاد دهد.
   در هر حال نوشتن یوزر استوری به زبان غیر فنی کمک می‌کند تا همه (نه فقط افراد فنی) درک کنند که تیم دارد روی چه چیزی کار می‌کند.
3. خلاصه بودن داستان کاربر به راحت بودن انجام کارها به عنوان یک تیم، کمک می‌کند. کافی است یوزر استوری را روی یک کارت بنویسید. هر زمان که بخواهید می‌توانید به سوالات پاسخ دهید.
4. سناریوی بالا یک سناریوی طبیعی است. مدیر محصول داستان کاربر را تعریف می‌کند. کل تیم روی آن بحث می‌کنند. همین سوالات می‌تواند به عنوان «آزمون پذیرش» یا «acceptance tests» بعدا مورد استفاده قرار گیرند.

مدل اینوست (INVEST) یا ویژگی‌های یک یوزر استوری خوب

این مدل توسط بیل ویک (Bill Wake) معرفی شده است. بیل ویک نویسنده و مشاور مشهور اجایل است. مطابق مدل اینوست هر یوزر استوری خوب دارای شش خصوصیت است:

مستقل (Independent)

داستان‌های کاربر باید مستقل باشند. به این معنی که دو یا چند یوزر استوری نباید از نظر عملکرد با همدیگر همپوشانی داشته باشند. این موضوع کمک می‌کند تا تیم هرکدام از یوزر استوری‌ها را که بخواهد انتخاب و روی آن کار کند. چرا که آنها به هم وابسته نیستند.

قابل مذاکره (Negotiable)

زیبایی یوزر استوری به این است که ماهیت نیاز را نشان دهد نه جزئیات آن را.

یک داستان خوب ماهیت را نشان می‌دهد نه جزئیات

بیل ویک

در مورد جزئیات می‌توان بعدا مذاکره کرد. تیم فنی یا حتی ذی‌نفعان می‌توانند بعدا در زمان توسعه راجع به جزئیات نظر بدهند.

ارزشمند (Valuable)

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

قابل تخمین (Estimable)

یوزر استوری باید به قدری اطلاعات در اختیار تیم فنی بگذارد که بتوانند یک تخمین حدودی از اندازه کار فنی مورد نیاز داشته باشند.

ما به تخمین دقیق نیاز نداریم. صرفا کافی است بدانیم یوزر استوری‌ها در مقایسه با هم چه وزنی دارند. مثلا بدانیم یوزر استوری شماره یک حدودا دو برابر یوزر استوری شماره ۲ به تلاش نیاز دارد.

محسن علوی!

کوچک (Small)

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

قابل آزمایش (Testable)

اگر تیم نمی‌داند که باید چه چیزی را آزمایش کند، به احتمال زیاد اصلا نمی‌داند که چه چیزی را باید بسازد. دانستن اینکه چه چیزی را باید آزمایش کنید معادل این است که بدانید چه چیزی را باید بسازید.

اپیک (Epic) چیست و با یوزر استوری چه تفاوتی دارد. (Epic VS User story)

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

شاید بعدا در یک وست جداگانه راجع به اپیک بیشتر صحبت کنم. اما الان به صورت خلاصه:

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

بهبود داستان‌های کاربر

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

1. آیا بلافاصله پس از خواندن داستان کاربر، مشخص است که یوزراستوری چیست؟
2. آیا هر یک از بخش‌های یوزراستوری ارزش مشخصی اضافه می‌کنند؟
3. آیا داستان کاربر عاری از راه‌حل است؟ (داستان باید ماهیت نیاز را نشان دهد. راه حل کار تیم است نه داستان!)

و سه سوال بعدی را در جلسه ریترو (retrospective meeting) باید بپرسید. بعد از پایان کار، می‌توانید یکی از افراد را به عنوان نماینده انتخاب کنید و از او بخواهید:

4. به داستان کاربر نمره دهید. (معمولا از یک تا ۱۰)
5. توضیح دهید که چه چیزی را در مورد این داستان کاربر دوست داشتید.
6. توضیح دهید که چطور می‌توانستیم داستان کاربر بهتری داشته باشیم.

خلاصه

• نیازهای کاربر را از طریق یوزراستوری‌ها بیان کنید.
• یوزر استوری (داستان کاربر) یک توضیح کوتاه از ویژگی‌های محصول است که در یک قالب استاندارد به شکل زیر نوشته می‌شود:
  من به عنوان <نقش کاربر>، <ویژگی یا هدف> را می‌خواهم به دلیل <حداقل یه دلیل>
• یک داستان کاربر خوب باید مستقل، قابل مذاکره، ارزشمند، قابل تخمین، کوچک و قابل آزمایش باشد.
• اپیک‌ها داستان‌های کاربر بزرگ‌تر هستند. قبل از کار روی آنها، به داستان‌های کاربر کوچک‌تر تقسیمشان کنید.

منابع اضافی

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

• گاهی اوقات استوری‌های کاربران می‌توانند بی‌اثر باشند و دید دقیقی ارائه نمی‌دهند. این مانع از چابکی می‌شود. این مقاله نحوه بهبود داستان‌های کاربر را نشان می‌دهد:  رفع داستان‌های بد کاربران .