User story (داستان کاربر) در متدلوژی اسکرام

تاریخ ارسال:

User story (داستان کاربر) در متدلوژی اسکرام

User Story in Scrum

User stories Agile Scrum
User stories Agile Scrum

در توسعه نرم افزار و مدیریت پروژه، یک User story یک توصیف و تعریف غیر رسمی و ساده از ویژگی های نرم افزار ماست. داستان های کاربر را از دید یک کاربر نهای (end-user) یا کاربران سیستم می نویسیم. بسته به نوع پروژه User story می توان توسط اعضای مختلف، مانند هیئت مدیره، تیم توسعه یا حتی مشتریان نوشته شوند.

User story ها به تیم های نرم افزاری برای درک بهتر از سیستم و ارتباط درست بین اعضای تیم کمک می کنند.

قواعد نوشتن User story

داستان های کاربر برای تاثیر گذاری و بهبود در عملکر سیستم های درحال توسعه نوشته میشوند. در بعضی از  تیم ها مدیر پروژه (product owner در اسکرام) وظیفه دسته بندی و مدیریت User story ها و تبدیل آنها به backlog را دارد. معمولا هر کسی می تواند User story را بنوسید. بعضی از آنها در جلسات مدیریتی تولید میشوند. یا بعضی ها هم در لحظه مثل یک ایده به ذهن میرسند.

Customer or Developer!
Customer or Developer!

ساختار های پیشنهادی

User story ها معمولا در ساختار های زیر نوشته می شوند.

  • Mike Cohn ساختار زیر را پیشنهاد میدهد. ساختاری پرکابردتر از بقیه.

به عنوان یک < نقش یا مسئولیت > من می توانم < ظرفیت یا توانایی >، پس بنابراین < منفعت دریافتی >

As a <role> I can <capability>, so that <receive benefit>

  • Chris Matts بیان می کند که "کسب ارزش" اولین قدم برای تحویل نرم افزار است. پس جایگزین زیر را پیشنهاد کرد.

 برای رسیدن به < منفعت دریافتی > به عنوان < نقش یا مسئولیت >، من می توانم < هدف/خواسته >

In order to <receive benefit> as a <role>, I can <goal/desire>

  • یک جایگزین هم بر مبنای 5 پرسش پیشنهاد شده است

به عنوان < چه کسی > < چه زمانی > < کجا >، من < چه چیزی می خواهم > به علت اینکه < چرا >

As <who> <when> <where>, I <want> because <why>

 چند مثال ازUser story

تست غربالگری

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

مرور تست

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

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

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

چند مثالی دیگر از User story

به عنوان (مشتری)، من میخواهم ( پشتیبانی از کارت بانکی انجام شود) تا ( من بتوانم به راحتی به صورت آنلاین خرید کنم).

به عنوان ( مدیر)، من ( گزارش می خواهم) تا ( بدانم کدام یک از دپارتمان ها منابع بیشتری نیاز دارند).

به عنوان (مشتری)، من میخواهم ( زمانی که محصول به مقصد میرسد، به من با پیامک اطلاع داده شود) تا (بتوانم هرچه سریع تر محصول را دریافت کنم)

به عنوان [مشتری] ، من [ویژگی سبد خرید] را می خواهم تا [به راحتی بتوانم اقلام آنلاین را بخرم].

من به عنوان [مدیر] می خواهم [گزارش تهیه کنم] تا [بفهمم کدام بخش ها به منابع بیشتری نیاز دارند].

من به عنوان [مشتری] می خواهم [هنگام ورود کالا یک پیامک دریافت کنم] تا [بتوانم بلافاصله آن را انتخاب کنم]

کاربرد

User story ها در بسیار از متدولوژی های مدیریت چابک کابرد دارند. نقش آنها اینست که تعیین می کنند که در پروژه های نرم افزار چه امکاناتی قرار داده شود. داستان ها کاربر توسط کاربران یا مالکان پروژه تعیین میشوند. اولویت و موارد مهم در پروژه را تعیین می کنند. و در آخر به تسک ها و ظایف تقسیم می گردنند.

زمانی که User story ها در حال توسعه هستند. توسعه دهندگان آنها باید بتوانند با مشتری در تماس باشند. گاهی اوقات ممکن است که حتی پیاده سازی داستان های کوتاه نیز دشوار است. چون ممکن است نیاز به دانش پیش زمینه داشته باشند. یا نیازمندی های آنها تغییر کرده باشد.

User story ها را می توان گسترش داد. می توان یادداشت ها، پیوست ها یا معیاری پذیرش (Acceptance criteria) جدید به آنها اضافه کرد.

مزایا User story

هیچ سند و مدرک دقیقی وجود ندارد که ثابت کند استفاده از User story ها بهره وری پروژه ها ها را افزایش می دهد. اما حداقل فایده User story کاهش ایرادات و خطاهای بی مورد در فرآیند توسعه و تولید است.

