মোবাইল প্রজেক্টের জন্য আনুমান — এটি কী, কাজ মূল্যায়নের পদ্ধতি

আনুমান কী?

আনুমান (ইংরেজি estimate থেকে — মূল্যায়ন) হলো একটি কাজ সম্পূর্ণ করতে প্রয়োজনীয় সময় বা প্রচেষ্টার পরিমাণের পূর্বাভাস। মোবাইল ডেভেলপমেন্টে, আনুমান ঘন্টা, দিন, স্টোরি পয়েন্ট বা আর্থিক পরিভাষায় প্রকাশ করা যেতে পারে। আনুমানের উদ্দেশ্য সঠিক ভবিষ্যদ্বাণী নয়, বরং সিদ্ধান্ত গ্রহণের জন্য অনিশ্চয়তা কমানো।

আনুমান প্রতিশ্রুতি থেকে কীভাবে আলাদা

আনুমান হলো ত্রুটির সম্ভাবনা সহ একটি পূর্বাভাস। প্রতিশ্রুতি হলো একটি নির্দিষ্ট তারিখের মধ্যে কাজ সম্পূর্ণ করার অঙ্গীকার। পার্থক্যটি গুরুত্বপূর্ণ: আনুমান বলে «সম্ভবত ৫ দিন», প্রতিশ্রুতি বলে «আমরা এটি ৫ দিনে করব»। ব্যবস্থাপকরা প্রায়শই এই ধারণাগুলিকে গুলিয়ে ফেলেন, আনুমানকে ত্রুটির কোনো সুযোগ ছাড়াই সময়সীমায় পরিণত করেন।

যোগাযোগের হাতিয়ার হিসেবে আনুমান

