احتمالا عناوین مورد کاربرد (Use Case) و داستان کاربر (User Story) را فراوان شنیده‌اید و شاید هم در تحلیل سیستم‌های خود از آن‌ها استفاده کرده باشید. در این مقاله به معرفی هر کدام از این دو عبارت، کاربردها و تفاوت‌های آن‌ها می‌پردازیم.
Alistair Cockburn، از نویسندگان بیانیه چابک چنین میگوید:
«.A user story is to a use case as a gazelle is to a gazebo»
در واقع اگرچه مورد کاربرد و داستان کاربر از جهت نام مشابه به نظر می‌رسند (مانند gazelle به معنی آهو و gazebo به معنی آلاچیق)، اما تفاوت‌های بسیاری دارند و عموما در مواقع متفاوتی استفاده می‌شوند.
هر دو در زمینه برنامه‌ریزی کارها و تعیین اینکه چه چیزی لازم است تا کار تکمیل شود، به تیم‌ها کمک می‌کنند؛ اما چگونگی استفاده از آن‌ها کاملا متفاوت است.
داستان کاربر شرحی مختصر و ساده از دیدگاه مشتری است و رفتار مشتری در تعامل با محصول را بیان می‌کند. در مقابل، مورد کاربرد شامل محتوای بسیار بیشتری است. ایجاد مورد کاربردهای دقیق و همراه با جزئیات، فرایند بسیار عمیق‌تری است که برای کمک به تیم‌ها در درک نحوه تعامل کاربر یا مشتری با یک سیستم طراحی شده است.
تفاوت بین مورد کاربرد و داستان کاربر چیست؟
موارد کاربرد سال‌های زیادی است که به عنوان مستند استاندارد برای تحلیل سیستم، تحلیل کسب و کار و نیازمندی‌های نرم‌افزار استفاده می‌شوند. با ظهور متد چابک، پروژه‌های نرم‌افزاری شروع به استفاده از داستان کاربر به جای مورد کاربرد کردند؛ زیرا این کار امکان بهره‌گیری از تفکر افزایشی و چابکی را فراهم می‌کرد.
در ادامه به توضیحات بیشتری از مورد کاربرد و داستان کاربر می‌پردازیم.
مورد کاربرد
Use Case یا مورد کاربرد بیش از ۲۰ سال پیش، توسط Ivar Jacobson برای تشریح نیازمندی‌های کارکردی یک سیستم از دیدگاه کاربر، معرفی شد. در واقع مورد کاربرد توضیح می‌دهد که طراحی سیستم چگونه به درخواست‌های کاربر نهایی خود که به عنوان یک کنشگر شناخته می‌شود، پاسخ می‌دهد. این کنشگرها می‌توانند انسان و یا سیستم‌های دیگر باشند.
به عنوان مثال یک سامانه آنلاین معاملات بورسی را در نظر بگیرید: ایجاد سفارش خرید یا فروش هر کدام مورد کاربردهای متفاوتی هستند. موارد کاربرد به تیم توسعه کمک می‌کنند که تمام نیازمندی‌های عملکردی محصول را ساختاردهی کنند و محدوده پروژه را تعیین کنند. بنابراین، مورد کاربرد شامل جزئیات زیر است:
- هدف مورد کاربرد
- کنشگر (انسان یا یک سیستم دیگر)
- پیش شرط‌ها: وضعیتی که سیستم باید در آن باشد تا مورد کاربرد رخ دهد.
- توالی منظمی از گام‌ها که در واقع رفت و برگشتی بین کاربر و سیستم است.
- مسیرهای جایگزینی که سیستم می‌تواند طی کند.
- پس شرط‌ها: اقداماتی که سیستم در پایان مورد کاربرد انجام می‌دهد و یا حالت‌های مختلفی که سیستم می‌تواند پس از پایان کار در آن باشد.
داستان کاربر
داستان کاربر، شرح مختصری از یک هدف یا یک نتیجه است که کاربر یا مشتری می‌خواهد به آن دست یابد. در واقع کوچک‌ترین بخشی از کار است که می‌تواند ارزش را به مشتری برگرداند. داستان کاربر از نقطه نظر کاربر نهایی نوشته می‌شود. نحوه نگارش داستان کاربر به صورت زیر است:
به عنوان یک {کنشگر}، می‌خواهم {عملی را انجام دهم} تا {منفعت} داشته باشم.
به عنوان یک معامله‌گر، می‌خواهم سفارش خرید ثبت کنم تا بتوانم سهم مورد نظر خود را خریداری کنم.
طراحی داستان کاربر
داستان کاربر به گونه‌ای طراحی شده است که تا حد امکان ساده باشد، تا تیم و همچنین ذینفعان، درگیر رمزگشایی زبان‌های فنی نشوند. اما این بدان معنا نیست که فرایند ایجاد داستان کاربر ساده است. اطلاعات بسیاری در یک جمله خلاصه شده است و قبل از نوشتن آن، تیم باید شخصیت کاربر خود را شناسایی و ایجاد کند و همه نیازمندی‌های محصول را جمع‌آوری کند. داستان کاربر به عنوان «بیانی تسهیل و تنظیم شده که همه را برای یک سفر همراه می‌کند» توصیف شده است.
INVEST چک لیستی از مجموعه معیارهای پذیرش یک داستان کاربر ارائه می‌دهد که تیم محصول می‌توانند با استفاده از آن فرایند ارزیابی داستان‌ها را انجام دهند. اگر داستان کاربر یکی از معیارها را برآورده نکند، باید بازنویسی انجام شود. لذا یک داستان کاربر خوب باید به صورت زیر باشد:
- مستقل از بقیه داستان‌های کاربر (Independent)
- قابل مذاکره، نه یک قرارداد خاص برای آینده (Negotiable)
- ارزش آفرین (Valuable): داستان کاربر کاملا مربوط به کاربر نهایی است. اگر نمی‌توانید ارزشی را که مشتری از داستان شما کسب می‌کند توصیف کنید، داستان خوبی ننوشته‌اید.
- تخمین‌پذیر (Estimatable)
- کوچک، به گونه‌ای که در یک اسپرینت قابل تحویل باشد (Small)
- تست‌پذیر (Testable)
یک پروژه و یا یک محصول توسعه یافته در محیط چابک، شامل داستان‌های کاربر فراوانی است که هر کدام در بک لاگ محصول اضافه و اولویت‌بندی می‌شوند.
موارد استفاده از مورد کاربرد
اگرچه در توسعه چابک استفاده از مورد کاربرد خیلی رایج نیست، اما مورد کاربرد مزایایی به همراه دارد که در این بخش به بررسی ۵ مورد از آن‌ها می‌پردازیم.
۱. مورد کاربرد خلاصه و شالوده برنامه‌ریزی را فراهم می‌کند.
use case به هرکسی که در پروژه درگیر است، یعنی افرادی مثل مدیران، رهبران، مالکان محصول، توسعه‌دهندگان و ذینفعان، خلاصه‌ای از آنچه که سیستم ارائه خواهد داد، فراهم می‌کند. مورد کاربرد یک طرح برنامه‌ریزی ارائه می‌دهد که به تیم برای اولویت‌بندی، تخمین زمان و اجرای اقدامات کمک می‌کند.
۲. مورد کاربرد فهم مشترکی از ویژگی سیستم برای کل تیم فراهم می‌کند.
در مورد کاربرد جزئیاتی مطرح می‌شود تا اطمینان حاصل شود که همه افراد تیم به یک فهم از موضوع رسیده‌اند. در واقع توافقی است بین اعضای تیم در مورد آنچه که سیستم انجام خواهد داد و آنچه انجام نخواهد داد.
۳. مورد کاربرد نگاهی به آنچه که می‌تواند کار را با کندی مواجه کند، ارائه می‌دهد
بخش مسیرهای جایگزین در مورد کاربرد، نگاهی پیشرفته به مواقعی که ممکن است خطایی رخ دهد ارائه می‌دهد. گلوگاه‌های کوچک گاهی می‌توانند زمان و هزینه زیادی را به خود اختصاص دهند. بنابراین هرچه زودتر بتوانید این مسائل را بشناسید بهتر است.
۴. مورد کاربرد پاسخ سناریوها و مسائل خاص را ارائه می‌دهد
موارد کاربرد به سوالات خاصی که توسعه‌دهندگان در طول مسیر می‌توانند داشته باشند پاسخ می‌دهد. فرایند نگارش مورد کاربرد این اطمینان را حاصل می‌کند که همه سوالات در مورد مسائل و سناریوهای احتمالی در همان ابتدا و قبل از اینکه پیشرفت تیم را کند کنند، پاسخ داده می‌شوند.
۵. مورد کاربرد مدلی برای تفکر کامل در تمام جنبه‌ها را ارائه می‌دهد
مدل مورد کاربرد تضمین می‌کند که توسعه‌دهندگان به تمامی جنبه‌های توسعه فکر کرده‌اند. مورد کاربرد جزئیات نیازهای کاربر، اهداف سیستم، مسائل احتمالی و انواع مختلف کسب و کار را بررسی می‌کند.
در اسکرام، توسعه محصول به اسپرینت‌های متوالی که هر کدام معمولا بین ۲ تا ۴ هفته هستند، شکسته می‌شود. معمولا هر داستان کاربر به صورت کامل در یک اسپرینت پیاده‌سازی می‌شود؛ در حالی که یک مورد کاربرد اغلب طی چندین اسپرینت پیاده‌سازی می‌شود.
مورد کاربرد و داستان کاربر کدام یک برای تیم شما مناسب‌تر است؟
اگر بین استفاده از داستان‌های کاربر و موارد کاربرد گیر افتاده‌اید، تنها پاسخ این است که این تصمیم‌گیری بستگی به تیم شما و بزرگی آن، محصولی که روی آن کار می‌کنید، مشتری شما و سازمانتان دارد.
بهترین قانون سرانگشتی هنگام این تصمیم‌گیری این است که با همه ذینفعان محصول بحث و گفتگو کنید. بر سر مزایا و معایب هر کدام به توافق برسید و آنی را انتخاب کنید که برای تیم شما آسان‌تر و سریع‌تر است. این نکته را به یاد داشته باشید که برای چابک نگه داشتن تیم، باید از اضافه کردن جزئیات بیش از حد خودداری کنید.
اگر تجربه زیادی در پروژه‌های چابک و کار با تیم‌های چابک دارید، ارزش غیرقابل انکار داستان کاربر را می‌دانید. داستان کاربر آنچه که مشتری می‌خواهد به دست آورد را منتقل می‌کند تا تیم‌ها همیشه نیازهای کاربر را در نظر بگیرند. در واقع به جای اینکه هزینه زیادی برای ایجاد نمونه اولیه بی‌نقص صرف کنید، به یک نمونه اولیه قابل قبول بسنده می‌کنید. برای همین استفاده از داستان کاربر موجب صرفه‌جویی در زمان تولید شده و چرخه گرفتن بازخورد و انجام اصلاحات مطابق با نظرات کاربران را تسریع می‌کند. به شرط اینکه تیم شما دانش کافی در مورد شخصیت‌های کاربر شما داشته باشد، تولید داستان‌های کاربر می‌تواند بسیار سریع‌تر از موارد کاربرد باشد.
با این وجود Cockburn میگوید سه مشکل اساسی با داستان کاربر وجود دارد:
- عدم وجود محتوای کافی
- احساس کاذب کامل بودن که تمام موارد اساسی یک هدف پوشش داده شده است
- عدم وجود راهکار برای مشاهده کارهای پیش رو
مستند‌های مورد کاربر
موارد کاربرد برای مستند کردن فرآیندهای سیستم‌های موجود، به ویژه سیستم‌هایی که احتمال دارد دستخوش تغییر و به‌روزرسانی باشند، نیز مناسبند. قبل از ایجاد تغییر که ممکن است مشکلات فنی زیادی ایجاد کند، با استفاده از موارد کاربرد می‌توان دید گسترده‌ای از سیستم پیدا کرد و مشکلات را قبل از ایجاد تغییر شناسایی کرد.
از جانب دیگر، اگر چه موارد کاربرد کمی قدیمی هستند، اما می‌توانند اطلاعات بیشتری از نحوه تعامل کاربر با سیستم فراهم کنند و به بسیاری از سوالات از قبل پاسخ دهند تا به مدیریت فرایندهای پیچیده کمک کنند. بنابراین در سیستم‌هایی که پیچیدگی بالایی دارند، استفاده از مورد کاربرد کمک بسیاری خواهد کرد و متقابلا زمان بیشتری برای ایجاد آن‌ها نیاز است.
جمع‌بندی
باوجود همه موارد فوق، ممکن است تیم شما تصمیم به استفاده ترکیبی از مورد کاربرد و داستان کاربر بگیرد. زمانی که موارد کاربرد با داستان‌های کاربر ترکیب شوند، افزوده‌ای عالی ایجاد می‌کنند؛ چرا که هم لحن زبان ساده حفظ شده و هم جزئیات بیشتری در مورد عملکردهای سیستم در راستای برآورده کردن هدف کاربر ارائه می‌شود. در این حالت، نظر برخی کارشناسان این است که برای ویژگی‌های اساسی محصول از موارد کاربرد استفاده کنید و سپس در اسپرینت‌های بعدتر برای افزودن ویژگی‌های اضافی از داستان کاربر بهره ببرید. همچنین، در شروع یک پروژه بزرگ و یا مرحله توسعه نرم‌افزار، معمولا جزئیات بیشتری برای گفتن وجود دارد. لذا ترکیب این دو مستند، یک رویکرد دقیق‌تر و ساختارمندتر را در اختیار شما قرار می‌دهد.
منابع:
https://www.visual-paradigm.com/guide/agile-software-development/user-story-vs-use-case/
https://www.justinmind.com/blog/user-stories-vs-use-cases/
https://www.easyagile.com/blog/use-cases-vs-user-stories/
https://medium.com/@a.reskova/the-difference-and-relationship-between-use-case-and-user-story-25e24df777a3
دیدگاهتان را بنویسید