CodeGym /Java Blog /এলোমেলো /আপনার সময়সীমা পূরণ করুন: বিকাশকারীরা প্রচেষ্টা অনুমান কর...
John Squirrels
লেভেল 41
San Francisco

আপনার সময়সীমা পূরণ করুন: বিকাশকারীরা প্রচেষ্টা অনুমান করার জন্য যে পদ্ধতিগুলি ব্যবহার করে

এলোমেলো দলে প্রকাশিত
সবাইকে অভিবাদন! সফ্টওয়্যার ডেভেলপমেন্ট শুরু করার জন্য আপনাকে প্রচুর পরিমাণে তত্ত্ব জানতে হবে। কিছু বিশেষজ্ঞ (উদাহরণস্বরূপ, ব্যাকএন্ড ডেভেলপার যারা জাভা এবং অন্যান্য ভাষা ব্যবহার করেন) এটি সম্পর্কে আরও জানেন, অন্যরা (উদাহরণস্বরূপ, ফ্রন্টএন্ড ডেভেলপার যারা জাভাস্ক্রিপ্ট এবং রিঅ্যাক্ট নেটিভ ব্যবহার করেন) কিছুটা কম জানেন। তাতে বলা হয়েছে, উভয় গোষ্ঠীরই কেবল প্রযুক্তিগত নয়, "সাংগঠনিক" জ্ঞানের একটি বৃহৎ দেহ থাকতে হবে। এই "সাংগঠনিক" জ্ঞান ফ্রন্টএন্ড এবং ব্যাকএন্ড বিকাশকারীদের জন্য ওভারল্যাপের একটি ক্ষেত্র। আপনার সময়সীমা পূরণ করুন: বিকাশকারীরা প্রচেষ্টা অনুমান করার জন্য যে পদ্ধতিগুলি ব্যবহার করে - 1আজ আমি এই নন-টেকনিক্যাল, সাংগঠনিক জ্ঞানের একটি দিক সম্পর্কে কথা বলতে চাই। আজ আমরা প্রচেষ্টার অনুমান সম্পর্কে কথা বলব । কারণ আমার কাছে শুধুমাত্র অ্যাজিল পদ্ধতি ব্যবহার করার অভিজ্ঞতা আছে(যা সবচেয়ে জনপ্রিয় বলে বিবেচিত হয়), আরো সুনির্দিষ্টভাবে স্ক্রাম ফ্রেমওয়ার্ক, আমি স্ক্রামের প্রসঙ্গে প্রচেষ্টার অনুমান বিবেচনা করব । শুরুতেই, আমি অবশ্যই বলব যে প্রচেষ্টা অনুমান করা কঠিন। আমার জন্য, এটি একজন বিকাশকারী হিসাবে আমার কাজের সবচেয়ে চ্যালেঞ্জিং/অপ্রীতিকর দিকগুলির মধ্যে একটি। বিবেচনা করার জন্য অনেকগুলি বিভিন্ন কারণ রয়েছে যা একটি কাজের জন্য প্রয়োজনীয় প্রচেষ্টার আপনার অনুমানকে প্রভাবিত করতে পারে। উপরন্তু, ভবিষ্যতের উন্নয়ন পরিকল্পনা আপনার অনুমানের উপর ভিত্তি করে করা হবে।

যদি আপনি একটি খারাপ অনুমান প্রদান করেন?

যদি একজন ডেভেলপার একটি টাস্কের জন্য শেষ পর্যন্ত ব্যয় করার চেয়ে অনেক বেশি সময় অনুমান করে, তাহলে তাদের দক্ষতা সন্দেহের মধ্যে পড়তে পারে কারণ অনুমানটি এতটাই ভুল ছিল। অন্য কথায়, এটি একটি বন্য অনুমান ছিল। একই সময়ে, যদি একজন বিকাশকারী পূর্বাভাসিত সময়ে কাজটি সম্পন্ন না করে, তাহলে তিনি পণ্য বা নতুন বৈশিষ্ট্য প্রকাশ করার গ্রাহকের পরিকল্পনাকে বিপন্ন করে তোলেন। এটি ব্যবসা, এবং ব্যবসা অর্থ। খুব কম গ্রাহক এই ধরনের একটি স্লিপ সঙ্গে সন্তুষ্ট হবে. আসলে, এই কারণেই আমি অনুমান পছন্দ করি না — কারণ কখনও কখনও একটি কাজ সম্পূর্ণ করার জন্য প্রয়োজনীয় সময় সঠিকভাবে নির্ধারণ করা খুব কঠিন।

