کار با User Story ها

در بخش آموزش پیاده سازی SCRUM قسمتی با عنوان نحوه ساخت Product Backlog وجود دارد که در این پست می خواهیم با نحوه جمع آوری User Stories  برای ساخت Product Backlog  آشنا بشویم .

User Story چیست ؟

عبارتست از توضیح کوتاهی در مورد عملیاتی که مد نظر کاربر و یا مشتری (صاحب محصول – Product Owner) می باشد .

User Stories  منبع و در واقع تغذیه کننده اصلی Product Backlog ما هستند . بهترین حالت ساخت این Backlog در حالت Just-in-Time است یعنی همان زمانی که با صاحب محصول (Product Owner) در حال بحث روی محصول می باشید .

شروع کار با User Stories دانه درشت

در اول کار شروع به یادداشت توضیحات بسیار کوتاه در مورد USs در Product Backlog نمایید.  شاید هر یک از این توضیحات بسیار بزرگ تر از آن باشد که بتوان در یک Release بگنجد ولی شما باید  توضیح مختصر عملکرد این نیاز مشتری را یادداشت نمایید . برای وضوح بیشتر مسئله , بگذارید سیستم RMS “سیستم مدیریت پرتاب موشک ” تشریح نماییم .

برای مثال یکی از USs های کاربر به صورت زیر می باشد :

– کاربر بتواند با یک کلیک موشک را پرتاب نماید .

بلی درست است . این کار به همین سادگی نیست که کاربر فکر می کند . شاید شما در ذهنتان باشد باید فلان کارها انجام بشود و باید فلان داده از فلان xml بارگذاری بشود و … . این عملیات ها را در ذهن خود نگه بدارید و به توضیح مختصر کفایت نمایید .

به چندین مثال دیگر توجه نمایید :

– کاربر بتواند با یک کلیک موشک را پرتاب نماید .

– کاربر بتواند پرتاب موشک را کنسل نماید .

– مدیر سیستم بتواند لیست موشک های هر روز را داشته باشد .

– مدیر سیستم بتواند سیستم را به صورت خودکار برای انجام عملیات پرتاب موشک در آخر هفته تنظیم بکند .

( و موارد زیر برای یک سیستم موشکی نیاز می باشد ,  خودتان به کاربر پیشنهاد می دهید )

– لاگ کردن عملکرد هر کاربر سیستم در فایل لاگ

– گرفتن تایید در هنگام پرتاب و کنسل موشک

شکستن نیاز ها به بخش های کوچکتر

ما باید هر موردی که در بالا نوشتیم به بخش های کوچک تر بشکنیم . بدلیل اینکه برآورد هزینه و زمان یک مورد کوچکتر بسیار راحتر و امکان پذیر تر نسبت به یک مورد بسیار بزرگ می باشد . مثلا مورد – کاربر بتواند با یک کلیک موشک را پرتاب نماید – را می توان به موارد زیر شکست :

– کاربر بتواند محل اصابت موشک را انتخاب نماید .

– کاربر بتواند با یک کلیک موشک را پرتاب نماید .

– کاربر بتواند در حین پرواز محل اصابت موشک را عوض نماید .

– کاربر بواند در حین پرواز موشک را منفجر نماید .

– کاربر بتواند موشک را در حالت Pause قرار دهد .

و…

اگر به موارد بالا دقت نمایید ,  متوجه می شوید که این موارد نزدیک تر برای پیاده سازی هستند .  این کار باید تا زمان تبدیل هریک از موارد به یک ویژگی انجام شود . بعد از طی این مراحل یک سند از نیازمندی های سیستم که کاملا واضح و بدون ابهام می باشد را در دست خواهید داشت .

Acceptance tests (ارزیابی های مشتری)
بسیار مهم است که ما برگه تست هر یک از موارد User Stories را در دست داشته باشیم و بعدا بتوانیم سیستم را با عناوین نیاز نیز تست نماییم. این برگه نیز باید با حضور مشتری (Product Owner)  انجام گیرد . برای مثال برگه تست مورد – کاربر بتواند با یک کلیک موشک را پرتاب نماید- به صورت زیر می باشد :

– کاربر بتواند با یک کلیک موشک را پرتاب نماید :

۱- تست اینکه بعد از کلیک بر روی پرتاب ,  موشک در عرض ۱۰ ثانیه پرتاب خواهد شد .

۲- تست اینکه کاربر حتی بعد از کلیک بر روی دکمه پرتاب ,  بتواند موشک را به حالت مثلا “حرکت دو برابر سرعت” یا “فرود به نرمی” .

۳- تست اینکه در هنگام پرتاب موشک های هسته ای دیالوگی مانند اینکه “آیا واقعا می خواهید تمام انسان ها را از بین ببرید ؟” نشان داده شود .

توجه داشته باشید که در یک بار  آن هم در اول پروژه تنظیم Product Backlog به صورت ۱۰۰% امکان پذیر نمی باشد  , همیشه در طی پیاده سازی وِیژگی ها با مشتری مشورت نمایید و به توسعه گران اجازه بدهید تا با مشتری به تبادل نظر بپردازند و حق اعمال نظر را هم از مشتری در مورد تمامی بخش ها سلب ننمایید.

یاشیاسیز