یک داستان کاربر واقعی

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

خواستم همین مثال را از طریق مفهوم داستان کاربر یا User Story با هم مرور کنیم، یعنی اگر به سبک داستان کاربر انجام میدادیم چه شکلی پیدا میکرد؟

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

داستان کاربر یک روش برای توضیح قابلیت یا ویژگی مورد نظر از زبان کسی است که نیازمند آن است(معمولا کاربر یا مشتری). خاصیت ویژه این توضیح، کوتاه و مختصر بودن، پرداختن به نیاز واقعی کاربر و تعاملی بودن آن است.

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

بعنوان <نوع کاربر>

من می خواهم  <قابلیت>

تا بتوانم <نیاز – دلیل و برآیند>

یا ساده تر : من  چه کسی هستم – چی می‌خواهم – چرا این را می‌خواهم یا چه نیازی دارم

داستان بات رزرو غذا 

بعنوان کسی که یادش میره غذای هفته بعد رو رزرو کنه <نوع کاربر>

من میخواهم رزرو غذا رو از طریق بات انجام بدهم <قابلیت>

تا بتوانم حتی با رزرو غذا از خانه پیش آقای کشاورز(مسئول مربوطه) شرمنده نشوم و ایشون هم احیانا غذا کم نیاورد <نیاز – دلیل و برآیند>

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

بعنوان کسی که یادش میره غذای هفته بعد رو رزرو کنه <نوع کاربر>

من میخواهم رزرو غذا رو از طریق پرتال شرکت انجام بدهم <قابلیت>

تا بتوانم حتی با رزرو غذا از خانه پیش آقای کشاورز شرمنده نشوم و ایشون هم احیانا غذا کم نیاورد <نیاز – دلیل و برآیند>

داستان کاربر در مورد صحبت کردن است

در داستان کاربر صحبت بر روی <قابلیت> کاملا باز است، اما باید ببینیم کدامیک از این قابلیت ها بیشتر ما را به برآیند مورد نظر می‌رساند. حالا فرض شده است، که <قابلیت> من میخواهم رزرو غذا را از طریق بات انجام بدهم، ما را بیشتر به نتیجه مورد نظر خواهد رساند.

اصطلاحا گفته می شود، وظیفه یک مالک/مدیر محصول خوب، شناسایی و تعریف مناسب نیاز برای تیم است، و وظیفه تیم ارائه راه حل مناسب برای رفع نیاز مطرح شده است.

به جای تعریف قابلیت یا فیچر، چالش درست را برای تیم تعریف کنید تا برای حل چالش مشتاق باشند نه انجام تسک.

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

فرمت استاندارد را بیخیال شوید

بعضی اوقات، فرمت استاندارد یا به قولی معروف داستان کاربری اذیت کننده و شاید بی مورد است، (بعنوان <نوع کاربر> من می خواهم  <قابلیت> تا بتوانم <نیاز – دلیل و برآیند> ). آیا واقعا این را باید از نگاه آقای کشاورز مسئول غذا نوشت یا از نگاه کسی که غذا ثبت نکرده است؟ واقعا نیاز چه کسی را بر طرف می‌‎کنیم؟ یک فرمت دیگری که می توان چنین نیازهایی را ثبت کرد به صورت زیر است:

بات رزرو غذا

————

برای کاهش میزان نفرات فراموش کننده رزرو غذا ( <نیاز – دلیل و برآیند>)

نیازمند رزرو غذا از طریق بات هستیم (قابلیت)

اندازه گیری نتیجه فراموش نشود

بعد از یک مدت باید ببینیم که آیا میزان یا تعداد افرادی که در یک هفته غذا رزرو نمی کردند، کاهش پیدا کرده است یا نه. پس در واقع متر ما برای سنجش، تعداد افرادی هستند که غذا دریافت کرده‌اند بدون اینکه غذا رزرو کرده باشند. معمولا 1 تا 3 ماه این پیگیری انجام می شود، و بعد در مورد این قابلیت تصمیم گیری می‌شود، در واقع یکی از مسئولیت های مالک/مدیر محصول پیگیری این نوع داده ها است. برای همین می گوییم کار وقتی بر روی تابلوی تیم در اسپرینت Done شد، برای مالک محصول هنوز آن بسته نشده است و پیگیری آن را باید انجام دهد که آیا به نتیجه مورد نظر رسیدیم یا نه؟

شرایط پذیرش کجاست؟

معمولا ایرادی که به داستان کاربر گرفته می شود، این هست که فقط با یک عنوان نمی شود کار کرد، پس جزئیات کجاست؟ معمولا جزئیات در قالب “شرایط پذیرش” در پشت کارت یا بخش توضیحات ابزارتان مثل جیرا یا ترلو آورده می شود:

شکست کار، داستان کاربر کوچک کجاست؟

یکی از خصوصیات مهم داستان کاربر، کوچک بودن است، اصطلاحا گفته میشود ما باید برش های ریز بزنیم، یکی از بهترین راهها دیدن “شرایط پذیرش” است، آیا میتوانیم آنها را در قالب داستان های کوچک تر انجام بدهیم؟ برش هایی کوچک ولی معنادار همانند شکل زیر:

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

1- بتوان با انجام بخش کوچک کار، عدم قطعیت را کاهش داد، یعنی یک بخش کوچک را انجام بدهیم و فیدبک بگیریم شاید کلا دیگر نیازی به انجام بقیه نشد.

2- تیم بتواند روزانه پیشرفت محسوسی نسبت به هدف اسپرینت داشته باشد.

اما برش های بات چگونه می تواند می شود؟

ما می توانیم چنین شکست کاری ایجاد کنیم:

در واقع بات رزرو غذا تبدیل به یک اپیک(Epic) می شود و اقلام زیر آن تبدیل به داستان های کاربر کوچکتر که هرکدام شرایط پذیرش خود را دارند.

آیا همه آنها اولویت بالایی دارند؟

برای مثال ما میتوانیم در این اسپرینت، لاگین و ثبت رزرو رو برداریم و مشاهده رزرو را برای اسپرینت بعد بگذاریم.

فیدبک یا بازخورد بگیریم

فرض کنیم، اسپرنیت تمام شد و با موفقیت بات لانچ شد، بعد از یکی دو هفته مشاهده کردیم آمار میزان فراموش کنندگان کم نشد، چه کار باید کنیم. اولین کار این است که سریع به این نتیجه نرسیم که کلا ایده بد بوده است، سعی کنیم با تغییرات کوچک، آزمایش انجام دهیم.

مثلا این داستان کاربر جدید را برای اسپرینت بعد آماده می کنیم:

با چنین شرایط پذیرشی:

1- آخر هر هفته روز چهارشنبه ساعت 2 یک پیغام از طریق بات برای کاربر باید ارسال شود که “رزرو غذا یادت نره”

1-1 : اگر کاربر غذا رزرو کرده بود این پیغام برای او ارسال نشود

نکات کلیدی: 

1- در داستان کاربر نکته مهم این است که ما بدانیم که چرا یک قابلیت را پیاده سازی می کنیم، نیاز اساسی که رفع می کنیم چیست؟

2- متری که میخواهیم موفقیت یا برآیند این قابلیت را بسنجیم چیست؟

3- سنجش در طی زمان را فراموش نکنیم، یعنی فیچرها یا قابلیت های بلااستفاده درست نکنیم.

4- داستان کاربر باید شکسته شود و داستان کاربر باید شکسته شود و داستان کاربر باید شکسته شود.

5- به جای صرفا انجام تسک تیم را درگیر چالش کنیم

چابک و موفق باشید

اسد صفری

درباره اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

11 دیدگاه در “یک داستان کاربر واقعی

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

    من این نکاتی که از نوشته شما فهمیدم رو اینجا لیست کردم:
    – نکته مهم توی داستان کاربری
    – شکسته‌شدن داستان کاربری
    -تعریف معیار و متریک
    – سنجش و گرفتن فیدبک

  2. سلام جناب صفری امکانش هست درباره ی این دوره هخای مدارک حرفای و نحوی کسب اونا توضیح بدید.ممنون

  3. سلام وقتتون بخیر، جسارتا به منظور کنترل پروژه تولید نرم افزار، شما قبول زحمت میفرمایید برای تدریس اسکرام و جیرا؟من قبلا کنترل پروژه برای پروژه های عمرانی و با نرم افزار MSP این کارو انجام میدادم و شرکت جدیدم تو زمینه آی تی و نرم افزار فعال هستش، ممنون میشم راهنماییم بفرمایید… با تشکر صادق پهلوان 09127346080

  4. سلام و وقت بخیر. توی قسمتی که گفتید داستان کاربری شکسته بشه به همون مواردی که داخل شرایط پذیرش به عنوان جزییات نوشته شده شکسته میشه ؟ توی این مثال من اینطور برداشت کردم که همون جزییات پذیرش تبدیل شد به داستان های کاربر کوچیک تر. درست متوجه شدم؟

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

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