কিভাবে একটি সময় অনুমান করা

একটি নিয়ম হিসাবে, অনুমান ঘন্টা বা গল্প পয়েন্ট তৈরি করা হয়। আমার ব্যক্তিগত পছন্দ গল্প পয়েন্ট ব্যবহার করে অনুমান প্রক্রিয়া করতে হয় . কংক্রিট ভৌত বস্তু সম্পর্কে ভুল করা কঠিন, তবে গল্পের পয়েন্টগুলি একটু বেশি বিমূর্ত। সফ্টওয়্যার ডেভেলপমেন্ট দলগুলি সাধারণত সময়ের পরিমাণ হিসাবে অনুমান প্রদান করে: ঘন্টা, দিন, সপ্তাহ, মাস। এই সময়ের অনুমান প্রাথমিকভাবে ব্যক্তিগত অভিজ্ঞতা, অনুমান, এবং/অথবা অন্তর্দৃষ্টির উপর ভিত্তি করে। এই ক্ষেত্রে, বিকাশকারীরা কেবল টাস্কটি দেখে এবং তাদের কতটা সময় লাগবে সে সম্পর্কে তাদের অনুমান প্রকাশ করে। ফলস্বরূপ, এই অনুমানগুলি খুব কমই সঠিক, কারণ অনেকগুলি কারণ রয়েছে যা কাজের সময়কালকে প্রভাবিত করতে পারে। এ কারণেই চতুর পদ্ধতি ব্যবহার করে এমন অনেক দল গল্পের পয়েন্টও ব্যবহার করে। এর মধ্যে ডুব দেওয়া যাক!

গল্প পয়েন্ট কি?

একটি স্টোরি পয়েন্ট হল পরিমাপের একটি ইউনিট যা কার্যকারিতার একটি নির্দিষ্ট অংশকে সম্পূর্ণরূপে বাস্তবায়নের জন্য প্রয়োজনীয় মোট প্রচেষ্টার অনুমান প্রকাশ করার জন্য। যে, আমরা আপেক্ষিক সম্পর্কে কথা বলছিজটিলতা. দলগুলি কাজের জটিলতা, কাজের পরিমাণ এবং ঝুঁকি বা অনিশ্চয়তার উপর ভিত্তি করে গল্পের পয়েন্টগুলিতে একটি অনুমান নির্ধারণ করে। এই মানগুলি সাধারণত কাজটিকে আরও দক্ষতার সাথে ছোট ছোট অংশে ভাগ করার জন্য বরাদ্দ করা হয়, যার ফলে অস্পষ্টতা দূর হয়। সময়ের সাথে সাথে, এটি দলগুলিকে একটি নির্দিষ্ট সময়ের মধ্যে তারা কী করতে পারে তা বুঝতে সাহায্য করে এবং পরবর্তী কাজগুলির আরও সঠিকভাবে পরিকল্পনা করতে সহায়তা করে। এটি আপনার কাছে সম্পূর্ণরূপে বিপরীত মনে হতে পারে, তবে এই বিমূর্ততাটি আসলেই কার্যকর: এটি দলকে কাজের জটিলতা সম্পর্কে কঠিন সিদ্ধান্ত নিতে চাপ দেয়। পরিকল্পনা করার সময় গল্পের পয়েন্টগুলি ব্যবহার করার কিছু কারণ দেখে নেওয়া যাক:
  • আপনি ভুল সময়ের অনুমান এড়াতে পারেন।
  • সময়ের এককে করা অনুমানের বিপরীতে, গল্পের পয়েন্টগুলি আপনাকে ওভারহেড খরচের জন্য হিসাব করতে দেয়: দলের সদস্য এবং গ্রাহকের মধ্যে যোগাযোগ, বিভিন্ন দলের আলোচনা এবং পরিকল্পনা কার্যক্রম, সেইসাথে অপ্রত্যাশিত পরিস্থিতি।
  • প্রতিটি দল বিভিন্ন স্কেল ব্যবহার করে তাদের কাজ অনুমান করবে, যার মানে তাদের ক্ষমতা (পয়েন্টে পরিমাপ করা) ভিন্ন হবে।
  • প্রতিটি গল্পের পয়েন্ট বরাদ্দ করার জন্য একটি স্কেল সংজ্ঞায়িত করে, আপনি খুব বেশি বিতর্ক ছাড়াই দ্রুত পয়েন্ট বরাদ্দ করতে পারেন।

