معیارهای پذیرش شفاف برای user story

0
12
how to write clear acceptance criteria

در یک جهان ایده آل، مردم با یک نگاه همدیگر را درک می کنند و هیچ چیز نمی تواند سردرگمی و سوتفاهم در بین آنها ایجاد کند. گرچه تصور یک دنیای ایده‌ال خوشایند است، اما باید با این حقیقت کنار بیاییم که دنیای واقعی ما با این تصویر خیالی از دنیای ایده‌آل تفاوت بسیار دارد. در دنیای واقعی ما باید راه هایی برای برقراری ارتباط شفاف جهت اشتراک ایده های خود بیابیم تا همسالان ما دچار سوتفاهم نشوند و برداشتی متفاوت از ذهنیت ما نکنند. در توسعه نرم افزار، معیارهای پذیرش(acceptance criteria) آن راه حلی است که به تعیین صحیح انتظارات مشتری از یک محصول کمک می‌کند. معیارهای برنامه ای مانند “من می‌خواهم برنامه من در میان اکثر افراد جامعه بسیار جذاب و محبوب باشد” واقعاً چیز زیادی به ما نمی گوید؛ بر عکس این حالت، معیارهای پذیرش باید به قدری شفاف باشند که ما سوتفاهم در برداشت مشتری و تیم توسعه از داستان کاربر را با مراجعه به آن‌ها از بین ببریم.

در این پست ما در مورد معیارهای پذیرش شفاف در روش های چابک (مانند اسکرام و کانبان) صحبت خواهیم کرد و چند نمونه از معیارهای پذیرش مدون را به شما ارائه می دهیم.


با استفاده از Scrum (دقیقاً مانند هر روش Agile دیگر)، ما با اصطلاحاتی مانند “داستان های کاربر” و “معیارهای پذیرش” کار می کنیم تا اطمینان حاصل کنیم که توضیحات روشنی در مورد استفاده کاربران نهایی از برنامه و اینکه تیم توسعه باید چه وظایفی را انجام دهد، بدست آورده‌ایم.

پیش‌تر در مطالبی دیگر آموختیم که user story چیست و چگونه user story بنویسیم. همچنین آموختیم که هدف از داستان های کاربران توضیح نقش کاربران در یک سیستم است. یعنی فعالیت های مورد نظر کاربران و آنچه که آنها قصد دارند با انجام آن(ها) داستان(های) کاربر را با موفقیت تکمیل نمایند. برای تیم های Agile، داستان های کاربر روش اصلی شناسایی نیازهای کاربر است.

همانطور که پیش‌تر نیز مطرح شد، در این پست بر روی معیارهای پذیرش تمرکز می‌کنیم. معیارهای پذیرش در واقع قوانین و شرایطی است که وقوع آن‌ها در نرم‌افزار، منجر به انجام موفقیت آمیز داستان کاربر خواهند شد.


تعریف معیارهای پذیرش

بنابراین چگونه می توان اطمینان حاصل کرد که داستان های کاربر به درستی تکمیل شده و مطابق با خواسته های مشتری است؟ اینجاست که معیارهای پذیرش وارد عمل می شود. معیارهای پذیرش لیستی از الزامات رسمی است که اطمینان حاصل می کند تمام داستان های کاربر کامل شده و تمام سناریوها در نظر گرفته شده اند. به زبان ساده ، معیارهای پذیرش شرایطی را نشان می دهد که در آن داستان کاربر برآورده می شود. معیارهای دقیقاً نوشته شده به تیم های توسعه کمک می کند تا از ابهام در مورد خواسته های مشتری جلوگیری کرده و از سوء ارتباط جلوگیری کنند.

نوشتن معیارهای پذیرش نه تنها برای استخراج چشم انداز یک محصول از دید مشتری، بلکه برای فرایند توسعه نیز مهم است. طبیعی است که افراد مختلف از زوایای مختلف یک مشکل را ببینند. معیارهای پذیرشی که واضح نوشته شده یک راه حل واحد برای عملکردی است که شما قصد اجرای آن را دارید.


معیارهای پذیرش برای چه استفاده می شود؟

برای تعیین مرزها. معیارهای پذیرش به تیم های توسعه کمک می کند تا مرزهای یک داستان کاربر را مشخص کنند. به عبارت دیگر ، معیارهای پذیرش به شما کمک می کنند زمانی که برنامه به صورت دلخواه(مطابق با معیارها) عمل می‌کند، انجام شدن داستان مربوطه را تأیید کنید، به این معنی که داستان کاربر کامل پیاده سازی شده است.
برای رسیدن به اتفاق نظر. داشتن معیارهای پذیرش، تیم توسعه را با مشتری هماهنگ می کند. تیم دقیقاً می داند چه شرایطی باید رعایت شود، همانطور که مشتری می داند چه انتظاری از برنامه دارد.
به عنوان پایه ای برای تست‌ها قرار بگیرند. آخرین و نه مهمترین سنگ بنای تست مثبت و منفی، معیارهای پذیرش است. این تست تعیین می‌کند که آیا سیستم مطابق انتظار کار می کند یا خیر.
برای امکان برنامه ریزی و برآورد دقیق. سناریوهای معیارهای پذیرش امکان تقسیم صحیح داستان های کاربر به وظایف را فراهم می کند، بنابراین داستان های کاربر به درستی برآورد و برنامه ریزی می شوند.


