Agile Sages با جستجو در سراسر وب، موارد استفاده و داستان های کاربر را دو چیز متفاوت می داند:

• مایک کوهن:  داستان‌های کاربر، موارد استفاده نیستند
• آلیستر کاکبرن:  یک داستان کاربری برای یک مورد استفاده قرار می گیرد، همانطور که غزال برای یک آلاچیق است
• Extreme Programming.org:  داستان های کاربر همان اهداف استفاده را دارند اما یکسان نیستند.

رویکرد استفاده از کیس یکی از داغ‌ترین تکنیک‌ها برای جمع‌آوری نیازها بود و برخی از مردم اکنون آن را نوعی تکنیک قدیمی و قدیمی می‌دانند که با مشکلات زیادی همراه است که باعث می‌شود تیم شما به دلیل مشکلات استفاده از «چابک» نباشد. :

• نیاز اولیه – تلاش برای تعریف جزئیات همه جنبه های مقدماتی منجر به اتلاف وقت و تلاش زیادی می شود زیرا بسیاری از کارها باید دوباره انجام شوند.
• تجزیه عملکردی: ماهیت عملکردی موارد استفاده به طور طبیعی منجر به تجزیه عملکردی یک سیستم از نظر موارد استفاده ملموس و انتزاعی می شود که به طور گسترده به هم مرتبط هستند و شامل تداعی موارد استفاده می شوند.

اگر در سرتاسر وب با کلمات کلیدی «مورد استفاده در مقابل داستان کاربر» جستجو کنید، فهرستی طولانی از مقالاتی را خواهید دید که درباره ایرادات، مشکلات یا مشکلات رویکرد استفاده از موارد پیشنهاد می‌کنند، در حالی که فهرست طولانی‌تری از مزایای مربوط به داستان کاربر وجود دارد. . جالب است، همه چیز در صنعت IT به سرعت تغییر می کند، و حتی برای افرادی که از چیزهای “مد روز” در گذشته به چیزهای “مد روز جدیدتر” اکنون تغییر می کنند، سریعتر تغییر می کند.

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

اکنون برخی افراد علامت مساوی مربوط به داستان کاربر و مورد کاربر را می گذارند:

• Agile = داستان کاربر یا Agile = داستان کاربر + Scrum
• داستان کاربر = به اندازه کافی و به موقع
• داستان کاربر = برآورده کردن انتظارات کاربر و رضایت بخش
• استفاده از Case = Upfront Detailed نیازمندی گرفتن
• Use case = <<شامل>> + <<extends>> = تجزیه عملکردی
• مورد استفاده فقط سبک “ورودی کاربر” -> “پاسخ سیستم” است
• مورد استفاده = سبک قدیمی و قدیمی

به عنوان یک فروشنده ابزار، ما در روش ها، ابزارها و تکنیک ها بسیار بی طرف هستیم. من شخصاً می خواهم تأکید کنم که از طرفداران بزرگ توسعه Agile، داستان کاربر و فرآیند اسکرام هستم. به‌ویژه، اصول و بهترین شیوه‌های مورد تأکید مربوط به مفاهیمی مانند:

 

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

(پست های بیشتری در رابطه با اصول بالا با نظرات خودم می نویسم، که ارتباط نزدیکی با حوزه تحقیقاتی دکترای من در سال های 1992-1995 دارد – تبدیل های متامدل و طرحواره)

حال، بیایید به موضوعات “استفاده از پرونده در مقابل داستان کاربر” برگردیم. خوب، حکیمان چابک وزنه‌بردار قبلاً به آن رأی داده‌اند، آیا من آنقدر سرسخت هستم که می‌خواهم «رأی‌های آنها را با این استدلال که شبیه یا حتی یکسان هستند، لغو کنم؟»

اجازه دهید مثالی را به شما نشان دهم تا نشان دهم که آیا داستان کاربر “خیلی متفاوت” از مورد کاربر است یا خیر:

مثال

داستان های کاربر خوب بسیار بیشتر از اظهارات هستند. یک داستان کاربر استاندارد از سه قسمت تشکیل شده است که معمولاً به عنوان سه C شناخته می شود.

اولین “C” هر داستان کاربر باید از قالب استاندارد شده پیروی کند:

به عنوان یک [نقش]، می خواهم [کاری انجام دهم]، به طوری که [منافع]

که حداقل محتوای یک داستان کاربر برای قرار دادن در کارت است.

گفتگوها محتوای دومین “C” یک داستان کاربر است که بیانگر بحث بین کاربران نهایی، مالک پروژه و تیم توسعه است. در این تبدیل، بحث شفاهی یا بسیاری از اطلاعات مفید دیگر مانند ایمیل ها، وایرفریم ها یا هر محتوای مرتبط دیگری را برای پروژه ضبط می کند.

“C” نهایی یک داستان کاربر تأیید است که معیار پذیرش مورد استفاده برای تأیید اجرای تصحیح داستان کاربر و تحویل موفقیت آمیز آن است.

