داستان کاربری (User Story)

داستان کاربری (User Story)

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

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

قواعد

داستان‌های کاربری، معمولاً توسط شخصی که نسبت به مکانیزم کسب‌وکار دید داشته، و همچنین از لحاظ فنی شمای کلی‌ دارد، نوشته می‌شود. در تیم‌های اسکرام، معمولاً شخصی تحت عنوان مدیر محصول این وظیفه را برعهده دارد. این داستان‌های کاربری معمولاً در انبار کارهای محصول یا بَک‌لاگ (Product Backlog) قرار خواهند گرفت.

چگونگی نوشتن

در نوشتن داستان‌های کاربری، اغلب از یک ساختار نظم یافته استفاده می‌شود. این ساختار، تعیین کننده‌ی سه پارامتر اصلی است، “چه کسی”، “چه کاری را” و “به چه دلیل”. مایک کُن، مبدع اصلی اسکرام عنوان می‌دارد که پاسخ عبارت “به چه دلیل” اختیاری، و در عین حال کمک کننده است. برای آن‌که ساختار نوشتار داستان کاربری ملموس‌تر گردد، فرض می‌کنیم که می‌خواهیم پلتفرمی همانند ویش ورک را به صورت ساده‌تر توسعه دهیم. به این ترتیب داستان‌های کاربری به صورت زیر خواهند بود:

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

داستان کاربریِ پلتفرمی همانند ویش ورک

داستان کاربریِ پلتفرمی همانند ویش ورک

اپیک

اپیک (Epic)، تعدادی از داستان‌های کاربری هستند که در کنار یکدیگر یک محصول و یا فیچر (Feature) را تشکیل می‌دهند. برای مثال داستان‌های کاربری‌ای که در بالا نوشته شد، می‌تواند همگی در یک اپیک قرار گیرند و در یک اپیک دیگر، پروفایل کاربر، رزومه‌ی او و دیگر مسائل قرار گیرند. به این ترتیب است که برای هر فاز یک محصول، ورژنی نام‌گذاری می‌شود. برای مثال ورژن آلفای اپیک اول، ورژن آلفا-۱ اپیک دوم و ورژن بتا اپیک سوم را دربر دارد. معمولاً در تیم‌های توسعه‌دهنده‌ی نرم‌افزاری، یک یا نهایت دو اپیک به صورت موازی درحال انجام است، چرا که تعداد اپیک‌های زیاد، محصول را پیچیده نموده، و توانایی بازخورد گرفتن از کاربران را می‌گیرد.

ملاک پذیرش

یکی از مهم‌ترین بخش‌ها و البته فنی‌ترین قسمت یک داستان کاربری، ملاک پذیرش یا Acceptance Criteria است. هنگامی که یک داستان کاربری تعریف می‌شود، باید ملاک‌های پذیرش آن داستان نیز مطرح گردند. این بخش البته نیاز به مهارت فنی و درک و شناخت سیستم‌های نرم‌افزاری به صورت جامع را داراست. در بخش ملاک‌های پذیرش نیز، ساختاری برای نوشتار وجود دارد. این ساختار می‌تواند به زبان طبیعی نزدیک بوده (که در این صورت مهارت فنی کمتری را نیاز دارد)، یا به صورت کامل مانند یک تِست عمل کند (در این صورت، حتی قابلیت برون‌سپاری به دیگر برنامه‌نویسان خارج از سازمان نیز میسر می‌گردد). در هر صورت، این ساختار نیز شامل سه بخش “فرض‌شده”، “اقدام”، و “وقوع” است. به عنوان مثال، در داستان کاربری به عنوان کاربر بتوانم ثبت‌نام کنم، تا بتوانم پروژه ثبت کنم، ملاک‌های پذیرش به صورت زیر خواهند بود.

ملاک‌های پذیرش برای یک داستان کاربری فرضی

ملاک‌های پذیرش برای یک داستان کاربری فرضی

همانطور که مشاهده می‌شود، ملاک پذیرش برای یک ثبت‌نام، شامل جزییات بیشتر یک داستان کاربری است. حال این ملاک‌های پذیرش می‌تواند جنبه‌ی فنی‌تری به خود گرفته، و به عنوان مثال در قسمت وقوع، از Status Code های متفاوت (۴۰۱، ۴۰۲، ۴۰۳ و …) استفاده گردد و همچنین در قسمت شرایط فرض شده، url مربوطه (مثلاً api/register) نوشته شود.

جمع‌بندی

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