مدیریت پروژه در حوزه IT
 
قالب وبلاگ
نويسندگان
پيوندهاي روزانه

شاید یکی از مشکل ترین کارها برای اعضاء تیم تخمین زدن زمان مورد نیاز برای انجام کارهای محول شده و در واقع برآورد حجم آنها باشد. در کل تیم (بعنوان یک کلیت) دو جا مجبور است که حجم کارها را تخمین بزند یا تخمین خود را اصلاح کند:

۱- در طی جلسه برنامه ریزی دوره جدید Sprint Planning Meeting = SPM

۲- قبل از برگزاری جلسه بازبینی دوره Sprint Review Meeting = SRM

 

در جلسه SPM ٬ تیم مجبور است حجم کارها را تخمین بزند چون باید بر اساس آن٬ مدت sprint و تعداد نفرات کار از Product Owner بگیرد و در واقع آنها  Sprint Backlog را براساس حجم کار نیازمندی ها پر می کنند.

در جلسه SRMُ ٬ تیم با اصلاح تخمین هایش و اعلام آنها به Product Owner  به وی کمک می کند تا وقت بیشتری در خلال sprint برای افزودن موارد یا تغییر آنها در Product Backlog داشته باشد.


شاید یکی از مشکل ترین کارها برای اعضاء تیم تخمین زدن زمان مورد نیاز برای انجام کارهای محول شده و در واقع برآورد حجم آنها باشد. در کل تیم (بعنوان یک کلیت) دو جا مجبور است که حجم کارها را تخمین بزند یا تخمین خود را اصلاح کند:

۱- در طی جلسه برنامه ریزی دوره جدید Sprint Planning Meeting = SPM

۲- قبل از برگزاری جلسه بازبینی دوره Sprint Review Meeting = SRM

 

در جلسه SPM ٬ تیم مجبور است حجم کارها را تخمین بزند چون باید بر اساس آن٬ مدت sprint و تعداد نفرات کار از Product Owner بگیرد و در واقع آنها  Sprint Backlog را براساس حجم کار نیازمندی ها پر می کنند.

در جلسه SRMُ ٬ تیم با اصلاح تخمین هایش و اعلام آنها به Product Owner  به وی کمک می کند تا وقت بیشتری در خلال sprint برای افزودن موارد یا تغییر آنها در Product Backlog داشته باشد.

 

واحد های اندازه گیری حجم کار (Units of Complexity)

برای اندازه گیری حجم کار در مدیریت پروژه ها معمولاْ سه واحد زیر را در نظر می گیرند:

 

- Size Category

- Story Points

- Work days

 

در ادامه در مورد هر کدام از این واحد ها صحبت می کنیم

۱- Size Category: ساده ترین روش برای برآورد حجم کار لازم برای افزودن یک ویژگی یا قابلیت به سیستم استفاده از کلماتی مانند: کوچک٬ متوسط٬ بزرگ  و خیلی بزرگ برای توصیف حجم کار لازمه برای آنهاست. البته لازمه استفاده از این دسته بندی این است که همه افراد درگیر دید یکسانی راجع به اطلاق این کلمات برای توصیف حجم کار لازمه فعالیت ها داشته باشند در غیر اینصورت احتمالاْ یکی از آنها بعضی از پیچیدگی ها کار را  بیشتر از بقیه دیده است.

۲- Story Points: در این روش به موارد مشخص شده در Product Backlog یک امتیاز (Point) نسبت داده می شود. که مشخص کنند سطح نسبی پیچیدگی آن است. اینجا هم باز باید دید یکسان بین افراد وجود داشته باشد. مثلاْ در این روش اگر ویژگی A  دو امتیاز داشته باشد و ویژگی B چهار امتیاز در اینصورت ویژگی B دو برابر بیشتر از ویژگی A طول خواهد کشید.

خاصیت این روش این است که تخمین زمان انجام پروژه را راحت تر می کند. در اینجا تعداد کل امتیاز ویژگی هایی که طی یک sprint تکمیل می شوند سرعت تیم (Velocity of the team) را مشخص می کند. بدست آوردن سرعت تیم برای خود تیم هم مفید است چون اعضاء تیم می توانند بر اساس آن بفهمند که چه مقدار کار را برای sprint بعدی می توانند قبول کنند.