কিভাবে গল্প পয়েন্ট ব্যবহার করবেন না

দুর্ভাগ্যবশত, গল্প পয়েন্ট প্রায়ই অপব্যবহার করা হয়. গল্পের পয়েন্টগুলি বিভ্রান্তিকর হতে পারে যখন সেগুলি লোকেদের মূল্যায়ন করতে ব্যবহার করা হয়, বিস্তারিত সময়সীমা এবং সংস্থানগুলি সংজ্ঞায়িত করা হয় এবং যখন তারা একটি কর্মক্ষমতা পরিমাপের জন্য ভুল হয়। পরিবর্তে, প্রতিটি কাজের সুযোগ/জটিলতা বোঝার জন্য এবং অগ্রাধিকার নির্ধারণের জন্য দলগুলিকে তাদের ব্যবহার করা উচিত। সম্ভবত যে অংশগুলিকে আরও কঠিন হিসাবে বিবেচনা করা হয় সেগুলি প্রথমে মোকাবেলা করা উচিত, যাতে সেগুলি স্প্রিন্ট শেষ হওয়ার আগে করা যেতে পারে , সম্ভবত সহজ কাজগুলিকে পরবর্তীতে স্থানান্তরিত করে। স্ক্রাম পদ্ধতির প্রেক্ষাপটে স্প্রিন্ট কী তা আমি আপনাকে মনে করিয়ে দিই :
একটি স্প্রিন্ট একটি পুনরাবৃত্তিযোগ্য নির্দিষ্ট সময়ের ব্যবধান যার সময় কার্যকারিতার কিছু পরিকল্পিত অংশ বাস্তবায়িত হয়।
এই সময়কালের দৈর্ঘ্য নির্ধারিত হয় যখন বিকাশ শুরু হয় এবং দল এবং গ্রাহকের মধ্যে সম্মত হয়। এটি দুই সপ্তাহ বা এক মাস বা অন্য কোনো সময়কাল হতে পারে। একটি নিয়ম হিসাবে, প্রতিটি স্প্রিন্টের শুরুতে প্রচেষ্টার অনুমান তৈরি করা হয় যাতে স্প্রিন্টের শেষের মধ্যে সম্পন্ন করা যেতে পারে, যখন সম্পূর্ণ কাজ গ্রাহকের কাছে পৌঁছে দেওয়া হয়।
যখন স্প্রিন্টের সময় সম্পন্ন করা কাজটি গ্রাহকের কাছে উপস্থাপন করা হয়, তখন আমরা তাকে ডেমো বলি।
ডেমো আপনাকে পণ্যটি বিকাশে আপনার অগ্রগতি দেখতে, গ্রাহকের কাছ থেকে প্রতিক্রিয়া পেতে এবং গ্রাহকের দৃষ্টিভঙ্গি অনুসারে প্রকল্পের গতিপথ সামঞ্জস্য করতে সহায়তা করে। কিন্তু আমরা একটু বিমুখ। আসুন অনুমানে ফিরে আসা যাক। শুধুমাত্র একজন বিকাশকারীকে সমস্ত কাজের জন্য অনুমান প্রদান করা খুবই বিষয়ভিত্তিক হবে। তাই এই প্রক্রিয়াটি সাধারণত একটি দলীয় প্রচেষ্টা। দলগুলি অনুমান তৈরি করতে ব্যবহার করতে পারে এমন বেশ কয়েকটি কৌশল রয়েছে। আজ আমরা সবচেয়ে জনপ্রিয় কৌশলটি দেখব: স্ক্রাম পোকারএই কৌশলটির জন্য একজন ম্যানেজার প্রয়োজন যিনি স্ক্রাম পোকারের একজন মডারেটর হিসেবে কাজ করবেন । এটি এমন কেউ হতে পারে যিনি একজন স্ক্রাম মাস্টার বা সম্ভবত একজন প্রধানমন্ত্রী

