داستان کاربر

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

داستان‌های کاربر باعث راحت شدن ارتباط می‌شوند و به تیم توسعه نرم‌افزار کمک می‌کنند تا درک خود از سامانه و ویژگی‌های آن را نظم بدهند.

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

قالب‌های متداول 

متداول‌ترین قالب نگارش داستان کاربر، قالب کانکسترا (Connextra) است. به پیشنهاد مایک کان عبارت «به طوری که» اختیاری است اگرچه نوشتن آن سودمند است.

به عنوان «مسئولیت» من می‌توانم «قابلیت‌ها»، به طوری که «منفعت»

کریس متس (Chris Matts) پیشنهاد داد که ارزش و منفعت باید به عنوان قدم اول تحویل سامانه نرم‌افزاری مورد توجه قرار گیرد در نتیجه قالب زیر را برای نوشتن داستان کاربر ارائه کرد:

برای دستیابی به «منفعت» به عنوان «مسئولیت»، من می‌توانم «هدف»

یک قالب دیگر که بر مبنای پنج پرسش بیان می‌شود:

به عنوان «چه کسی» «چه زمانی» «کجا»، من «چه چیزی» به علت اینکه «چرا»

چند مثال 
تست غربالگری

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

مرور تست 

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

پشتیبان‌گیری محدود 

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

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

نقشه داستان 

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

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

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

جستارهای وابسته 
 مورد استفاده
 مدیریت زمان
 توسعه نرم‌افزار
 نیازمندی‌های غیرعملیاتی

منابع

برای مطالعه بیشتر 
 Daniel H. Steinberg, Daniel W. Palmer, Extreme Software Engineering, Pearson Education, Inc. , .
 Mike Cohn, User Stories Applied, 2004, Addison Wesley, .
 Mike Cohn, Agile Estimating and Planning, 2006, Prentice Hall, .
 Business Analyst Time
 Payton Consulting 'How user stories are different from IEEE requirements

برنامه‌سازی مفرط
توسعه نرم‌افزاری چابک
نیازمندی‌های نرم‌افزار