۳ - Work days: این روش از قبل هم مرسوم بوده و تحت عنوان نفر- ساعت مطرح می شده. در اینجا پذیرنده کار عنوان می کند که مثلاْ این کار ۳ نفر ساعت وقت می گیرد. البته این نوع ارزش گذاری بر روی حجم کار ها می تواند بشدت گمراه کنند باشد. چون اولاْ بر اساس قابلیت های اعضاء فعلی تیم مطرح می شود و ثانیاْ امکان دارد باعث شود که کارفرما فکر کند با افزودن نیروی کار جدید کار سریعتر انجام می شود. یعنی به عنوان مثال اگر کار ۳ نفر ساعت باشد و این کار توسط یک برنامه نویس در ۳ ساعت انجام شود دلیلی وجود ندارد که اگر ما تعداد برنامه نویس ها را ۳ نفر کنیم این کار در یک ساعت انجام شود. وقتی می گوییم این کار ۶ نفر ساعت وقت می گیرد و تیم مان هم دو نفر بیشتر نیست یعنی اینکه این دو نفر در سه ساعت این کار را انجام خواهد داد و این خیلی اشتباه است که فکر کنیم با افزودن برنامه نویس سوم اینکار در دو ساعت انجام خواهد شد! (ولو اینکه برنامه نویس اضافه شده در قد و قوارهٔ دو برنامه نویس قبلی باشد). در واقع تخمین بر اساس این واحد نیازمند درک خوبی از کار محوله و قابلیت های تیم است٬ بنابراین با دقت از آن استفاده کنید.

 

روش های تخمین حجم کار

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

 

روش بعدی ایجاد Work Breakdown Structure (اختصاراْ WBS) است. در اینجا کارها را آنقدر می شکنیم تا بجایی برسیم که بتوانیم در مورد خورده کارها تخمین درستی بزنیم و بعد با جمع تخمین خورده کارها می توانیم تخمین نسبتاْ خوبی از حجم کار لازم برای افزودن ویژگی مورد انتظار به سیستم بدست آوریم. این روش درواقع یک روش درختی است و از گذشته در تخمین زمان فعالیت های مختلف پروژه ها استفاده می شده. فقط اینجا باید احتیاط کنیم که زیاد در شکستن کارها عمیق نشویم چون در متدولوژی Agile سعی بر سریع انجام شدن کارهاست.

 

اصلاح تخمین ها

بعضی اوقات بعلت هایی مثل تغییر اعضاء تیم٬ تغییر شرایط کارکردن آنها و نظایر آنها مجبور خواهیم شد که در برآورد حجم کارها باقی مانده تجدید نظر کنیم. بهتر است در مورد هر کدام از این عوامل یک Drag Factor داشته باشیم. Drag Factor یا هزینه اضافی معمولاْ به درصد بیان می شود بعنوان مثال می گوییم اگر یکی از اعضاء تیم بخواهد از خانه اش و از راه دور با تیم کار کند ۲۰ درصد هزینه کار افزایش می یابد و در واقع Drag Factor اینجا ۲۰ درصد است. تعین Drag Factor ها کاری ذهنی و ابتکاری است ولی مقدار آنها باید در مستندات اسکرام ذکر شود.

 

منبع: http://scrumdevelopment.blogfa.com/post-8.aspx

[ دوشنبه ٢٥ فروردین ،۱۳٩۳ ] [ ۱٠:٤٧ ‎ق.ظ ] [ لیلا آذری ]
.: Weblog Themes By WeblogSkin :.
درباره وبلاگ

کارشناس ارشد معماری سیستم های کامپیوتری - عضو انجمن مدیریت پروژه ایران - بیش از 8 سال سابقه کار در زمینه مدیریت پروژه IT - تحلیل - ساخت داشبوردهای مدیریتی با Tableau و ...
صفحات ديگر
امکانات وب