স্ক্রাম জুজু কি?

স্ক্রাম পোকার , বা পরিকল্পনা পোকার, একটি অনুমান কৌশল যা একটি চুক্তিতে পৌঁছানোর উপর ভিত্তি করে। এটি মূলত সামনের কাজের জটিলতা বা সফ্টওয়্যার বিকাশের কাজগুলির আপেক্ষিক আকার অনুমান করতে ব্যবহৃত হয়। আমি সরাসরি যে স্ক্রাম জুজু বলবএটি একটি সাধারণ সফ্টওয়্যার ডেভেলপমেন্ট অনুশীলন, এবং আপনাকে জানতে হবে এটি কী। এটি সাধারণত একটি অ্যাপ বা ওয়েবসাইট জড়িত করে একটি নির্দিষ্ট কাজের জন্য একটি অনুমান তৈরি করার জন্য একটি দলের সহযোগীতামূলক তৈরির সুবিধার জন্য। এটা কিভাবে হয়? দলটি ব্যাকলগ থেকে কিছু নেয় (একটি নতুন কাজ, কিছু কার্যকারিতা) এবং সংক্ষিপ্তভাবে সম্ভাব্য ক্ষতি এবং এর সাথে সম্পর্কিত অন্যান্য সূক্ষ্মতা নিয়ে আলোচনা করে। তারপরে প্রতিটি অংশগ্রহণকারী একটি নম্বর সহ একটি কার্ড বেছে নেয় যা তাদের জটিলতার অনুমান প্রতিফলিত করে। ওহ, আরও একটি জিনিস, এই অনুমানগুলি করার সময়, আমরা সাধারণ সংখ্যার পরিবর্তে ফিবোনাচি ক্রম অনুসারে সংখ্যাগুলি ব্যবহার করি। স্ক্রাম পোকারে ফিবোনাচি সংখ্যা জনপ্রিয়, কারণ তাদের মধ্যে একটি ক্রমবর্ধমান বড় ব্যবধান রয়েছে (একটি পিরামিডের স্তরের অনুরূপ)। কিছু কাজ অত্যন্ত জটিল হবে, এবং আমরা অল্প সংখ্যক গল্পের পয়েন্ট দিয়ে দূরে যেতে সক্ষম হব না। আপনার সময়সীমা পূরণ করুন: বিকাশকারীরা প্রচেষ্টা অনুমান করার জন্য যে পদ্ধতিগুলি ব্যবহার করে - 2কিছু অস্বাভাবিক কার্ড রয়েছে যার নিম্নলিখিত অর্থ রয়েছে: আপনার সময়সীমা পূরণ করুন: বিকাশকারীরা প্রচেষ্টা অনুমান করার জন্য যে পদ্ধতিগুলি ব্যবহার করে - 3

শেষবিন্দুর অজানা সংখ্যা

আপনার সময়সীমা পূরণ করুন: বিকাশকারীরা প্রচেষ্টা অনুমান করার জন্য যে পদ্ধতিগুলি ব্যবহার করে - 4

অসীম দীর্ঘ টাস্ক

আপনার সময়সীমা পূরণ করুন: বিকাশকারীরা প্রচেষ্টা অনুমান করার জন্য যে পদ্ধতিগুলি ব্যবহার করে - 5

একটি বিরতি প্রয়োজন

কম সাধারণ অনুমান পদ্ধতি ব্যবহার করে:
  • টি-শার্টের আকার — এস, এম, এল, এক্সএল
  • কুকুরের জাত — চিহুয়াহুয়া, পগ, ড্যাচসুন্ড, বুলডগ এবং আরও অনেক কিছু (ব্যক্তিগতভাবে, আমি মনে করি এটি প্রচেষ্টা অনুমানের জন্য পরিমাপের সবচেয়ে অদ্ভুত একক =D)
