ছোট দলগুলির জন্য প্রোগ্রামিংয়ের সেরা উপায়? [বন্ধ]

Question

আমি একটি ছোট্ট স্টার্টআপ সংস্থার পরিচালক। আমাদের কাছে বর্তমানে দুটি প্রোগ্রামার রয়েছে (একজন অভিজ্ঞ, একজন কম অভিজ্ঞ) যারা ওয়েব অ্যাপ্লিকেশন প্ল্যাটফর্ম তৈরি করছেন।

এখন পর্যন্ত সবচেয়ে বড় চ্যালেঞ্জগুলির মধ্যে একটি হ'ল পরিকল্পনা প্রক্রিয়া। প্রোগ্রামাররা সাধারণত তাদের নিজস্ব কাজ করার পরিকল্পনার দায়িত্বে থাকে তবে আমরা তাদের স্ব-চাপিয়ে দেওয়া সময়সীমা ছাড়িয়ে চলেছি। উদাহরণস্বরূপ, কোনও কাজ তারা অনুমান করে যে 2 দিন সময় লাগবে, শেষ হয় 8 দিন।

আমার পক্ষে তাদের পরিকল্পনায় সমর্থন করা শক্ত, কারণ কোনও নির্দিষ্ট কাজ কত দিন স্থায়ী হবে তা সম্পর্কে সঠিকভাবে অনুমান করার মতো প্রযুক্তিগত জ্ঞানের অভাব আমার কাছে নেই।

যদি আপনার কোন ধারণা আছে:

1. এর কারণ কী, প্রোগ্রামারদের জন্য এটি কি সাধারণ?
2. পরিকল্পনায় তাদের সমর্থন করার জন্য আমি কী করতে পারি? ছোট দলগুলিতে প্রোগ্রামারদের জন্য দরকারী এমন কোন পদ্ধতি বা সরঞ্জাম রয়েছে কি?

Comments

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

— লুৎস ফ্রাঙ্কেন

@ জন বি, আপনি এখানে অনুরূপ প্রশ্নগুলি দেখে নিতে পারেন ( প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার / প্রশ্নস / ট্যাগড / )) তবে আপনি অ-প্রযুক্তিগত কারণ তাদের বেশিরভাগকে সহায়ক হিসাবে মুছে ফেলবে। কিন্তু এই বেশী হতে পারে সহায়ক: programmers.stackexchange.com/questions/16326/... , programmers.stackexchange.com/questions/39468/... , programmers.stackexchange.com/questions/208700/...

— superM

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

— জন বি

এই বিষয়টিতে একটি খুব ভাল বই রয়েছে: মাইক কোহনের চটপটি অনুমান এবং পরিকল্পনা। Mountaingoatsoftware.com/books/agile-estimating-and-planning

— Hbas

আমি অবাক হয়েছি এখনও কেউ এর সাথে লিঙ্ক করেনি: joelonsoftware.com/items/2007/10/26.html

— পল

Answer 1

সাধারণ কৌশলগুলি কিছুটা সাধারণ জ্ঞানের, এটি জেনে রাখা গুরুত্বপূর্ণ বিষয়টি হল যে তাদের খুব বেশি প্রযুক্তিগত দক্ষতার প্রয়োজন নেই।

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

একবার আপনি প্রয়োজনীয়তাটি সনাক্ত করার পরে এটি সমাধানের সাথে জড়িত কাজের কাজগুলি সনাক্ত করতে হবে। এটি একটি ক্লাসিক বিভাজন এবং বিজয়ী অনুশীলন - যে কোনও কাজকে আরও ভাঙা যায় সেগুলি আরও ভাঙা দরকার।

একটি বৃহত্তর দলে আপনি জড়িত প্রত্যেকের অভিজ্ঞতার ভিত্তিতে একটি অনুমান পেতে अनुमान নির্ধারণের জুড়ি ব্যবহার করতে পারেন। এটি একটি ছোট দলে ভাল কাজ করে না, তবে এটি এখনও আপনার বিকাশকারী উভয়ের কাছ থেকে একটি স্বতন্ত্র অনুমান পাওয়ার জন্য এবং সম্ভবত নিজের থেকে একজনকে অন্তর্ভুক্ত করাও কার্যকর is আপনার নির্দিষ্ট দক্ষতার অভাব এখানে সহায়ক হতে পারে কারণ আপনাকে ব্যাখ্যা করার ক্ষেত্রে কার্যটি তাদের দৃষ্টিকোণ থেকে জড়িত, বিকাশকারী দল সম্ভবত সমস্যাটি আরও ভাল করে ধরে ফেলবে।

