یکی از اصلی‌ترین وظایف یک مدیر محصول نوشتن صحیح یوزر استوری هست. یه سری مطالعات شخصی داشتم و یه سری تجربیات که سعی می‌کنم در این مطلب بهشون اشاره کنم. بیس اصلی این مطلب از این مقاله می‌باشد ولی در انتهای این مقاله یک نمونه یوزر استوری واقعی براتون نوشتم که می‌تونه براتون مفید باشه و بهتون دید بده.
چطور بهترین یوزر استوری را بنویسیم؟
این که چطور بهترین یوزر استوری را بنویسیم، یک سوال مهم است که اکثر تیم‌های توسعه نرم‌افزار با آن سر و کار دارند. تقریباً می‌توان گفت که تمام تیم‌هایی که در حوزه توسعه نرم‌افزار فعالیت دارند، از فریمورک کانبان یا اسکرام یا تلفیقی از این دو استفاده می‌کنند. البته این موضوع که کدام یک از این فریمورک‌ها را مورد استفاده قرار دهید، بستگی به فرایند انجام کارها و هماهنگ بودن اعضای تیم با عملکرد آن‌ها دارد. به واقع چیزی که در نهایت می‌خواهیم، رسیدن به بهره‌وری بالا و بهینه‌سازی فرایندها است و اگر این موضوع با هر یک از این فریمورک‌ها تامین شود؛ مشکلی از بابت به کار گیری آن وجود نخواهد داشت.
مطابق چیزی که می‌دانیم فارغ از این که کدام یک از این فریمورک‌ها را مورد استفاده قرار دهید، لازم خواهد بود که برخی موارد به صورت مستند در فریمورک‌ها ثبت شده و از این طریق مدیریت پروژه‌ها، به شکلی بهینه انجام پذیرد. یکی از این مستندات مهم همین یوزر استوری‌ها هستند.
یوزر استوری چیست؟
همان‌طور که می‌توان از نامش حدس زد، یوزر استوری‌ها، در حقیقت معرفی کننده بخشی از یک فعالیت هستند که قرار است برای مشتری ایجاد ارزش کند. این بخش معرفی کننده یا همان یوزر استوری، قسمت کوچکی از یک فعالیت مشخص بوده و در دامنه‌ای ثابت و تعیین شده و در یک بازه زمانی مشخص، اجرا خواهد شد.
به این شکل هدف‌گذاری در مسیری قرار می‌گیرد که تیم بر مشتری و نیازهای او متمرکز شده و طراحی و زمینه‌سازی فیچرها از سوی طراحان و مهندسین به شکلی بهینه به منظور کسب رضایت مشتری و پاسخگویی به نیازهای او، صورت بگیرد.
به این شکل هر تیم می‌تواند به صورت مستقل طبقه‌بندی یوزر استوری‌های خود را تعیین کند. البته فرمت‌های کارآمدی وجود دارد که بر حسب مطالعه و تجربه به دست آمده و می‌توان آن‌ها را به عنوان الگو در نظر گرفت.
نیازمندی‌های یک یوزر استوری خوب
بیل ویک برای نوشتن یک یوزر استوری اصل Invest را مطرح و معرفی کرده است که در ادامه به آن خواهیم پرداخت.
لازم به توضیح است که اگر یوزر استوری‌های شما از این اصول پیروی کنند، این که از چه فرمتی برای نوشتن آن‌ها استفاده کنید، موضوعیت خاصی نخواهد داشت و در نهایت فرقی نمی‌کند که کدام پلتفرم را انتخاب کنید. البته این نکته را نیز در نظر داشته باشید که قرار است به طور مرتب یوزر استوری را به بک لاگ اضافه کنید و استفاده از یک فرمت مشخص و ثابت، کمک خواهد کرد تا کار شما نظم بهتری داشته و دچار سردرگمی نشوید.
با توجه به این که قرار است یک تیم، همگی از این فرمت استفاده کنند؛ بهتر است که برای انتخاب آن، نظر تمام اعضای تیم و هماهنگی با آن، سنجیده شده و در نهایت بهترین فرمت انتخاب شود.
بسیاری از ابزارهایی که توسط تیم‌های مختلف مورد استفاده قرار می‌گیرند، نظیر Jira و …؛ این امکان را فراهم می‌کنند که یک تمپلیت برای ایجاد تسک‌های مختلف داشته باشید.
در گام اول پیشنهاد می‌کنم که یک ساختار برای نوشتن یوزر استوری با تیم خود داشته باشید. پس از آن باید این ساختار را به عنوان تمپلیت نوشتن یوزر استوری به هر نرم افزار مدیریت تسکی که استفاده می‌کنید، متصل نمایید.
البته لازم است که تمپلیت را با نیازهای تیم خود تطبیق داده و به شکلی آن را شخصی سازی کنید. به طور مثال ممکن است شما نیازی به جزئیات زیاد نداشته و لازم باشد که برخی از قسمت‌های یک تمپلیت از پیش تعریف شده را حذف کنید. با تمرکز روی هدلاین‌ها، می‌توان میزان پیچیدگی تمپلیت را کاهش داده و عملکرد آن را بهینه‌سازی کرد.
در تعیین تمپلیت این موارد را در نظر بگیرید:
- چی؟
- چرا؟
- چگونه؟
- معیارهای پذیرش (Acceptance Criteria)
- مثال‌ها
- اطلاعات تکمیلی
- منابع مورد نیاز
- وابستگی‌ها (داخلی و خارجی)
نمونه یوزر استوری برای درک بهتر (مدلی که خودم می‌نویسم)
خب بخوام براتون مثالی بزنم که تقریباً میشه گفت خودم همینجوری می‌نویسم و شامل این سه بخش هست: مسئله، یوزر استوری، معیار پذیرش
مسئله: اول از همه من یکبار مسئله رو شفاف توضیح میدم. اصلا چرا می‌خوایم این فیچر رو انجام بدیم. این فیچر چه‌جوری می‌خواد مشکل کاربر رو حل کنه و … .
یوزر استوری: توی این مرحله میام طبق استانداردی که تقریبا همه ازش استفاده می‌کنند یوزر استوری رو می‌نویسم. به عنوان مثال:
به عنوان (یک نوع یوزر)، می‌خواهم (یک نوع هدف)، برای اینکه (نتیجه).
As a (type of user), I want (some goal), so that (reason).
به عنوان کاربر، می‌خواهم بتوانم لیست تسهیلات و جزئیات اقساط آن را مشاهده کنم برای اینکه جهت بررسی وضعیت تسهیلات خود نیازی به مراجعه حضوری به شعبه نداشته باشم.
معیارهای پذیرش (Acceptance Criteria): یک یوزر استوری خوب باید توضیحات کاملی داشته باشد. معیار پذیرش، در واقع توضیحات جزئی از نحوه اجرا شدن فیچر برای تیم فنی می‌باشد و برای تیم QA سندی در راستای تست‌های پذیرش رقم خواهد زد. به عنوان مثال:
- گام اول: کاربر پس از ورود به اپ، در تب فلان وارد بخش تسهیلات می‌شود.
- گام دوم: در این بخش کاربر می‌تواند از طریق تب بالای صفحه …………… را انتخاب کند.
- گام سوم: با انتخاب هر کدام از تسهیلات قادر خواهد بود وضعیت پرداخت خود را با اطلاعات زیر مشاهده کند:
مجموع اقساط باقیمانده، مبلغ کل، مبلغ پرداخت‌شده، مبلغ جریمه، تعداد اقساط سررسید شده، تعداد اقساط سررسید نشده، تعداد اقساط پرداخت شده و همچنین اطلاعات تکمیلی شامل: مبلغ، شماره تسهیلات، تاریخ شروع و خاتمه تسهیلات، شعبه بانک
- گام چهارم: کاربر می‌تواند در بخش وضعیت پرداخت با انتخاب بخش مشاهده اقساط، لیست اقساط خود را همراه با وضعیت آن مشاهده کند.
- گام پنجم: …….
توجه داشته باشید که اگه تیم دیزاین داشته باشید، بر اساس این یوزر استوری و دیزاین‌سیستم، میاد این فیچر رو طراحی می‌کنه. و بعدش برای تیم فنی قابل اجرا خواهد بود. البته اینم بگم که در این بخش می‌تونید به صورت وایرفریم نیز تمام گام‌هارو نمایش بدید.
چه کسی باید یوزر استوری‌ها را بنویسد؟
لازم به توضیح است که مسئولیت نوشتن مداوم یوزر استوری‌ها بر عهده یک یا چند نفر از اعضای تیم خواهد بود که وجه بیزنسی محصول را بیش از سایرین می‌دانند. به این معنی که مدیر محصول یا تحلیلگر کسب و کار، مسئول نوشتن یوزر استوری خواهد بود. البته تا حد امکان بهتر است که از سایر اعضای تیم برای رسیدن به بهترین ساختار کمک گرفت.
در نظر داشته باشید که حتی بهترین و ایده‌آل‌ترین یوزر استوری در صورتی که به نقطه استفاده درست از آن‌ها نرسیم، هیچ کاربرد مفیدی نخواهد داشت. اکثر اوقات فردی که مسئولیت نوشتن یوزر استوری را برعهده دارد، می‌تواند خود به تنهایی بیشتر قسمت‌های آن را تکمیل کند. اما معمولاً چنین چیزی بدون دانش فنی عمیق پیش رفته و نمی‌توان از آن برای برآورد لازم، استفاده کرد.
چطور بهترین کارکرد یوزر استوری‌ها را داشته باشیم؟
این تجربه شخصی بنده هست که وقتی یوزر استوری رو آماده می‌کنم، قبل از جلسه پلنینگ حتماً یکبار طی جلسه‌ای با بچه‌های فنی (تک‌لیدهای بک‌اند و فرانت‌اند) بررسیش می‌کنم. این حضور و همفکری باعث خواهد شد تا سوالات لازم و بحث‌های موازی در خصوص این که چه کاری قرار است صورت بگیرد، مطرح شده و پاسخ دهی به آن‌ها به منظور پیشبرد پروژه شکل بگیرد.