দলটি তখন একই কাজের জন্য বিভিন্ন ডেভেলপারদের দেওয়া অনুমানের তুলনা করে। যদি তারা রাজি হয়, তাহলে দারুণ! যদি না হয়, তাহলে বিভিন্ন অনুমানের কারণ (যুক্তি) আলোচনা করা দরকার। এর পরে, দলটি একসাথে কাজ করে একটি একক অনুমান তৈরি করে যা সবাই কমবেশি গ্রহণ করে। তাহলে কেন জুজু এমনকি গুরুতর সফ্টওয়্যার প্রকল্পের পরিকল্পনা করতে ব্যবহৃত হয়? আপনাকে স্বীকার করতে হবে যে এটি অদ্ভুত। আসল বিষয়টি হ'ল এই ধরণের গ্যামিফিকেশন দলের সদস্যদের স্বাধীনভাবে চিন্তা করতে উত্সাহিত করে, তাদের সতীর্থদের মতো একই সময়ে তাদের অনুমান প্রকাশ করতে আমন্ত্রণ জানায়। এটি, ঘুরে, এমন পরিস্থিতি তৈরি করা এড়ায় যেখানে কিছু দলের সদস্য অন্যদের মতামতের উপর নির্ভর করে। যদি এটি এইভাবে করা না হয়, তাহলে কম অভিজ্ঞ বিকাশকারীরা আরও অভিজ্ঞ দলের সদস্যদের দ্বারা প্রদত্ত অনুমানগুলি দেখবে এবং ফোকাস করবে, এবং এটি তাদের নিজস্ব অনুমান কম উপযোগী করে তুলবে। কিন্তু একই সাথে অনুমান দেখানো এটাকে অসম্ভব করে তোলে। আটলাসিয়ান অফারপরিকল্পনা প্রক্রিয়ায় ব্যবহারের জন্য একটি স্ক্রাম পোকার অ্যাপ ।

প্রচেষ্টা অনুমানের উদাহরণ

ধরুন আপনার দল অনুমানে গল্পের পয়েন্ট বরাদ্দ করার জন্য নিম্নলিখিত স্কেল স্থাপন করেছে:
1. আপনার কি এই ধরনের কাজের কোন অভিজ্ঞতা আছে? +1 — আমি আগে এই কাজটি করেছি +2 — আমি এই কাজটি করিনি, তবে একই রকম কাজ করেছি +3 — আমি এই কাজটি করিনি এবং অনুরূপ কিছুর সাথে আমার কোন অভিজ্ঞতা নেই
2. কার্যকারিতার জন্য প্রয়োজনীয় কাজের পরিমাণ +1 — ছোট ভলিউম +2 — গড় আয়তন +3 — বড় ভলিউম
3. কার্যকারিতা বাস্তবায়নের জটিলতা +1 — সহজ +2 — গড় +3 — কঠিন
4. কার্যকারিতা পরীক্ষার জটিলতা +1 — সহজ +2 — গড় +3 — কঠিন
স্ক্রাম জুজু প্রতিটি কাজের জন্য খেলা হয়, এবং আপনি নিম্নরূপ একটি অনুমান প্রদান করেন:
  • আপনি আগে কখনও অনুরূপ কার্যকারিতা প্রয়োগ করেননি: +3
  • কার্যকারিতা গড় আকারের: +2
  • বাস্তবায়ন অত্যন্ত জটিল হবে: +3
  • কার্যকারিতার জন্য লেখার পরীক্ষাগুলি অত্যন্ত জটিল হবে: +3
প্রতিটি কম্পোনেন্ট যোগ করলে, আপনি মোট 11টি স্টোরি পয়েন্ট পাবেন, কিন্তু এমন কোনো কার্ড নেই, তাই আপনি 13টি সাজেস্ট করেন। একজন সহকর্মী টাস্কের জন্য নিম্নলিখিত অনুমানটি এগিয়ে দেন:
  • তিনি এর আগে একটি অনুরূপ কাজের সাথে কাজ করেছেন: +1
  • কার্যকারিতা গড় আকারের: +2
  • বাস্তবায়ন গড় জটিলতা হবে: +2
  • কার্যকারিতার জন্য লেখার পরীক্ষাগুলি গড় জটিলতার হবে: +2
