قانون وبر و خطای تخمین زمان؛ چرا اسکرام از اعداد فیبوناچی به جای ساعت استفاده می‌کند؟

در سال ۱۸۳۴، ارنست هاینریش وبر، فیزیولوژیست آلمانی، مجموعه‌ای از وزنه‌ها را به دست افراد داد تا ببیند یک بار چقدر باید تغییر کند تا انسان متوجه این دگرگونی شود. نتیجه مشخص بود: توانایی ما در تشخیص تغییر وزن مطلق نیست، بلکه کاملاً نسبی و درصدی است.[1]

اگر وزنه‌ای یک‌کیلوگرمی دست بگیرید، اضافه شدن یک کیلوگرم دیگر بلافاصله احساس می‌شود، چون بار ۱۰۰ درصد افزایش یافته است. اما اگر وزنه اولیه ۲۰ کیلوگرم باشد، اضافه شدن همان یک کیلوگرم ابداً به چشم نمی‌آید.[2]

میزان اضافه بار در هر دو حالت دقیقاً یک کیلوگرم است. با این حال، مغز در حالت دوم این تغییر را فقط یک افزایش ۵ درصدی می‌بیند که بسیار پایین‌تر از آستانه حساسیت حسی ما است.[2]

این محدودیت زیستی «قانون وبر» نام گرفت؛ اصلی بنیادین در علم روان‌فیزیک. طبق این قانون، «کمترین تفاوت محسوس» در هر محرکی—چه نور باشد، چه صدا یا وزن—همواره یک نسبت ثابت از اندازه اولیه محرک است.[1]

معمای برآورد در مهندسی نرم‌افزار

حدود ۱۷۰ سال بعد، صنعت نرم‌افزار دقیقاً به همین محدودیت زیستی برخورد. جیمز گرنینگ، مهندس نرم‌افزار، در سال ۲۰۰۲ یک بازی برآورد دسته‌جمعی به نام «پلنینگ پوکر» (Planning Poker) ابداع کرد تا تیم‌ها راحت‌تر حجم کارهای پیش رو را پیش‌بینی کنند.[3]

هدف گرنینگ حذف جلسات فرسایشی برآورد زمانی و جایگزینی آن با سیستمی تیمی و سریع بود. او کارت‌هایی با اعداد خاص طراحی کرد تا اعضای تیم همزمان روی پیچیدگی یک تسک رأی دهند.[3]

وقتی مایک کوهن در کتاب سال ۲۰۰۵ خود، «تخمین و برنامه‌ریزی چابک»، این شیوه را جا انداخت، استفاده از دنباله فیبوناچی روی کارت‌ها تثبیت شد: اعداد ۱، ۲، ۳، ۵، ۸، ۱۳ و ۲۱.[3]

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

راهکار دنباله فیبوناچی

این پیشرفت ریاضی نقصی اساسی در سازوکار ذهن را دور می‌زند. وقتی برنامه‌نویسان تلاش می‌کنند پروژه‌های بزرگ را با ساعت‌های خطی تخمین بزنند، به دام «توهم دقت» می‌افتند.[5]

توسعه‌دهنده‌ای ممکن است بحث کند که انتقال دیتابیس ۸۰ ساعت طول می‌کشد یا ۸۵ ساعت. طبق قانون وبر، این تفاوت ۶ درصدی از نظر ادراکی اصلاً قابل تفکیک نیست و بحث روی آن اتلاف وقت است.[2]

استفاده اجباری از دنباله فیبوناچی در برآورد چابک، شیوه کار را با ظرفیت‌های شناختی انسان سازگار می‌کند. وقتی حجم کار از حدی فراتر می‌رود، ذهن تنها در صورتی تفاوت دو تسک را می‌فهمد که این تفاوت چشمگیر باشد.[5]

کوهن صراحتاً این رویکرد را به قانون وبر پیوند زد و یادآور شد که بعد از عدد ۲، هر گام در دنباله فیبوناچی تقریباً نمایانگر یک پرش ۶۰ درصدی نسبت به مقدار قبلی است.[2]

پیوند روان‌فیزیک و توسعه نرم‌افزار

