بایگانی

نوشته های برچسب زده شده ‘تخمين نرم افزار’

planning poker

میخواهید مجموعه فروش محصولات خود را برای سال جدید تخمین بزنید، برای این تخمین به سراغ چه کسانی می روید؟ کارشناسان خبره بازار، کارمندان شرکت خود، مشتریان و یا…. می خواهید سایز و بزرگی یک پروژه، یا مدت زمانیکه برای پیاده سازی قسمتی از نرم افزار را نیاز است تخمین بزنید، به سراغ چه کسانی می روید؟

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

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

بعد از ایام عید، پیش بینی های هر دو گروه مورد بازبینی قرار گرفت. گروه کارشناسان ۹۵ درصد فروش واقعی را تخمین زده بودند در حالیکه گروه کارمندان ۹۹٫۹ درصد فروش واقعی را تخمین زده بودند. اما چگونه ممکن است که یک گروه از کارمندان به گروهی از کارشناسان خبره غلبه کنند؟

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

آیا می توانیم از روش مشابه بالا برای تخمین زدن اندازه کارها در پروژه های نرم افزاری استفاده کنیم یا نه؟ پاسخ بله است. در متدلوژهای Agile ما تکنیکی به نام planning poker برای تخمین زدن داریم که تقریبا مشابه روش بالا می باشد. در این تکنیک به جای اینکه فقط مدیران کار تخمین را انجام بدهند، کل تیم یعنی مدیران، تحلیلگران، معمارها، مدیران پایگاه داده و …. با هم اینکار را نجام می دهند.

در این روش ما مجموعه ای از کارت ها داریم، که بر روی هر کدام از آنها عددی نوشته شده است. این اعداد در اکثر موارد سری فیبوناچی یا یک سری مانند سری مقابل ۰,۱/۲,۱,۲,۳,۵,۸,۱۳,۲۰,۴۰,۱۰۰ می باشد.

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

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