داستان کاربر
همان طور که می دانیم، اسکرام برای برخورد با نیازنمندی‌های کاربر روش داستان نویسی را به عنوان متداولترین شکل بیان ارزشهای کسب‌وکار بیان می‌کند. در این مقاله قصد داریم به صورت مختصر تعریف صحیحی از “داستان کاربر” ارائه دهیم و سپس مشکلاتی که تیم‌ها اغلب در اجرای آن مواجه هستند را به همراه کلید حل آنها معرفی کنیم.
مقدمه
داستان کاربر ابزار اسکرام برای بیان نیازمندی‌های کسب‌وکار است که در آن سعی برآن شده مشکلات روشهای سنتی ترتیبی ( غیرقابل مذاکره بودن نیازمندی ها و جزئیات از پیش تعیین شده) را به صورت بیان جزئیات نیازمندی ها از طریق گفت‌و‌گوهایی بطور مداوم که در طول فرایند توسعه انجام می شوند. حل کند. داستان کاربر باید به صورتی نوشته شود که هم برای افراد حوزه کسب‌وکار و هم برای افراد فنی قابل فهم باشد.
از نکاتی که می توان برای بیان صحیح یک داستان کاربر(منظور همان جزئیات و نیازمندی ها) نام برد این است که هر داستان باید به موقع و به اندازه کافی برای اعضای تیم بیان گردد. لازم به توجه است که نیازمندی ها بصورت موضوعی بیان می گردند که درجه آزادی زیادی دارند، تا حدی که بتوان با دستکاری آنها اهداف کسب‌وکار را محقق نمود به عنوان مثال اگر بودجه یا زمان رو به اتمام باشد، می توان از نیازمندی‌های کم ارزش صرف نظر کرد.
در اسکرام از گفت‌و‌گو به عنوان ابزار کلیدی برای اطمینان از انتقال درست نیازمندی‌ها و تبادل نظر درباره‌ی آنها استفاده می شود. ارتباط کلامی مزایای متعددی دارد؛
- کانال ارتباط وسیعی برای تعامل ایجاد می کند.
- دریافت بازخورد را سریع می نماید.
- دستیابی به فهم مشترکی از نیازمندی ها را ساده تر و کم هزینه‌تر می‌کند.
در اسکرام برخلاف روشهای توسعه ترتیبی نیاز نیست همه نیازمندی‌ها در لحظه اول دارای سطح یکسانی از جزئیات باشند. نیازمندی‌هایی که زودتر انجام می شوند کوچکتر و دارای جزئیات بیشتری نسبت به آنهایی هستند که برای مدتی روی آنها کار انجام نخواهد شد.
قالب داستان کاربر
یکی از روشهای رایج برای نوشتن داستان کاربر قالب کارتی است : روی یک کارت عنوان نیازمندی را می نویسیم و در زیر آن توضیح میدهیم که چه کاربری(نقش کاربر)، چه می خواهد بدست بیاورد(هدف) ،و دلیلی که کاربر بدنبال این هدف است چیست.
INVEST چیست ؟
برای نوشتن بهتر داستان کاربر بهتر است از اصول زیر استفاده کنیم
- مستقل باشند: تا جایی که ممکن است باید داستان های کاربر مستقل از یکدیگر باشند و یا در غیر این صورت وابستگی بین آیتم ها باید کمینه باشد تا بتوان براحتی به آنها امتیاز داد و اولویت بندی کرد و در آخر بتوان براحتی برنامه ریزی کرد.
- قابل مذاکره باشد: نباید داستان کاربر را بگونه ای نوشت که به تیم فنی دیکته کند که چگونه کار را انجام دهند باید قابل مذاکره باشد تا تیم نوآوری خود را از دست ندهد. درواقع کارگاه داستان کاربر بهترین مکان برای گفت و گو بین تیم فنی و مشتری می باشد تا دو طرف به درک دقیقی از کاری که قرار است انجام شود برسند. همانطور که می دانید همیشه تمامی داستان های کاربر را نمیتوان قابل مذاکره نوشت اما باید در بیشتر موارد این اصل را رعایت کرد.
- ارزشمند باشد: درواقع وقتی می خواهیم کاری انجام دهیم باید توجیه داشته باشد، به بیان دیگر داستان کاربر ویژگیی را ارائه می دهد که برای مشتری و یا کاربر و یا هر دو ارزشمند است. اما در برخی مواقع، مثلا وقتی بحث تکنیکال مطرح میشود، پیشنهاد می شود داستان را بگونه ای بنویسید که اهمیت کاری که قرار است انجام شود برای مشتری کاملا قابل درک باشد.
- قابل برآورد کردن باشد: داستان کاربر باید بگونه ای نوشته شود که تیم توسعه بتواند آن را برآورد کند، وقتی تیم توسعه نتواند داستان را بدرستی بیان کند مشکل می‌تواند ناشی از این باشد که تیم خواسته مشتری را بدرستی درک نکرده، یا داستان کاربر بشدت بزرگ است و یا تیم دانش کافی برای انجام کار را ندارد.
- کوچک باشد: وقی شروع به انجام داستان کاربر می‌کنیم باید دارای اندازه مناسب باشد. بصورت کلی می توان این گونه بیان کرد که داستان های کاربری که قرار است در اسپرینت جاری انجام شوند باید در صورت امکان کوچوکتر از سایز اسپرینت باشند اما اگر داستان کاربری طولانی است بدین معنی نیست که این داستان کاربر بدی است به عنوان مثال اگر داستان کاربری که می خواهیم در انتشار های بعدی به انجام آن بپردازیم اندازه آن بیش از حد بزرگ بود اشکالی ندارد چون ما هنوز به شناخت کامل از برنامه نرسیده ایم تا بتوانیم به درستی به اندازه مناسب بشکنیم.
- آزمون پذیر باشد: داستان ها باید بصورت دودویی (قبول یا رد) قابل آزمایش باشند یعنی یا همه آزمونها را پشت سر هم می گذاریم و قبول میشوند یا با رد حتی یک از آزمون ها، کلا رد می شوند. آزمون پذیری به معنای وجود معیار مناسبی برای پذیرش داستان است. چنین معیاری بر اساس شرایط رضایتمندی تعیین می شود و بیانگر جنبه تایید داستان کاربر می باشد. البته لزوما نیازی به آزمون همه داستان ها نداریم و آزمودن برخی از آنها نیز امکان پذیر نیست. به عنوان مثال داستان های کاربری که در سطح اپیک قرار دارند نیازی به آزمون‌پذیری ندارند چون اپیک ها مستقیما ساخته نمی شوند.
یکی از ویژگی های مهم داستان کاربر این است که محل خوبی برای بحث برای کسب دانش توسط تیم توسعه است به عنوان مثال می‌توان از منابع در نوشتن داستان کاربر استفاده نمود که به توجیه دلیل انجام کار برای تیم توسعه کمک شایانی می کند.
کارگاه داستان نویسی چیست ؟
هدف از این کار برگزاری طوفان ذهنی گروهی درباره ارزشهای درخواستی کسب‌وکار است. ایجاد داستانهایی که بیانگر کار مورد انتظار از محصول یا سرویس باشد، هدف دیگر این کارگاه است.
غالبا با حضور مالک محصول، تیم اسکرم، استاد اسکرام و دیگر ذینفعان داخلی و خارجی برگزار میگردد و مدت کارگاه بین چند ساعت تا چند روز می تواند باشد و به ندرت دیده شده که بیشتر از این باشد، لازم به یادآوری است که هدف کارگاه شناسایی زود هنگام مجموعه کامل و بی نقص از داستان های کاربر نیست. معمولا کارگاه ها بر موضوعی خاص تمرکز دارند. یکی از تمرین های خوب، برگزاری کارگاه های داستان نویسی براساس هر انتشار است.
نگاشت داستان
یک تکنیک کاربر‌محور بسیار جذاب است. برای ایجاد مجموعه ای از داستان های کاربر که در کارگاه داستان نویسی نیز مورد استفاده قرار می گیرید. براین ایده است که ایده های کلان و سطح بالای کاربر به مجموعه ای از کارها تبدیل می شود که خود آن کارها در سطح بعد به وظایف کوچکتری شکسته می شوند.
خلاصه بخش اول داستان کاربر
در بخش اول به معرفی داستان کاربر، ویژگی‌ها و مزایای استفاده از آن بصورت کاملا خلاصه پرداختیم. در توسعه مبتنی بر اسکرام، محل‌هایی برای نیازمندی ها ایجاد می شود که اقلام یک بک‌لاگ محصول نامیده میشود. اغلب اوقات این اقلام به شکل داستان کاربر بیان میشوند. حرکت داستان‌ها در فرایند اسکرام با تاکید ویژه‌ای بر استفاده از گفتگو به عنوان روشی برای تشریح جزئیات نیازمندی‌ها انجام میشود. در این فرایند از راهبرد تشریحی و مبتنی بر رویکرد«به موقع» برای تبدیل داستان‌های بزرگ و کلی به داستان‌های کوچک و تفصیلی استفاده میشود.
منابع:
