محسن احمدی
محسن احمدی
خواندن ۶ دقیقه·۵ سال پیش

تفاوت اپیک و یوزر استوری در اسکرام

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

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

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

اما قبل از شروع شاید بد نباشه یه نگاهی هم به این مطلب بندازید؛

کار تیمی؛ رؤیایی که در تیم‌های دورکار به حقیقت می‌پیوندد!
راهنمای دور کاری و کار با تیم‌های توزیع‌شده؛ قسمت اول

تعریف اپیک

اپیک یا Epic در واقع بخش‌های بزرگی از کار هستند که می‌تونن به تعدادی قطعات کوچکتر تقسیم بشن. در واقع زمانی که یک ویژگی دارای چندین سناریوی اجرا باشه، اجرای سناریوها و بخش‌های مختلف می‌تونن به تکمیل شدن اپیک کمک کنند.

اینجا در مورد پلنیست بخونید. پلنیست یک ابزار کاملا رایگان هست که احتمالا خیلی بهتون توی مدیریت جلسات کمک می‌کنه.

به صورت نمونه

و همونطور که تصویر بالا می‌بینید در واقع کارکردهای اصلی یک سیستم نمونه (در اینجا یک سیستم پیام‌رسانی) در قالب اپیک‌های مختلف درنظر گرفته شده. در هر ویژگی/قابلیت یا اپیک درنظر گرفته شده کاربر با چندین سناریو روبه‌رو خواهد شد. به عنوان مثال در اپیک مربوط به اشتراک عکس و فیلم، کاربر می‌تونه ویدیویی را بارگذاری یا ضمیمه کنه یا پیش‌نمایش اون‌رو ببینه. این دو نمونه از داستان‌های کاربری یا User Storyهای مربوط به این اپیک است.

نامگذاری اپیک‌ها باید به نحوی باشه که فقط با دیدن اون بتونیم فانکشنالیتی اصلی اون قابلیت رو درک کنیم. نمونه‌ای از نامگذاری خوب برای یک اپیک می‌تونه اینجوری باشه؛

پیاده‌سازی اشتراک‌گذاری عکس و فیلم

و یک نمونه از نامگذاری بد برای یک اپیک؛

پرونده‌های چند رسانه‌ای در پیام‌رسان بارگذاری و ارسال شود

یک اپیک خوب باید شامل موارد زیر باشه؛

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

در مثال مرتبط با بارگذاری تصویر و ویدیو در سرویس پیام‌رسانی؛

این ویژگی به کاربر این امکان را می‌دهد تا از طریق سرویس پیام‌رسان ما تصاویر/ویدیوهای خود را به مخاطبان خود ارسال کند. تحقیقات ما نشان داده است که ۶۰ درصد از کاربران از این قابلیت استفاده می‌کنند و در تست‌های کاربری ما نیز این مورد وجود داشته است. ما انتظار داریم تا با اضافه کردن این قابلیت ۱۰ درصد افزایش تعداد پیام‌های ارسال شده را بهبود ببخشیم و ۳ درصد میزان استفاده کاربران از پیام‌رسان خود ارتقا دهیم. در حالت ایده‌آل ما می‌خواهیم افراد بتوانند انواع مختلفی از فایل‌ها را بارگذاری و با یکدیگر به اشتراک بگذارند اما در فاز نخست فقط اجازه ارسال عکس از موبایل و دسکتاپ را برای کاربران فراهم خواهیم کرد.

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

به طور مثال؛

کاربر می‌تواند یک عکس را از گالری موبایل خود انتخاب کند.

یا

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

3. الزامات فنی این بخش از اپیک اغلب توسط تیم توسعه تکمیل می‌شود و تمامی الزامات فنی را که به تولید یک ویژگی قابل ارایه می‌انجامد را ثبت می‌کند. به طور مثال برای اجرا نیازمندیم تا اطلاعات پروفایل کاربر را در تیبل‌های جداگانه و خارج از بخش‌های فعلی سیستم ذخیره کنیم و…

4. الزامات طراحی این بخش معمولا توسط تیم دیزاین و رابط کاربری تکمیل شده و تمامی نکاتی که به لحاظ UI/UX می‌تواند بر کیفیت ویژگی‌های محصول تاثیرگذار باشند را در آن لحاظ می‌کند. به طور مثال در صورت تاخیر در بارگذاری عکس پروفایل کاربر می‌بایست عکسی به صورت پیش‌فرض به کاربر نمایش داده شود و…

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

تعریف داستان کاربر

داستان کاربر یا User Storyها در واقع توصیف غیررسمی از یک یا چند ویژگی یک سیستم است که از منظر کاربر نهایی یا کاربر سیستمی نوشته می‌شود.

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

نکته مهم؛ وقتی از منظر کاربر به موضوع فکر می‌کنیم باید تمامی سناریوهایی که ممکن است از طرف کاربر اتفاق بیافتد را نیز بررسی کرده و برای آن راه‌حل داشته باشیم.

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

یک الگوی ساده برای داستان کاربر عبارتست از؛

من به عنوان (نوع کاربر) می‌خواهم (هدف)، بنابراین (دلیل)

هدف اصلی داستان‌نویسی بیان نیازمندی‌های سطح بالا با جزییات اضافه‌ای است که به معیارهای پذیرش افزوده می‌شود.

معیارهای پذیرش یا Acceptance Criteria تصویر روشنی را برای تمام اعضای تیم توسعه بیان می‌کند که چه چیزی ساخته می‌شود و برای تیم تست، آزمون قبولی آن‌را بیان می‌کند.

داستان‌های کاربری می‌بایست شامل؛

  • عنوان داستان
  • ملاک‌های پذیرش
  • و طراحی‌های متصل به داستان کاربری باشند.

به عنوان نمونه یک داستان کاربر می‌بایست به‌این صورت نوشته شود؛

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

ضوابط پذیرش این داستان عبارتند از؛

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

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

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

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

اجایلاسکراممدیریت پروژهتیم توسعهuser story
مدیر پروژه، مدیر محصول، اسکرام مستر با سابقه مدیریت محصول/پروژه‌های موفق و البته گاهی هم ناموفق:-)
شاید از این پست‌ها خوشتان بیاید