داستان کاربری در توسعه نرم افزار و مدیریت محصول، شرح غیر رسمی وطبیعی ویژگیها در یک سیستم نرم افزاری است. داستان کاربر ابزاری است که در”توسعه نرم افزاری چابک” برای توصیف ویژگی نرم افزار از دید کاربر نهایی استفاده می شود. در داستان کاربری نوع کاربر ، آنچه که می خواهند و دلیل آن خواسته تعریف می شود و به ارائه توضیحی ساده از یک نیاز کمک می کند.
داستانهای کاربر اغلب در کارتهای فهرست، در یادداشتهای Post-it یا در نرم افزار مدیریت پروژه ضبط می شوند. بسته به پروژه، داستانهای کاربر ممکن است توسط ذینفعان مختلف مانند مشتری، کاربران، مدیران یا اعضای تیم توسعه نوشته شود.
“داستانهای کاربر بخشی از یک رویکرد چابک است که به تغییر تمرکز از نوشتن در مورد الزامات تا صحبت کردن در مورد آنها کمک می کند. تمام داستانهای کاربر چابک شامل یک یا دو جمله نوشته شده و مهمتر از همه ، یک سری گفتگوها درباره عملکرد مورد نظر است”
– مایک کوهن ، نقش اصلی در اختراع روش توسعه نرم افزار Scrum
چرا ازداستان کاربری یا User Story استفاده می کنیم؟
با پیشرفت تیم و مشتریان، آنها در مورد سیستم به اطلاعات بیشتری دست پیدا می کنند. این یک انتظار منطقی نیست که تیم های پروژه بتوانند از لیست مورد نیاز استاتیک خارج شوند و ماه ها بعد نرم افزار کاربردی را ارائه دهند.
با رویکرد داستان کاربر، ما طراحی وسیع و پیشرو را با یک رویکرد “فقط کافی” جایگزین می کنیم. داستانهای کاربر با تأکید بر مکالمات مشتری محور ، زمان نوشتن اسناد جامع را کاهش می دهد. در نتیجه، داستانهای کاربر به تیمها امکان می دهد نرم افزارهای با کیفیت را سریعتر ارائه دهند و این همان چیزی است که مشتریان ترجیح می دهند. برای اتخاذ رویکرد داستان کاربر در توسعه چابک مزایای بسیار زیادی وجود دارد:
• قالب ساده و مداوم در زمان گرفتن و اولویت بندی الزامات باعث صرفه جویی در وقت می شود و در عین حال به اندازه کافی همه کاره باقی می ماند تا در ویژگی های بزرگ و کوچک به طور یکسان استفاده شود.
• با ارائه محصولی که مشتری واقعاً به آن نیاز دارد، ارزش تجاری خود را بیان کنید.
• خیلی سریع جزئیات را وارد نکنید که مانعی برای گزینه های طراحی باشند و یافتن راه حل برای سازندگان را دشوار کند.
• از ظهور کامل و وضوح کاذب خودداری کنید
• به قسمت های کوچکی بروید که نیاز به رسیدگی دارند و اجرایشان به تعویق افتاده
• کارکردهای فنی را به معمار، توسعه دهندگان، آزمایش کنندگان و غیره واگذار کنید
مفاهیم اساسی داستان کاربر
داستان کاربر روشی آسان برای جواب سریع گرفتن سوالات “چه” ، “چه کسی ” و “چرا” از نیاز محصول است. به زبان ساده، داستانهای کاربر ایده هایی از نیازمندی ها را مطرح می کنند که نیاز کاربران را بیان می کند. داستان های کاربر مختصر است و هر عنصر اغلب حاوی کمتر از ۱۰ یا ۱۵ کلمه است. این داستانها، لیست هایی برای انجام کارهایی هستند که به شما در تعیین مراحل در مسیر پروژه کمک می کنند. آنها کمک می کنند تا اطمینان حاصل شود که روند شما و همچنین محصول طراحی شده، خواسته شما را برآورده می کنند.
یک داستان کاربری به صورت تدریجی و در سه مرحله تعریف می شود:
• شرح مختصری از نیاز
• مکالماتی که هنگام رفع مشکلات و تکرار برنامه ریزی برای تحکیم جزئیات اتفاق می افتد
• تست هایی که صحت رضایت بخش داستان را تأیید می کند
و این ، به کارتهای ۳C، کارت، مکالمه و تأیید معروف هستند. ما در این مورد بعداً صحبت خواهیم کرد.
داستان کاربری – INVEST
کلمه INVEST به شما کمک می کند تا مجموعه ای از معیارها یا لیست چک را بپذیرید که کیفیت یک داستان کاربری را ارزیابی می کند. اگر داستان نتواند یکی از این معیارها را برآورده کند ، ممکن است تیم بخواهد آن را تغییر دهد ، یا حتی دوباره یک بازنویسی را در نظر بگیرد (که اغلب منجر به پاره شدن کارت داستان قدیمی و نوشتن یک نسخه جدید می شود).
یک داستان کاربری خوب باید INVEST باشد:
• Independent مستقل: باید به گونه ای باشد که بتواند بدون وابستگی به بخشهای دیگر پیش برود.
• Negotiable قابل مذاکره: فقط ذات نیاز کاربر را ضبط کند و فضای برای مکالمه باقی بماند. داستان کاربر نباید مانند قرارداد نوشته شود.
• Valuable ارزشمند: ارزش را برای کاربر نهایی ارائه می دهد.
• Estimable قابل براورد کردن: داستانهای کاربر باید تخمین زده شوند تا بتوانند به درستی در اولویت بندی قرار گیرند و در بخش های مختلف متناسب باشند.
• Small: یک داستان کاربر بخش کوچکی از کار است که معمولا باید طی حدود ۳ تا ۴ روز به پایان برسد.
• Testable قابل آزمایش: یک داستان کاربر باید از طریق معیارهای پذیرش از پیش نوشته شده تأیید شود
منشا داستان کاربری یا User Story
• اولین بار در کتاب ” Extreme Programming Explained ” از کنت بک مطرح شد. این متن بدون ساختار کاملاً شبیه موارد استفاده با محدودیت در اندازه بود.
• ران جفری مفاهیم ۳C: کارت ، گفتگو ، تأیید را در سال ۲۰۰۱ معرفی کرد
• ۲۰۰۳: فهرست بررسی INVEST برای ارزیابی سریع داستانهای کاربر، در مقاله ای نوشته شده توسط بیل ویک ارائه شد ، که مخفف اختصاری (خاص ، قابل اندازه گیری ، دستیابی ، مرتبط ، با محوریت زمانی)برای کارهایی است که ناشی از تجزیه فنی داستانهای کاربر است.
• ۲۰۰۴: مخفف INVEST از جمله تکنیک هایی است که در “داستانهای کاربر استفاده شده” از مایک کوه توصیه شده است.
چگونه داستان های کاربر را بنویسیم؟
هنگام نوشتن داستان های کاربری، یک الگو می تواند این اطمینان را به شما بدهد که اشتباها شروع به نوشتن کارهای فنی نمی کنید:
الگوی داستان کاربر
داستان های کاربر فقط عناصر اساسی یک مورد را ضبط می کنند:
• برای چه کسی است؟
• چه انتظاری از سیستم دارد؟
• چرا مهم است (اختیاری؟)؟
در اینجا یک قالب ساده از داستان کاربر که اغلب در ۷۰٪ موارد ، مورداستفاده قرار می گیرد ارائه می شود:
نقش – کاربر باید انسانی واقعی باشد که با سیستم در تعامل است.
• تا حد ممکن دقیق باشید
• تیم توسعه کاربر نیست
عمل – رفتار سیستم باید به عنوان یک عمل نوشته شود.
• معمولاً عمل برای هر داستان کاربر منحصر بفرد است
• “سیستم” ضمنی است و در داستان نوشته نمی شود
• صدای فعال ، نه صدای منفعل (“من می توانم مطلع شوم”)
مزایا – سود آن باید نتیجه ای در دنیای واقعی باشد که غیر عملکردی یا بیرونی برای سیستم است.
• بسیاری از داستانها ممکن است جمله سود را با یکدیگر به اشتراک بگذارند.
• این مزیت ممکن است برای سایر کاربران یا مشتریان باشد، نه فقط برای کاربر موجود در داستان
نکته:
داستانهای کاربر به زبان روزمره نوشته می شود و هدف خاصی (چه) را از دیدگاه یک فرد (که) به همراه دلیل (چرا) او می خواهد توصیف می کند.
در توسعه نرم افزار، هدف اغلب ویژگی محصول جدید است ، فرد به نوعی کاربر نهایی است و دلیل آن فایده ای است که کاربر در ویژگی محصول هدفمند می بیند.
مثال هایی از داستان کاربر
• به عنوان [مشتری] ، من [ویژگی سبد خرید] را می خواهم تا [به راحتی بتوانم اقلام آنلاین را بخرم].
• من به عنوان [مدیر] می خواهم [گزارش تهیه کنم] تا [بفهمم کدام بخش ها به منابع بیشتری نیاز دارند].
• من به عنوان [مشتری] می خواهم [هنگام ورود کالا یک پیامک دریافت کنم] تا [بتوانم بلافاصله آن را انتخاب کنم]
در مثال های بالا:
• نقش نماینده شخص ، سیستم ، زیر سیستم یا هر نهاد دیگری است که برای دستیابی به یک هدف با سیستم اجرایی تعامل برقرار خواهد کرد. او با تعامل با سیستم، ارزشهایی به دست می آورد.
• عمل بیانگر یک انتظار کاربر است که می تواند از طریق تعامل با سیستم انجام شود.
• مزایا بیانگر مقدار ارزش تعامل با سیستم است.
این یک قانون نیست بلکه یک راهنمایی است که به شما کمک می کند با در نظر گرفتن موارد زیر درباره داستان کاربر فکر کنید:
• داستان کاربر برای شخصی یا طرف خاصی (به عنوان مثال مشتریان) ارزش می آورد.
• داستان کاربر نیاز کاربر را برآورده می کند (به عنوان مثال در هنگام ورود یک پیامک دریافت کنید)
• دلیلی برای پشتیبانی از اجرای این داستان کاربر وجود دارد (به عنوان مثال مشتری می تواند کالای خریداری شده خود را انتخاب کند)
جزئیات داستان های کاربر با ۳C (کارت ، مکالمه و تأیید)
ران جفری ، یکی دیگر از سازندگان XP ، آنچه به روش مورد علاقه ما برای فکر کردن در مورد داستان های کاربران تبدیل شده است را توصیف کرد. کاربر داستان دارای سه مؤلفه اصلی است که هر یک از آنها با حرف “C” شروع می شوند: کارت (Card) ، مکالمه (Conversation)و تأیید (Confirmation) برای توصیف سه عنصر یک داستان کاربر. جایی که:
کارت
کارت بیانگر ۲-۳ جمله است که برای توصیف هدف داستان استفاده می شود و می تواند به عنوان دعوت به مکالمه در نظر گرفته شود. کارت به عنوان نشانه ای به یادماندنی است ، که خلاصه قصد را نشان می دهد و یک نیاز دقیق تر را مشخص می کند ، که جزئیات آن هنوز واضح نیست.
لازم نیست همه مواردی که انجام نشده اند را قبل از آنکه به کار تیم وارد شوند را بنویسید. مشتری و تیم در هنگام کار روی آن “مشاغل / سیستم ” نیاز اساسی را کشف می کنند. این کشف از طریق مکالمه و همکاری درمورد داستانهای کاربر اتفاق می افتد. کارت معمولاً از قالب مشابه شکل زیر پیروی می کند:
من به عنوان (نقش) محصول، می توانم (اقداماتی انجام دهم) تا بتوانم (برخی از مزایا / ارزش) را بدست آورم.
توجه داشته باشید:
• متن نوشتاری، دعوت به مکالمه ، باید به “چه کسی (نقش)” ، “چه (عمل)” و “چرا (مزایا)” داستان بپردازد.
گفتگو
مکالمه بیانگر بحث بین کاربران هدف، تیم، صاحب محصول و سایر ذینفعان است که برای تعیین رفتار دقیق تر مورد نیاز برای اجرای هدف ضروری است. به عبارت دیگر ، کارت همچنین “قول گفتگو” در مورد قصد را نشان می دهد.
• مکالمه مشترک توسط صاحب محصول که شامل همه ذینفعان و تیم می شود ، تسهیل می شود.
• مکالمه جایی است که ارزش واقعی داستان در آن نهفته است و کارت نوشته شده باید تنظیم شود تا منعکس کننده درک مشترک فعلی این مکالمه باشد.
• این مکالمه عمدتا کلامی است ، اما بیشتر آنها توسط اسناد و انواع تستهای خودکار مختلف پشتیبانی می شوند (مثلاً آزمونهای پذیرش).
تائیدیه
تأیید نشان دهنده پذیرش آزمون است ، به این ترتیب مشتری یا مالک محصول تأیید می کند که این داستان به رضایت آنها منجر شده است. به عبارت دیگر، تأیید بیانگر شرایط رضایتمندی است و برای تعیین اینکه آیا داستان هدف را تحقق می بخشد یا نیازهای دقیق تر را نشان می دهد، استفاده می شود.
• صاحب محصول می تواند تأیید می کند که داستان کامل است قبل از اینکه “انجام” پذیرد.
• تیم و صاحب محصول با توجه به تعریف فعلی تیم از “انجام شده” ، “اهمیت” هر داستان را بررسی می کنند.
• معیارهای پذیرش خاص که با تعریف فعلی “انجام شده” متفاوت است می تواند برای داستانهای فردی تعیین شود، اما معیارهای فعلی باید به خوبی درک و با توافق تیم باشد. کلیه آزمون های پذیرش مرتبط باید در حالت گذر باشد.
چگونه داستان کاربر را شناسایی کنیم؟
داستانهای کاربر باید همراه با ذینفعان آن مشخص شود، ترجیحاً از طریق یک نشست رو در رو. داستان کاربر به جای فرآیند تجزیه و تحلیل نیازهای مقدماتی، یک فرآیند کشف نیاز است.
در رویکردهای ضبط الزامات سنتی ، تحلیلگر سیستم سعی می کند نیازهای مشتریان را درک کند و سپس مشخصات مورد نیاز سیستم را با جزئیات تهیه کند. این روش کارکرد داستان کاربر نیست. به جای یک فرآیند مستند سازی ، شناسایی داستان کاربر بیشتر شبیه به یک یادداشت برداری است. ما مراحل اصلی برای شناسایی داستانهای کاربر را به شرح زیر ذکر می کنیم:
۱. از طریق بحث و گفتگو با کاربران، ما به مشکلات و نیازهای آنها گوش می دهیم و می فهمیم
۲. سپس همزمان نیازهای آنها را به عنوان داستانهای کاربر بنویسید.
۳. این داستانهای کاربر منبع الزامات خواهند شد.
۴- جزئیات می تواند متعاقباً به موقع پر شده و در اختیار تیم قرار بگیرد که در طول فرآیند توسعه پروژه ، منابع “کافی” را ارائه دهد.
چرخه زندگی یک User Story
به معنای گسترده، شش حالت اصلی برای هر داستان کاربر در طول یک پروژه نرم افزاری وجود دارد:
در انتظار
از طریق ارتباط بین کاربر و تیم پروژه، داستانهای کاربر یافت می شود. در این حالت، داستان های کاربر چیزی جز شرح مختصری از نیاز کاربر ندارند. هنوز بحث دقیقی در مورد الزامات، منطق سیستم و طراحی صفحه وجود ندارد. در واقع، تنها هدف داستان کاربر فعلاً فقط یادآوری همه طرفین برای بحث در مورد درخواست کاربر است که در (کارت) نوشته شده است. این امکان وجود دارد که در آینده داستان کاربر حذف شود.
انجام دادن
از طریق بحث و گفتگو میان ذینفعان مختلف ، در چند هفته آینده داستانهای کاربر مورد بررسی و تصمیم گرفته می شود و در یک جعبه زمانی به نام حداکثر سرعت قرار می گیرند. گفته می شود که چنین داستانهای کاربر در وضعیت انجام کار هستند. هنوز بحث مفصلی در این بخش انجام نشده است.
بحث کردن
هنگامی که یک داستان کاربر در حال بحث است ، کاربر نهایی در تأیید الزامات و همچنین تعیین معیارهای پذیرش ، با تیم توسعه ارتباط برقرار می کند. تیم توسعه ملزومات یا تصمیماتی را به عنوان یادداشت مکالمه درج خواهد کرد. متخصص UX ممکن است برای پیش نمایش ویژگی های پیشنهادی در مدل های بصری و ایجاد احساسات، صفحات داستانی ایجاد کند. این فرایند به عنوان طراحی تجربه کاربر (طراحی UX) شناخته می شود.
در حال توسعه
پس از مشخص شدن شرایط ، تیم توسعه برای تحقق درخواست های کاربر ویژگی ها را طراحی و پیاده سازی می کند.
تأیید
پس از پیاده سازی تیم توسعه داستانی ، داستان کاربر توسط کاربر نهایی تأیید می شود. برای تأیید ویژگی، وی به محیط آزمایشی یا یک محصول نرم افزاری نیمه کامل (که بعضاً به عنوان نسخه آلفا نیز شناخته می شود) دسترسی پیدا می کند. تأیید بر اساس موارد تأیید نوشته شده هنگام جزئیات داستان کاربر انجام خواهد شد. تا زمانی که تأیید انجام شود ، گفته می شود که داستان کاربر در حالت تأیید قرار دارد.
تمام شده
سرانجام ، وقتی ویژگی تأیید شده انجام می شود، داستان کاربر در حالت نهایی در نظر گرفته می شود. به طور معمول ، این پایان داستان کاربر است. اگر کاربر نیاز جدیدی داشته باشد یا مربوط به یک ویژگی جدید باشد که نیازبه افزایش داستان کاربر نهایی باشد ، تیم یک داستان جدید را برای تکرار بعدی ایجاد می کند.
سازماندهی داستانهای کاربر با نقشه داستان
داستان های کاربر روشی مفید برای ایجاد یک محصول بهتر است ، شخصی که کاربر محور است و نیازهای نرم افزار را به روشی عملی توصیف می کند. اما داستانهای کاربر به تنهایی نمی تواند کل تصویری را که شما درسفر بزرگتری که کاربر از لحظه بارگیری یک برنامه تا رسیدن به هدف نهایی خود عبور می کند، نشان دهد.
نقشه داستان کاربر می تواند به ما کمک کند تا داستان های کاربر را در یک مدل قابل کنترل برای برنامه ریزی ، درک و سازماندهی عملکرد سیستم به صورت سیستماتیک یاری کنیم. با دستکاری در ساختار نقشه ، می توان موانع و موارد حذف شده را شناسایی کرد و داستان های کاربر را با یکدیگر در ارتباط ساخت. کمک به برنامه ریزی کامل برای انتشار نسخه های جامع که ارزش هر کاربر را برای کاربران و مشاغل فراهم می کند. نقشه داستان کاربر به شما امکان می دهد یک بعد دوم را اضافه کنید. در اینجا چند دلیل وجود دارد که باید در استفاده از این تکنیک در نظر بگیرید:
• این تکنیک اجازه دیدن یک تصویر کلی از دورنمای کار را به شما می دهد.
• به شما ابزاری بهتر برای تصمیم گیری در مورد پاکسازی و اولویت بندی موارد روی هم انباشته شده را می دهد.
• این کار طوفان مغزی و رویکرد مشترک برای تولید داستانهای کاربر شما را ترویج می دهد.
• یک روش توسعه مکرر را ترجیح می دهد که در آن نسخه های اولیه معماری و راه حل شما را تأیید کنند.
• یک جایگزین عالی بصری برای برنامه های پروژه های سنتی است.
• یک مدل مفید برای بحث و مدیریت دامنه است.
• به شما امکان می دهد برنامه ریزی بعدی و گزینه های واقعی را برای پروژه / محصول خود تجسم کنید.
الگوی نقشه داستان کاربر
نقشه برداری داستان یک رویکرد از بالا به پایین برای جمع آوری نیاز است و به عنوان یک درخت نشان داده شده است. نقشه برداری داستان از فعالیت های کاربر شروع می شود. فعالیت کاربر باید به اهداف خاصی برسد و برای انجام یک فعالیت، کاربران باید وظایف مرتبط را انجام دهند. این وظایف را می توان به رفتارها و داستان های کاربر برای توسعه نرم افزار تبدیل کرد. به طور معمول، نقشه داستان کاربر شامل ۳ سطح است: فعالیتهای کاربر / وظایف کاربر / داستان کاربر. برای پروژه های مقیاس سازمانی ، ممکن است با معرفی Epics در سطح سوم ، یک ساختار ۴ سطحی مناسب تر باشد.
فعالیت های کاربر – آنها در ستون دوم ارائه شده اند. اینها اهداف اصلی است که سیستم باید با نتایج اقتصادی ملموس از آنها پشتیبانی کند. کل ردیف ستون فقرات را تشکیل می دهد.
وظایف کاربری – هر یک از فعالیتهای کاربر به مجموعه ای از وظایف کاربر به نام جریان روایی تقسیم می شود. (کل این ردیف اسکلت راه رفتن را تشکیل می دهد)
حماسه ها / داستان های کاربر – هر یک از وظایف کاربر به یک داستانی دیگر که به ویژگی کاربر توجه می کند تقسیم می شود. بسته به پیچیدگی پروژه های شما ، تیمتان ممکن است سطح ۳ یا ۴ نقشه داستان را انتخاب کند که مناسب تر باشد.
نقشه داستان پارادایم ویژوال Visual Paradigm در هر دو سطح ۳ و ۴ سطح پیچیدگی را برای شما برای مقابله با انواع متنوع پروژه پشتیبانی می کند.
نقشه داستان سطح ۳ (فعالیت های کاربر > وظایف کاربر> داستان کاربر)
نقشه داستان سطح ۴ (فعالیت های کاربر> وظایف کاربر> حماسه ها> داستانهای کاربر)
برنامه ریزی برای انتشار داستان کاربری
استفاده از یک جداکننده برای شناسایی کارهایی که ممکن است کاربران برای دستیابی به اهداف خود از نرم افزار شما استفاده کنند، لازم است. کوچکترین کارهایی که به کاربران خاص شما اجازه می دهد تا به هدف خود برسند و محصول مطلوبی را ترجیح می دهند.
چگونه می توان از داستان کاربر به طور موثر استفاده کرد؟
درست مانند بسیاری از روشهای توسعه نرم افزار ، اگر داستان کاربر را به درستی در پروژه نرم افزاری خود بکار بگیرید ، می توانید یک سیستم نرم افزاری با کیفیت برای جلب اعتماد و رضایت مشتری تولید کنید. در اینجا نکاتی وجود دارد که هنگام استفاده از داستان کاربر باید به خاطر داشته باشید:
• توضیحات داستان کاربر را کوتاه نگه دارید.
• هنگام نوشتن داستان کاربر از نقطه نظر کاربر نهایی فکر کنید.
• موارد تأیید قبل از شروع توسعه باید تعریف شوند.
• قبل از اجرا ، داستان کاربر را تخمین بزنید تا اطمینان حاصل شود که حجم کار تیم شما تحت کنترل است.
• تشخیص نیازها با “کاربران نهایی” است، نه فقط کاربر نهایی یا فقط تیم توسعه دهنده. برقراری یک رابطه خوب با کاربران نهایی یک وضعیت برنده برای هر دو طرف خواهد بود.
• ارتباطات همیشه در درک آنچه کاربر نهایی می خواهد مهم است.
منبع: www.visual-paradigm.com
