تحلیل نیازمندیها با کمک سه یار !

نیازمندیهای ناقص

یکی از مشکلاتی که در جلسات برنامه ریزی اسکرام با آن مواجه می شویم، وجود بک لاگ هایی است که ظاهرا به اندازه کافی دقیق نیستند. منظور از دقیق نبودن آنها این است که از نظر تیم توسعه، جنبه هایی از نیازمندی به صورت شفاف مشخص نیست. مثلا برخی از قواعد کسب و کار تعیین نشده، محدودیتها و تاثیراتی که تغییر درخواستی ممکن است بر سایر بخشهای سیستم بگذارد در نظر گرفته نشده است و …

از طرفی فرستادن توسعه دهنده ها به سمت مشتری برای کسب نیازمندیها نیز کار اشتباهی است. تعامل و دریافت نیازمندیهای واقعی یک مشتری نیازمند مجموعه مهارتهایی است که از عهده یک تحلیل گر بر می آید. پس راه حل چیست؟

BDD

اما BDD برای این مسئله یک پیشنهاد دارد. قبل از آن اما خود BDD چیست؟

(Behavior-Driven-Development) BDD مجموعه ای از ابزارها و تکنیک هاست که تلاش می کند، نیازمندیهای واقعی مشتری را درک کرده و از طریق اتصال نیازمندیها به تست خودکار سیستم  (Automated Test)، تضمین کند که یک سیستم درست، که به درستی هم کار می کند (Software Right & Right Software) ایجاد شود .برای آشنایی بیشتر با BDD به این مقاله رجوع نمایید.

یکی از مفاهیم و تکنیک هایی که این فرایند پیشنهاد می دهد، مفهوم شناسایی نیازمندیها به صورت تعاملی (Collaborative) است. BDD اعتقاد دارد که نیازمندیها جنبه های مختلفی دارد که برای شناخت صحیح آن باید دیدگاه های مختلف در کنار هم قرار گیرد. BDD پیشنهاد می دهد بعد از شناسایی اولیه نیازمندیهای مشتری توسط تحلیل گر کسب و کار، لازم است تا این نیازمندیها در یک جلسه تعاملی بررسی و تکمیل شده و اصطلاحا نیازمندیها “Ready for Dev” شده و سپس به تیم توسعه منتقل شود.

سه یار!

اما شرکت کنندگان در این جلسه چه کسانی هستند. این جلسه باید حداقل از سه نقش تشکیل شود. تحلیل گر کسب، آزمون گر (Tester) و توسعه دهنده (Developer)

سه یار

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

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

شما ممکن است این را هم بپسندید

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *