اپنی ڈیڈ لائن کو پورا کریں: وہ طریقے جو ڈویلپر کوششوں کا اندازہ لگانے کے لیے استعمال کرتے ہیں۔

سب کو سلام! تھیوری کی ایک بہت بڑی مقدار ہے جو آپ کو سافٹ ویئر ڈویلپمنٹ میں شروع کرنے کے لیے جاننے کی ضرورت ہے۔ کچھ ماہرین (مثال کے طور پر، بیک اینڈ ڈویلپر جو جاوا اور دوسری زبانیں استعمال کرتے ہیں) اس کے بارے میں زیادہ جانتے ہیں، جبکہ دوسرے (مثال کے طور پر، فرنٹ اینڈ ڈویلپر جو JavaScript اور React Native استعمال کرتے ہیں) تھوڑا کم جانتے ہیں۔ اس نے کہا، دونوں گروہوں کے پاس نہ صرف تکنیکی، بلکہ "تنظیمی" علم کا ایک بڑا ادارہ ہونا چاہیے۔ یہ "تنظیمی" علم فرنٹ اینڈ اور بیک اینڈ ڈویلپرز کے لیے اوورلیپ کا ایک شعبہ ہے۔ آج میں اس غیر تکنیکی، تنظیمی علم کے ایک پہلو پر بات کرنا چاہتا ہوں۔ آج ہم کوششوں کے تخمینے کے بارے میں بات کریں گے ۔ چونکہ مجھے صرف Agile طریقہ کار (جسے سب سے زیادہ مقبول سمجھا جاتا ہے) استعمال کرنے کا تجربہ ہے، خاص طور پر Scrum فریم ورک، میں Scrum کے تناظر میں کوششوں کے تخمینے پر غور کروں گا ۔ بالکل شروع میں، میں یہ کہوں گا کہ کوشش کا اندازہ لگانا مشکل ہے۔ میرے لیے، یہ ایک ڈویلپر کے طور پر میری ملازمت کے سب سے مشکل/ناخوشگوار پہلوؤں میں سے ایک ہے۔ غور کرنے کے لیے بہت سے مختلف عوامل ہیں جو کسی کام کے لیے درکار کوشش کے آپ کے اندازے کو متاثر کر سکتے ہیں۔ مزید برآں، مستقبل کے ترقیاتی منصوبے آپ کے اندازوں پر مبنی ہوں گے۔

اگر آپ غلط تخمینہ فراہم کرتے ہیں تو کیا ہوگا؟

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

وقت کا اندازہ کیسے لگایا جائے۔

ایک اصول کے طور پر، تخمینہ گھنٹوں یا کہانی کے پوائنٹس میں بنایا جاتا ہے۔ میری ذاتی ترجیح کہانی کے پوائنٹس کا استعمال کرتے ہوئے تخمینہ لگانے کا عمل کرنا ہے ۔ ٹھوس جسمانی اشیاء کے بارے میں غلطی کرنا مشکل ہے، لیکن کہانی کے نکات کچھ زیادہ ہی تجریدی ہیں۔ سافٹ ویئر ڈویلپمنٹ ٹیمیں عام طور پر وقت کی مقدار کے طور پر تخمینہ فراہم کرتی ہیں: گھنٹے، دن، ہفتے، مہینے۔ یہ وقت کے تخمینے بنیادی طور پر ذاتی تجربے، اندازہ لگانے، اور/یا وجدان پر مبنی ہیں۔ اس معاملے میں، ڈویلپرز صرف کام کو دیکھتے ہیں اور اپنے مفروضے کا اظہار کرتے ہیں کہ اس میں انہیں کتنا وقت لگے گا۔ نتیجے کے طور پر، یہ اندازے بہت کم ہی درست ہوتے ہیں، کیونکہ بہت سارے عوامل ہیں جو کام کی مدت کو متاثر کر سکتے ہیں۔ یہی وجہ ہے کہ بہت سی ٹیمیں جو چست طریقہ کار استعمال کرتی ہیں وہ بھی کہانی کے پوائنٹس کا استعمال کرتی ہیں۔ آئیے اندر غوطہ لگائیں!

کہانی کے پوائنٹس کیا ہیں؟

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

• آپ غلط وقت کے تخمینے سے بچ سکتے ہیں۔
• وقت کی اکائیوں میں لگائے گئے تخمینوں کے برعکس، کہانی کے نکات آپ کو اوور ہیڈ اخراجات کا حساب دینے دیتے ہیں: ٹیم کے اراکین اور گاہک کے درمیان رابطے، ٹیم کے مختلف مباحثے اور منصوبہ بندی کی سرگرمیاں، نیز غیر متوقع حالات۔
• ہر ٹیم مختلف پیمانوں کا استعمال کرتے ہوئے اپنے کام کا تخمینہ لگائے گی، جس کا مطلب ہے کہ ان کی صلاحیت (پوائنٹس میں ماپی گئی) مختلف ہوگی۔
• ہر سٹوری پوائنٹ کو تفویض کرنے کے لیے ایک پیمانے کی وضاحت کر کے، آپ بغیر کسی تنازعہ کے جلدی پوائنٹس مختص کر سکتے ہیں۔

