داستان کاربری درمقابل موارد کاربردی

در این مقاله، داستان کاربری درمقابل موارد کاربردی، تفاوت­های مهم و اینکه کدام یک برای شما مناسب تر است را کشف می کنید.

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

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

داستان کاربری در مقابل موارد کاربردی: اسناد زیاد

دنیای شتابزده امروز مملو از حجم بی پایانی از اسناد کاربر محور است که می توانند در کنار ابزار Wireframe قابل استفاده باشند. مشکل اینجاست که همه آنها مفید هستند.

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

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

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

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

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

ساختار داستان کاربری

داستان کاربری اغلب فقط شامل یک جمله یا چند خط هست که در ساختار زیر نوشته شده:

• به عنوان یک (کاربر)

• می خواهم (عملی انجام دهم)

• بنابراین من می توانم (رسیدن به هدف)

نمونه ای از این موارد می تواند:

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

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

• با توجه به (چگونگی اتفاقات)

• چه زمانی (اقدام انجام شده)

• سپس (نتیجه همان اقدام)

با استفاده از آن قالب، معیارهای پذیرش معمولاً کمی شبیه موارد زیر است:

“با توجه به اینکه بودجه کافی در حساب بانکی کاربر وجود دارد، هنگامی که آنها اطلاعات خود را به درستی وارد می کنند و ساعت معتبری را انتخاب می کنند، بلیط باید در داشبورد ظاهر شود، سپس یک ایمیل تأیید و رسید خرید باید به آدرس ایمیل کاربری ارسال شود “

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

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

با این حال، این تنها رسانه ای نیست که داستان های کاربری می تواند در آن وارد شود. آنها اغلب در واقع دیجیتالی شده و در اسناد Excel یا Word یا صفحات google یا حتی قابل ارائه در PowerPoint نوشته می شوند.

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

اطلاعات زیادی متراکم است

داستان کاربری ممکن است در ابتدا یک سند بسیار ساده به نظر برسد و موضوع دقیقاًاین است. با این حال، تلاشی که برای ایجاد این جملات به ظاهر ساده یکی دو خطی انجام می شود، کم نیست.

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

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

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

قبل از اینکه سرعت عمل برای ادامه کار و جایگزینی برای روش آبشاری به عنوان محبوب ترین متد توسعه نرم افزار، وارد صحنه فناوری شود، موارد کاربردی چیزهای مهمی بودند. آنها در اواخر دهه ۱۹۸۰ به عنوان نمودار ULM (Unified Modeling Language) توسعه داده شدند.

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

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

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

موارد کاربردی معمولاً ساختار زیر را در نظر می گیرند:

• بازیگر (کاربر، گروهی از کاربران)

• سیستم (محصول یا ویژگی محصولی که بازیگر با آن تعامل دارد)

• هدف (آنچه بازیگر سعی دارد از طریق سیستم به آن دست یابد)

موارد کاربردی به شکل نمودار با بازیگر یا بازیگران (کاربران) در سمت چپ مربع و سیستم محصول یا بخش های مسئول شرکت در سمت راست است.

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

تیم های مختلف اغلب موارد اضافی مانند موارد زیر را اضافه می کنند:

• بررسی اجمالی اهداف کاربر (یادداشت کوتاه در کنار نمودار)

• لیستی از کلیه ذینفعان درگیر

• اعضای تیم طراحی و توسعه

• پیش شرط ها

• شرایط ارسال

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

تهیه زمینه

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

درج پیش شرط سیستم قبل از تعامل کاربر با ویژگی، راهی عالی برای تهیه زمینه در مورد ویژگی مورد نظر است. همچنین روشن می شود که سیستم بعد از آن باید در چه وضعیتی باشد (وضعیت پس از آن).

شرایط ارسال

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

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

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

تفاوت ها

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

درجه جزئیات

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

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

میزان سرعت

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

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

موارد کاربردی معمولاً ویژگیهای سیستم مورد نیاز برای هر مرحله از فرآیند یک ویژگی را ذکر می کند و ورودی مورد نیاز کاربر و سیستم را به شما نشان می دهد.

ساختار

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

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

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

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

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

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

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

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

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

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

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

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

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

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

انتخاب داستان کاربری یا موارد کاربردی؟

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

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

منبع: uxmag.com