User Story چیست؟ نحوه ساخت یوزر استوری + 4 تمپلیت رایگان

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

نکات نوشتن User Story

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[تا بتوانم]:

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

چرخه حیات یک یوزر استوری

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

1. ایده‌پردازی و جمع‌آوری ورودی‌های اولیه

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

2. نوشتن و شکل‌دهی اولیه با تیم

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

3. گفت‌وگوی تیمی در قالب Refinement یا Grooming

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

• معیارهای پذیرش / Acceptance Criteria

• تخمین استوری پوینت / Story Points

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

4. اولویت‌بندی در بک‌لاگ

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

5. انتخاب برای اسپرینت یا ورود به جریان کار

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

6. طراحی، توسعه و تست

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

7. ارائه Demo و دریافت بازخورد

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

8. تأیید و انتقال به محیط واقعی (Deployment)

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

9. ارزیابی پس از انتشار

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 تمپلیت یوزر استوری برای ساده‌تر شدن کارهای شما

1. یک تمپلیت ساده برای یوزر استوری

این قالب اولیه به شما کمک می‌کند User Story و معیارهای پذیرش را بنویسید و همه چیز را در یک نمای ساده و قابل‌خواندن سازمان‌دهی کنید. همچنین می‌توانید جزئیاتی مثل اولویت و میزان تلاش / Effort موردنیاز را هم به آن اضافه کنید.

2. تمپلیت یوزر استوری برای Epic

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

3. تمپلیت یوزر استوری بر اساس Theme

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

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

4. تمپلیت یوزر استوری SAFe

تیم‌هایی که از برخی روش‌های اجایل استفاده می‌کنند ممکن است ترجیح دهند هنگام نوشتن User Story جزئیات بیشتری را وارد کنند. برای مثال، سازمان‌هایی که چارچوب سیف / SAFe را اجرا می‌کنند معمولاً مواردی مثل فرضیه‌ سود / Benefit Hypothesis، نیازمندی‌های غیرعملکردی / NFR و هزینه تأخیر / Cost of Delay را نیز اضافه می‌کنند.

دانلود فایل تمپلیت یوزر استوری

در لینک زیر میتوانید فایل Google Sheet دوزبانه تمپلیت یوزر استوری را دانلود کنید (از آن کپی تهیه کنید).

نتیجه‌گیری

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

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