User Story چیست ؟

یوزر استوری یا داستان کاربر یعنی چی ؟

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

داستان کاربر (User Story)  یعنی چی؟
اجازه دهید ابتدا بفهمیم که چرا درک ویژگی های محصول مهم است.

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

در سال 1999، کنت بک اصطلاحی به نام «داستان های کاربر» "User Stories"  برای ویژگی های محصول ابداع کرد. او توضیح داد که کلمه User Story به بهترین وجه از دیدگاه مشتری توصیف می‌شود، آنچه که او می‌خواهد داشته باشد به جای اینکه سیستم می‌تواند برای او انجام دهد. از این رو، چشم انداز در نهایت از محصول به کاربر نهایی تغییر کرد و User Stories به استانداردهای واقعی برای نیازها در تمام فرآیندهای Agile تبدیل شد.

در اصل، داستان های کاربر Agile برای نوشتن روی برگه های چسب ناک (sticky note)  یا کارت های فهرست (index cards) بسیار کوتاه و ساده ایجاد شده است. "User Story" ها بر روی میزها یا دیوارها نصب می شدند تا برنامه ریزی و بحث nvfhvi آنها ساده باشد . بنابراین، هدف را از نوشتن در مورد ویژگی ها"Features" به توضیح درباره آنها تغییر دادند.

در واقع، این توضیحات مهمتر از هر داستانی است که نوشته می شود.

در پروژه های اجایل، Product Backlog متشکل از تمام داستان های کاربر "User Stories" است. در جلسه برنامه ریزی اسپرینت(Sprint Planning Meeting)، داستان های کاربر بر اساس اولویت به بک لاگ اسپرینت (Sprint Backlog) کشیده می شوند.

مفهوم تخمین (Estimation) نیز بر اساس "User Stories" نوشته می شود و اندازه محصول نیز می تواند از روش های مختلفی مانند Story Points تعیین شود.

ساختار استاندارد داستان های کاربران "User Stories" به چه شکل است ؟

تیم‌های اسکرام معمولاً از یک رویکرد ساده برای داستان کاربر پیروی می‌کنند:

As a < type of user >, I want < some goal > so that < some reason >

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

رویکرد دیگر :

As a <user type>, I want <some goal> because <why>.

به عنوان یک <نوع کاربر>، <اهداف یا ارزش ها یا فیچرهایی> می خواهم <برای اینکه ...(چرا؟) >.

خب بنابراین دقیقاً هدف از "داستان های کاربر" چیست؟

"ران جفریس" - یک راه بسیار ساده و موثر برای توضیح داستان های کاربر ارائه می دهد که آنها را به عنوان سه C نشان می دهد:

1. card (کارت) 
2. conversation (گفتگو)
3. confirmation (تایید)
    

card (کارت) : 

ایده نگه داشتن کارت و نوشتن داستان بسیار آسان است. برای نوشتن داستان‌های کاربر، کارت‌های فهرست (index cards) یا برگه های یادداشت‌ چسبناک (sticky note) با اندازه‌های 3 × 5 اینچ داریم.

ساختاری از داستان های کاربر"User Stories" را می توان آماده کرد تا مشخص کند که آنها چه نوع کاربرانی هستند، می خواهند به چه چیزی برسند و دلیل پشت سر هدف آنها چیست.

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

conversation (گفتگو):

در این مورد داستان کاربر"User Stories" در مورد مکالمات است!

الزامات دقیق کاربر نهایی به همه اعضای تیم، ذینفعان و مالک محصول توضیح داده می شود.

گفتگوها برای یک پدیده تنها یک بار اتفاق نمی افتد. باید در تمام تکرارها "iterations " با یک فرآیند پیوسته برای کل چرخه پروژه انجام شود. داستان های کاربر"User Stories" باید از ابتدا تا انتهای پروژه مکالمه داشته باشند. در نهایت، مکالمات مداوم داستان کاربر پس از تکمیل شدن باید:

طراحی شده،
ساخته و توسعه داده شده
و در طول تکرار "iterations " تست شود.

مزیت اصلی داستان های کاربر"User Stories" این است که تمرکز را از نوشتن مداوم داستان ها به مکالمات مؤثر هدایت می کنند. این مکالمات ابزارهای آسانی برای تغییر اطلاعات و ترکیب آنها برای اطمینان از مدیریت و درک صحیح الزامات توسط همه فراهم می کند. این مکالمات می تواند شفاهی باشد یا بصورت مستند همراه با محدودیت های ما ثبت شود. اگر ما یک طرح UI یا توضیحی از قوانین تجاری داشته باشیم که نوشته شده باشد، ممکن است باعث بهبود و شفافیت در آنها شود.

شروع داستان های کاربر برای استخراج ماهیت اولیه چیزی که مورد نیاز است بسیار ساده است. همچنین نشانه ای برای بحث در مورد الزامات دقیق  به صورت مناسب ارائه می دهد.

