در حال حاضر اسکرام به یکی از متدهای پرطرفدار برای مدیریت پروژه های توسعه نرم افزار تبدیل شده است. طی این مقاله و چند مقاله آتی سعی میکنم که با مفاهیم اصلی این متد آشنا بشیم. بیشترین منبع مورد استفاده برای من در این سری مقالات کتاب Scrum and xp from the trenches online و اندکی تجربیات کاری شخصی است.
اولین مطبی که شاید به جرات بشه گفت که قلب اسکرام است، Product back log است. اگر به طور خلاصه بخواهیم در این مورد بحث کنیم Product back log لیست مرتبی از خواسته ها یا قابلیت هایی است که مالک نرم افزار از ما توقع دارد که انجام شود و با زبان خودش و کاملا غیرفنی برای ما شرح میدهد. به هر یک از این خواسته ها ما Story یا backlog items میگوییم.
برای ایجاد یک جدول کاربردی برای Product backlog ما به فیلد های زیر نیاز داریم.
1-ID یا شناسه: این فیلد فقط یک فیلد عددی است که به کمک آن ما Story مورد نظر را در هر موقعیت مکانی که باشد شناسایی میکنیم.
2: نام: نام این story است که با نگاه کردن به آن هدف از این Story را متوجه میشویم. برای مثال "مشاهده لیست تراکنشها". با اولین نگاه به این نام میتوانیم از ماهیت و هدف این Story باخبر شویم.
3: اهمیت: این فیلد توسط مالک برنامه پر میشود. بعد از اینکه لیست را کامل کردیم به مالک نرم افزار میگوییم اهمیت هر یک از Story ها را برای ما معلوم کند. هر کدام که عدد بزرگتری داشت یعنی درجه اهمیت بیشتری دارد. مثلا Story با اهمیت 100 مهم تر از اهمیت 20 است. دقت کنید که عدد بزرگتر فقط نشان دهنده اهمیت بیشتر است و نه نسبت اهمیت. در مثال قبل Story با اهمیت 100مهم تر از 20 است. اما این به این معنا نیست که این Story پنج برابر مهم تر است.
4: زمان تکمیل: بعد از اینکه اهمیت کار معلوم شد، وظیفه تیم توسعه است که برای هرکاری زمانی را تعیین کند که آن کار در آن زمان معین به اتمام برسد. زمان تکمیل میانگین زمانهایی است که اعضای تیم بیان میکنند، نه بهترین زمان نه بدترین زمان. البته به این نکته توجه کنید که نظر افراد با تجربه تیم اهمیت بیشتری در این میانگین دارد. کاری که من انجام میدهم ایجاد یک میانگین وزن دار است که به هر یک از اعضای تیم وزنی میدهم که اهمیت نظرات فرد در توسعه را بیان میکند.
5: نحوه نمایش: در این فیلد توضیح میدهیم که روز دمو چگونه این Story باید دمو داده شود و چه مراحلی باید طی شود. مثلا برای نمونه بالا "ابتدا به سایت وارد میشوم و بعد وارد قسمت لیست تراکنشهای شخصی میشوم. در این قسمت امکانات جستجو و مرتب سازی را نمایش میدهم."
6: توضیحات: در این فیلد میتوانید هر توضیحی که در باره این Story لازم است و در سایر فیلدها جایی برای آن وجود نداشت را مشاهده کنید.
این سند یک سند عمومی و پرکاربرد است، هم در اختیار مدیر تیم، هم اعضای تیم و هم مالک پروژه میباشد. به همین دلیل برای ایجاد آن بهتر است از ابزار عمومی استفاده شود و در قسمت عمومی قرار داده شود که همگان بتوانند به آن دسترسی داشته باشند و به محض تغییر آن، از آخرین تغییرات با خبر شوند. برای پیاده سازی این سند میتوانید به سادگی از اکسل استفاده نمایید.
فیلد هایی که در بالا نام بردیم فیلد های اساسی و اصلی بودند، اما ممکن است بنا بر نیاز از فیلد های زیر نیز جهت ایجاد این جدول استفاده کنید
1- دسته بندی: ممکن است فیلدی با عنوان دسته بندی برای مرتب سازی و جدا سازی منطقی Story ها از یکدیگر ایجاد کنید.
2- ابزار ها: در فیلد دیگری میتوانید ابزار هایی که در تولید این Story دخالت دارند را لیست کنید تا با نگاه کردن به آن منابع مورد نیاز را شناسایی کنید. مثلا دیتابیس و اچ تی ام ال
3- درخواست کننده: در حین توسعه نرم افزار ما با فردی به عنوان مالک برنامه در تماس دائم هستیم، اما این فرد میتواند بیان کند که کدام قسمت یا بخش درخواست این Story را داشته اند.
دقت کنید که در پیاده سازی Product backlog تنها Story های مورد نیاز مالک باید لیست شود نه مطالب فنی. مثلا "ایجاد اندیس رو دیتابیس برای بالا رفتن سرعت جستجو" ممکن است از سخنان مالک برنامه و به دلیل داشتن دیدگاه فنی وی باشد، اما این یک نکته فنی است که اصلا نباید در بحث Product backlog شرکت کند.
همین دیگه! تموم شد.
اولین مطبی که شاید به جرات بشه گفت که قلب اسکرام است، Product back log است. اگر به طور خلاصه بخواهیم در این مورد بحث کنیم Product back log لیست مرتبی از خواسته ها یا قابلیت هایی است که مالک نرم افزار از ما توقع دارد که انجام شود و با زبان خودش و کاملا غیرفنی برای ما شرح میدهد. به هر یک از این خواسته ها ما Story یا backlog items میگوییم.
برای ایجاد یک جدول کاربردی برای Product backlog ما به فیلد های زیر نیاز داریم.
1-ID یا شناسه: این فیلد فقط یک فیلد عددی است که به کمک آن ما Story مورد نظر را در هر موقعیت مکانی که باشد شناسایی میکنیم.
2: نام: نام این story است که با نگاه کردن به آن هدف از این Story را متوجه میشویم. برای مثال "مشاهده لیست تراکنشها". با اولین نگاه به این نام میتوانیم از ماهیت و هدف این Story باخبر شویم.
3: اهمیت: این فیلد توسط مالک برنامه پر میشود. بعد از اینکه لیست را کامل کردیم به مالک نرم افزار میگوییم اهمیت هر یک از Story ها را برای ما معلوم کند. هر کدام که عدد بزرگتری داشت یعنی درجه اهمیت بیشتری دارد. مثلا Story با اهمیت 100 مهم تر از اهمیت 20 است. دقت کنید که عدد بزرگتر فقط نشان دهنده اهمیت بیشتر است و نه نسبت اهمیت. در مثال قبل Story با اهمیت 100مهم تر از 20 است. اما این به این معنا نیست که این Story پنج برابر مهم تر است.
4: زمان تکمیل: بعد از اینکه اهمیت کار معلوم شد، وظیفه تیم توسعه است که برای هرکاری زمانی را تعیین کند که آن کار در آن زمان معین به اتمام برسد. زمان تکمیل میانگین زمانهایی است که اعضای تیم بیان میکنند، نه بهترین زمان نه بدترین زمان. البته به این نکته توجه کنید که نظر افراد با تجربه تیم اهمیت بیشتری در این میانگین دارد. کاری که من انجام میدهم ایجاد یک میانگین وزن دار است که به هر یک از اعضای تیم وزنی میدهم که اهمیت نظرات فرد در توسعه را بیان میکند.
5: نحوه نمایش: در این فیلد توضیح میدهیم که روز دمو چگونه این Story باید دمو داده شود و چه مراحلی باید طی شود. مثلا برای نمونه بالا "ابتدا به سایت وارد میشوم و بعد وارد قسمت لیست تراکنشهای شخصی میشوم. در این قسمت امکانات جستجو و مرتب سازی را نمایش میدهم."
6: توضیحات: در این فیلد میتوانید هر توضیحی که در باره این Story لازم است و در سایر فیلدها جایی برای آن وجود نداشت را مشاهده کنید.
این سند یک سند عمومی و پرکاربرد است، هم در اختیار مدیر تیم، هم اعضای تیم و هم مالک پروژه میباشد. به همین دلیل برای ایجاد آن بهتر است از ابزار عمومی استفاده شود و در قسمت عمومی قرار داده شود که همگان بتوانند به آن دسترسی داشته باشند و به محض تغییر آن، از آخرین تغییرات با خبر شوند. برای پیاده سازی این سند میتوانید به سادگی از اکسل استفاده نمایید.
فیلد هایی که در بالا نام بردیم فیلد های اساسی و اصلی بودند، اما ممکن است بنا بر نیاز از فیلد های زیر نیز جهت ایجاد این جدول استفاده کنید
1- دسته بندی: ممکن است فیلدی با عنوان دسته بندی برای مرتب سازی و جدا سازی منطقی Story ها از یکدیگر ایجاد کنید.
2- ابزار ها: در فیلد دیگری میتوانید ابزار هایی که در تولید این Story دخالت دارند را لیست کنید تا با نگاه کردن به آن منابع مورد نیاز را شناسایی کنید. مثلا دیتابیس و اچ تی ام ال
3- درخواست کننده: در حین توسعه نرم افزار ما با فردی به عنوان مالک برنامه در تماس دائم هستیم، اما این فرد میتواند بیان کند که کدام قسمت یا بخش درخواست این Story را داشته اند.
دقت کنید که در پیاده سازی Product backlog تنها Story های مورد نیاز مالک باید لیست شود نه مطالب فنی. مثلا "ایجاد اندیس رو دیتابیس برای بالا رفتن سرعت جستجو" ممکن است از سخنان مالک برنامه و به دلیل داشتن دیدگاه فنی وی باشد، اما این یک نکته فنی است که اصلا نباید در بحث Product backlog شرکت کند.
همین دیگه! تموم شد.
0 نظرات:
ارسال یک نظر