আনুমান প্রক্রিয়াটি এর ফলাফলের চেয়ে কম গুরুত্বপূর্ণ নয়। যখন দল একটি কাজের আনুমান নিয়ে আলোচনা করে, তখন লুকানো প্রয়োজনীয়তা, নির্ভরতা এবং ঝুঁকি সামনে আসে।即使 চূড়ান্ত সংখ্যাটি ভুল হলেও, আলোচনা সমস্ত অংশগ্রহণকারীদের কাজটি বুঝতে সাহায্য করে। এই কারণেই দলগত আনুমান পদ্ধতি (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 প্রতি কাজে ৫-১০ মিনিট সময় নেয়, কিন্তু শুধুমাত্র মাত্রার ক্রম প্রদান করে।

তিন-বিন্দু আনুমান (PERT)

PERT তিনটি আনুমান ব্যবহার করে: আশাবাদী (O), হতাশাবাদী (P), এবং সবচেয়ে সম্ভাব্য (M)। চূড়ান্ত আনুমান সূত্র (O + 4M + P) / 6 দ্বারা গণনা করা হয়। এই পদ্ধতি অনিশ্চয়তা বিবেচনায় নেয় এবং একক আনুমানের চেয়ে বেশি বাস্তবসম্মত ফলাফল দেয়। PERT বিশেষ করে উচ্চ ঝুঁকি বা নতুন প্রযুক্তির কাজের জন্য উপযোগী।

আনুমানের নির্ভুলতা: প্রত্যাশা বনাম বাস্তবতা

আনুমানের নির্ভুলতা প্রকল্পের পর্যায় এবং জানা তথ্যের পরিমাণের ওপর নির্ভর করে। যত তাড়াতাড়ি আনুমান করা হয়, ত্রুটির পরিধি তত বেশি — এটি স্বাভাবিক এবং পরিকল্পনায় বিবেচনা করা উচিত।

অনিশ্চয়তার শঙ্কু

অনিশ্চয়তার শঙ্কু (Cone of Uncertainty) একটি মডেল যা বর্ণনা করে যে প্রকল্প অগ্রসর হওয়ার সাথে সাথে আনুমান ত্রুটি কীভাবে কমে। ধারণা পর্যায়ে, ত্রুটির পরিধি 400% (একটি কাজ 1 থেকে 4 মাস সময় নিতে পারে)। স্প্রিন্ট পর্যায়ে, এটি 20% (1-1.2 মাস) হয়। এই মডেল বোঝা প্রাথমিক পর্যায়ে সঠিক আনুমান দাবি না করতে সাহায্য করে।

নির্ভুলতাকে প্রভাবিতকারী উপাদান

• কাজের জটিলতা — এটি কি নতুন প্রযুক্তি নাকি পরিচিত? অজানা ত্রুটির পরিধি ২-৩ গুণ বাড়িয়ে দেয়।
• কাজের আকার — ছোট কাজ (২ দিন পর্যন্ত) বড় কাজের চেয়ে বেশি নির্ভুলভাবে আনুমান করা হয়। বিভাজন নির্ভুলতা উন্নত করে।
• দলের অভিজ্ঞতা — ৬+ মাস ধরে একসঙ্গে কাজ করা দল নতুন দলের চেয়ে ৩০-৫০% বেশি নির্ভুল আনুমান করে।
• ঐতিহাসিক তথ্য — velocity মেট্রিক এবং চক্রমিতি তথ্য পূর্বাভাসের নির্ভুলতা উন্নত করে।

আপেক্ষিক বনাম পরম আনুমান

আপেক্ষিক আনুমান (স্টোরি পয়েন্টে) পরম আনুমানের (ঘন্টায়) চেয়ে বেশি নির্ভুল কারণ মানুষ সময় আনুমান করার চেয়ে কাজ তুলনা করতে বেশি পারদর্শী। «এই কাজটি ওটির চেয়ে দ্বিগুণ জটিল» «এই কাজটি ৮ ঘন্টা সময় নেবে» এর চেয়ে বেশি নির্ভরযোগ্য রায়। আপেক্ষিক আনুমান কোনো নির্দিষ্ট ডেভেলপারের ওপর নির্ভর করে না এবং নির্বাহক পরিবর্তন হলে নির্ভুলতা বজায় রাখে।

কীভাবে আনুমানের নির্ভুলতা উন্নত করবেন: সেরা অভ্যাস

আনুমানের নির্ভুলতা পদ্ধতিগত পদ্ধতি, দলগত আলোচনা এবং অতীতের ভুল বিশ্লেষণের মাধ্যমে উন্নত করা যেতে পারে। বেশ কিছু প্রমাণিত অভ্যাস আছে।

১-২ দিনে বিভাজন

২ দিনের বেশি আনুমান করা যেকোনো কাজকে উপ-কাজে বিভাজিত করা উচিত। নীতি: যদি একটি কাজ ৫০% এর বেশি নির্ভুলতার সাথে আনুমান করা না যায়, তবে এটি খুব বড়। এটিকে ধাপে ভাগ করুন, যার প্রতিটি বোধগম্য এবং আনুমানযোগ্য। বিভাজনের পর, মোট আনুমান প্রায়শই প্রাথমিক আনুমানের চেয়ে ১.৫-২ গুণ বড় হয়।

ঐতিহাসিক তথ্য এবং মেট্রিক্স

আনুমানের ইতিহাস বজায় রাখুন এবং প্রকৃত প্রচেষ্টার সাথে তুলনা করুন। উদাহরণ: «৩ স্টোরি পয়েন্টে আনুমান করা কাজ গড়ে ৪ দিন সময় নেয়, ২ নয়»। পূর্বাভাসের জন্য দলের velocity ব্যবহার করুন: যদি দল প্রতি স্প্রিন্টে ২০ স্টোরি পয়েন্ট সম্পূর্ণ করে, তাহলে ৩০ পরিকল্পনা করবেন না। অতীতের আনুমান নির্ভুলতার বিশ্লেষণ আনুমান দক্ষতার জন্য সেরা প্রশিক্ষণ।

নোঙ্গর এবং ক্রমাঙ্কন

নোঙ্গর একটি মনস্তাত্ত্বিক প্রভাব যেখানে প্রথম উচ্চারিত আনুমান সমস্ত অংশগ্রহণকারীদের প্রভাবিত করে। Planning Poker-এ নোঙ্গর এড়াতে, সবাই পালাক্রমে নয় বরং একসাথে তাদের কার্ড দেখান। ক্রমাঙ্কন হলো আনুমানের প্রকৃত ফলাফলের সাথে নিয়মিত তুলনা: ১০-২০ স্প্রিন্টের পর, দল প্রতিক্রিয়ার মাধ্যমে আরও নির্ভুল আনুমান করতে শেখে।

ঝুঁকি-সমন্বিত আনুমান

প্রতিটি কাজে লুকানো ঝুঁকি থাকে: ডেভেলপারের অসুস্থতা, API সমস্যা, প্রয়োজনীয়তা পরিবর্তন। আপনার আনুমানে ঝুঁকি-সমন্বিত ফ্যাক্টর যোগ করুন: উচ্চ ঝুঁকির কাজের জন্য ১.৫-২ এর গুণক, কম ঝুঁকির জন্য ১.১-১.২। ক্লায়েন্টকে স্বচ্ছভাবে দেখান কোন ঝুঁকিগুলি বিবেচনায় নেওয়া হয়েছে এবং সেগুলি সময়সীমাকে কীভাবে প্রভাবিত করে।

আনুমানে সাধারণ ভুল

আনুমানের ভুলগুলি বেশিরভাগ দলে পুনরাবৃত্তি হয়, তাদের পরিপক্কতা নির্বিশেষে। এই ভুলগুলি জানা সেগুলি সংশোধনের প্রথম পদক্ষেপ।

আশাবাদী পক্ষপাত

সবচেয়ে সাধারণ ভুল হলো সর্বোত্তম পরিস্থিতি অনুসারে আনুমান করা: «যদি সবকিছু নিখুঁতভাবে হয়, আমরা এটি ৩ দিনে করব»। বাস্তবে, কিছুই নিখুঁতভাবে হয় না: বাগ, প্রয়োজনীয়তা নিয়ে প্রশ্ন, নির্ভরশীল কাজ। সমাধান: আশাবাদীর পরিবর্তে সবচেয়ে সম্ভাব্য পরিস্থিতি অনুসারে আনুমান করুন। পরিবর্তনশীলতা বিবেচনায় নিতে PERT ব্যবহার করুন।

চাপের মধ্যে আনুমান

যখন ব্যবস্থাপক বলেন «আমাদের শুক্রবারের মধ্যে দরকার», ডেভেলপার অবচেতনভাবে সেই সময়সীমার সাথে আনুমান সামঞ্জস্য করেন। চাপের মধ্যে আনুমান সবসময় কম হয় এবং সময়সীমা মিস করে। সমাধান: আনুমান সময়সীমার আগে হওয়া উচিত, উল্টো নয়। প্রথমে দল আনুমান করে, তারপর পক্ষগুলি সময়সীমায় সম্মত হয়।

জটিলতা এবং সময়কে গুলিয়ে ফেলা

কাজের জটিলতা (কতটা ভাবতে হবে) এবং সময় (কতটা করতে হবে) ভিন্ন মেট্রিক। একটি কাজ সহজ কিন্তু সময়সাপেক্ষ হতে পারে (১০টি স্ক্রিন তৈরি করা) বা জটিল কিন্তু দ্রুত (লিগ্যাসি কোডে বাগ খুঁজে পাওয়া)। স্টোরি পয়েন্ট সাধারণত জটিলতা আনুমান করে, যখন সময় দলের velocity থেকে প্রাপ্ত হয়।

প্রসঙ্গ পরিবর্তন উপেক্ষা করা

একজন ডেভেলপার একটানা ৮ ঘন্টা একটি কাজে কাজ করেন না: মিটিং, কোড পর্যালোচনা, সহকর্মীদের সাহায্য এবং প্রশাসনিক কাজ কাজের সময়ের ৩০-৫০% গ্রাস করে। প্রসঙ্গ পরিবর্তন আনুমানে বিবেচনায় নেওয়া উচিত: বাস্তবে, একজন ডেভেলপার প্রতিদিন ৩-৪ ঘন্টা কোড লেখেন।