داستان کاربر (User Story) چیست و چگونه استفاده می‌شود؟

در توسعه نرم افزار و مدیریت محصول، داستان کاربر (User Story) در واقع توصیف غیر رسمی و طبیعی از یک یا چند خصوصیت از یک سیستم نرم افزاری است. داستان کاربر ابزاری است که در توسعه نرم افزاری چابک (Agile) به کار برده میشود تا خصوصیات یک نرم افزار را از دیدگاه یک کاربر نظاره گر باشد. داستان کاربر به شما میگوید که مخاطبان شما چه کسانی هستند، چه چیزی می خواهند و چرا؟

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

داستان کاربران یکی از راهکارهای دیدگاه چابک است. به این صورت تمرکز از روی نیازها برداشته شده و به تجربه کاربران و نظرات آنها می پردازد
– مایک کوهن، مخترع روش توسعه نرم افزاری اسکرام.

چرا داستان کاربر؟

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

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

با روش داستان کاربران، ما به جای اینکه هزینه زیادی روی نمونه اولیه بی نقص انجام دهیم، به یک نمونه اولیه قابل قبول بسنده می کنیم. به این صورت، داستان کاربر، باعث صرفه جویی در زمان تولید شده و سپس طبق نظرات کاربران اصلاح میشود و پیشرفت میکند. به همین شکل، داستان کاربر به تیم ها کمک میکند تا محصول باکیفیت را سریع تر در دسترس کاربر قرار دهد، که البته با سلیقه کاربر هم تناسب دارد. در اینجا به چندین مزیت در استفاده از روش داستان کاربر در توسعه Agile اشاره میکنیم:

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

مفاهیم پایه‌ای داستان کاربر

داستان کاربر یک روش ساده برای رسیدن به جواب چند سوال است و سوالاتی مثل “چه کسی”، “چه چیزی”، و “چرا” را در مورد محصول جواب میدهد. به عبارت ساده تر، داستان کاربر، نیاز های مشتری را بیان میکند. داستان کاربران کوتاه هستند به طوری که هر قسمت آن کمتر ۱۰ تا ۱۵ کلمه خواهد بود. داستان کاربر همان لیست کارهایی است که در طول پروژه باید باید انجام شود. این داستان ها کمک میکنند تا مطمئن شوید که فرایندها و نتایجتان، توانایی برطرف کردن نیاز هایتان را دارند.

داستان کاربر در سه مرحله توصیف میشود:

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

ما بعدا در این باره بیشتر صحبت خواهیم کرد.

داستان کاربر (User Story) و موضوع (INVEST)

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

داستان کاربر – INVEST

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

خاستگاه داستان کاربر

•       اولین اشاره به این مفهوم در کتاب کنت بک به نام ” توضیح برنامه نویسی پیشرفته” انجام شد.
•       ران جفریز برای اولین بار مفهوم داستان کاربری را در سه مرحله در سال ۲۰۰۱ تعریف کرد:
•       ۲۰۰۳: چک لیست INVEST برای ارزیابی سریع داستان کاربری، از مقاله های بیل ویک، استخراج شد که خود او بعد ها چک لیست دیگری به نام SMART برای ارزیابی نتیجه وظایف، ابداع کرد.
•       ۲۰۰۴ : اسم مخفف INVEST یکی از تکنیک های توصیه شده در کتاب مایک کوهن به نام ” کاربرد داستان کاربران” میباشد.

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

زمانی که شروع به نوشتن یک داستان کاربر میکنیم، یک پیش نویس می تواند به شما کمک کند تا سهوا و یا اشتباها به جای داستان، یک شرح وظایف تکنیکی ننویسید:

پیش نویس داستان کاربری

داستان کاربری تنها نیازهای ضروری را پاسخ میدهد

•       برای چه کسی طراحی شده؟
•       چه انتظاراتی از سیستم میرود؟
•       چرا مهم است(اختیاری)؟

این یک فرمت ساده از داستان کاربری است که توسط ۷۰ درصد شرکت کنندگان استفاده شده:

نقش – کاربر باید یک انسان واقعی باشد که با سیستم سرو کار دارد.

•       تا حد ممکن دقیق باشد
•       تیم توسعه نمیتواند به عنوان کاربر در نظر گرفته شود.