একটি ছোট টিমের সাহায্যে এটি প্রতিটি কাজের জন্য সেরা / প্রত্যাশিত / নিকৃষ্টতম মামলার প্রাক্কলন পেতে সহায়তা করতে পারে যা আপনাকে বিভিন্ন মান দেয়, তবে আপনি যদি প্রচুর পরিমাণে অনুমান করতে থাকেন তবে আপনার ডেভস পর্যন্ত আপনি সবচেয়ে খারাপের দিকে ঝুঁকতে পারেন আরও সঠিকভাবে অনুমান করতে শিখুন।

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

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

এই ধরণের সমস্যার জন্য আমি কোনও রূপালী বুলেট সম্পর্কে সচেতন নই তবে সবচেয়ে বড় কারণটি হল যোগাযোগ- যা একটি ছোট দলের সাথে আসলে সহজ - এবং আপনার সম্মিলিত দক্ষতা পরিমার্জন করতে প্রতিক্রিয়া ব্যবহার করে।

Comments

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

— জন বি

@ জনবি এটি যথাযথভাবে সঠিক। ডেভস এবং ম্যানেজার সফ্টওয়্যার প্রকল্পগুলির মধ্যে সম্পূর্ণরূপে পরিষ্কার এবং দ্ব্যর্থহীন যোগাযোগের কোনও উপায় থাকলে সর্বদা সুচারুভাবে চলতে পারে। দুর্ভাগ্যক্রমে, মানুষ কীভাবে এটি কাজ করে না ...

— glenatron

আপনি যদি এই দিকে আরও আরও তথ্য চান, আপনি স্ক্রাম সম্পর্কে একটি ভাল পাঠ্য পড়তে পারেন, উদাহরণস্বরূপ অনুমান (/ পরিকল্পনা) জুজু এবং উল্লিখিত পর্যালোচনা অংশ গ্লেনাস্ট্রন এর অংশ are

— TheMorph

Answer 2

[তাদের আনুমানিক 2 দিনের 8 দিন সময় লাগবে] এর কারণ কী, প্রোগ্রামারদের পক্ষে এটি কি সাধারণ?

এটি, যদি:

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

কিছু জিনিস নামকরণ করা।

আপনার বিকাশকারীদের কেন তাদের অনুমানটি বন্ধ হয়ে যায় বলে মনে হয় তা জিজ্ঞাসা করা ভাল। :-)

Comments

এই উত্তর পোস্ট করার জন্য ধন্যবাদ। আমাদের পরিকল্পনার প্রক্রিয়ায় ন্যূনতম 'অজানা' আছে কিনা তা নিশ্চিত করতে আমরা এই তালিকাটি একটি চেক তালিকা হিসাবে হাতে রাখব। আমি মনে করি এটি প্রোগ্রামারদের এই তালিকাটি পড়তে সহায়তা করবে। পিএস আমি যদি এটি করতে পারি তবে এটি উত্সাহিত করব, তবে নতুন হিসাবে আমার এখনও যথেষ্ট খ্যাতি পয়েন্ট নেই :)

— জন বি

আপনি আংশিকভাবে সঠিক, যদিও আমি মনে করি না যে কোনও উপযুক্ত প্রোগ্রামার সঠিকভাবে কোনও প্রকল্প করার জন্য প্রয়োজনীয় সময় অনুমান করার বাইরে হবে beyond এই হিসাবে, আমি মনে করি আপনারা সর্বদা হাফস্টাডটারের আইনের জন্য পরিকল্পনা করা উচিত , এমনকি এই তালিকার সমস্ত দিক পর্যবেক্ষণ করা হলেও।

— নিল

কোড বেস সম্পর্কে অপর্যাপ্ত জ্ঞানও ভুয়া অনুমানের জন্য সহায়ক হতে পারে।

— TheMorph

Answer 3

উন্নয়নের সময় পরিকল্পনা করার সর্বোত্তম উপায়টি বের করার চেষ্টা করার জন্য আপনি দীর্ঘ শটে প্রথম নন। এটি একটি অংশে এই সত্যটির কারণে যা আপনি বাস্তবে নির্মিত হচ্ছে দেখছেন না এমন কিছু পরিমাণ নির্ধারণ করা কঠিন, এবং আংশিকভাবে পৌরাণিক মনুষ্য-মাসের কারণে , যা স্বজ্ঞাত ধারণার প্রত্যক্ষ বৈপরীত্য যে আপনার যদি 2 প্রোগ্রামার থাকে তবে আপনার উচিত আপনার যদি 1 জন প্রোগ্রামার থাকে তার চেয়ে দ্বিগুণ দ্রুত বিকাশ করতে সক্ষম হন।

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