confirmation (تایید):
صرف نظر از اینکه چه مقدار مستند یا بحث ایجاد می کنیم، باید تأیید کنیم که «چه چیزی» باید تکمیل شود. بنابراین، جنبه های کلیدی داستان کاربر شامل تایید به عنوان سومین C است که در واقع به عنوان عنصری برای آزمون پذیرش " acceptance test" به آن نیاز داریم.

اجازه دهید به سرعت در مورد ارتباط آزمون پذیرش" acceptance test" و معیارهای پذیرش "acceptance criteria" در این زمینه صحبت کنیم.

کارت ها دارای پشت و رو هستند ما روی کارت را داریم که داستان را با یک خط تشریح میکند که به آن"front of the card" می گویم . طرف دیگر کارت دارای "شرایط رضایت بخش" (satisfactory conditions)  است که چیزی جز پذیرش نیست.

اینها اساساً معیارهای پذیرشی هستند که شبهات را به روشی مناسب برطرف می کنند. داستان های کاربر توسط تیم توسعه استفاده می شود تا بفهمند چه چیزی باید توسط مالک محصول ساخته و آزمایش شود. مالک محصول مسئول تایید استوری کاربر پیاده سازی شده برای رضایت  کاربران واقعی است.

اعضای یک تیم که هیچ ایده یا تجربه ای ندارند، اغلب می خواهند از صفحات گسترده استفاده کنند که محاسبات ریاضی، موارد استفاده، طرح کلی طرح پنجره پیشنهادی، و همچنین اسناد چند صفحه ای را که مانند الزامات معمولی ظاهر می شوند، نشان دهند. اینها ممکن است در بسیاری از موارد مفید باشند. اما در چند سال گذشته، ما هرگز این نوع اسناد را کامل ندیدیم.

هر دو داستان و آزمون پذیرش توسط برنامه نویسان اجرا می شود.

در پایان هر اسپرینت، زمانی که داستان ها کامل می‌شود، تیم توسعه به ذینفعان نشان می‌دهد که داستان ها با موفقیت کامل مطابق با آزمون‌های پذیرش " acceptance test" تکمیل شده است.

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

با تکمیل این مثال‌های خاص، می‌توانیم ایجاد یک داستان و فرآیند اصلاح را مدیریت کنیم. همچنین می‌توانیم آزمون‌های پذیرش (اتوماتیک) را برای هر داستان در دسترس داشته باشیم.

جزئیات بیشتر:

داستان های کاربر "User Stories" یکی از بهترین راه ها برای انتقال آیتم های سهامداران یا ایده های کاربران از طریق جریان ارزش آفرینی اسکرام است. اگر چه، شاید با اندازه داستان کاربر راحت باشیم، اما انجام یک برنامه ریزی سطح بالاتر و کسب مزایای پالایش مداوم continuous refinement پیچیده خواهد بود.

در سطح Sprint، داستان‌ها بسیار زیاد و کوچک هستند تا از برنامه‌ریزی انتشار و محصول سطح بالاتر پشتیبانی کنند. در این سطوح، ما به موارد کمتر، انتزاعی‌تر و داستان‌های کم‌تری نیاز داریم. در غیر این صورت، ما در جزئیات بی ربط گیر خواهیم کرد.

ما هرگز از epic در Sprint برای توسعه استفاده نخواهیم کرد زیرا دشوار است و به روشی دقیق توضیح داده نشده است. از طرفی اپیک ها "epic" به عنوان بهترین روش برای بیان مجموعه های کلی و  سنگین از فیچر ها با داستان های دقیق است که در زمان مناسب ایجاد می شود.

داستان های کاربر "User Stories" معمولا در اندازه های بزرگ ارائه داده می شوند، بنابر این برای یک تکرار "iteration" بیش از حد بزرگ هستند و باید بر اساس اولویت دسته بندی شوند. 

لازم به ذکر است که در برخی تیم ها این داستان های کاربر تحت عنوان "ویژگی ها"(features)  شناخته می شود.

به بخش‌هایی از داستان کاربران به‌طور کلی «stories» گفته می‌شود. برای نادیده گرفتن سردرگمی با "features" ها "epic" ها یا سایر موارد بزرگ‌تر، برخی از آنها را «stories» یا «sprint table stories» می‌نامند. در هر صورت، این داستان‌ها قابل پیاده‌سازی هستند تا مشخص کنند که آنها به ترتیب روز و بر اساس بزرگی و اولویت در اهمیت آنها هستند. بنابراین اندازه کوچک برای قرار گرفتن در یک تکرار "iteration" برای اجرای آنها  بهتر است.

INVEST:

چگونه بفهمیم داستان های نوشته شده، "User Stories" های خوبی هستند یا خیر؟ در اجایل شو به شما می گوییم که، مفهوم مهمی به نام INVEST  وجود دارد که می تواند به شما کمک کند.

