موبائل پروجیکٹس کے لیے تخمینہ — یہ کیا ہے، کاموں کی جانچ کے طریقے

تخمینہ کیا ہے؟

تخمینہ (انگریزی estimate سے — جانچ) کسی کام کو مکمل کرنے کے لیے درکار وقت یا محنت کی مقدار کی پیشین گوئی ہے۔ موبائل ڈویلپمنٹ میں، تخمینے گھنٹوں، دنوں، اسٹوری پوائنٹس یا مالی اصطلاحات میں ظاہر کیے جا سکتے ہیں۔ تخمینے کا مقصد درست پیشین گوئی نہیں، بلکہ فیصلہ سازی کے لیے غیر یقینی کو کم کرنا ہے۔

تخمینہ عہد سے کیسے مختلف ہے

تخمینہ غلطی کی گنجائش والی پیشین گوئی ہے۔ عہد کسی مخصوص تاریخ تک کام مکمل کرنے کا وعدہ ہے۔ فرق اہم ہے: تخمینہ کہتا ہے «ممکنہ طور پر 5 دن»، عہد کہتا ہے «ہم اسے 5 دنوں میں کریں گے»۔ مینیجرز اکثر ان تصورات کو گڈمڈ کر دیتے ہیں، تخمینہ کو غلطی کی گنجائش کے بغیر ڈیڈ لائن میں تبدیل کر دیتے ہیں۔

مواصلاتی آلے کے طور پر تخمینہ

تخمینہ کا عمل اس کے نتیجے سے کم اہم نہیں ہے۔ جب ٹیم کسی کام کے تخمینے پر بحث کرتی ہے، تو پوشیدہ ضروریات، انحصار اور خطرات سامنے آتے ہیں۔ چاہے حتمی عدد غلط ہو، بحث تمام شرکاء کو کام کی سمجھ دیتی ہے۔ اسی لیے اجتماعی تخمینہ کے طریقے (Planning Poker) انفرادی طریقوں سے زیادہ مؤثر ہیں۔

ڈویلپمنٹ میں تخمینہ لگانے کے طریقے

پروجیکٹ کے مختلف مراحل اور تفصیل کی سطحوں کے لیے کئی تخمینہ طریقے موجود ہیں۔ طریقے کا انتخاب دستیاب اعداد و شمار اور مطلوبہ درستگی پر منحصر ہے۔

Planning Poker

Planning Poker Agile میں تخمینہ کا سب سے مقبول طریقہ ہے۔ ہر ڈویلپر کو فبونیکی نمبروں (1، 2، 3، 5، 8، 13، 21) والے کارڈز کا ایک ڈیک ملتا ہے۔ کام پر بحث کرنے کے بعد، سب ایک ساتھ اپنا کارڈ دکھاتے ہیں۔ اگر تخمینے مختلف ہوں تو، کم سے کم اور زیادہ سے زیادہ تخمینہ والے ڈویلپر اپنی منطق بیان کرتے ہیں، پھر دوبارہ ووٹنگ ہوتی ہے۔ یہ طریقہ اختیار کے تعصب کو ختم کرتا ہے اور زیادہ درست تخمینہ دیتا ہے۔

T-Shirt sizing

T-Shirt sizing ٹی شرٹ کے سائز (XS، S، M، L، XL، XXL) کے مطابق ایک تخمینی تخمینہ ہے۔ یہ طریقہ بڑے کاموں (ایپک) کے فوری تخمینے کے لیے ابتدائی مراحل میں استعمال ہوتا ہے جب تفصیلات معلوم نہ ہوں۔ بعد میں، ایسے ہر کام کو ٹکڑوں میں تقسیم کیا جاتا ہے اور Planning Poker میں تخمینہ لگایا جاتا ہے۔ T-Shirt sizing فی کام 5-10 منٹ لیتا ہے، لیکن صرف ایک تقریبی پیمانہ فراہم کرتا ہے۔

تین نکاتی تخمینہ (PERT)

PERT تین تخمینے استعمال کرتا ہے: رجائیتی (O)، یاسیتی (P)، اور زیادہ تر ممکنہ (M)۔ حتمی تخمینہ فارمولے (O + 4M + P) / 6 سے لگایا جاتا ہے۔ یہ طریقہ غیر یقینی کو مدنظر رکھتا ہے اور ایک تخمینے سے زیادہ حقیقت پسندانہ نتیجہ دیتا ہے۔ PERT خاص طور پر زیادہ خطرات یا نئی ٹیکنالوجی والے کاموں کے لیے مفید ہے۔

تخمینے کی درستگی: توقعات بمقابلہ حقیقت

تخمینے کی درستگی پروجیکٹ کے مرحلے اور معلوم معلومات کی مقدار پر منحصر ہے۔ تخمینہ جتنا پہلے لگایا جاتا ہے، غلطی کی گنجائش اتنی ہی زیادہ ہوتی ہے — یہ معمول ہے اور منصوبہ بندی میں اسے مدنظر رکھنا چاہیے۔

غیر یقینی کا مخروط

غیر یقینی کا مخروط (Cone of Uncertainty) ایک ماڈل ہے جو بتاتا ہے کہ پروجیکٹ کے آگے بڑھنے کے ساتھ تخمینے کی غلطی کیسے کم ہوتی ہے۔ تصوراتی مرحلے میں، غلطی کی گنجائش 400% ہے (کام میں 1 سے 4 مہینے لگ سکتے ہیں)۔ اسپرنٹ کے مرحلے تک، یہ 20% (1-1.2 مہینے) ہوتی ہے۔ اس ماڈل کو سمجھنا ابتدائی مراحل میں درست تخمینے کا مطالبہ نہ کرنے میں مدد دیتا ہے۔

درستگی کو متاثر کرنے والے عوامل

• کام کی پیچیدگی — کیا یہ نئی ٹیکنالوجی ہے یا واقف؟ نامعلوم غلطی کی گنجائش کو 2-3 گنا بڑھا دیتا ہے۔
• کام کا سائز — چھوٹے کام (2 دن تک) بڑے کاموں سے زیادہ درست تخمینہ لگائے جاتے ہیں۔ ٹکڑوں میں تقسیم درستگی بہتر کرتی ہے۔
• ٹیم کا تجربہ — 6+ مہینوں سے ایک ساتھ کام کرنے والی ٹیم نئی ٹیم سے 30-50% زیادہ درست تخمینہ لگاتی ہے۔
• تاریخی اعداد و شمار — velocity میٹرکس اور سائیکلومیٹری اعداد و شمار پیشین گوئی کی درستگی بہتر کرتے ہیں۔

نسبتی بمقابلہ مطلق تخمینہ

نسبتی تخمینہ (اسٹوری پوائنٹس میں) مطلق تخمینہ (گھنٹوں میں) سے زیادہ درست ہے کیونکہ لوگ وقت کا تخمینہ لگانے کے بجائے کاموں کا موازنہ کرنے میں بہتر ہیں۔ «یہ کام اس سے دوگنا پیچیدہ ہے» «یہ کام 8 گھنٹے لے گا» سے زیادہ قابل اعتماد فیصلہ ہے۔ نسبتی تخمینے کسی مخصوص ڈویلپر پر منحصر نہیں ہوتے اور ذمہ دار تبدیل ہونے پر درستگی برقرار رکھتے ہیں۔

تخمینے کی درستگی کیسے بہتر بنائیں: بہترین طریقے

تخمینے کی درستگی کو منظم طریقہ کار، اجتماعی بحث اور ماضی کی غلطیوں کے تجزیے سے بہتر بنایا جا سکتا ہے۔ کئی ثابت شدہ طریقے ہیں۔

2-1 دنوں میں تقسیم

2 دن سے زیادہ کا تخمینہ لگایا گیا کوئی بھی کام ذیلی کاموں میں تقسیم کیا جانا چاہیے۔ اصول: اگر کسی کام کا 50% سے زیادہ درستگی سے تخمینہ نہیں لگایا جا سکتا، تو وہ بہت بڑا ہے۔ اسے ایسے مراحل میں تقسیم کریں جو سمجھ میں آتے ہوں اور قابل تخمینہ ہوں۔ تقسیم کے بعد، کل تخمینہ اکثر ابتدائی تخمینے سے 1.5-2 گنا بڑا ہوتا ہے۔

تاریخی اعداد و شمار اور میٹرکس

تخمینوں کی تاریخ رکھیں اور اصل محنت سے موازنہ کریں۔ مثال: «3 اسٹوری پوائنٹس پر تخمینہ لگائے گئے کام اوسطاً 4 دن لیتے ہیں، 2 نہیں»۔ پیشین گوئی کے لیے ٹیم کی velocity استعمال کریں: اگر ٹیم فی اسپرنٹ 20 اسٹوری پوائنٹس مکمل کرتی ہے، تو 30 کا منصوبہ نہ بنائیں۔ ماضی کے تخمینوں کی درستگی کا تجزیہ تخمینہ کی مہارت کے لیے بہترین تربیت ہے۔

لنگر اور انشانکن

لنگر ایک نفسیاتی اثر ہے جہاں پہلا بیان کردہ تخمینہ تمام شرکاء کو متاثر کرتا ہے۔ Planning Poker میں لنگر سے بچنے کے لیے، سب باری باری نہیں بلکہ ایک ساتھ اپنے کارڈ دکھاتے ہیں۔ انشانکن تخمینوں کا اصل نتائج سے باقاعدہ موازنہ ہے: 10-20 اسپرنٹ کے بعد، ٹیم فیڈ بیک کے ذریعے زیادہ درست تخمینہ لگانا سیکھتی ہے۔

خطرے کے مطابق ایڈجسٹ تخمینہ

ہر کام میں پوشیدہ خطرات ہوتے ہیں: ڈویلپر کی بیماری، API کے مسائل، ضروریات میں تبدیلی۔ اپنے تخمینے میں خطرے کے مطابق عنصر شامل کریں: زیادہ خطرہ والے کاموں کے لیے 1.5-2 کا ضارب، کم خطرہ کے لیے 1.1-1.2۔ کلائنٹ کو شفاف طریقے سے دکھائیں کہ کن خطرات کو مدنظر رکھا گیا ہے اور وہ وقت کے جدول کو کیسے متاثر کرتے ہیں۔

تخمینہ لگانے میں عام غلطیاں

تخمینہ کی غلطیاں زیادہ تر ٹیموں میں دہرائی جاتی ہیں، ان کی پختگی سے قطع نظر۔ ان غلطیوں کو جاننا ان کی اصلاح کا پہلا قدم ہے۔

رجائیتی تعصب

سب سے عام غلطی بہترین منظر نامے کے مطابق تخمینہ لگانا ہے: «اگر سب کچھ کامل ہو، تو ہم 3 دنوں میں کریں گے»۔ حقیقت میں، کچھ بھی کامل نہیں ہوتا: بگز، ضروریات کے بارے میں سوالات، منحصر کام۔ حل: رجائیتی کے بجائے زیادہ تر ممکنہ منظر نامے کے مطابق تخمینہ لگائیں۔ تغیر کو مدنظر رکھنے کے لیے PERT استعمال کریں۔

دباؤ میں تخمینہ

جب مینیجر کہتا ہے «ہمیں جمعہ تک چاہیے»، ڈویلپر لاشعوری طور پر تخمینہ کو اس ڈیڈ لائن کے مطابق ایڈجسٹ کرتا ہے۔ دباؤ میں تخمینہ ہمیشہ کم ہوتا ہے اور ڈیڈ لائن ضائع ہونے کا باعث بنتا ہے۔ حل: تخمینہ ڈیڈ لائن سے پہلے آنا چاہیے، نہ کہ اس کے برعکس۔ پہلے ٹیم تخمینہ لگائے، پھر فریقین وقت کے جدول پر متفق ہوں۔

پیچیدگی اور وقت میں الجھن

کام کی پیچیدگی (کتنا سوچنا ہے) اور وقت (کتنا کرنا ہے) مختلف میٹرکس ہیں۔ ایک کام سادہ لیکن وقت طلب ہو سکتا ہے (10 اسکرینز بنانا) یا پیچیدہ لیکن تیز (لیگسی کوڈ میں بگ ڈھونڈنا)۔ اسٹوری پوائنٹس عام طور پر پیچیدگی کا تخمینہ لگاتے ہیں، جبکہ وقت ٹیم کی velocity سے اخذ کیا جاتا ہے۔

سیاق و سباق کی تبدیلی کو نظر انداز کرنا

ایک ڈویلپر ایک کام پر لگاتار 8 گھنٹے کام نہیں کرتا: میٹنگز، کوڈ ریویو، ساتھیوں کی مدد اور انتظامی کام کام کے وقت کا 30-50% استعمال کرتے ہیں۔ سیاق و سباق کی تبدیلی کو تخمینے میں مدنظر رکھنا چاہیے: حقیقت میں، ایک ڈویلپر دن میں 3-4 گھنٹے کوڈ لکھتا ہے۔