ইস্যু ট্র্যাকিং সিস্টেম ব্যবহারের অসুবিধাগুলি সম্পর্কে গবেষণা আছে? [বন্ধ]

Question

ইস্যু ট্র্যাকিং সিস্টেমগুলি আমি পছন্দ করি না কারণ:

• এটিতে বিষয়গুলি বর্ণনা করতে খুব বেশি সময় লাগে। এটি এর ব্যবহারকে নিরুৎসাহিত করে।
• আপনি আপনার বাগগুলি রাখার জন্য একটি জায়গা তৈরি করেন। এবং যদি তাদের জন্য কোনও জায়গা থাকে তবে লোকেরা সাধারণত কোনও বাগ কারণ ঠিক করতে খুব বেশি যত্ন নেয় না কারণ তারা এটি সেখানে রাখতে পারে যাতে কোনও দিন কেউ এটি ঠিক করতে পারে (বা না)।
• সময়ের সাথে সাথে ত্রুটির তালিকাগুলি এত দীর্ঘ হয়ে যায় যে কেউ আমাদের সাথে প্রচুর সময় ব্যয় করে আর এটিকে মোকাবেলা করতে পারে না।

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

আমি কি এখানে একা আছি? ইস্যু ট্র্যাকিং সিস্টেম ব্যবহারের অসুবিধাগুলি (বা দুর্দান্ত সুবিধা) সম্পর্কে অধ্যয়ন (বই / নিবন্ধ / যাই হোক না কেন) আছে?

Comments

ভোট বন্ধ, খুব স্থানীয়করণ। সংস্থার বাগ-হ্যান্ডলিংয়ের প্রক্রিয়াটি না করে এখানে সমস্যাটি ট্র্যাকিং সিস্টেমগুলির সাথে উপস্থিত বলে মনে হচ্ছে না।

— P.Brian.Mackey

আপনি কোন ইস্যু-ট্র্যাকিং সিস্টেমগুলি চেষ্টা করেছেন (এটি পোস্টের পরে নোট এবং হোয়াইটবোর্ড বাদে)? তাদের ব্যবহার প্রায় প্রক্রিয়া কি ছিল?

— হতাশ

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

— হতাশিত

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

— s_heitt

আপনি একটি পোস্টে একটি স্ট্যাক ট্রেস কীভাবে সংযুক্ত করবেন? বা একটি স্ক্রিনশট? বা একটি ত্রুটি বার্তা?

— জে কে।

Answer 1

এটিতে বিষয়গুলি বর্ণনা করতে খুব বেশি সময় লাগে। এটি এর ব্যবহারকে নিরুৎসাহিত করে।

আপনি যদি কোনও বাগ বর্ণনা করতে না পারেন তবে কীভাবে আপনি এটি ঠিক করতে শুরু করতে পারেন?

আপনি আপনার বাগগুলি রাখার জন্য একটি জায়গা তৈরি করেন। এবং যদি তাদের জন্য কোনও জায়গা থাকে তবে লোকেরা সাধারণত কোনও বাগ কারণ ঠিক করতে খুব বেশি যত্ন নেয় না কারণ তারা এটি সেখানে রাখতে পারে যাতে কোনও দিন কেউ এটি ঠিক করতে পারে (বা না)।

এটি আপনার দলের সফটওয়্যার নিয়ে নয় with

সময়ের সাথে সাথে বাগ তালিকাগুলি এত দীর্ঘ হয়ে যায় যে কেউ আমাদের সাথে প্রচুর সময় নেয়, এটি আর মোকাবেলা করতে পারে না।

আবার আপনার দলের সাথে কোনও সমস্যার বর্ণনা দিচ্ছেন।

বাগ ট্র্যাকিং সফ্টওয়্যারটির বিন্দুটি আপনার দলকে বাগগুলি ঠিক করতে উত্সাহিত করতে সহায়তা করা নয়, এটি একটি রেকর্ড রাখতে হবে যাতে আপনি বাগের কারণটি সন্ধান করতে পারেন এবং সেগুলি আবার ঘটতে বন্ধ করে দিতে পারেন। কোনও সফ্টওয়্যার কখনওই ভাল ম্যানেজমেন্টের জন্য প্রতিস্থাপন হতে পারে না।

Comments