چه کسی معیارهای پذیرش را می نویسد و چه زمانی؟

مشتری یا تیم توسعه دهنده معیارهای پذیرش را می نویسد. به عنوان یک قاعده ، معیارهایی که توسط صاحب محصول (مشتری) نوشته شده است توسط یکی از اعضای تیم توسعه بررسی می شود تا اطمینان حاصل شود که معیارها به طور واضح مشخص شده اند و از نظر توسعه هیچ محدودیت فنی یا مغایرت ندارند. اگر صاحب محصول تجربه ای در زمینه تولید نرم افزار داشته باشد و از نحوه نوشتن مستندات پروژه آگاه باشد ، چنین جریانی راهی عالی برای همکاری است.

اگر ترجیح می دهید معیارهای پذیرش نوشتن را به تیم توسعه اختصاص دهید، یک تحلیلگر نیاز، مدیر پروژه یا یک متخصص کیفیت باید این کار را انجام دهد. زیرا هر یک از این افراد از تکنولوژی و امکان اجرای ویژگی‌ها اطلاع دارند.

به یاد داشته باشید که معیارهای پذیرش باید از قبل مشخص شود و هرگز نباید پس از شروع مرحله توسعه به تعیین آن‌ها پرداخت. بنابراین، تیم توسعه و مالک محصول باید در مورد حداقل محصولات قابل تحویل که شرایط مالک محصول را برآورده می کنند، توافق کنند.


چگونه معیارهای پذیرش شفاف بنویسیم؟

معیارهای پذیرش انواع مختلفی دارد. مشهورترین آنها قاعده گرا (به صورت لیست) و سناریو گرا (به صورت سناریوهایی است که هر معیار را نشان می دهد). نوع سناریو گرا در میان تیمهای Agile محبوب است زیرا از آنجا که به شما در برآوردن نیازها ، پیش بینی موارد استفاده مختلف و استفاده بیشتر از سناریوها برای آزمونهای قبولی دستی و خودکار کمک می کند.

الگوی معمول برای توصیف معیارهای پذیرش با استفاده از یک رویکرد سناریو محور، Given/When/Then است که از توسعه رفتار محور (BDD) گرفته شده است. از فرمت Given/When/Then برای نوشتن آزمون های قبولی استفاده می شود که اطمینان حاصل می کند همه شرایط مورد نیاز را برآورده می کند.

قالب Given/When/Then برای انسان‌ها مناسب است (از آنجا که به صورت آشنایی علت و معلولی نوشته شده است) و همچنین ابزار آزمایش خودکار مانند Cucumber و RSpec برای تست آن موجود است. به عنوان مثال، وقتی وب سایتی ایجاد می کنیم که دارای دو نوع کاربر است – کاربران وارد شده و میهمانان – احتمالاً معیارهای پذیرش زیر را برای داستان کاربری خواهیم نوشت که ویژگی ورود به سیستم را برای یک کاربر خارج شده تعریف می کند:

به عنوان یک کاربر خارج شده
می خواهم بتوانم به یک وب سایت وارد شوم
تا بتوانم مشخصات شخصی خود را بدست آورم

سناریو: کاربر سیستم با اطلاعات کاربری معتبر وارد سیستم می شود
“با توجه به اینکه من یک کاربر سیستم هستم و من در صفحه ورود به سیستم هستم(Given)
وقتی قسمت های “نام کاربری” و “رمز عبور” را با اطلاعات احراز هویت خود پر می کنم و من دکمه ورود به سیستم را کلیک می کنم(When)
سپس سیستم مرا وارد سیستم می کند(Then) ”

الگوی Given/When/Then به شما کمک می کند زمان مصرفی برای نوشتن موارد آزمایشی را کاهش دهید زیرا با این کار شما پیش تر رفتار سیستم را توصیف کرده‌اید. ما معیارهای پذیرش را با اول شخص “من” نوشتن ترجیح می دهیم زیرا این امر به ما کمک می کند تا از دید کاربر صحبت کنیم و نیازهای کاربر را در ذهن داشته باشیم.

در اینجا چند نکته وجود دارد که به شما کمک می کند معیارهای پذیرش شفاف و عالی بنویسید:

معیارهای خود را کاملاً مشخص نگه دارید تا هر یک از اعضای تیم پروژه ایده‌ای را که می خواهید انتقال دهید درک کند.
معیارها را واقع بینانه و قابل دستیابی نگه دارید. حداقل عملکردی را که می توانید ارائه دهید مشخص کنید و به آن پایبند باشید. از طرف دیگر، سعی نکنید همه جزئیات را توصیف کنید زیرا خطر بهم ریختگی backlog خود را دارید و زیر فشار کارهای کوچک زیادی دفن می شوید.
با همه ذینفعان هماهنگی کنید تا معیارهای پذیرش شما بر اساس اجماع باشد.
معیارهایی قابل اندازه گیری ایجاد کنید که به شما امکان می دهد زمان توسعه را به درستی تخمین بزنید تا بتوانید در محدوده بودجه و زمان باقی بمانید.
چک لیست‌هایی فراهم کنید که به شما امکان می دهد ببینید چه داستان های کاربر با معیارهای پذیرش پوشانده شده است.