بیل ویک "Bill Wake" خالق مفهوم INVEST است. او شش معیار را برای نمایش کیفیت داستان های کاربران پیشنهاد می کند. "INVEST" مخفف عباراتی است که به حفظ مجموعه ای از معیارها یا چک لیست های پذیرفته شده برای تخمین کیفیت یک داستان کاربر کمک می کند. اگر هر یک از داستان های کاربر نتواند معیارها را برآورده کند، تیم باید دوباره روی آن کار کند، حتی آنها باید داستان های قدیمی را قبل از نوشتن داستان های جدید بازنویسی کنند.

یک داستان کاربری خوب باید مفاهیم زیر را در بر بگیرد:

I - مستقل باشد (Independent)

N - قابل مذاکره باشد (Negotiable)

V - با ارزش باشد (Valuable)

E - قابل تخمین باشد (Estimable)

S - کوچک باشد (Small)

T - قابل آزمایش باشد (Testable)

مستقل باشد (Independent)
داستان‌های کاربر "User Stories" باید مستقل باشند یا حداقل باید با داستان‌های دیگر مرتبط باشند . داستان‌های کاربر که سطح بالایی از وابستگی متقابل را نشان می‌دهند منجر به تخمین، برنامه‌ریزی و اولویت‌بندی پیچیده می‌شوند. اگر از دید استقلال به آن نگاه کنیم، ساده است که به "نظم مستقل" فکر کنیم. به عبارت دیگر، داستان های کاربر را می توان به هر ترتیبی عملیاتی کرد.

پس چرا این معیار نقش مهمی دارد؟

زیرا اولویت های معتبری را برای هر یک از داستان های کاربر ارائه می دهد.

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

قابلیت مذاکره (Negotiable)
جزئیات داستان کاربر نیز باید قابل مذاکره باشد. داستان های کاربر در هیچ قراردادی نوشته نشده است، اما موضوعی قابل گفتگو است، این داستان‌ها امکان مکالماتی را دارند که در آن جزئیات واقعی قابل انتقال خواهند بود. داستان‌های کاربر خوب، به وضوح ماهیت نوع عملکردی را که افراد تجاری می‌خواهند و اینکه چرا به آن نیاز دارند، را روشن می‌کنند.

وقتی در اسکرام، توسعه‌دهندگان، مالک محصول و افراد مربوط به پروژه (مسئولان) بخواهند جزئیات پروژه را مشخص کنند، جلسه‌ای به نام Sprint Planning برگزار می‌شود. در این جلسه، تیم توسعه و مسئول محصول با هم مذاکره می‌کنند.

در این مذاکرات، مسائل فنی، محدودیت‌های بودجه، و جنبه‌های عملیاتی مورد بحث قرار می‌گیرند. هدف این مذاکرات، برآورده کردن نیازهای افراد مربوط به پروژه است، اما با احترام به محدودیت‌های تکنیکی، بودجه و جنبه‌های کاربردی.

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

با ارزش باشد (Valuable)

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

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

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

در نهایت، بند "<value>" داستان کاربر را در نظر بگیرید. دلیل آن ارائه ارزش دقیق پس از به ثمر رسیدن داستان است.

قابل تخمین باشد (Estimable)

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

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

کوچک باشد (Small)

بدیهی است که داستان‌های کاربر به تکه‌های کوچک‌تر تبدیل می‌شوند، اما چگونه می‌توان آنها را به واحدهای کوچک‌تر تقسیم کرد؟ راه حل بستگی به روش مورد استفاده اعضای تیم اسکرام دارد.

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

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

قابل آزمایش باشد (Testable)

هر داستان کاربر باید معیارهای قابل آزمایش را برآورده کند تا "انجام شده (done)" در نظر گرفته شود. در واقع، ما «قابل آزمایش (Testable) » را چیزی جز معیارهای پذیرش نمی‌دانیم.

ما نمی توانیم هیچ کاری را بدون معیارهای قابل آزمایش انجام دهیم. در غیر این صورت، چگونه ممکن است بدانیم که "User Stories" در پایان تکرار کامل شده است؟ و همچنین، استفاده از این تست ها به طور منظم جزئیات داستان های کاربر را ارائه می دهد. دانستن آن ممکن است قبل از محاسبه داستان توسط تیم اسکرام مفید باشد. ممکن است همیشه لازم نباشد که هر داستانی آزمایش شود. بنابراین، با تفکر در این راه، کار تیمی را بهبود می بخشد، کیفیت خوبی را با حرکت به سمت تضمین کیفیت در فرآیند به سمت بالا ایجاد می کند و شرایط رضایت بخش (معیارهای پذیرش) را فراهم می کند.

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

مترجم و نویسنده : علی امینی

اجایل شو شمارا به مطالعه مطالب مرتبط زیر دعوت می کند:

چگونه تیم ها را از نظر چابکی بالغ کنیم ؟

User Story Life Cycle چیست ؟

معرفی 16 کتاب آموزشی اسکرام

Planning Poker | پلنینگ پوکر چیست ؟

DoR یا Definition Of Ready چیست؟

DOD ، تعریف انجام شده یا Definition Of Done چیست ؟