ট্র্যাকিং সফ্টওয়্যার বাগগুলিও ঠিক করতে ঠিক রাখতে সহায়তা করে। একটি স্টিকি নোট পড়তে পারে এবং আপনি যদি ডানদিকে কাজ করতে পারেন এমন চারটি বাগ আপনার কাছে যদি আসে তবে আপনি তিনটি ঠিক করতে পারেন এবং চতুর্থটি ভুলে যেতে পারেন। আপনি বাগগুলির কারণগুলিতে কোনও মনোযোগ না দিলেও এটি কার্যকর।

— ডেভিড থর্নলি

এবং আপনি অনুপাত হল ব্যবহার করতে পারে আপনার টিমের সাথে সমস্যাটি সমাধানের জন্য -> en.wikipedia.org/wiki/Gamification

— marc.d

@ জোয়াওবসকো: হাতে লিখিত টিকিটগুলি হারিয়ে যাবে, স্ক্রিবিলে যাবে, দুর্ঘটনার শিকার হয়ে ছুঁড়ে যাবে ... মুখোমুখি কথোপকথনগুলি দুর্দান্ত যখন আপনি ফটোগ্রাফিক স্মৃতি নেই এমন লোকদের কাছে জটিল বাগগুলি বর্ণনা করছেন except লোকেরা কথোপকথন থেকে জিনিসগুলি ভুলে যাবে , কারণ তারা চায় না বরং কেবল তাই ঘটে।

— হতাশ

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

— হতাশ

@ ব্যবহারকারী 1062120: "বাগগুলি রাখার কোনও জায়গা না থাকলে লোকেরা এটি আরও প্রায়শই সংশোধন করতে শুরু করে" - বা তারা বাগগুলি উপেক্ষা ও ভুলে যাওয়া শুরু করে। এটি "মানুষকে অনুপ্রাণিত করার কৌশল" নয় বরং একটি দুর্বলতাটিকে শক্তিতে রূপান্তরিত করার একটি অযৌক্তিক প্রচেষ্টা attempt

— মাইকেল বর্গওয়ার্ট

Answer 2

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

তবে, যদি বিকাশকারীরা যত্নবান হন এবং প্রকল্পটি আকারের চেয়ে তুচ্ছ থেকে বড় হয় এবং এতে একক বিকাশকারী ছাড়াও আরও কিছু থাকে এবং এর মধ্যে রয়েছে একরকম পরিচালনাও (যা সব বাস্তব বাস্তব প্রকল্পে বেশ সাধারণ) ), শীঘ্রই এই জাতীয় প্রশ্ন উঠবে:

1. প্রথমে কোন খোলা বাগ ঠিক করা উচিত? (দ্রষ্টব্য: একটি বুদ্ধিমান প্রকল্পে, এটি কোনও পণ্য বিকাশকারী দ্বারা নয়, পণ্য মালিক এবং / বা পরিচালনা দ্বারা সিদ্ধান্ত নেওয়া উচিত - যার জন্য তাদের অবশ্যই প্রথমে সমস্ত খোলা বাগ সম্পর্কে সচেতন হতে হবে!)
2. আমাদের কতগুলি খোলা বাগ রয়েছে এবং এর তীব্রতা কী?
3. এর মধ্যে কোনটি অবশ্যই প্রকাশের জন্য প্রস্তুত হওয়ার আগে ঠিক করতে হবে?
4. এই সংশোধনগুলির জন্য কত সময় পরিকল্পনা করতে হয় - প্রায়শই বাড়ে: একটি বাগ ঠিক করতে গড় সময় নিতে কত সময় লাগে?
5. গত প্রকাশে ক্লায়েন্টরা কতটি বাগ রিপোর্ট করেছে?
6. এই-এবং-এই বাগটি কে সমাধান করেছে, কখন এবং কী (কোড / কনফিগারেশন / ডেটা) পরিবর্তনগুলি জড়িত ছিল?
7. আমরা যে প্রকাশ করতে চলেছি সেটিতে কি বাগ ফিক্সগুলি অন্তর্ভুক্ত রয়েছে?
8. ...

আপনার পোস্ট নোটের উপর ভিত্তি করে আপনি কি এই জাতীয় প্রশ্নের উত্তর [আপডেট] পুনরাবৃত্তিযোগ্য, নির্ভরযোগ্য ও দক্ষতার সাথে [/ আপডেট] করতে পারেন?

হ্যাঁ, ইস্যু ট্র্যাকারে বাগ ডেটা প্রবেশ করা কিছু ওভারহেডকে আবশ্যক। তবে এটি সঞ্চিত বাগের ডেটা থেকে অনুসন্ধানের সময় এবং প্রচুর পরিমাণ সাশ্রয় করার চেয়ে বেশি ক্ষতিপূরণযোগ্য।

