পরিবর্তনের ঝুঁকি নিয়ে কাজগুলি / বাগগুলি শ্রেণীবদ্ধ করুন


17

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

আমরা JIRA ব্যবহার করি তাই আমি এই অনুমানের উপর নজর রাখতে সমস্যাগুলি লেবেল করা শুরু করি। আমি লক্ষ্য করেছি যে আমি বাগ / টাস্কটিকে শ্রেণিবদ্ধ করতে বেশ কয়েকটি মেট্রিক ব্যবহার করে শেষ করেছি:

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

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

আগে কেউ এই ধরণের জিনিস নিয়ে কাজ করেছে?

উত্তর:


25

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

বহুমাত্রিক বাগ ট্র্যাকিং বর্ণনা করে এমন একটি ব্লগ পোস্ট এতে বিকাশকারী দৃষ্টিভঙ্গি: পিইএফ এবং আরইভি সহ এটিকে সম্বোধন করে।

পিইএফ মানগুলি ব্যবহারকারীর দৃষ্টিভঙ্গি:

  • পি ‍য়াইন - বাগটি দেখা দিলে এটি কত বেদনাদায়ক?
  • আইফোর্ট - চারপাশে কাজ করতে কত প্রচেষ্টা লাগে?
  • এফ ঃ ফ্রিকোয়েন্সি - বাগটি কতবার ঘটে?

আরইভি পাশটি বিকাশকারীর দর্শন থেকে:

  • আর ইস্ক - ঠিক কতটা ঝুঁকিপূর্ণ?
  • ‍ফোর্ট - ঠিক করতে কত প্রচেষ্টা লাগবে?
  • ভি ‍রিফিয়েবিলিটি - বাগটি স্থির হয়েছে তা যাচাই করা কতটা সহজ?

এর প্রত্যেকটি 1 টি কম / সহজ এবং 9 টি উচ্চ / শক্ত হওয়ার সাথে একটি 1..9 স্কেলে পরিমাপ করা হয়। PEF এবং REV এর জন্য স্কোর দেওয়ার জন্য নম্বরগুলি একসাথে যুক্ত করা হয়।

বর্ণিত বিটগুলিকে সম্বোধন করে এমন অংশ:

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

আরইভিতে বর্ণিত প্রচেষ্টা এবং ঝুঁকির মধ্যে এই ফ্যাক্টর।

হ্যাঁ, এটি এমন কিছু যা আগে লড়াই হয়েছিল। আমি (অতীতে) রেডমিনে কাস্টম ক্ষেত্রগুলির জন্য এই মডেলটি ব্যবহার করেছি এবং এটি যুক্তিসঙ্গতভাবে সফল হয়েছিল।

আপনি PEF এবং REV স্কোরগুলি তুলনা করলে এর বড় সুবিধাটি আসে advantage আপনার যদি 21 এর একটি পিইএফ এবং 7 টির আরইভি থাকে তবে এমন কোনও কিছু রয়েছে যা বড় জয় হতে পারে। যদিও 7 এর একটি PEF এবং 21 এর REV এমন কিছু বিষয় যা কিছুক্ষণের জন্য এড়ানো উচিত কারণ ঝুঁকি এবং প্রচেষ্টা পক্ষ সম্ভবত এটি নির্ধারণের সুবিধাকে ছাড়িয়ে যায়।

এরপরে আরইভি স্কোরটি দেখতে এবং কম অভিজ্ঞ বিকাশকারীকে কম ঝুঁকিযুক্ত জিনিসগুলি অর্পণ করতে পারেন (কম ঝুঁকি, উচ্চ প্রচেষ্টা প্রায়শই এই পরিস্থিতির জন্য আদর্শ) are


1
ধন্যবাদ, এই পোস্টটি খুব দরকারী। আমি অবাক হয়েছি এটি বইগুলিতে বেশি লেখা হয়নি তবে আমি সম্ভবত ভুল জায়গাগুলিতে সন্ধান করছি।
টাকটেক

@ টাকটেক আরেকটি বিট, এটি এর সাথে সম্পর্কিত হ'ল হারিয়ে যাওয়াডাউন / ২০০৮ / ২০০5 / আইপ্রোভিং-বুগ-ট্যারেজ-উইথ ইউজার- পেইন এইচটিএমএল যা বিশেষত 'ব্যথা' দিকটির ব্যবহারকারীর দিকটি পরিমাপ করার আরেকটি পদ্ধতি এবং কী এই মেট্রিকগুলি গাড়ি চালানোর জন্য ব্যবহার করা যেতে পারে (এটি 1-100 স্কেল উত্পন্ন করে যা ব্যবহারকারীর পক্ষের সমস্ত তথ্য অন্তর্ভুক্ত করে আমি এটিও দেখার পরামর্শ দিই)। এটিতে "ব্যয়" অর্পণ করার প্রলোভনটিতে নোট করুন যাতে ব্যবহারকারীর সাইড মেট্রিকের বিকাশকারী পক্ষের তথ্য অন্তর্ভুক্ত করে না।

4

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

তবে আপনি যা লিখেছেন তা বিচার করে আপনার মনে হচ্ছে দুটি সমস্যা রয়েছে:

  1. আপনি নতুন বা অনভিজ্ঞ প্রোগ্রামারদের সাথে কাজ করছেন।
  2. আপনার কোডটির (অনেকগুলি / কিছু) গুণমান সন্দেহজনক বলে মনে হচ্ছে।

'জটিলতা' ক্ষেত্রের মতো কিছু (যা আপনার কাজ পরিচালনা এবং অগ্রাধিকার দিতে সহায়তা করবে) এর মতো কিছু প্রবর্তনের পাশাপাশি, আমি আপনাকে পরামর্শ দিচ্ছি যে উপরোক্ত দুটি সমস্যার ঝুঁকি হ্রাস করার দিকে মনোনিবেশ করুন।

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

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


1

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

আমি পরামর্শ দিচ্ছি যে বিকল্প কৌশল হ'ল কোড পর্যালোচনার একটি ব্যবস্থা প্রতিষ্ঠা করা। নবজাতকদের কৌতূহলোদ্দীপক জিনিসগুলিতে (কারণের মধ্যে) কাজ করতে দিন তবে তাদের কাজটি পুরোপুরি পর্যালোচনা করুন।

স্বল্পমেয়াদে, এটি সবার পক্ষে বেশি কাজ। দীর্ঘমেয়াদে, আপনি এমন বিকাশকারীদের পুরো টিমের সাথে সমাপ্ত হবেন যারা জটিল জিনিসগুলি পরিচালনা করতে পারবেন এবং কোড মানের হিসাবে যতদূর সম্ভব "একই পৃষ্ঠায়" থাকবেন।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.