তার মধ্যবর্তী ফলাফল হল 7 স্টোরি পয়েন্ট, কিন্তু সেই সংখ্যাটি ফিবোনাচি সিরিজে বিদ্যমান নেই, তাই তিনি সর্বাধিক আনুমানিক সংখ্যা - 8 সহ কার্ডটি জমা দেন। অন্যান্য দলের সদস্যরাও তাদের বিষয়গত মতামতের উপর ভিত্তি করে তাদের অনুমান করে। তারপর প্রত্যেকে তাদের কার্ড দেখায় এবং আপনি দেখতে পান যে আপনার প্রায় সকল সহকর্মী 13 এর অনুমান দিয়েছেন, একজন ডেভেলপার ব্যতীত যিনি 8টি প্রস্তাব করেছিলেন। এই ক্ষেত্রে, তাকে তার নিম্ন অনুমানের কারণগুলি দিয়ে কথা বলার অনুমতি দেওয়া হয়। ধরুন তিনি এই ন্যায্যতা প্রস্তাব করেছেন: তিনি পূর্বে একই টাস্কে কাজ করেছিলেন, এবং এটি যতটা কঠিন মনে হয় ততটা কঠিন নয়। শেষ পর্যন্ত, তিনি দলের বাকিদের 13 থেকে 8 গল্পের পয়েন্ট থেকে তাদের মন পরিবর্তন করতে রাজি করান, এই বলে যে যে এই কাজটি শেষ করবে তাকে তিনি সাহায্য করবেন। অথবা সম্ভবত তিনি নিজেই এটি করবেন। যে কোনো ক্ষেত্রে, এটা হয় না অন্যরা তার যুক্তি গ্রহণ করে কি না তা বিবেচ্য নয়, কারণ একভাবে বা অন্যভাবে একটি অনুমান কাজটির জন্য বরাদ্দ করা হবে এবং দলটি পরবর্তীটি বিবেচনা করার জন্য এগিয়ে যাবে। প্রাথমিকভাবে, অনুমানগুলি ভুল হবে, যেমন আপনি পরবর্তী সময়ের (স্প্রিন্ট) মধ্যে যে পরিমাণ কাজ করার পরিকল্পনা করছেন তার অনুমান হবে। সব পরে, অনুমান ব্যবহার করে এই অনুমান করা. কিছু সময় পরে, হয়তো তিন মাস পরে, দলটি আরও সঠিকভাবে কাজগুলির জন্য প্রয়োজনীয় সময় অনুমান করতে শুরু করবে, এবং দলটি স্প্রিন্টে কতটা কাজ করতে সক্ষম তা স্পষ্ট হয়ে উঠবে। তবে এটি কাজের সুযোগের জন্য একটি সাধারণ পরিকল্পনা তৈরি করার একটি প্রক্রিয়া। এটি প্রধানত সময়ের উপর ফোকাস করে, কিন্তু এই ক্ষেত্রে বিভিন্ন প্রাসঙ্গিক কারণ থাকতে পারে। উদাহরণস্বরূপ, ধরুন একজন বিকাশকারী দুই সপ্তাহের জন্য ছুটিতে গেছেন। আপনাকে পরিকল্পিত কাজের একটি নির্দিষ্ট পরিমাণ (পরিকল্পিত কার্যকারিতা) কাটাতে হবে। অথবা ধরুন একজন নতুন ডেভেলপার দলে যোগ দিয়েছেন, কিন্তু এখনও সম্পূর্ণভাবে গতি পাচ্ছেন না, তাই আপনাকে তাকে প্রকল্পের সাথে পরিচিত হতে সময় দিতে হবেঅনবোর্ডিং প্রক্রিয়া। এটি দুই সপ্তাহ হতে পারে, প্রকল্পের জটিলতার উপর নির্ভর করে এক সপ্তাহ সময় দিতে বা নিতে পারে। আজ যে জন্য সব! আমি আশা করি সফ্টওয়্যার বিকাশের একটি প্রয়োজনীয় অ-প্রযুক্তিগত দিক, প্রচেষ্টার অনুমানের বিষয়ে আমি আপনার জ্ঞানকে কিছুটা উন্নত করেছি। আপনি যদি এই বিষয়ের গভীরে যেতে চান, এবং স্ক্রামের বিশদ বিবরণে, আমি দৃঢ়ভাবে সুপারিশ করছি যে আপনি জেফ সাদারল্যান্ডের "SCRUM" বইটি পড়বেন। আমি পরিণতি সম্পর্কে কোনো প্রতিশ্রুতি দিতে পারি না, কারণ এটি পড়ার পরে আপনার স্ক্রাম মাস্টার হওয়ার বিরক্তিকর ইচ্ছা থাকবে =D
মন্তব্য
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION