logo image
00 یوزر استوری

User Story چیست؟ نمونه و نحوه ساخت یوزر استوری

6 روز پیش
زمان مطالعه:
9 دقیقه

«همیشه حق با مشتری است.»

این شعار، اگرچه در دنیای کسب‌وکار بسیار رایج و البته مورد بحث بسیار است، اما برای پروژه‌های «اجایل / Agile» نیز به‌وفور استفاده می‌شود. یا بهتر بگوییم: اصلاً رضایت مشتری به‌عنوان بالاترین اولویت در تفکر اجایل ذکر شده است.

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

هنگامی که پروژه‌ها با تفکر اجایل شروع به کار می‌کنند و قصد دارند بخشی از کار را شروع و پیش ببرند، تیم‌ها کار خود را با بررسی دیدگاه مشتری آغاز می‌کنند و این کار را معمولاً از طریق ایجاد یک یوزر استوری / User Story یا داستان‌ کاربر انجام می‌دهند.

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

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

داستان کاربر «کوچک‌ترین واحد کار» در چارچوب اجایل است.

این داستان باید بیانگر یک هدف نهایی باشد، نه توصیف یک ویژگی؛ و باید صرفاً از دیدگاه یک کاربرِ نرم‌افزار به قضیه نگاه و بیان شود.

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

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

User Story شامل چند جمله به زبان ساده است که نتیجه موردنظر را بدون ورود به جزئیات شرح می‌دهد. جزئیات و نیازمندی‌ها بعداً و پس از توافق تیم به آن اضافه می‌شوند.

این داستان‌ها به‌خوبی در چارچوب‌های اجایل مانند اسکرام و کانبان جا می‌گیرند. در اسکرام، داستان‌های کاربری به اسپرینت‌ها اضافه می‌شوند و در طول یک اسپرینت «کاهش» می‌یابند. 

در کانبان، تیم‌ها داستان‌های کاربری را به بک لاگ خود اضافه کرده و آن‌ها را از طریق یک «گردش کار / Workflow» اجرا می‌کنند. استفاده از داستان کاربر به تیم‌های اسکرام کمک می‌کند در برآوردها و برنامه‌ریزی اسپرینت‌ها مهارت بیشتری پیدا کنند و چابکی خود را افزایش دهند. 

به لطف یوزر استوری، تیم‌های کانبان یاد می‌گیرند که چگونه «کارهای در حال انجام / WIP» را مدیریت کرده و گردش کار خود را بهینه‌تر کنند.

User Story ها همچنین بلوک‌های سازنده چارچوب‌های بزرگ‌تر اجایل مانند «اپیک‌»ها و «ابتکار / Initiative»ها هستند. اپیک‌ها اقلام کاری بزرگی از اسپرینت‌ها هستند که به مجموعه‌ای از داستان‌ها تقسیم می‌شوند و چندین اپیک یک ابتکار را تشکیل می‌دهند. 

این ساختارهای بزرگ‌تر کمک می‌کنند که کارهای روزمره تیم توسعه (بر روی داستان‌ها و اسپرینت‌ها) به اهداف سازمانی بزرگ‌تر و کلان‌تر منجر شوند.

یوزر استوری

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

سؤال اینجاست که آیا صرفاً مالک محصول داستان کاربر را می‌نویسد؟ جواب ساده این است که هر کسی می‌تواند یوزر استوری را بنویسد.

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

توجه داشته باشید که:

اینکه چه کسی در نهایت یوزر استوری را می‌نویسد کمتر اهمیت دارد؛ مهم‌تر این است که افراد تیم ما، در بحث‌های مربوط به آن دخیل شوند.

چه زمانی داستان کاربر نوشته می‌شود؟

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

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

نکات نوشتن User Story

هنگام نوشتن یوزر استوری، نکات زیر را در نظر بگیرید:

مراحل نوشتن یوزر استوری

  1. «تعریف انجام‌شده» را در نظر بگیرید.

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

  1. تسک‌ها و ساب تسک‌ها را مشخص کنید.

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

  1. پرسونای کاربران را در نظر بگیرید.

اگر کاربران نهایی متعدد با پرسوناهای متفاوتی دارید، ممکن است لازم باشد برای هر کدام یک داستان مجزا بنویسید.

  1. ترتیب مراحل را رعایت کنید.

برای هر مرحله از یک فرایند بزرگ، یک داستان کاربر مجزا بنویسید.

  1. به بازخوردهای کاربران گوش کنید.

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

  1. زمان را که حتماً در نظر بگیرید!

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

  1. تا حد ممکن شفاف باشید.

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

چگونه یوزر استوری بنویسیم؟

در این بخش، نحوه نوشتن یوزر استوری را با هم بررسی می‌کنیم.

یوزر استوری‌ها معمولاً در قالب یک جمله ساده بیان می‌شوند و ساختاری به شکل زیر دارند:

به‌عنوان یک [پرسونا]، من [می‌خواهم]، [تا بتوانم].

جزئیات این ساختار:

به‌عنوان یک [پرسونا]:

در اینجا باید بگوییم چه کسی قرار است از این ویژگی استفاده کند.

اینجا فقط به دنبال یک عنوان شغلی نیستیم، بلکه شخصیت و خصوصیات کاربر را مدنظر داریم؛
مثلا «ترانه».

کل تیم ما (مالک محصول، اسکرام مستر، برنامه‌نویس) باید درک مشترکی از این پرسونا داشته باشد. پس بهتر است یا با بسیاری از افرادی مانند «ترانه» مصاحبه کرده باشیم و بدانیم او چگونه کار می‌کند، چگونه فکر می‌کند و چه احساساتی دارد؛ یا از طرق مختلف مانند تیم برندینگ سازمان، دیتاهایی از این دست را در اختیار ما قرار داده باشند. ما باید بتوانیم با «ترانه» همدلی کنیم.

من [می‌خواهم]:

در این بخش، قصد و نیت کاربر را توصیف می‌کنیم؛ نه ویژگی‌هایی که نیاز دارد. باید بگوییم هدف واقعی کاربر چیست؟ این بخش باید کاملاً بدون اشاره به نحوه پیاده‌سازی باشد. اگر در اینجا به «رابط کاربری / UI» اشاره می‌کنید و نه به هدف کاربر، نکته اصلی را از دست داده‌اید.

[تا بتوانم]:

چگونه این خواسته به کاربر کمک می‌کند؟ کاربر چه منفعت کلی می‌خواهد به دست آورد؟ مشکل بزرگ‌تری که باید حل شود چیست؟

مثال یوزر استوری

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

  1. مثال برای یک مدیر پروژه

به‌عنوان یک مدیر پروژه، می‌خواهم تسک‌های تیمم را در یک داشبورد مشاهده کنم، تا بتوانم وضعیت پروژه را سریعاً ارزیابی کنم.

  1. مثال برای یک کاربر نهایی

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

  1. مثال برای یک توسعه‌دهنده نرم‌افزار

به‌عنوان یک توسعه‌دهنده، می‌خواهم ابزار تست خودکار داشته باشم، تا بتوانم کدهای جدید را سریع‌تر و با اطمینان بیشتر بررسی کنم.

  1.  مثال برای یک گیمر آنلاین

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

  1. مثال برای یک سرپرست تیم طراحی

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

  1. برای یک مربی:

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

  1. برای یک بازدیدکننده سایت:

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

این قالب ساده و شفاف به تیم‌ها کمک می‌کند تا روی نیازها و اهداف واقعی کاربران تمرکز کنند و از اضافه‌کردن جزئیات غیرضروری در این مرحله اجتناب کنند.

نکته: توجه به نوع کاربر در User Story

در یوزر استوری، معمولاً جمله‌ای مثل «به‌عنوان یک مالک محصول، می‌خواهم لیستی از دوره‌های دارای گواهینامه داشته باشم تا...» نمی‌بینید. «مالک محصول / Product Owner» یکی از ذی‌نفعان پروژه است و کاربر نهایی یا مشتری محسوب نمی‌شود.

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

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

  • تمرکز بیشتر: داستان‌های کوچک‌تر با جزئیات کمتر، تیم شما را از سردرگمی نجات داده و کارها را سریع‌تر پیش می‌برند.

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

  • شفافیت بیشتر: داستان‌های کوچک‌تر پیشرفت پروژه را شفاف‌تر می‌کند و گزارش‌دهی‌ها را ساده‌تر می‌کند.

داستان‌های کوچک‌تر برای مدیریت بهتر تسک‌ها، کاهش ریسک و افزایش بهره‌وری مناسب‌تر هستند.

نتیجه‌گیری

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

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

 

سوالات متداول

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

مقاله‌های مرتبط

Scrum Master   Cover

اسکرام مستر کیست؟ | چرایی و چگونگی یک شغل مدرن

5 روز پیش
زمان مطالعه:
10 دقیقه
Product Owner

مالک محصول کیست؟ | نگاهی به نقش Product Owner در پروژه‌های اجایل

5 روز پیش
زمان مطالعه:
6 دقیقه
اصول اجایل

اصول اجایل، نگاهی نزدیک‌تر به «Agile Principles» با مثال‌های کاملاً عملی

6 روز پیش
زمان مطالعه:
27 دقیقه
عضو خبرنامه اجیلیتی شوید تا مقالات تخصصی، راهکارهای به‌روز و ابزارهای کاربردی را در باکس خود دریافت کنید.