کاموں کا اندازہ لگانے کے لیے ڈویلپر کون سے طریقے استعمال کرتے ہیں؟

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

اگر آپ کو صحیح درجہ بندی نہیں ملتی ہے تو کیا ہوگا؟

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

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

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

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

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

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

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

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

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

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

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

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

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

تخمینہ لگانے کے مزید نادر طریقے:

• ٹی شرٹ کے سائز میں - ایس، ایم، ایل، ایکس ایل
• یا کتوں میں - chihuahua، pug، dachshund، bulldog، وغیرہ

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

کام کی تشخیص کی مثال

آئیے تصور کریں کہ آپ کی ٹیم نے کہانی کے نکات میں تشخیص کے لیے ایک خاص پیمانے کی نشاندہی کی ہے: سکرم پوکر ایک کام پر شروع ہوتا ہے ، اور آپ اس کا اندازہ اس طرح کرتے ہیں:

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

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

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

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