تاریخ ارسال:
در توسعه نرم افزار و مدیریت پروژه، یک User story یک توصیف و تعریف غیر رسمی و ساده از ویژگی های نرم افزار ماست. داستان های کاربر را از دید یک کاربر نهای (end-user) یا کاربران سیستم می نویسیم. بسته به نوع پروژه User story می توان توسط اعضای مختلف، مانند هیئت مدیره، تیم توسعه یا حتی مشتریان نوشته شوند.
User story ها به تیم های نرم افزاری برای درک بهتر از سیستم و ارتباط درست بین اعضای تیم کمک می کنند.
داستان های کاربر برای تاثیر گذاری و بهبود در عملکر سیستم های درحال توسعه نوشته میشوند. در بعضی از تیم ها مدیر پروژه (product owner در اسکرام) وظیفه دسته بندی و مدیریت User story ها و تبدیل آنها به backlog را دارد. معمولا هر کسی می تواند User story را بنوسید. بعضی از آنها در جلسات مدیریتی تولید میشوند. یا بعضی ها هم در لحظه مثل یک ایده به ذهن میرسند.
User story ها معمولا در ساختار های زیر نوشته می شوند.
به عنوان یک < نقش یا مسئولیت > من می توانم < ظرفیت یا توانایی >، پس بنابراین < منفعت دریافتی >
As a <role> I can <capability>, so that <receive benefit>
برای رسیدن به < منفعت دریافتی > به عنوان < نقش یا مسئولیت >، من می توانم < هدف/خواسته >
In order to <receive benefit> as a <role>, I can <goal/desire>
به عنوان < چه کسی > < چه زمانی > < کجا >، من < چه چیزی می خواهم > به علت اینکه < چرا >
As <who> <when> <where>, I <want> because <why>
به عنوان مدیر منابع انسانی من میخواهم یک تست غربالگری درست کنم به طوری که بتوانم تشخیص دهم آیا یک نیروی تازهوارد به مدیر عملیاتی فرستاده شود یا خیر.
به عنوان مدیر میخواهم بین تستهای موجود بگردم به طوری که بتوانم در صورت نیاز برای موقعیتهای شغلی جدید از تستهای قبلی استفاده کنم یا آنها را به روز کنم.
به عنوان کاربر من میتوانم پوشههایی را که نمیخواهم از آنها پشتیبان تهیه کنم مشخص کنم به طوری که حافظه پشتیبانم پر از پوشههای ناخواسته نشود.
به عنوان (مشتری)، من میخواهم ( پشتیبانی از کارت بانکی انجام شود) تا ( من بتوانم به راحتی به صورت آنلاین خرید کنم).
به عنوان ( مدیر)، من ( گزارش می خواهم) تا ( بدانم کدام یک از دپارتمان ها منابع بیشتری نیاز دارند).
به عنوان (مشتری)، من میخواهم ( زمانی که محصول به مقصد میرسد، به من با پیامک اطلاع داده شود) تا (بتوانم هرچه سریع تر محصول را دریافت کنم)
به عنوان [مشتری] ، من [ویژگی سبد خرید] را می خواهم تا [به راحتی بتوانم اقلام آنلاین را بخرم].
من به عنوان [مدیر] می خواهم [گزارش تهیه کنم] تا [بفهمم کدام بخش ها به منابع بیشتری نیاز دارند].
من به عنوان [مشتری] می خواهم [هنگام ورود کالا یک پیامک دریافت کنم] تا [بتوانم بلافاصله آن را انتخاب کنم]
User story ها در بسیار از متدولوژی های مدیریت چابک کابرد دارند. نقش آنها اینست که تعیین می کنند که در پروژه های نرم افزار چه امکاناتی قرار داده شود. داستان ها کاربر توسط کاربران یا مالکان پروژه تعیین میشوند. اولویت و موارد مهم در پروژه را تعیین می کنند. و در آخر به تسک ها و ظایف تقسیم می گردنند.
زمانی که User story ها در حال توسعه هستند. توسعه دهندگان آنها باید بتوانند با مشتری در تماس باشند. گاهی اوقات ممکن است که حتی پیاده سازی داستان های کوتاه نیز دشوار است. چون ممکن است نیاز به دانش پیش زمینه داشته باشند. یا نیازمندی های آنها تغییر کرده باشد.
User story ها را می توان گسترش داد. می توان یادداشت ها، پیوست ها یا معیاری پذیرش (Acceptance criteria) جدید به آنها اضافه کرد.
هیچ سند و مدرک دقیقی وجود ندارد که ثابت کند استفاده از User story ها بهره وری پروژه ها ها را افزایش می دهد. اما حداقل فایده User story کاهش ایرادات و خطاهای بی مورد در فرآیند توسعه و تولید است.
در آخر می خواهم کمی خودمانی صحبت کنم. من تا اینجا سعی کردم، اندکی داستان کاربر را معرفی کنم. در آخر ممطلب هم چند مرجع معتبر برای آشنایی باهاشون قرار میدهم. به زودی هم سعی می کنم در متدلوژی چابک بیشتر صحبت کنم.
اما جمع بندی. ببینید استفاده از داستان های کاربر به معنی چابک بودن در مدیریت پروژه است. چابک بودن خوبه ها. نه که بد باشه. ولی خب مشکلاتی داره. اولین نکتش اینه که باید کاملا باهاش سازگار باشیم. یعنی اینکه اعضای تیم این مهم را درک کرده باشند. نوشتن User story و Backlog اکر با دقت کافی همراه باشه. به راحتی در طول فرآیند توسعه، یک سند سازی دقیق به همراه خط زمانی و تاریخچه تمام تغییرات شما به وجود می آید.
اما در نقطه مقابل.اگر این داستان ها بی دقت و نامنظم نوشته بشوند. یا بک لاگ هاشون را افراد متخصص و با تجربه تهیه نکنند. باعث ایجاد سرگردمی بسیار می شوند. ممکنه داستان کاربر آنقدر بزرگ باشه که در یک چرخه و تکرار قابل پیاده سازی نباشد. یا آنقدر User story ها و Backlog ها آنقدر سردرگم باشند، که روند تیم را بهم بریزند. پس دانش و تجربه مالک محصول (Product owner) بسیار اهمیت دارد.
نظرات خود را در این مورد با من در میان بگذارید.
دوست دار شما داریان
داستان کاربر یا User Story چیست ؟
داستان کاربر در متدلوژی اسکرام
آخرین بروز رسانی: يکشنبه 5 تير 1401 ( 520 )
User story (داستان کاربر) در متدلوژی اسکرام تاریخ:
مدیریت - تاریخچه خلاصه و کاربردی تاریخ:
مدیریت Route در ASP.NET Core5 تاریخ:
کتاب هایی که هر برنامه نویس باید بخواند تاریخ:
شباهت های موجود در کاتلین و سی شارپ تاریخ:
خلاصه نکات مهم از کتاب کد تمیز (CLEAN CODE) تاریخ:
کد نویس تمیز - خلاصه کتاب و نکات مهم تاریخ:
آموزش گیت در ویندوز تاریخ:
برای نظر دادن وارد شوید.
گیت هاب ابزار بررسی و نگهداری تاریخچه هرگونه فایل و پروژه می باشد. هدف از توسعه چنین ابزاری کمک به ت...
خلاصه کتاب کد نویس تمیز می گوید که برنامه نویس حرفه ای چگونه...
کد زمانی تمیز است که به راحتی توسط تمام افراد حاضر در تیم قا...
"بر اساس این اصل که تصمیمات کوچک و روزمره یا شما را به زندگی...
بیان شباهت های موجود بین زبان سی شارپ و کاتلین برای برنامه ن...