همانطور که در تصویر زیر نیز مشاهده می‌شود، زمانی که معیارهای پذیرش شفاف باشند، زمان‌های کمتری برای بازبینی و تغییر محصول نیاز خواهد بود.

clear acceptance criteria vs unclear acceptance criteria


نمونه هایی از معیارهای پذیرش شفاف

در این بخش نگاهی خواهیم انداخت به نمونه هایی از معیارهای پذیرش نوشته شده برای ویژگی های مشترک موجود در اکثر وب سایت ها. ما داستانهای کاربر را از قبل تعریف خواهیم کرد زیرا معیارهای پذیرش پس از مشخص شدن همه قابلیتها از طریق داستانهای کاربر ، نوشته می شوند.

مثال اول

اولین داستان کاربر ما ویژگی جستجوی صفحه وب را توصیف می کند:

به عنوان یک کاربر وب سایت
می خواهم در صفحه وب جستجو کنم
تا بتوانم اطلاعات لازم را پیدا کنم

با توجه به الگوی Given/When/Then، معیارهای پذیرش به شرح زیر است:

سناریو: کاربر موردی را به نام خود جستجو می کند
با توجه به اینکه من در نقش کاربر ثبت نام شده یا مهمان هستم(Given)
وقتی صفحه “محصولات” را باز می کنم
و سیستم لیست تمام محصولات را به من نشان می دهد
و همچنین بخش “جستجو” را در گوشه سمت راست بالای صفحه نشان می دهد
چنانچه قسمت “جستجو” را با نام مورد موجود در لیست محصولات پر کنم
و روی دکمه “اعمال” کلیک کنم یا کلید Enter را از صفحه کلید فشار دهم(When)
سپس سیستم محصولات را در بخش نتایج جستجو با نام محصول مطابق با نام محصول وارد شده نشان می دهد
و سیستم تعداد نتایج جستجو را در بالای قسمت نتایج جستجو نشان می دهد(Then)”

مثال دوم

مثال بعدی معیارهای پذیرش فرم صفحه بازخورد را نشان می دهد. داستان کاربر به شرح زیر است:

به عنوان یک کاربر وب سایت
می خواهم بتوانم بازخورد ارسال کنم
به طوری که صاحبان وب سایت می توانند نظر یا نگرانی من را در هنگام به روزرسانی وب سایت در نظر بگیرند.

معیارهای پذیرش برای این قطعه از عملکرد عبارتند از:

سناریو: کاربر فرم بازخورد را با داده های معتبر ارسال می کند
با توجه به اینکه من در نقش یک کاربر وارد شده یا مهمان هستم(Given)
وقتی صفحه بازخورد را باز می کنم
و سیستم فرم ارسال بازخورد حاوی فیلدهای “ایمیل” ، “نام” و “نظر” را که الزامی هستند به من نشان می دهد.
وقتی فیلد “ایمیل” را با یک آدرس ایمیل معتبر پر می کنم
و فیلد “Name” را با نام خود پر می کنم
و همچنین فیلد “نظر” را با نظر دلخواه خودم پر می کنم
و روی دکمه “ارسال بازخورد” کلیک می کنم(When)؛
سپس سیستم نظر من را ارسال می کند
و سیستم پیامی با این متن که “شما با موفقیت بازخورد خود را ارسال کرده اید” را نشان می دهد
و در نهایت سیستم فیلدهای فرم بازخورد را پاک می کند.(Then) ”

جمع بندی نهایی

همانطور که مشاهده می کنید، نوشتن معیارهای پذیرش هم برای مشتریان و هم برای تیم های توسعه یک فعالیت برنده-برنده است: نه تنها به تیم کمک می کند دقیقاً بفهمد چه کاری باید انجام دهد، بلکه مشتری را در جریان روند توسعه قرار می دهد و به آنها اجازه می دهد تا بررسی کنند که نرم افزار توسعه یافته نیازهای واقعی کسب و کار را برآورده می کند یا خیر.

در انتها توصیه می‌شود که هیچ‌گاه اجازه ندهید داستان های کاربر و معیارهای پذیرش شما را بترسانند – زمانی که برای توصیف و مشخص کردن تمام ویژگی‌های محصول سرمایه گذاری می کنید در نهایت نتیجه می دهد و از این سرمایه‌گذاری قطعا بهره‌ی زیادی خواهید برد. معیارهای پذیرش به عنوان پایه ای برای موارد استفاده و موارد تست است که اطمینان حاصل می کند شما به اهداف تجاری خود رسیده اید و برنامه های بدون اشکال تولید می کنید.

موفق و پیروز باشید.

به این مطلب امتیاز بدهید

ارسال یک پاسخ

لطفا دیدگاه خود را وارد کنید!
لطفا نام خود را در اینجا وارد کنید