اجازه دهید در مورد چگونگی توسعه بخش تایید یک داستان کاربر کمی بیشتر توضیح دهم. در اینجا ما از شناخته‌شده‌ترین قالب به نام Gherkin استفاده می‌کنیم که از فرمول Given-When-Then برای هدایت نوشتن تست‌های پذیرش برای یک داستان کاربر استفاده می‌کند:

• (با توجه به.. و) برخی زمینه ها
• (وقتی.. و) عملی انجام می شود
• (سپس.. و) اعمالی را انجام دهید

ابزارهایی مانند چارچوب‌های تست Cucumber و Jbehave استفاده از الگوی Given/When/Then را برای انجام آزمایش خودکار تشویق می‌کنند، اگرچه می‌توان آن را صرفاً به‌عنوان یک روش اکتشافی صرف نظر از اینکه ابزاری مورد استفاده قرار گیرد استفاده کرد.

بیایید تمام اطلاعات داستان کاربر «ثبت نام دوره» را جمع آوری کنیم و آن را در قالب 3Cs قرار دهیم:

من فرمت رایج 3 Cs را برای نمایش داستان کاربر “ثبت نام دوره” اتخاذ کردم. به همین ترتیب، من همچنین پرکاربردترین قالب را برای توصیف همان مورد استفاده «دوره ثبت نام» که با شرح مورد استفاده توضیح داده شده است، اتخاذ کردم. من مراحل قسمت تایید (آخرین C) داستان کاربر را شماره گذاری کردم که با شماره مرحله ای که در توضیحات استفاده قرار دادم مرتبط است. آنها همان “نه مرحله” سناریو هستند که در هر یک از رویکردها با ترتیب متفاوت قرار می گیرند. من معتقدم که هر دو مدل بازنمایی برای حکیمان و پیروان مربوطه آنها قابل قبول است. سپس مجدداً این سوال مطرح می شود که آیا داستان کاربر بسیار شبیه به پرونده کاربر است و در عین حال متفاوت است یا ترتیب مراحل باعث ایجاد انواع انتقادات برای رویکرد مورد استفاده می شود؟

معادل معنایی با معنی متفاوت؟

بیایید بررسی کنیم که آیا مورد مشابهی در حوزه مدل‌سازی وجود دارد یا نه، تا با وضعیت اینجا مقایسه کنیم، یا ممکن است به ما کمک کند رای خود را در مورد «داستان کاربر در مقابل موارد استفاده» بدهیم، اما نه کورکورانه از جمعیت پیروی کنیم یا آنچه را که حکیمان مثل طوطی صحبت می کنند.

مثال: معادل معنایی

در UML می‌توانیم یک سناریو مورد استفاده را با یک نمودار توالی توصیف کنیم، اما معمولاً از یک نمودار همکاری برای همان هدف استفاده نمی‌کنیم. حتی از طریق هر دو نمودار از نظر معنایی معادل هستند. به عبارت دیگر، نمودار توالی و نمودار همکاری دارای تعداد یکسانی از اشیاء شرکت کننده در یک سناریو با تعداد پیام های مشابهی هستند که از اطراف مجموعه مشابهی از اشیاء برای انجام یک کار سناریو عبور می کنند. با این حال، اولی تمرکز زمان و دومی تمرکز فضا است. نمودار توالی هنگام استفاده از آن با مدل سازی سناریو بصری تر است، در حالی که نمودار همکاری برای مدل سازی روابط ساختاری بین اشیا مناسب است. یعنی می خواهید سناریوی شی شرکت شده را به صورت ساختاری در چارچوب MVC (لایه های مدل/نما و کنترل) نشان دهید.

شخصاً فکر نمی‌کنم استفاده از داستان کاربر باعث چابکی تیم من شود و استفاده از case باعث می‌شود تیم من “پیشرو” باشد. مهمتر از همه این است که چگونه از آن ابزارها با چه نوع طرز فکر و بهترین شیوه ها استفاده کنیم. من خیلی نگران این نیستم که مردم وقتی من واقعاً چابک رفتار می‌کنم، من را «سبک قدیمی» یا قدیمی می‌دانند.

هنوز در روزهای تحلیل ساختاریافته و طراحی به یاد دارم، شاید بتوانیم از نوع داده انتزاعی در ADA برای اعمال تحلیل شی گرا و اصول طراحی بدون پشتیبانی از OOP در 198x استفاده کنیم، درست است؟ متأسفانه، ممکن است اصلاً با مفاهیم Abstract Data Type برخورد نکنید! اوه خدای من به طور تصادفی فاش کردم – من پیر شدم؟ یا باید مثبت فکر کنم – با تجربه؟

شما چی فکر میکنید؟ رای شما در این مورد چیست؟ اگر اشتباه می کنم به من اطلاع دهید یا اصلاح کنید.