داستان‌های کاربر، همان نیازمندی‌های سامانه نرم‌افزاری است که درصدد تولید آن هستید. نیازمندی‌ها ممکن است به هر شکلی توصیف شوند، هر چیزی ممکن است یک نیازمندی برداشت شود و شمارا به بی‌راهه بکشاند. در ادامه به توصیف خصوصیات داستان کاربر بدردنخور پرداخته‌شده است.
۱) داستان‌های کاربر که فقط یک پوشش هستند.
درصورتی‌که داستان کاربر فقط شامل یک تکلیف فنی (Technical Task) باشد! این موضوع نشان می‌دهد که شما از آن تنها به‌عنوان پوشش استفاده کرده‌اید. من نمی‌دانم چرا، ولی بسیاری از افراد تصور می‌کنند که می‌توانند از الگوی داستان کاربر برای هر چیزی استفاده کنند. یک داستان کاربر یک «پیمان یا نقطه شروع گفتگو» است. در مواقعی که چیزی برای بحث و گفتگو وجود ندارد و یک تکلیف فنی ساده در اختیاردارید لطفاً یک داستان ساختگی به دور آن نکشید. در بسیاری از موارد که این اتفاق در شرف وقوع است نشانه ایست که شاید داستان شما بیش‌ازاندازه کوچک است.
۲) داستان‌های کاربر که در کمتر از یک روز تکمیل می‌شوند.
اگر شما بیش از ۴۰ داستان کاربر در بکلاگتان دارید، برای جلب مشارکت گروه، کاری دشوار پیش رو خواهید داشت. افرادی ممکن است در مقابل این حرف بگویند: «صبر کن ببینم! مگر هرچقدر داستان‌های کاربر کوچک‌تری داشته باشیم، بهتر نیست؟». کاملاً درست است، مشکلی در اصل موضوع وجود ندارد ولی نه اینکه هر داستان یک تکلیف فنی یک‌روزه باشد. در این‌گونه مواقع، این داستان‌های کاربر قطعاً به داستان‌های کاربر بزرگ‌تری تعلق دارند و به‌خودی‌خود و ابتدابه‌ساکن باعقل جور در‌نمی‌آیند. همیشه مراقب باشید که داستان‌های کاربر شما یک عملکرد (Functionality) تازه را دنبال کنند، اگر این‌گونه نیست یک جای کار می‌لنگد.
۳) داستان‌های کاربر که توصیف‌کننده یک قابلیت (Feature) نیستند.
این مورد خیلی به موردهای ۱ و ۲ مرتبط است، زیرا این موارد اغلب باهم پیش می‌آیند. هر زمان که داستان کاربر موردنظرتان بجای آنکه یک عملکرد تازه را توصیف کند، یک تکلیف فنی را برای توسعه‌دهنده تشریح کرد، قطعاً یک جای کار مشکل دارد. دیده‌شده است که مالکان محصول داستان‌های کاربری ایجاد کرده‌اند که چیزی شبیه این را توصیف کرده است: «تهیه مستندات الف»، «ایجاد آزمون‌های پذیرش ب». در این مواقع من از گروه می‌خواهم که آن‌ها را در لیست تعاریف تکمیل شد (Definition Of Done) داستان‌های کاربر قرار دهند. اگر نمی‌خواهید آن‌ها را در لیست معیارهایتان قرار دهید، یک تکلیف فنی ویژه به آن‌ها اختصاص داده و ساختار و قالب داستان را بر هم نزنید.
۴) برای توصیف همه‌چیز از داستان کاربر استفاده کرده‌اید.
این فوق‌العاده است که تصمیم گرفته‌اید از داستان‌های کاربر برای ایجاد بکلاگ تان استفاده کنید. موضوع این است که شما در استفاده از قالب‌های گوناگون آزاد خواهید بود. قاعده صریحی در اسکرام یا متدهای دیگر چابک، وجود ندارد که شمارا مجبور به استفاده تمام و کمال از داستان کاربر کند.مجبور نیستید از این قالب برای توصیف هر آنچه نیاز مشتری خود می‌خوانید استفاده کنید. در خیلی از مواقع انجام این کار عقلانی هم به نظر نمی‌رسد به‌عنوان‌مثال وقتی‌که می‌خواهید نیازمندی‌های غیر کارکردی (Non-functional Requirement) را توصیف کنید؛ بجای ایجاد یک داستان مجزا، آن‌ها را در بخش شاخص‌های پذیرشِ (Acceptance Criteria) داستان‌های کاربر دیگر لحاظ کنید. اگر به تعداد بیشتری از داستان‌های کاربر مرتبط هستند، یک منظومه داستان (Epic) ایجاد کرده و در آن قرارشان دهید. ولی لطفاً از قالب داستان کاربر برای هر آنچه نیاز مشتری خود می‌خوانید استفاده نکنید!
۵) کاربر یا راوی داستان خود را گم‌کرده‌اید.
آیا تابه‌حال داستان کاربری به این شکل نوشته‌اید: «به‌عنوان مدیر پروژه می‌خواهم که . . .»، «به‌عنوان مدیر محصول می‌خواهم که . . .»، «به‌عنوان متخصص آزمون می‌خواهم که . . .»؟ خب در این حالت مشخص است که کاربر واقعی سامانه یا راوی داستان خود را گم‌کرده‌اید. مدیر محصول یا مدیر پروژه، کاربر نهایی نرم‌افزار نخواهد بود. مجدد شروع و از خود سؤال کنید که چه کسی از این امکان یا قابلیت استفاده خواهد کرد و داستان را از دریچه دید او در ذهن خود بازنویسی کنید. روش ممکن دیگر شخصیت‌پردازی عمل‌گرا (Pragmatic Persona) است. درهرصورت همواره کاربر خود را در کانون توجه قرار دهید.
منبع این یادداشت مقاله ای از Marc Löffler است.
دیدگاهتان را بنویسید