প্রোগ্রামার হিসাবে আমার নিজের ব্যক্তিগত অভিজ্ঞতায়, আমি আপনাকে বলতে পারি যে এটি প্রকল্পগুলিকে মাইলফলক ভাঙ্গতে সহায়তা করে। মাইলফলক 1, তারপরে মাইলফলক 1 থেকে মাইলফলক 2, তারপরে মাইলফলক 2 থেকে মাইলফলক 3 ইত্যাদি কত সময় লাগবে? এইভাবে ভেঙে গেলে উত্তরটি সম্পূর্ণরূপে সম্পূর্ণ প্রকল্পটি অনুমান করার চেষ্টা করার চেয়ে অনেক বেশি নির্ভুল হয়। আশ্চর্যজনকভাবে যথেষ্ট, আপনি যদি এই সমস্ত মাইলফলকের অনুমানের যোগফলটি যোগ করেন তবে এটি সাধারণত পুরো প্রকল্পের মূল অনুমানের চেয়ে বড় হবে (যদি প্রোগ্রামারটি যেভাবেই নিজের সাথে সৎ হয়ে থাকে), যা কেবল আমাকে ভাবতে পরিচালিত করে যে বিশদটি মূল কী এখানে.

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

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

আমি আশা করি এটি সাহায্য করবে!

Comments

সংযোজন: পুনরাবৃত্তি অনুমানের সাথে প্রোগ্রামারদের কয়েকটি সমস্যা আছে । আমার, অন্ততপক্ষে পুনরাবৃত্তি থেকে একঘেয়েমি নিয়ে প্রচুর সমস্যা রয়েছে (যা কখনও কখনও অটোমেশনের খরগোশের ছিদ্র, একটি স্বল্প-মেয়াদী ডুবে থাকে যা দীর্ঘমেয়াদী শোধ করতে পারে);)

— ইজকাটা

@ ইজকাটা, যদি প্রোগ্রামিংগুলি অনুলিপি করা এবং আটকানো সম্পর্কে থাকে তবে আমি এই ব্যবসায় থাকব না। এটা অভাব পুনরাবৃত্তি যে আমি আমার কাজ সম্পর্কে ভোগ করেন। :)

— নীল

Answer 4

অনুমানগুলি প্রায়শই বন্ধ হয়ে যাওয়ার কারণগুলির একটি কারণ কারণ অনুমানটি আসলে বেশ শক্ত এবং সিস্টেমটি পরিবর্তন করার জন্য অভিজ্ঞতা এবং জ্ঞান প্রয়োজন। প্রায়শই এটি বড় আকারের ছোট পদক্ষেপগুলি ভাঙ্গতে সহায়ক।

এখন আপনার দুটি সম্ভাবনা রয়েছে যার মধ্যে আমি দুটি উল্লেখ করব:

• পরিকল্পনা পোকার
• পিইআরটি (প্রোগ্রাম মূল্যায়ন এবং পর্যালোচনা প্রযুক্তি)

পরিকল্পনা পোকার

এটি ছোট চতুর দলগুলিতে বেশ ভাল কাজ করে।

উইকিপিডিয়া থেকে অংশ:

• একজন মডারেটর, যিনি খেলবেন না, তিনি সভাটির সভাপতিত্ব করেন।
• প্রোডাক্ট ম্যানেজার একটি সংক্ষিপ্ত বিবরণ দেয়। অনুমান এবং ঝুঁকি পরিষ্কার করার জন্য দলটিকে প্রশ্ন জিজ্ঞাসা করার এবং আলোচনার সুযোগ দেওয়া হয়। আলোচনার একটি সংক্ষিপ্ত বিবরণ প্রকল্প পরিচালক দ্বারা রেকর্ড করা হয়।
• প্রতিটি ব্যক্তি তাদের অনুমানের প্রতিনিধিত্ব করে একটি কার্ড মুখ নীচে রাখে। ব্যবহৃত ইউনিটগুলি পরিবর্তিত হয় - সেগুলি দিনকাল, আদর্শ দিন বা গল্পের পয়েন্ট হতে পারে। আলোচনার সময়, অ্যাঙ্করিং এড়ানোর জন্য বৈশিষ্ট্যের আকারের সাথে সংখ্যার উল্লেখ করা উচিত নয়।
• প্রত্যেকে তাদের কার্ডগুলি একসাথে ঘুরিয়ে কল করে।
• উচ্চতর অনুমান এবং কম অনুমানযুক্ত লোকদের তাদের অনুমানের ন্যায়সঙ্গত প্রস্তাব দেওয়ার জন্য একটি সাবান বাক্স দেওয়া হয় এবং তারপরে আলোচনা অব্যাহত থাকে।
• Aক্যমত্য না হওয়া পর্যন্ত অনুমান প্রক্রিয়াটি পুনরাবৃত্তি করুন। যে বিকাশকারী সম্ভবত বিতরণযোগ্যর মালিক হতে পারে তার "sensকমত্য ভোট" এর একটি বৃহত অংশ রয়েছে যদিও মডারেটর theকমত্যের জন্য আলোচনা করতে পারেন।
• একটি ডিমের টাইমারটি আলোচনার কাঠামোবদ্ধ কিনা তা নিশ্চিত করতে ব্যবহার করা হয়; মডারেটর বা প্রজেক্ট ম্যানেজার যে কোনও সময়ে ডিমের টাইমারটি ঘুরিয়ে দিতে পারে এবং যখন এটি শেষ হয়ে যায় তখন সমস্ত আলোচনা অবশ্যই বন্ধ হয়ে যায় এবং পোকারের আরও একটি রাউন্ড বাজানো হয়। কথোপকথনের কাঠামোটি সাবান বাক্সগুলির মাধ্যমে পুনরায় চালু করা হয়।

এখানে গুরুত্বপূর্ণ বিটগুলি হ'ল স্পষ্টকরণ, আলোচনা, একই সাথে অনুমানকে কল করা, যাতে কোনও পক্ষপাতিত্ব চালু করা হয় না এবং sensকমত্য হয়।

অকালপক্ক

একটি সঠিক অনুমান দেওয়া প্রায়শই কঠিন। সহজ কি একটি সম্ভাবনা দেওয়া হয়। পিইআরটি অনুমানের জন্য 3 টি মান ব্যবহার করে:

• শেষ করার জন্য সবচেয়ে আশাবাদী সময় (যদি প্রত্যাশার চেয়ে কম সমস্যা দেখা দেয়)
• শেষ করার জন্য সবচেয়ে হতাশাবাদী সময় (যদি সব কিছু ভুল হয়ে যায় - বড় বিপর্যয় বাদে)
• সম্ভবত শেষ করার সময় (যদি সবকিছু প্রত্যাশা অনুযায়ী চলে) <- আপনার বিকাশকারীদের এখনই সম্ভবত এটি অনুমান করা যায়

এই তিনটি অনুমানকে ওজন দিয়ে আপনি আরও নির্ভরযোগ্য অনুমান পাবেন।

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

এবং / অথবা আপনি সম্ভাব্যতা বন্টন তৈরি করতে এই তিনটি মান ব্যবহার করতে সক্ষম হবেন যা আরও সত্যিকারের বিশ্বের অনিশ্চয়তা প্রতিফলিত করতে পারে। বিটা বিতরণ এবং ত্রিভুজাকার বিতরণ বিশিষ্ট পছন্দ। এটি ব্যবহার করে আপনি এখন "বর্তমান প্রদত্ত অনুমানের তারিখের শেষ হওয়া কতটা সম্ভব" বা "যদি আমি 95% নিশ্চিততা চাই, সময়টি কোন মুহূর্তে শেষ হবে" এর মতো পরিসংখ্যান প্রয়োগ করতে পারে।

প্রকৃতপক্ষে পিইআরটি এখানে বর্ণিত এই দিকগুলির চেয়ে বেশি সমন্বিত রয়েছে, যা আমি বংশবৃদ্ধির স্বার্থে বাদ দিয়েছিলাম।

Comments

আমি পরিসংখ্যান ব্যবহার বিবেচনা করিনি, তবে এটি একটি উজ্জ্বল ধারণা!

— নিল

Answer 5

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

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

আপনি যদি সত্যিকারের ডেটা সংগ্রহ না করেন তবে আপনার বিকাশকারীরা আপনাকে যতবার প্রাক্কলন দেয় আপনি যতবারই জিজ্ঞাসা করবেন না কেন তারা সত্যিই কেবল তাদের পিছন থেকে নম্বর টানবে। হ্যাঁ, আসল তথ্য সংগ্রহ করা একটি ব্যথা এবং প্রথমে এটি প্রচুর দরকারী তথ্য সরবরাহ করে না, তবে সময়ের সাথে সাথে এটি যথাযথভাবে সঠিক অনুমান সরবরাহ করা শুরু করে।

আমি এটিও উল্লেখ করতে চাই যে অনুমানগুলি সাধারণত বড় চিত্রের চেয়ে ভাল হয় এবং স্বল্পমেয়াদী পরিমাপের জন্য নয়। উদাহরণস্বরূপ, বিকাশকারী 2 দিন অনুমান করে তবে এটি 8 লাগে takes ভাল বিকাশকারী পরীক্ষার পরিবেশ স্থাপন এবং একটি সিমুলেটর বিকাশের জন্য অ্যাকাউন্ট করেন নি বা তাদের শিখতে হবে এমন একটি সম্পূর্ণ নতুন প্রযুক্তি রয়েছে বা তারা কোনও বাগে আটকে গেছে got তারা বুঝতে পারেনি বা কার্যকারিতা বিদ্যমান সিস্টেমের একটি রিফ্যাক্টরিং প্রয়োজন। আপনি ছোট কাজের জন্য সর্বদা এই ধরণের জিনিসগুলির পূর্বাভাস দিতে পারবেন না। তবে, একটি সম্পূর্ণ প্রকল্প চলাকালীন 6 দিনের কম সময়কাল গ্রহণ করে অন্যান্য অতিরিক্ত কাজগুলি দ্বারা অতিরিক্ত 6 দিন ধুয়ে যেতে পারে।

Answer 6

আমি নিজের থেকে কয়েকটি ছোট প্রকল্পের একমাত্র বিকাশকারী হয়েছি এবং একটি বড় টিমের সাথে কাজ করার কিছু শিল্প অভিজ্ঞতা আছে। আমি লক্ষ করেছি যে একটি বড় সংস্থা যে কৌশলগুলি ব্যবহার করে তা অগত্যা একটি ছোট দলের জন্য কাজ করে না। এক পর্যায়ে আমি কোড লেখার চেয়ে বেশি পরিকল্পনা এবং ডকুমেন্টেশন করছিলাম। আমি আপনাকে পরামর্শ দিচ্ছি যে আপনি প্রথমে বিভিন্ন কৌশল (অন্য উত্তরগুলি কিছু দুর্দান্ত অন্তর্দৃষ্টি সরবরাহ করে) এবং সরঞ্জাম ব্যবহার করে প্রথমে কাজ করার একটি ভাল উপায় সন্ধান করার চেষ্টা করুন, এতে আপনার কিছুটা সময় এবং প্রচেষ্টা ব্যয় করতে হবে তবে পরে আপনি এটি থেকে উপকৃত হবেন। আমি দরকারী বলে মনে করেছি যে কয়েকটি সরঞ্জাম / কৌশলগুলি হ'ল:

-প্রাইভোটাল ট্র্যাকার - গল্পের উপর নজর রাখার জন্য দুর্দান্ত কর্মসূচি এবং ভাঙ্গন ভাঙতে উত্সাহিত করে, এটি গল্পগুলিতে প্রবেশের ক্ষেত্রে দ্রুত আলোকপাত করে এবং স্বয়ংক্রিয়ভাবে বেগকে হ্রাস করে। https://www.pivotaltracker.com/ ।

- ডকুমেন্টেশনের জন্য জিডোকস একসাথে একাধিক ব্যবহারকারীর সম্পাদনা এবং আলোচনা করা সহজ।

-আমি যে সংস্থার জন্য কাজ করতাম আমরা তার প্রত্যেকটি গল্পের জন্য একটি সভা করতাম, এই সভাটিতে একজন সিনিয়র প্রোগ্রামারকে অন্তর্ভুক্ত করতে হবে যেহেতু কোনও কাজ কতক্ষণ সময় নেবে সে বিষয়ে বিচার করার ক্ষেত্রে সে আরও ভাল হবে। কোনও কার্যক্রমে কী কী কঠিন অংশ হতে পারে তা বিচার করার ক্ষেত্রেও তিনি আরও ভাল হতে পারেন।

সংক্ষেপে আমি বিশ্বাস করি যে ছোট দলে কাজ করার মূল চাবিকাঠি হ'ল একটি দৃ solid় পরিকল্পনা ব্যবস্থা রাখা যা দ্রুত এবং তরল। এছাড়াও গল্পটি নিয়ে যে কোনও সমস্যা তাড়াতাড়ি শনাক্ত করা যায় যাতে কোনও কার্য পরিকল্পনা করা তা মনে রাখে (এটি অন্যরকম কিছু তৈরির কারণ হতে পারে)।

আশাকরি এটা সাহায্য করবে