Comments

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

— ব্যবহারকারী 1062120

@ ব্যবহারকারী 1062120: এবং অন্য সকলেই বলছে আপনি খুব, খুব ভুল wrong পোস্ট-তার হয় একটি বিষয় ট্র্যাকিং সিস্টেম, শুধু একটি অত্যন্ত দরিদ্র এক যে অপরিহার্য বৈশিষ্ট্য অনেকটা অভাব আছে।

— মাইকেল বর্গওয়ার্ট

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

— প্যাটার টারিক

@ ব্যবহারকারী 1062120, উদাহরণস্বরূপ পরিকল্পনাগুলি উপরের প্রশ্নোত্তর 1 - আসুন অগ্রাধিকার অনুযায়ী স্টিকি নোটগুলি পুনরায় সাজানো যাক। শীঘ্রই প্রধানমন্ত্রী কিউ 2 কে জিজ্ঞাসা করলেন: ওফ, তীব্রতার সাথে পুনরায় সাজান। তবে কিউ 1 টি এখনও উন্মুক্ত, সুতরাং এখন অগ্রাধিকার অনুসারে এগুলি আবার বাছাই করুন। ওহো, জো-এর ডেস্কে থাকার কারণে 3 টি পোস্ট-পরে এড়িয়ে গেছে - আবার শুরু করুন! তারপরে Q6 - আসুন historicalতিহাসিক পোস্টগুলি সংরক্ষণ করে সেই বাক্সগুলি খনন করুন, যথাযথ একটিটি সন্ধান করার জন্য হাতের সাহায্যে সমস্তটি ব্রাউজ করুন, তারপরে পরিবর্তনগুলি বর্ণনা করার অর্থ এর পিছনে স্ক্রিবিলে পড়ার চেষ্টা করুন ... ওফফ, কেউ একটি খুলল কাছাকাছি উইন্ডো, আপনার পোস্টটিকে বাতাসের মাধ্যমে পালানো থেকে রক্ষা করার জন্য

— ছুটে যান

Answer 3

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

কিছু নিবন্ধ / অধ্যয়ন যা আপনার আগ্রহী হতে পারে জেন্ডার জেন্ডার ব্যবহার এবং বাগ ট্র্যাকিং সিস্টেমের ব্যবহার নিয়ে এই ফরাসী অধ্যয়নের বিষয়ে আলোচনা করে এই নিবন্ধটি অন্তর্ভুক্ত করে ।

Comments

রেফারেন্সের জন্য আপনাকে অনেক ধন্যবাদ। আমি তাদের একবার দেখে নেব। এবং হ্যাঁ, এটি এখানে 3 টি ছোট দলের মধ্যে কাজ করছে।

— ব্যবহারকারী 1062120

রেফারেন্সগুলির জন্য +1, যা প্রশ্নে স্পষ্টতই জিজ্ঞাসা করা হয়েছিল।

— mattnz

Answer 4

পড়াশোনা হতে পারে তবে ক্ষেত্রের লোকদের কঠোর অর্জিত অভিজ্ঞতা better বেশিরভাগ ইস্যু ট্র্যাকিং সিস্টেমগুলি তাদের নকশা চালানোর প্রক্রিয়াগুলিতে ভোগে। ইস্যু ট্র্যাকারদের প্রায়শই 2 টি পৃথক শ্রেণীর ব্যবহারকারীদের সমর্থন করা প্রয়োজন:

1. উন্নয়ন দল
2. সিস্টেমের ব্যবহারকারীরা

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

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

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

টিএল; ডিআর আপনার প্রক্রিয়াটিতে ফোকাস দিন, সহজ সরঞ্জামগুলি বেছে নিন এবং সমস্যাগুলি সামনে আসার সাথে সাথেই সমাধান করুন।

Comments

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

— ব্যবহারকারী 1062120

Answer 5

গুরুত্বপূর্ণ বাগগুলি উপস্থিত হওয়ার সাথে সাথে হত্যা করা

মনে হচ্ছে আপনি এখানে খোলা দরজা ভেঙেছেন। গুরুত্বপূর্ণ বাগগুলি যত তাড়াতাড়ি সম্ভব "হত্যা" হয়ে যায় আপনি ইস্যু ট্র্যাকার ব্যবহার করেন বা না তা বিবেচনা না করেই।

• ওহ এবং অংশ "তারা প্রদর্শিত হিসাবে" বেশ পিচ্ছিল বিটিডাব্লু। একটি প্রকল্পে আমাদের একটি গুরুত্বপূর্ণ ত্রুটি ছিল যা পুরো পণ্যটিকে ব্যবসায়ের বাইরে ফেলে দেওয়ার হুমকি দেয় (এর চেয়ে গুরুত্বপূর্ণ আরও কী হতে পারে?)। এটি অত্যন্ত জটিল (আর্কিটেকচার ত্রুটি) ছিল এবং আমরা জানতাম এটি ঠিক করতে এটি বেশি সময় নিতে পারে। গ্রাহকরা দয়া করে আমাদের এক বছর দেওয়ার জন্য সম্মত হন (আমাদের পণ্যটি ফেলে দেওয়ার আগে) এবং আমরা এটি প্রায় এক বছরে করেছিলাম।

---

ইস্যু ট্র্যাকারদের হিসাবে, আমি এগুলি প্রায় দশ বছর ধরে ব্যবহার করে আসছি এবং একটি নিয়ম হিসাবে, আমার চারপাশের সমস্ত প্রোগ্রামাররা ট্র্যাকারের সাথে বেশ অল্প সময় ব্যয় করেছিল (নোট আমি প্রোগ্রামারদের নিয়ে কথা বলছি; পরিচালকরা ভিন্ন গল্প)। আমি কেসগুলি (খুব কমই) দেখেছি যখন এটি তখন ছিল না - এই সমস্ত ক্ষেত্রে কিছু মারাত্মকভাবে ভেঙে গিয়েছিল।

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

• আসলে আপনি f2f সম্পর্কে জিজ্ঞাসা করলে মনে হয় যে আপনি (ভুল) বিষয়গুলি নিয়ে আলোচনার জন্য ট্র্যাকার ব্যবহার করছেন - এটি এর উদ্দেশ্য নয়। এর উদ্দেশ্যযুক্ত ব্যবহারটি সনাক্ত করতে, কেবল ধীরে ধীরে এবং স্পষ্টভাবে এর নামটি বানান: ট্র্যাকিং সিস্টেম ইস্যু করুন ।

বাগের তালিকা এত দীর্ঘ হয়ে যায় gets

আমার অভিজ্ঞতা হিসাবে, উপরে একটি সুবিধা নয় কোনও সমস্যা নয়।

সঙ্গে দীর্ঘ বাগ তালিকা ডেভেলপারদের অনেক দূরে এগিয়ে একটি সারিতে পরিকল্পনা সংশোধন করা হয়েছে সেট আপ করতে পারেন। এটি যতটা উত্পাদনশীল তা পায়; আমার সাথে এই কাজ করার জন্য যখন সারি থাকে তখন এটি মূলত আমার একটি নির্বান। প্রথম বাগ - ফিক্স - সম্পন্ন, দ্বিতীয় বাগ - ফিক্স - শেষ, পরবর্তী বাগ - ফিক্স - সম্পন্ন ইত্যাদি No কোনও বোকা বাধা নেই, ওহ-তাই-দক্ষ F2f কথোপকথনের সাথে কোনও বেদনাদায়ক বিঘ্ন নেই, খাঁটি প্রবাহ ।

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

Comments

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

— মাইকেল বর্গওয়ার্ট

@ মিশেলবার্গওয়ার্ড হ্যাঁ এত দীর্ঘ তালিকান যে আমার অভিজ্ঞতায় কেউ এটিকে মোকাবেলা করতে পারে না যতক্ষণ না 200, 400, 1000 এর মতো ভীতিকর সংখ্যায় কেউ হিমায়িত হয় না I আমি মাত্র কৌতূহলের বাইরে দ্রুত চেক করেছি - গত বছরের জন্য আমি 300+ সমস্যাগুলি স্থির করেছি - আমি একা (!)। কৌতূহলের বাইরে আমি অন্যান্য ছেলেদেরকেও এই ভেবে দেখেছিলাম যে আমি অনন্য - না, 200-400 ফিক্স / বছর কেবলমাত্র গড় হার হিসাবে প্রদর্শিত হয়। 500 বাগ তবে ভয়ের এগুলি দেখতে, 4-5 বিকাশকারী, পিষ্টক :) টুকরা জন্য কাজ মাত্র সাড়ে তিন বছরের হতে পারে

— মশা