محدودیت ها

در استفاده از User story چهار محدودیت کلی وجود دارد.

  • مشکل افزایش مقیاس : داستان های کاربر معمولا بر روی کاغذ های کوچک نوشته می شوند. بنابراین در پروژه های بزرگ مدیریت آنها سخت می شود. نگهداری آنها مشکل است. و در مواردی که اعضای تیم به صورت دور از هم کار میکنند. دسترسی برای همه امکان پذیر نیست. (البته در حال حاظر همه چیز آنلاین است. اما افزایش تعداد داستان های کاربر در پروژه های بزرگ مشکل ساز است.)
  • گنگ و ناقص بودن: User story ها معمولا آغاز کننده بحث های تحلیلی هستند. پس خلاصه و غیر رسمی بودن آنها باعث سردرگمی می شود. ممکن است مواردی ضروری برای پیاده سازی Feature فراموش شوند. یا در زمان عقد قرارداد رسمی لحن داستان های کاربر مشکل ساز شوند.
  • بیان شدن نیازمندی های غیر ضروری و غیر وظیفه ای: User story ها معمولا نگاه عملکردی یا غیر وظیفه ای دارند. (وقتی  توسط مشتری نوشته شوند، بیشتر علایق شخصی را در برمیگیرند). پس ممکن است نکات غیر وظیفه ای (Non-Functional) در این موارد بیش از حد مورد توجه قرار بگیرند.
  • لزوماً نشان نمی دهد که فناوری مدنظر چگونه باید ساخته شود: از آن‌جایی که داستان‌های کاربر معمولاً از دید تجاری و برای سود و منفعت نوشته می‌شوند. زمانی که تیم توسعه درگیر پیاده‌سازی این ویژگی‌ها می‌شود ممکن است به محدودیت‌های تکنیکی برخورد کنند. که حل آن‌ها ورای یک User story تکی باشد. البته در بعضی موارد شکاندن این داستان‌های کاربر به داستان‌های کوچک‌تر می‌تواند مشکل را حل کند. از طرفی داستان‌های کاربری که از دید تکنیکی نوشته شده‌اند ممکن است از دید سهامداران تجاری بی‌ارزش قلمداد شده و دچار مشکل شوند.

جمع بندی

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

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

User story example
User story example

اما در نقطه مقابل.اگر این داستان ها بی دقت و نامنظم نوشته بشوند. یا بک لاگ هاشون را افراد متخصص و با تجربه تهیه نکنند. باعث ایجاد سرگردمی بسیار می شوند. ممکنه داستان کاربر آنقدر بزرگ باشه که در یک چرخه و تکرار قابل پیاده سازی نباشد.  یا آنقدر User story ها و Backlog ها آنقدر سردرگم باشند، که روند تیم را بهم بریزند. پس دانش و تجربه مالک محصول (Product owner) بسیار اهمیت دارد.

نظرات خود را در این مورد با من در میان بگذارید.

دوست دار شما داریان

اینجا هم چند مطلب پیشنهادی ما به شما برای مطالعه بیشتر در User story


داستان کاربر یا User Story چیست ؟

داستان کاربر در متدلوژی اسکرام

User story in Wikipedia

User Stories with Examples and Template

Retrofit: معرفی و استفاده

آخرین بروز رسانی: يکشنبه 5 تير‏ 1401 ( 520   )

پست های مشابه

نظرات کاربران

برای نظر دادن وارد شوید.

0 نظر

جدیدترین مطالب! آخرین مطالب بلاگ

آموزش گیت در ویندوز

آموزش گیت در ویندوز

شنبه 17 ارديبهشت 1401 ( 109   )

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

بخوانید
کد نویس تمیز - خلاصه کتاب و نکات مهم

کد نویس تمیز - خلاصه کتاب و نکات مهم

چهارشنبه 10 فررودين 1401 ( 252   )

خلاصه کتاب کد نویس تمیز می گوید که برنامه نویس حرفه ای چگونه...

بخوانید
خلاصه نکات مهم از کتاب کد تمیز (CLEAN CODE)

خلاصه نکات مهم از کتاب کد تمیز (CLEAN CODE)

سه‏ شنبه 2 فررودين 1401 ( 300   )

کد زمانی تمیز است که به راحتی توسط تمام افراد حاضر در تیم قا...

بخوانید
معرفی کتاب اثر مرکب

معرفی کتاب اثر مرکب

شنبه 28 اسفند 1400 ( 198   )

"بر اساس این اصل که تصمیمات کوچک و روزمره یا شما را به زندگی...

بخوانید
شباهت های موجود در کاتلین و سی شارپ

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

چهارشنبه 11 اسفند 1400 ( 251   )

بیان شباهت های موجود بین زبان سی شارپ و کاتلین برای برنامه ن...

بخوانید