کہانی کے پوائنٹس کا استعمال کیسے نہ کریں۔

بدقسمتی سے، کہانی کے پوائنٹس کا اکثر غلط استعمال کیا جاتا ہے۔ کہانی کے نکات گمراہ کن ہو سکتے ہیں جب انہیں لوگوں کا اندازہ لگانے، تفصیلی ڈیڈ لائنز اور وسائل کی وضاحت کرنے کے لیے استعمال کیا جاتا ہے، اور جب ان سے کارکردگی کی پیمائش کے لیے غلطی کی جاتی ہے۔ اس کے بجائے، ٹیموں کو ان کا استعمال ہر کام کی گنجائش/پیچیدگی کو سمجھنے اور ترجیحات طے کرنے کے لیے کرنا چاہیے۔ شاید یہ کہ جن حصوں کو زیادہ مشکل سمجھا جاتا ہے ان سے پہلے نمٹا جانا چاہیے، تاکہ وہ سپرنٹ کے اختتام سے پہلے کیے جا سکیں ، ممکنہ طور پر آسان کاموں کو بعد میں منتقل کر دیں۔ میں آپ کو یاد دلاتا ہوں کہ اسکرم طریقہ کار کے تناظر میں سپرنٹ کیا ہے : اس مدت کی لمبائی کا تعین اس وقت ہوتا ہے جب ترقی شروع ہوتی ہے اور ٹیم اور گاہک کے درمیان اس پر اتفاق ہوتا ہے۔ یہ دو ہفتے یا ایک ماہ، یا کوئی اور مدت ہو سکتی ہے۔ ایک اصول کے طور پر، کوششوں کے تخمینے ہر سپرنٹ کے شروع میں لگائے جاتے ہیں تاکہ اس کام کی منصوبہ بندی کی جا سکے جو سپرنٹ کے اختتام تک مکمل ہو سکتا ہے، جب مکمل شدہ کام گاہک کو پہنچا دیا جاتا ہے۔ ڈیمو آپ کو پروڈکٹ تیار کرنے میں آپ کی پیشرفت دیکھنے، گاہک سے فیڈ بیک حاصل کرنے، اور گاہک کے وژن کے مطابق پروجیکٹ کی رفتار کو ایڈجسٹ کرنے میں مدد کرتا ہے۔ لیکن ہم تھوڑا سا ہچکچاتے ہیں۔ آئیے تخمینوں پر واپس آتے ہیں۔ یہ بہت ساپیکش ہوگا کہ صرف ایک ڈویلپر تمام کاموں کے لیے تخمینہ فراہم کرے۔ لہذا یہ عمل عام طور پر ایک ٹیم کی کوشش ہے. کچھ ایسی تکنیکیں ہیں جو ٹیمیں تخمینہ لگانے کے لیے استعمال کر سکتی ہیں۔ آج ہم سب سے مشہور تکنیک دیکھیں گے: سکرم پوکر ۔ اس تکنیک کے لیے ایک مینیجر کی ضرورت ہے جو سکرم پوکر کے لیے بطور ناظم کام کرے گا ۔ یہ کوئی ایسا شخص ہو سکتا ہے جو اسکرم ماسٹر ہو یا ممکنہ طور پر PM ہو ۔

سکرم پوکر کیا ہے؟

سکرم پوکر ، یا پلاننگ پوکر، تخمینہ لگانے کی ایک تکنیک ہے جو کسی معاہدے تک پہنچنے پر مبنی ہے۔ یہ بنیادی طور پر آگے کام کی پیچیدگی یا سافٹ ویئر ڈویلپمنٹ کے کاموں کے نسبتا سائز کا اندازہ لگانے کے لیے استعمال ہوتا ہے۔ میں فوراً کہوں گا کہ سکرم پوکر ایک عام سافٹ ویئر ڈویلپمنٹ پریکٹس ہے، اور آپ کو یہ جاننے کی ضرورت ہے کہ یہ سب کیا ہے۔ اس میں عام طور پر ایک ایپ یا ویب سائٹ شامل ہوتی ہے تاکہ ٹیم کے تعاون سے کسی خاص کام کے لیے تخمینہ تیار کیا جا سکے۔ یہ کیسے ہوتا ہے؟ ٹیم بیک لاگ (ایک نیا کام، کچھ فعالیت) سے کچھ لیتی ہے اور اس سے وابستہ ممکنہ نقصانات اور دیگر باریکیوں پر مختصراً بحث کرتی ہے۔ پھر ہر شریک ایک نمبر کے ساتھ ایک کارڈ کا انتخاب کرتا ہے جو ان کی پیچیدگی کے تخمینے کی عکاسی کرتا ہے۔ اوہ، ایک اور چیز، یہ تخمینہ لگاتے وقت، ہم عام نمبروں کے بجائے فبونیکی ترتیب میں اعداد استعمال کرتے ہیں۔ اسکرم پوکر میں فبونیکی نمبرز مقبول ہیں ، کیونکہ ان کے درمیان تیزی سے بڑا فاصلہ ہے (اہرام کی سطح سے ملتا جلتا ہے)۔ کچھ کام انتہائی پیچیدہ ہوں گے، اور ہم کہانی کے بہت کم پوائنٹس سے دور نہیں ہو پائیں گے۔ کچھ غیر معمولی کارڈز ہیں جن کے مندرجہ ذیل معنی ہیں:

اختتامی پوائنٹس کی نامعلوم تعداد

لامحدود طویل کام

ایک وقفے کی ضرورت

کم عام اندازے کے طریقے استعمال ہوتے ہیں:

• ٹی شرٹ کے سائز — ایس، ایم، ایل، ایکس ایل
• کتے کی نسلیں — چیہواہوا، پگ، ڈچ شنڈ، بلڈوگ، وغیرہ

اس کے بعد ٹیم ایک ہی کام کے لیے مختلف ڈویلپرز کی جانب سے دیے گئے تخمینوں کا موازنہ کرتی ہے۔ اگر وہ متفق ہیں، تو بہت اچھا! اگر نہیں، تو مختلف اندازوں کی وجوہات (دلائل) پر بحث کی ضرورت ہے۔ اس کے بعد، ٹیم مل کر ایک ایسا تخمینہ بنانے کے لیے کام کرتی ہے جسے ہر کوئی قبول کرتا ہے، کم و بیش۔ تو پھر کیوں پوکر کو سافٹ ویئر کے سنجیدہ منصوبوں کی منصوبہ بندی کے لیے بھی استعمال کیا جاتا ہے؟ آپ کو تسلیم کرنا پڑے گا کہ یہ عجیب بات ہے۔ حقیقت یہ ہے کہ اس قسم کی گیمیفیکیشن ٹیم کے اراکین کو آزادانہ طور پر سوچنے کی ترغیب دیتی ہے، انہیں اپنے ساتھیوں کے ساتھ ہی اپنے تخمینے ظاہر کرنے کی دعوت دیتی ہے۔ یہ، بدلے میں، ایسی صورت حال پیدا کرنے سے گریز کرتا ہے جہاں ٹیم کے کچھ ارکان دوسروں کی رائے پر منحصر ہوں۔ اگر یہ اس طرح نہیں کیا گیا تھا، تو کم تجربہ کار ڈویلپر ٹیم کے زیادہ تجربہ کار اراکین کے فراہم کردہ تخمینوں کو دیکھیں گے اور ان پر توجہ مرکوز کریں گے، اور اس سے ان کے اپنے تخمینے کم کارآمد ہوں گے۔ لیکن ایک ہی وقت میں تخمینہ دکھانا یہ بنیادی طور پر ناممکن بنا دیتا ہے۔ Atlassian منصوبہ بندی کے عمل میں استعمال کرنے کے لیے ایک سکرم پوکر ایپ پیش کرتا ہے۔

کوشش کے تخمینہ کی مثال

فرض کریں کہ آپ کی ٹیم نے تخمینوں کے لیے کہانی کے پوائنٹس تفویض کرنے کے لیے درج ذیل پیمانہ قائم کیا ہے: ہر کام کے لیے سکرم پوکر کھیلا جاتا ہے، اور آپ مندرجہ ذیل تخمینہ فراہم کرتے ہیں:

• آپ نے پہلے کبھی بھی ایسی فعالیت کو نافذ نہیں کیا ہے: +3
• فعالیت اوسط سائز کی ہے: +2
• عمل درآمد انتہائی پیچیدہ ہوگا: +3
• فعالیت کے لیے تحریری ٹیسٹ انتہائی پیچیدہ ہوں گے: +3

ہر جزو کو شامل کرنے سے، آپ کو کل 11 اسٹوری پوائنٹس ملتے ہیں، لیکن ایسا کوئی کارڈ نہیں ہے، اس لیے آپ 13 تجویز کرتے ہیں۔ ایک ساتھی کام کے لیے درج ذیل تخمینہ پیش کرتا ہے:

• اس نے پہلے بھی اسی طرح کے کام کے ساتھ کام کیا ہے: +1
• فعالیت اوسط سائز کی ہے: +2
• عمل درآمد اوسط پیچیدگی کا ہوگا: +2
• فعالیت کے لیے تحریری ٹیسٹ اوسط پیچیدگی کے ہوں گے: +2

