فرادرسیوزر استوری چیست؟ + نحوه نوشتن User Story در اسکرام
بسیار وسوسه‌کننده است که یوزر استوریها (User Stories) را صرفا پیش‌نیازهای یک سیستم نرم‌افزاری به حساب آوریم، اما حقیقت چیزی دیگر است. یکی از بنیادین‌ترین و کلیدی‌ترین قواعد توسعه نرم‌افزار چابک، در اولویت قرار دادن مشتریان است و یوزر استوری هم کاری می‌کند که کاربران، در مرکز توجه قرار بگیرند. این استوریها یا «داستان‌ها»، با ادبیاتی غیر رسمی نوشته می‌شوند تا اطلاعات لازم را در اختیار تیم توسعه محصول قرار دهند.
بعد از مطالعه یک یوزر استوری، تیم توسعه دقیقا خواهد دانست که در حال ساخت چه چیزی است، چرا آن را می‌سازد و چگونه با محصول نرم‌افزاری، به ارزش‌سازی برای مشتریان مشغول خواهد شد. می‌خواهید بدانید یوزر استوری چیست و چگونه نوشته می‌شود و چه ویژگی‌هایی دارد؟ به مطالعه این مقاله ادامه دهید.
یوزر استوری چیست؟
یوزر استوری (User Story) توصیفی کلی و غیر رسمی از قابلیتی در یک نرم‌افزار است که از نقطه نظر کاربر یا مشتری نوشته می‌شود. اگر بپرسید هدف از نوشتن یوزر استوری چیست، به شما خواهیم گفت که هدف غایی آن، فراهم آوردن بستر لازم برای ارزش‌سازی برای مشتریان، به شکلی به‌خصوص است. در نظر داشته باشید که وقتی می‌گوییم «مشتری»، صرفا راجع به کاربران و مخاطبان سنتی یک محصول صحبت نمی‌کنیم، بلکه ممکن است مشتریانی داخلی یا همکارانی در سازمان داشته باشید که متکی بر تیم شما هستند.
یوزر استوری در قالب چند جمله و با ادبیاتی بسیار ساده نوشته می‌شود و بر خروجی مطلوب یک ویژگی تمرکز دارد. در یوزر استوری خبری از هیچ‌گونه جزییات نیست و پیش‌نیازها، بعدا و پس از دستیابی به توافقی تیمی، به آن اضافه می‌شوند.
این دست از استوریها سازگاری کامل با فریمورک‌های مختلف مدیریت چابک مانند اسکرام و کانبان دارند. در اسکرام، طی اسپرینت ها است که تیم توسعه به سراغ یوزر استوریها می‌رود. در کانبان نیز، تیمها یوزر استوریها را در بک لاگ محصول قرار و سپس از میان جریان کاری خود عبور می‌دهند. همین رسیدگی به یوزر استوریها است که باعث می‌شود تیمهای اسکرام قادر به دستیابی به تخمین‌های زمانی دقیق‌تر، برنامه‌ریزی بهتر برای اسپرینت‌ها و چابکی هرچه بیشتر باشند. به لطف استوریها، تیمهای کانبان میتوانند نحوه رسیدگی به کارهای در جریان (Work-in-Progress یا به اختصار WIP) را بیاموزند و جریان کاری خود را بیش از پیش بهبود دهند.
یوزر استوریها را ضمنا می‌توان بلوک‌های سازنده فریمورک‌های بزرگ‌تر چابک مانند «اپیک‌ها» (Epics) و «ابتکارها» (Initiatives) به حساب آورد. اپیک‌ها وظایفی بزرگ هستند که به مجموعه‌ای از استوریها تقسیم می‌شوند و از سوی دیگر، چندین اپیک با قرارگیری کنار یکدیگر، یک ابتکار را شکل می‌دهند. این ساختارهای بزرگ‌تر باعث حصول اطمینان از این می‌شوند که امور روزمره تیم توسعه، به اهداف غایی سازمان کمک می‌کنند.
دلیل ساخت یوزر استوری چیست؟
برای آن دسته از تیمهای توسعهای که به تازگی رویکردهای چابک را در آغوش کشیدهاند، یوزر استوریها میتوانند مثل یک گام اضافی و نهچندان کاربردی به نظر برسند. این تیمها از خود میپرسند که چرا صرفا یک پروژه بزرگ را تبدیل به گامهایی خردتر نکرده و کار را به پایان نرسانیم؟ اما حقیقت این است که استوریها میتوانند پسزمینههایی مهم برای تیم ترسیم کنند و ارزشی که هر یک از وظایف به همراه میآورند را به نمایش بگذارند.
برخی از کلیدی‌ترین مزیت‌های یوزر استوریها به شرح زیر است:
- باقی ماندن تمرکز بر کاربر: فهرستی از کارهایی که باید انجام شود، باعث می‌شود تیم روی وظایف ضروری متمرکز باقی بماند. اما مجموعه‌ای از استوریها سبب می‌شوند که تیم روی حل مساله برای کاربران واقعی متمرکز باشد.
- مشارکت در تیم: وقتی هدف غایی ترسیم شده باشد، اعضای تیم میتوانند با یکدیگر همکاری و راجع به نحوه خدمت‌رسانی به مشتری و رسیدن به هدف تصمیم‌گیری کنند.
- ارائه راهکارهای خلاقانه: استوریها تیم توسعه را مجبور به تفکر انتقادی و خلاقانه راجع به نحوه رسیدگی به امور می‌کند.
- شکل‌گیری گشتاور: با پشت سر گذاشتن وظایف مربوط به هر استوری، تیم توسعه از یک چالش کوچک و یک پیروزی کوچک لذت می‌برد و به این ترتیب، گشتاور افزایش می‌یابد.
نحوه کار با یوزر استوریها
زمانی که یک استوری نوشته شد، نوبت به تعبیه آن در جریان کاری تیم می‌رسد. به صورت معمول، نوشتن هر استوری برعهده مالک محصول، مدیر محصول یا مدیر برنامه است و سپس مورد بازنگری قرار می‌گیرد.
در جریان یک اسپرینت یا جلسه برنامه‌ریزی اسپرینت، تیم راجع به استوری‌هایی که در این برهه توسعه به سراغ آن‌ها خواهد رفت تصمیم‌گیری می‌کند. در این مرحله، اعضای تیم به مباحثه راجع به پیش‌نیازها و کارکردهای مورد نیاز هر یوزر استوری مشغول می‌شوند. در واقع این فرصتی برای تیم است تا به ابعاد فنی و خلاقانه در فرایند پیاده‌سازی استوری فکر کند. زمانی که توافق نظری کلی حاصل شد، پیش‌نیازها هم به هر استوری افزوده می‌شوند.
یک گام رایج دیگر در چنین جلساتی، امتیاز دادن به استوریها براساس میزان پیچیدگی یا مدت‌زمان مورد نیاز برای رسیدگی به آن‌هاست. تیمهای توسعه از واحدهای اندازه‌گیری مختلفی مانند سایز تی‌شرت‌ها یا دنباله فیبوناچی برای امتیاز دادن به استوریها و تخمین زدن میزان وقت و تلاش مورد نیاز خود استفاده می‌کنند.
چطور یوزر استوریها را بنویسیم؟
هنگام نوشتن یوزر استوریها، به موارد زیر توجه داشته باشید:
- معنای «پایان یافتن»: استوری معمولا زمانی به «پایان» می‌رسد که کاربر قادر به انجام دادن کار مورد نظر باشد، اما باید اطمینان حاصل کرد که تعریفی واضح برای آن کار وجود دارد.
- مشخص کردن وظایف و وظایف خرد: لازم است به تصمیم‌گیری راجع به گامهایی که باید برداشت و همینطور شخص یا اشخاص مسئول هر گام مشغول شد.
- مشخص کردن پرسونای کاربران: قابلیت مورد نظر برای چه کسی ساخته می‌شود؟ اگر چندین مشتری مختلف مد نظرتان است، چندین استوری مختلف بنویسید.
- گام‌های ضروری: یک استوری برای هر گام در فرایندی بزرگ‌تر بنویسید.
- گوش دادن به بازخوردها: با کاربران خود مکالمه و مشکلات یا نیازهایشان را شناسایی کنید. وقتی می‌توان مستقیما به سراغ مشتریان رفت، نیازی نیست که استوریها را با حدس و گمان بنویسید.
- توجه به زمان: زمان موضوعی حساس است. بسیاری از تیمهای توسعه ترجیح می‌دهند اصلا راجع به زمان‌بندی‌ها صحبت نکرده و صرفا برای تخمین‌های خود متکی باشند. از آن‌جایی که استوریها را باید بتوان در یک اسپرینت به پایان رساند، استوری‌هایی که چندین هفته یا ماه زمان می‌برند باید به استوری‌های خردتر تقسیم شده و خود، یک اپیک به حساب آیند.
زمانی که یوزر استوریها تعریف و نوشته شدند، اطمینان حاصل کنید که در معرض دید تمام اعضای تیم قرار می‌گیرند.
قالب و مثال‌های یوزر استوری
یوزر استوریها معمولا در قالب جملاتی ساده نوشته می‌شوند و ساختاری مشابه آنچه در ادامه آورده‌ایم دارند:
«به عنوان یک [پرسونا]، من [می‌خواهم که...]، [تا این‌طور شود...].»
بیایید هر بخش این جمله را به صورت جداگانه بررسی کنیم:
- به عنوان یک [پرسونا]: قابلیت مورد نظر برای چه کسی ساخته می‌شود؟ ما صرفا یک سمت شغلی نمی‌خواهیم، بلکه می‌خواهیم تصویری از مشخصات فردی آن شخص ترسیم کنیم. تیم ما باید درکی یکسان از هویت کاربری که در اینجا اسمش را «شایان» می‌گذاریم داشته باشد. در حالت ایده‌آل، تیم ما با چندین «شایان» مصاحبه کرده است. بنابراین می‌دانیم که شایان چطور کار می‌کند، چطور فکر می‌کند و چه احساسی دارد. ما با شایان همدردی می‌کنیم.
- می‌خواهم که: در اینجا به توصیف مقاصد کاربر می‌پردازیم، نه قابلیتی که از آن استفاده می‌کند. کاربر در این لحظه به دنبال دستیابی به چیست؟ بار دیگر تاکید می‌کنیم که این بخش از جمله باید عاری از اطلاعات ویژگی باشد. اگر در حال توصیف بخشی از رابط کاربری یا هرآنچه که به هدف مخاطب مربوط نمی‌شود باشید، کار را به شکلی اشتباه پیش می‌برید.
- تا این‌طور شود: نیاز کاربر چه ارتباطی به تصویر بزرگ‌تر محصول ما دارد؟ اصلی‌ترین مزیت کاری که می‌خواهد انجام دهد چیست؟ آن مشکل بزرگی که باید رفع و رجوع شود چیست؟
برای مثال یوزر استوریها میتوانند چنین شمایلی داشته باشند:
- به عنوان شایان، می‌خواهم دوستانم را دعوت کنم تا بتوانیم با همدیگر از این سرویس لذت ببریم.
- به عنوان رضا، می‌خواهم کارهایم را منظم کنم تا احساس کنم کنترل بیشتری بر امور دارم.
- به عنوان یک مدیر، می‌خواهم قادر به درک میزان پیشرفت همکارانم باشم تا به شکلی بهتر شکست‌ها و موفقیت‌هایمان را گزارش کنم.
این ساختار کاملا ضروری نیست، اما می‌تواند به پیشبرد امور کمک کند. زمانی که پرسونای مورد نظر قادر به دستیابی به ارزش مورد نظرش باشد، استوری به پایان رسیده است. پیشنهاد ما این است که تیمهای مختلف، ساختار خاص خود را بیابند و سپس در سراسر مسیر توسعه از آن استفاده کنند.
سخن پایانی
در نهایت باید گفت که یوزر استوریها به توصیف چرایی و چیستی کارهای انجام شده از سوی اعضای تیم توسعه می‌پردازند و معمولا هم با ساختار «پرسونا + نیاز + مقصود» نوشته می‌شوند. با درک نقشی که یوزر استوریها ایفا می‌کنند، اعضای تیم به ذهنیتی مشترک دست یافته و از سوی دیگر، دلیل پشت وظایف مختلف خود را می‌دانند.
اگر می‌خواهید بدانید نحوه ساخت یوزر استوری چیست، بار دیگر یادآوری می‌کنیم. کافی‌ست کارتان را با پروژه بزرگ بعدی (یا یک اپیک) شروع کنید. این پروژه را به یوزر استوری‌های خردتر تقسیم کرده و برای بهبود هرچه بیشتر آن‌ها، به سراغ تیم توسعه بروید. زمانی که یوزر استوریها نوشته شده و در مقابل چشم تمام اعضا قرار گرفتند، می‌توانید کار را شروع کنید.