عملکرد – رفتار سیستم باید به عنوان یک عملکرد نوشته شود.

•       معمولا این قسمت مختص هر داستان کاربری است و با بقیه داستان ها متفاوت است.
•       جملات نمیتوانند مجهول باشد و ضمیر باید مشخص باشد.

مزایا – مزیت باید یک نتیجه در دنیای واقعی باشد و در بیرون سیستم اتفاق بیفتد.

•       بسیاری از داستان ها می توانند مزیت های یکسانی داشته باشند.
•       مزیت باید به صورت کلی در نظر گرفته شود و خاص یک کاربر نباشد.

یادداشت ها:

داستان کاربران به زبان امروزی نوشته میشود و نظر یک شخص خاص است و هدفی را دنبال میکند و برای آن دلیلی دارد.

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

مثال‌های داستان کاربر

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

مراحل داستان کاربر

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

یک داستان کاربری سه جزء اصلی دارد، برگه، گفتگو، و تایید همان سه قسمتی هستند که داستان کاربری را تعریف میکنند. جایی که:

برگه

برگه همان ۲ یا ۳ جمله ای است که هدف داستان در آن نوشته میشود و در واقع سراغاز یک گفتگو است. برگه به عنوان یک نشانه ماندگار در نظر گرفته میشود، که خلاصه ای از هدف را بیان میکند، اما جزئیات هنوز باقی میماند.

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

به عنوان (نقش) ، من میتوانم ( عملی انجام دهم) تا ( یک سری مزیت ها/ ارزش ها) به سیستم اضافه کند.

یادداشت:

•       متن نوشته شده، یا همان شروع کننده یک بحث باید حتما مشخص باشد که توسط چه کسی نوشته شده، چه میخواهد و چرا.

بحث و گفتگو

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

•       مکالمات مشترک توسط سهامداران و تیم، برنامه ریزی میشود
•       مکالمه در مورد ارزش داستان صورت میگیرد و برگه نوشته شده باید طوری تنظیم شود که به درک بهتر مکالمه کمک کند.
•       مکالمه در اکثر مواقع به صورت شفاهی صورت میگیرد اما گاهی ثبت هم میشود تا مورد آزمایش قرار گیرد.

تایید

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

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

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

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

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

1.     از طریق گفتگو با کاربران، ما گوش می دهیم و مشکلات و نیاز های آن ها را درک میکنیم.
2.     و سپس، نیاز های آن ها را به عنوان داستان کاربر در جایی ثبت میکنیم.
3.     این داستان کاربران به منبعی از نیاز ها تبدیل میشود.
4.     جزئیات میتواند بعد ها اضافه شود، و اینگونه تیم توسعه دهنده ایده های کافی برای پیشرفت پروژه در دست خواهند داشت.

چرخه عمر داستان کاربر

به طور کلی، ۶ حالت اصلی برای هر داستان کاربری در هر پروژه نرم افزاری وجود دارد:

انتظار

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

لیست کارها

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

بحث

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

متخصصان UX  ممکن است یک نسخه آزمایشی را در دسترس کاربر قرار دهند و به کاربر اجازه دهند تا برنامه را احساس کند. این فرآیند طراحی تجربه کاربری (UX design) نام دارد.

توسعه

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

تایید کردن

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

اتمام

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

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

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

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

•       این کار به شما امکان میدهد تا تصویر بزرگتری از اهداف خود را مشاهده کنید.
•       با این کار شما ابزار مورد نظر برای تصمیم گیری در مورد اولویت بندی سیستم خود را در دسترس دارید.
•       باعث میشود تا همکاری ها افزایش پیدا کرده و داستان کاربری بهتری ایجاد شود.
•       این روش بهترین انتخاب برای جایگزینی برنامه های پروژه قدیمی است.
•       این یک مدل کاربردی برای بحث و مدیریت محدوده است.
•       به شما اجازه میدهد تا برنامه ریزی را برای پروژه خود ترسیم کنید.

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

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

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

جمع‌بندی

در این مقاله سراغ بررسی تعریف داستان کاربر (User Story) و مثال‌های آن و نحوه کاربرد و استفاده از آن در پروژه‌ها رفتیم. شما می‌توانید از داستان کاربر برای پروزه‌های خود استفاده نمایید.