پرش به محتوا

داستان کاربر

از ویکی‌پدیا، دانشنامهٔ آزاد
نمونه داستان کاربر.

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

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

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

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

[ویرایش | اشتراک‌گذاری]

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

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

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

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

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

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

تست غربالگری

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

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

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

[ویرایش | اشتراک‌گذاری]

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

محدودیت‌ها

[ویرایش | اشتراک‌گذاری]

محدودیت‌های داستان کاربر شامل موارد زیر هستند:

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

نقشه داستان

[ویرایش | اشتراک‌گذاری]
تصویرسازی نقشه داستان.

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

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

مقایسه با مورد استفاده

[ویرایش | اشتراک‌گذاری]

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

داستان کاربر مورد استفاده
شباهت‌ها
  • عموماً به زبان مورد استفاده کاربران نوشته می‌شوند تا امکان درک ویژگی‌های سامانه را به خواننده بدهد.
  • به زبان تجاری مورد استفاده کاربر نوشته می‌شود تا ارتباط بین سهامداران بهتر صورت بگیرد.
تفاوت‌ها
  • یک توصیف ساده و کوچک و با جزئیات کم از ویژگی‌های سامانه ارائه می‌دهد.
  • مدیریت نیازمندی‌ها را راحت‌تر می‌کند و بیشتر روی اهداف سامانه و نحوه ارتباط اجزای سامانه برای رسیدن به آن هدف تمرکز می‌کند.
  • جریان مورد استفاده، ترتیب ارتباطات را مشخص می‌کند و به تنهایی شامل جزئیات کافی برای استفاده است.
قالب
  • به عنوان «نقش کاربر»، من می‌خواهم «هدف» به طوری که «علت»
  • تیتر: هدف مورد استفاده
  • طرح اصلی موفقیت: لیست شماره‌گذاری شده از گام‌ها
    • گام: یک توصیف ساده از ارتباط بین کاربر و سامانه
  • افزونه‌ها: لیست شماره گذاری شده از افزونه‌ها

جستارهای وابسته

[ویرایش | اشتراک‌گذاری]
  1. Dimitrijević, Sonja; Jovanović, Jelena; Devedžić, Vladan (2015). "A comparative study of software tools for user story management". Information and Software Technology (in English). 57: 352–368. doi:10.1016/j.infsof.2014.05.012. a great number of software tools that provide, inter alia, support for practices based on user stories have emerged in recent years.
  2. 1 2 Ralph, Paul (2015). "The Sensemaking-coevolution-implementation theory of software design". Science of Computer Programming. 101: 21–41. arXiv:1302.4061. doi:10.1016/j.scico.2014.11.007. S2CID 6154223.
  3. Lucassen, Garm; Dalpiaz, Fabiano; Werf, Jan Martijn E. M. van der; Brinkkemper, Sjaak (2016), Daneva, Maya; Pastor, Oscar (eds.), "The Use and Effectiveness of User Stories in Practice", Requirements Engineering: Foundation for Software Quality, vol. 9619, Springer International Publishing, pp. 205–222, doi:10.1007/978-3-319-30282-9_14, ISBN 978-3-319-30281-2, The most prevalent user story template is the 'original' one proposed by Connextra{{یادکرد}}: نگهداری یادکرد:پارامتر اثر با شابک (رده)
  4. Cohn, Mike (2004). User Stories Applied: For Agile Software Development. Addison-Wesley. ISBN 0-321-20568-5. OCLC 54365622.
  5. "Glossary: User Story Template". agilealliance.org. Agile Alliance. 17 December 2015. Retrieved 2020-02-03. Another name is the "Connextra format", in recognition of its origins
  6. Cohn, Mike (2008-04-25). "Advantages of the "As a user, I want" user story template". Mountaingoatsoftware.com. Archived from the original on 2016-12-18. Retrieved 2016-12-18. While I consider the so-that clause optional, I really like this template.
  7. Marcano, Antony (2011-03-24). "Old Favourite: Feature Injection User Stories on a Business Value Theme". Antonymarcano.com. Retrieved 2017-02-23.
  8. "User Story". t2informatik GmbH. Retrieved 2020-02-03. "As (who) (when) (where), I (want) because (why)." – this phrase is based on typical W questions: who, when, where, what and why.
  9. 1 2 Cowan, Alexander. "Your Best Agile User Story". Cowan+. Retrieved 29 April 2016.
  10. "Limitations of user stories". Ferolen.com. 15 April 2008. Archived from the original on 13 آوریل 2014. Retrieved 5 فوریه 2021.
  11. Patton, Jeff (2008-10-08). "The New User Story Backlog is a Map". Jeff Patton & Associates. Retrieved 2019-07-16.
  12. Patton, Jeff (Software developer) (2014). User story mapping. Economy, Peter,, Fowler, Martin, 1963-, Cooper, Alan, 1952-, Cagan, Marty (First ed.). Beijing. ISBN 978-1-4919-0490-9. OCLC 880566740.{{cite book}}: نگهداری یادکرد:مکان بدون ناشر (رده)
  13. Cohn, Mike. "Project Advantages of User Stories as Requirements". Mountaingoatsoftware.com. Retrieved 26 September 2017.

برای مطالعه بیشتر

[ویرایش | اشتراک‌گذاری]