مفاهیم اساسی user story
در این پست می‌خواهیم بدانیم که چگونه user story بنویسیم. پیش‌تر در مورد این که user story چیست و چرا اهمیت دارد توضیح داده‌ایم. داستان کاربر روشی سبک برای ثبت سریع “who” و “what” و “why” موردِ نیازِ محصول است. به زبان ساده‌تر، داستان های کاربر ایده های مورد نیازی است که بیانگر آن چیزی است که کاربران نیاز دارند. داستان های کاربر مختصر است و هر عنصر آن اغلب حاوی کمتر از ۱۰ یا ۱۵ کلمه است. داستان های کاربر در واقع لیست “کارهایی هستند که به شما کمک می کنند مراحل مسیر پروژه را تعیین کنید. آنها به شما اطمینان می دهند که روند شما و همچنین محصول بدست آمده، نیازهای مورد انتظار کاربران شما را برآورده می کند.
داستان کاربر بصورت تدریجی و در سه مرحله تعریف می شود:
- شرح مختصر نیاز
- مکالمه هایی که هنگام backlog grooming و iteration planning برای قطعی کردن جزئیات اتفاق می افتد
- تست هایی که پایان رضایت بخش داستان را تایید می کنند
البته این مراحل به عنوان ۳C نیز شناخته می شوند(Card و Conversation و Confirmation) که بعدا در این راهنما در مورد آنها نیز بیشتر صحبت خواهیم کرد.
داستان های کاربر – INVEST
مخفف INVEST به شما کمک می کند تا مجموعه ای از معیارهای پذیرفته شده یا چک لیست برای ارزیابی کیفیت داستان کاربر را به خاطر بسپارید. اگر داستان نتواند یکی از این معیارها را برآورده کند، تیم ممکن است بخواهد آن را دوباره واژه سازی کند، یا حتی یک بازنویسی را در نظر بگیرد (که اغلب به معنی پاره شدن فیزیکی کارت داستان قدیمی و نوشتن کارت جدید است).
یک داستان کاربر خوب باید INVEST باشد
Independent (مستقل): داستان کاربر باید به گونه ای باشد که بتواند بدون وابستگی به داستانی دیگر نقل شود.
Negotiable (قابل مذاکره): فقط اصل نیاز کاربر را مورد توجه قرار دهید و فضای گفتگو را باز نگهدارید. داستان کاربر نباید مانند قرارداد نوشته شود.
Valuable (ارزشمند): ارزش را به کاربر نهایی برساند.
Estimable (قابل تخمین): داستان های کاربر باید قابل تخمین باشد، بنابراین می توان آن را به درستی اولویت بندی کرد و در sprint قرار داد.
Small (کوچک): داستان کاربر قسمت کوچکی از کار است که باید این امکان وجود داشته باشد تا توسعه‌ی آن در حدود ۳ تا ۴ روز به پایان برسد.
Testable (قابل آزمایش): داستان کاربر باید از طریق معیارهای مقبولیت(acceptance criteria) تایید شود.
تاریخچه‌ی داستان های کاربر
مفهوم داستان کاربر اولین بار در کتاب “توضیح برنامه نویسی افراطی” اثر “کنت بک” ذکر شد. در این کتاب داستان کاربر اینگونه تعریف شده است که متنی بدون ساختار است که کاملاً مشابه use case است اما با ین تفاوت که محدودیت اندازه دارد.
ران جفریس در سال ۲۰۰۱ مفاهیم ۳C را معرفی کرد: کارت ، مکالمه ، تایید
سال ۲۰۰۳ چک لیست INVEST برای ارزیابی سریع داستانهای کاربر در مقاله‌ای توسط بیل ویک نوشته شد که همچنین مخفف اختصار SMART (خاص، قابل اندازه گیری، قابل دستیابی، مربوط، زمان بندی شده) را برای task های حاصل از تجزیه فنی داستانهای کاربر مورد استفاده مجدد قرار داد.
۲۰۰۴: مخفف INVEST از جمله تکنیک‌های توصیه شده در “استفاده از داستانهای کاربر” توسط مایک کوه معرفی گردید.
چگونه user story بنویسیم
هنگام شروع به نوشتن داستانهای کاربر، یک الگوی ساده می تواند به شما اطمینان دهد که شما سهواً شروع به نوشتن کارهای فنی نمی کنید. به الگوی ساده‌ی زیر توجه کنید:
الگوی داستان کاربر
همانطور که پیش‌تر نیز مطرح شد، داستان های کاربر فقط عناصر اساسی یک نیاز را دربر می‌گیرند. این عناصر عبارتند از:
- برای چه کسانی است؟ (who)
- چه انتظاری از سیستم دارد؟ (what)
- چرا مهم است (اختیاری؟)؟ (why)
این یک قالب ساده از داستان کاربر است که توسط ۷۰٪ از تمرین کنندگان استفاده می شود. به مثالی از جمله‌بندی داستان کاربر که تحت الگوی فوق نوشته شده دقت کنید:
نقش( role) – کاربر باید یک انسان واقعی باشد که با سیستم تعامل داشته باشد.
تا حد ممکن خاص نگر باشید، تیم توسعه یک کاربر نیست!
عمل( action) – رفتار سیستم باید به عنوان یک عمل نوشته شود.
معمولاً برای هر استوری، نوع کاربر منحصر به فردی وجود دارد
“سیستم” ضمنی است و در داستان صریحا نام سیستم بکار نمی‌رود.
برای تعریف داستان کاربر از صدای فعال به جای صدای منفعل استفاده کنید (“مثلا من می توانم مطلع شوم”)
مزایا( benefit) – منافع باید نتیجه ای در دنیای واقعی باشد که non-functional باشد یا از سیستم خارج باشد.
بسیاری از داستان ها ممکن است منافع مشترکی داشته باشند.
این منافع ممکن است برای سایر کاربران یا مشتریان باشد، نه فقط برای کاربر مورد هدف در داستان.
یادداشت:
داستان های کاربر به زبان روزمره نوشته می شوند و هدف خاصی را توصیف می کنند (what) از دیدگاه یک فرد (who) همراه با دلیل (why) که فرد آن را می خواهد.
در توسعه نرم افزا ، هدف اغلب یک ویژگی محصول جدید است، فرد نوعی کاربر نهایی است و دلیل آن منفعتی است که کاربر در ویژگی محصول هدف قرار می دهد.
مثالهایی از داستان کاربر:
من به عنوان [مشتری] ، [ویژگی سبد خرید] را می خواهم تا [بتوانم به راحتی وسایل را بصورت آنلاین خریداری کنم].
من به عنوان [مدیر] می خواهم [گزارشی تهیه کنم] تا [بفهمم کدام بخش ها به منابع بیشتری احتیاج دارند].
به عنوان [مشتری] ، می خواهم [هنگام رسیدن کالا پیامکی دریافت کنم] تا [بلافاصله بتوانم آن را تحویل بگیرم]
موفق و پیروز باشید.