داستان کاربر
| توسعه نرم‌افزار |
|---|
در توسعه نرم‌افزار و مدیریت تولید به توصیف غیررسمی و با استفاده از زبان طبیعی یک یا چند ویژگی یک سامانه نرم‌افزاری داستان کاربر می‌گویند. داستان کاربر معمولاً از دید کاربران سامانه نوشته می‌شود و عموماً روی برگه‌های کوچک یا به شکل دیجیتالی در سامانه‌های مدیریت پروژه ثبت می‌شوند.[۱] بسته به نوع پروژه، داستان کاربر می‌تواند توسط سهامداران سامانه از جمله مدیران و تیم توسعه نیز نوشته شود. هدف اصلی داستان کاربر، کمک به درک سامانه و اجزای مرتبط به آن توسط تیم‌های نرم‌افزاری است.[۲]
داستان‌های کاربر باعث راحت شدن ارتباط می‌شوند و به تیم توسعه نرم‌افزار کمک می‌کنند تا درک خود از سامانه و ویژگی‌های آن را نظم بدهند.[۲]
قواعد[ویرایش]
داستان‌های کاربر توسط کاربران و مشتریان سامانه نوشته می‌شوند و ویژگی‌های سامانه در حال توسعه را مشخص می‌کنند. در برخی تیم‌ها، مدیر محصول (یا صاحب محصول در چارچوب اسکرام)، مسئول یک‌پارچه کردن داستان‌های کاربر و مرتب کردن آن‌ها در انبار محصول است. در برخی دیگر از تیم‌ها، همه اعضای تیم می‌توانند در یک‌پارچه کردن داستان‌های کاربر نقش داشته باشند. فرایند تولید داستان کاربر می‌تواند در قالب بحث با سهامداران صورت بگیرد.
قالب‌های متداول[ویرایش]
متداول‌ترین قالب نگارش داستان کاربر، قالب کانکسترا (Connextra) است.[۳][۴][۵] به پیشنهاد مایک کان عبارت «به طوری که» اختیاری است اگرچه نوشتن آن سودمند است.[۶]
به عنوان «مسئولیت» من می‌توانم «قابلیت‌ها»، به طوری که «منفعت»
کریس متس (Chris Matts) پیشنهاد داد که ارزش و منفعت باید به عنوان قدم اول تحویل سامانه نرم‌افزاری مورد توجه قرار گیرد در نتیجه قالب زیر را برای نوشتن داستان کاربر ارائه کرد:[۷]
برای دستیابی به «منفعت» به عنوان «مسئولیت»، من می‌توانم «هدف»
یک قالب دیگر که بر مبنای پنج پرسش بیان می‌شود:[۸]
به عنوان «چه کسی» «چه زمانی» «کجا»، من «چه چیزی» به علت اینکه «چرا»
چند مثال[ویرایش]
تست غربالگری
به عنوان مدیر منابع انسانی من می‌خواهم یک تست غربالگری درست کنم به طوری که بتوانم تشخیص دهم آیا یک نیروی تازه‌وارد به مدیر عملیاتی فرستاده شود یا خیر.[۹]
مرور تست[ویرایش]
به عنوان مدیر می‌خواهم بین تست‌های موجود بگردم به طوری که بتوانم در صورت نیاز برای موقعیت‌های شغلی جدید از تست‌های قبلی استفاده کنم یا آن‌ها را به روز کنم.[۹]
پشتیبان‌گیری محدود[ویرایش]
به عنوان کاربر من می‌توانم پوشه‌هایی را که نمی‌خواهم از آن‌ها پشتیبان تهیه کنم مشخص کنم به طوری که حافظه پشتیبانم پر از پوشه‌های ناخواسته نشود.
محدودیت‌ها[ویرایش]
محدودیت‌های داستان کاربر شامل موارد زیر هستند:
- مشکل توسعه مقیاس: داستان‌های کاربر روی برگه‌های کوچک کاغذ نوشته می‌شوند در نتیجه توسعه آن‌ها به پروژه‌های بزرگ مشکل است.
- گنگ و ناکامل بودن: داستان‌های کاربر به علت بیان شدن به زبان طبیعی، احتمال سوء برداشت دارند و هم‌چنین به علت کوتاهی، نمی‌توانند بیان‌کننده جزییات پیاده‌سازی ویژگی‌ها باشند. به همین دلایل نمی‌توان از داستان‌های کاربر در قراردادهای رسمی استفاده کرد.[۱۰]
- بیان نشدن نیازمندی‌های غیروظیفه‌ای: به ندرت در داستان‌های کاربر شاخص‌های عملکردی یا نیازمندی‌های غیروظیفه‌ای ثبت می‌شوند. در نتیجه ممکن است در انجام آزمون‌های عملکردی کوتاهی شود.
- مشخص نبودن نحوه پیاده‌سازی: از آن‌جایی که داستان‌های کاربر معمولاً از دید تجاری و سود و منفعت نوشته می‌شوند، زمانی که تیم توسعه درگیر پیاده‌سازی این ویژگی‌ها می‌شود ممکن است به محدودیت‌های تکنیکی برخورد کند که حل آن‌ها ورای یک داستان کاربر تکی باشد. البته در بعضی موارد شکاندن این داستان‌های کاربر به داستان‌های کوچک‌تر می‌تواند مشکل را حل کند. از طرفی داستان‌های کاربری که از دید تکنیکی نوشته شده‌اند ممکن است از دید سهامداران تجاری بی‌ارزش قلمداد شده و دچار مشکل شوند.
نقشه داستان[ویرایش]
نقشه داستان،[۱۱] داستان‌های کاربر را بر اساس نقشه راه محصول که تصویر بزرگ محصول است نظم می‌دهد. این تکنیک توسط جف پاتون (Jeff Patton) توسعه داده شد که هدف از آن عنوان کردن خطر پروژه‌های با داستان‌های کاربر بسیار زیاد بود که توجه را از هدف اصلی محصول دور می‌کند.[۱۲] تصویرسازی داستان‌های کاربر به شکل نقشه داستان در قالب کارگاه‌هایی با حضور کاربران سامانه اتفاق می‌افتد که در آن ابتدا فعالیت‌های اصلی و اهداف سامانه مشخص می‌شوند.
مزیت استفاده از نقشه داستان این است که می‌توان به شکل گرافیکی، نمایی دو بعدی از از انبار محصول را مشاهده کرد که در بالای آن تیترها قرار دارند که داستان‌های کاربر ذیل آن گروه‌بندی می‌شوند. در جهت افقی نیز ترتیب توصیف رفتار سامانه است.
مقایسه با مورد استفاده[ویرایش]
به یک توصیف سطح بالا از ارتباطات بین سامانه و یک یا چند کاربر که این کاربر می‌تواند خود یک سامانه یا انسان باشد، مورد استفاده می‌گویند.[۱۳] با وجود شباهت مورد استفاده با داستان کاربر تفاوت‌هایی نیز میان آن‌ها وجود دارد.
| داستان کاربر | مورد استفاده | |
|---|---|---|
| شباهت‌ها |
|
|
| تفاوت‌ها |
|
|
| قالب |
|
|
جستارهای وابسته[ویرایش]
منابع[ویرایش]
- ↑ Dimitrijević, Sonja; Jovanović, Jelena; Devedžić, Vladan (2015). "A comparative study of software tools for user story management". Information and Software Technology (به انگلیسی). 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.
- ↑ ۲٫۰ ۲٫۱ 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.
- ↑ 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, Springer International Publishing, vol. 9619, 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
- ↑ Cohn, Mike (2004). User Stories Applied: For Agile Software Development. Addison-Wesley. ISBN 0-321-20568-5. OCLC 54365622.
- ↑ "Glossary: User Story Template". agilealliance.org. Agile Alliance. 17 دسامبر 2015. Retrieved 3 February 2020.
Another name is the "Connextra format", in recognition of its origins
- ↑ Cohn, Mike (25 آوریل 2008). "Advantages of the "As a user, I want" user story template". Mountaingoatsoftware.com. Archived from the original on 18 December 2016. Retrieved 18 December 2016.
While I consider the so-that clause optional, I really like this template.
- ↑ Marcano, Antony (24 مارس 2011). "Old Favourite: Feature Injection User Stories on a Business Value Theme". Antonymarcano.com. Retrieved 23 February 2017.
- ↑ "User Story". t2informatik GmbH. Retrieved 3 February 2020.
"As (who) (when) (where), I (want) because (why)." – this phrase is based on typical W questions: who, when, where, what and why.
- ↑ ۹٫۰ ۹٫۱ Cowan, Alexander. "Your Best Agile User Story". Cowan+. Retrieved 29 April 2016.
- ↑ "Limitations of user stories". Ferolen.com. 15 آوریل 2008. Archived from the original on 13 April 2014. Retrieved 5 February 2021.
- ↑ Patton, Jeff (8 اکتبر 2008). "The New User Story Backlog is a Map". Jeff Patton & Associates. Retrieved 16 July 2019.
- ↑ 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.
- ↑ Cohn, Mike. "Project Advantages of User Stories as Requirements". Mountaingoatsoftware.com. Retrieved 26 September 2017.
برای مطالعه بیشتر[ویرایش]
- 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