اس کا انٹرمیڈیٹ نتیجہ 7 اسٹوری پوائنٹس ہے، لیکن وہ نمبر فبونیکی سیریز میں موجود نہیں ہے، اس لیے وہ سب سے زیادہ تخمینی نمبر کے ساتھ کارڈ جمع کراتا ہے — 8۔ ٹیم کے دیگر اراکین بھی اپنے ساپیکش خیالات کی بنیاد پر اپنے تخمینے لگاتے ہیں۔ پھر ہر کوئی اپنے کارڈ دکھاتا ہے اور آپ کو معلوم ہوتا ہے کہ آپ کے تقریباً تمام ساتھی کارکنوں نے 13 کا تخمینہ دیا، سوائے ایک ڈویلپر کے جس نے 8 تجویز کیا۔ اس صورت میں، اسے اپنے کم تخمینہ کی وجوہات بتانے کے لیے بات کرنے کی اجازت ہے۔ فرض کریں کہ وہ یہ جواز پیش کرتا ہے: اس نے پہلے اسی کام پر کام کیا تھا، اور یہ اتنا مشکل نہیں جتنا لگتا ہے۔ بالآخر، وہ ٹیم کے باقی لوگوں کو 13 سے 8 اسٹوری پوائنٹس تک اپنا ذہن بدلنے پر راضی کرتا ہے، یہ کہتے ہوئے کہ جو بھی اس کام کو انجام دیتا ہے وہ اس کی مدد کرے گا۔ یا شاید وہ خود ہی کرے گا۔ کسی بھی صورت میں، اس سے کوئی فرق نہیں پڑتا کہ دوسرے اس کے دلائل کو قبول کرتے ہیں یا نہیں، کیونکہ ایک اندازے کے مطابق ایک اندازے کو اس کام کے لیے تفویض کیا جائے گا، اور ٹیم اگلے پر غور کرنے کے لیے آگے بڑھے گی۔ ابتدائی طور پر، اندازے غلط ہوں گے، جیسا کہ اس کام کی مقدار کا تخمینہ ہوگا جسے آپ اگلی مدت (سپرنٹ) میں انجام دینے کا ارادہ رکھتے ہیں۔ سب کے بعد، یہ اندازے تخمینوں کا استعمال کرتے ہوئے بنائے گئے. کچھ وقت کے بعد، شاید تین ماہ بعد، ٹیم کاموں کے لیے درکار وقت کا زیادہ درستگی سے اندازہ لگانا شروع کر دے گی، اور کام کی اوسط مقدار ظاہر ہو جائے گی جو ٹیم سپرنٹ میں انجام دینے کے قابل ہے۔ لیکن یہ کام کے دائرہ کار کے لیے ایک عمومی منصوبہ بنانے کا عمل ہے۔ یہ بنیادی طور پر وقت پر مرکوز ہے، لیکن اس معاملے میں بہت سے مختلف متعلقہ عوامل ہو سکتے ہیں۔ مثال کے طور پر، فرض کریں کہ ایک ڈویلپر دو ہفتوں کے لیے چھٹیوں پر گیا تھا۔ آپ کو منصوبہ بند کام (منصوبہ بند فعالیت) کی ایک خاص مقدار میں کمی کرنے کی ضرورت ہوگی۔ یا فرض کریں کہ ایک نیا ڈویلپر ٹیم میں شامل ہوا ہے، لیکن ابھی تک اس کی رفتار پوری نہیں ہے، لہذا آپ کو اسے آن بورڈنگ کے عمل کے ذریعے پروجیکٹ سے واقف ہونے کے لیے وقت دینے کی ضرورت ہے۔ یہ دو ہفتے ہو سکتا ہے، پروجیکٹ کی پیچیدگی کے لحاظ سے، ایک ہفتہ دیں یا لیں۔ آج کیلئے بس اتنا ہی! مجھے امید ہے کہ میں نے کوششوں کے تخمینے کے بارے میں آپ کے علم میں قدرے بہتری لائی ہے، جو سافٹ ویئر کی ترقی کا ایک ضروری غیر تکنیکی پہلو ہے۔ اگر آپ اس موضوع کی گہرائی میں جانا چاہتے ہیں، اور اسکرم کی تفصیلات میں جانا چاہتے ہیں، تو میں آپ کو جیف سدرلینڈ کی کتاب "SCRUM" کو پڑھنے کی سختی سے سفارش کرتا ہوں۔ میں اس کے نتائج کے بارے میں کوئی وعدہ نہیں کر سکتا، کیونکہ اسے پڑھنے کے بعد آپ کو اسکرم ماسٹر بننے کی ایک پریشان کن خواہش ہوگی =D