اگر یک تیم تفاوت ۶۰ درصدی حجم را بین تسک‌های کوچک خوب درک می‌کند، بر اساس قانون وبر می‌تواند همان مقایسه نسبی را در تسک‌های عظیم معماری نیز به کار ببندد.[2][5]

فاصله تصاعدی بین اعداد، اعضا را به بحث‌های سازنده وا می‌دارد. وقتی فردی عدد ۵ و دیگری عدد ۸ را رو می‌کند، این پرش ۶۰ درصدی نشان‌دهنده اختلاف نظر واقعی روی پیچیدگی کار است.

پلتفرم چابک Kollabe توضیح می‌دهد: «وقتی دو توسعه‌دهنده در مقیاس فیبوناچی اختلاف نظر دارند، مسئله بسیار مهم است. این شکاف نشان می‌دهد یکی از آن‌ها مسیر را هموار و دیگری سرشار از پیچیدگی پنهان می‌بیند.»

برای جلوگیری از سوگیری لنگرانداختن (پذیرش ناخودآگاه اولین عددی که مطرح می‌شود)، پلنینگ پوکر حکم می‌کند همه همزمان کارت بکشند. سپس کمترین و بیشترین برآورد، دلایلشان را برای جمع توضیح می‌دهند.

کشف اختلاف‌نظرهای پنهان

هدف میانگین گرفتن نیست، بلکه کشف ریسک‌های ناشناخته است. تبدیل عدد ۳ و ۱۳ به میانگین ۸، فقط اختلاف نظر و ابهام کار را پنهان می‌کند بدون آنکه آن را رفع کند.

استوری پوینت (Story Point) ترکیبی از سه چیز است: حجم کار، پیچیدگی فنی و میزان عدم قطعیت. تسکی با ۱۳ پوینت فقط خط کد بیشتری نسبت به تسک ۳ پوینتی ندارد؛ بلکه بسیار غیرقابل پیش‌بینی‌تر است.

چون ریسک با حجم کار بالا می‌رود، کوهن اعداد پایانی دنباله را برای تیم‌هایش دستکاری کرد. او ۲۱، ۳۴ و ۵۵ را کنار گذاشت و به‌جای آن‌ها از ۲۰، ۴۰ و ۱۰۰ استفاده کرد.[2]

دلیل این کار ساده بود: عددی مانند ۳۴ توهمی از دقت ریاضی ایجاد می‌کند که اصلاً در تولید نرم‌افزارهای حجیم واقعیت ندارد. عدد رندی مثل ۴۰ به ذینفع پیام می‌دهد که این فقط یک بازه تقریبی و کلان است.[2][5]

اصلاح دنباله برای تسک‌های سنگین

این دنباله تعدیل‌شده روی مزیت اصلی تخمین نسبی تمرکز دارد. تیم اصلاً نیازی ندارد بداند یک فیچر چند ساعت زمان می‌برد؛ کافی است بداند سختی آن تقریباً دو برابر فیچری است که هفته قبل تحویل داده شد.[4]

کوهن در کتاب خود نوشت: «تجربه به من نشان داده که تخمین بر مبنای زمان، اغلب دشوارتر از تخمین نسبی با استوری پوینت است؛ زیرا انسان‌ها در تخمین زدن بر اساس ساعت بسیار ناتوانند.»[4]

با کنار گذاشتن مقیاس ساعتی، تیم‌های چابک دست از تقلا علیه سیم‌کشی مغز خود برمی‌دارند. دیگر لازم نیست تظاهر کنند متوجه تفاوت بین یک تسک ۵۰ ساعته با تسکی ۵۲ ساعته می‌شوند.[5]

در عوض، به مهارتی تکیه می‌کنند که تکامل در ذهن انسان نهادینه کرده است: مقایسه همزمان دو شیء و تشخیص اینکه کدام‌یک سنگین‌تر است.[2][5]

آزمایش‌های وبر در قرن نوزدهم ثابت کرد قضاوت حسی ما نسبی است. امروزه، همین ویژگی فیزیولوژیک شیوه برنامه‌ریزی میلیون‌ها توسعه‌دهنده نرم‌افزار را تنظیم می‌کند؛ نشانه‌ای از اینکه رفتار انسانی همپای فناوری دگرگون نشده است.[1][5]