"কোনওভাবে" সমাধান করার জন্য আপনি কীভাবে ক্রমবর্ধমান সমস্যার সমাধান করছেন?


15

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

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

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


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

কেন এটি সংশোধন করা প্রয়োজন? যদি এটি গুরুত্বপূর্ণ না হয় এবং কখনই স্থির না হয় তবে এটি সঠিক।
বি সেভেন

উত্তর:


11

সবেমাত্র আপনার সংস্থায় যোগদান করেছেন এমন নতুন বিকাশকারীদের ঠিক করার জন্য এগুলি প্রথম ভাল যোগাযোগের বাগ। বা জুনিয়র বিকাশকারীদের সিস্টেম সম্পর্কে তাদের জ্ঞান ব্যয় করার জন্য।

যদি তা না হয় তবে আপনি এগুলিকে "ওন্টস ফিক্স" চিহ্নিত করতে পারেন, যদি তারা ঠিক করার জন্য যে সময় লাগে তা ঠিক করার পক্ষে যথেষ্ট গম্ভীর না হয়।


3
+1 ঠিক করার জন্য এটি কোনও সামাজিক সমস্যা পাশাপাশি কোনও প্রযুক্তিগত সমস্যাও হতে পারে। কখনও কখনও আপনাকে কেবল না বলতে হবে। আপনি যদি বাগগুলি স্থির করতে থাকেন, বিশেষত তুচ্ছ বা অতিরিক্ত অতিরিক্ত বৈশিষ্ট্যগুলির অনুরোধ করে মানুষের প্রত্যাশা বাড়বে এবং তারা আরও জিজ্ঞাসা করতে থাকবে।
কিও

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

6
@ মার্কোদিনাচি - আপনি "ব্যয়বহুল" কী রেখেছেন তার উপর এটি নির্ভর করে। স্বল্পমেয়াদী দর্শন সহ আপনি সঠিক। তবে যদি প্রকল্পটি দীর্ঘকাল স্থায়ী হয়, জুনিয়র প্রোগ্রামারকে 'ফিক্স বাগ' অ্যাসাইনমেন্ট দেওয়া বিনিয়োগ হিসাবে দেখা যায়।
mouviciel

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

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

11

বাগটি ছাড়াই অ্যাপ্লিকেশনটি আরও মূল্যবান হলে কেবল আপনার একটি বাগ ঠিক করা উচিত।

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

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

কিছু সংস্থাগুলি যদি এখনও বাকী মুলতুবি থেকে থাকে তবে নতুন কোডের একটি লাইন লিখেন না। অন্যরা প্রসবের আগে টেস্টিং পর্ব পর্যন্ত বিরক্ত করে না।

আপনার সংস্থায় আপনি স্পষ্টতই নতুন বাগগুলি ঠিক করার আগে অনেক সময় দিতে দিচ্ছেন যাতে তারা জমে থাকে। দলের মনোবলের পক্ষে বিশাল আকারের বাগের তালিকা দেখতে পাওয়া খারাপ।

আমি আপনাকে বিদ্যমান বাগগুলি বাছাই করার জন্য কেবল একটি দিন ব্যয় করার পরামর্শ দিচ্ছি, যা ঠিক করার যোগ্য এবং সেগুলি ঠিক নয় এবং পরবর্তী মাইলফলকের আগে সমস্যাগুলি সমাধানের লক্ষ্য নিয়ে বিদ্যমান টিম সদস্যদের ঠিক করার জন্য একটিকে নির্ধারিত করুন ing ।


6

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


1
এটি একটি ভাল কৌশল - বছরের পর বছর ধরে আপনার প্রতি ঝুঁকছে এমন একটি ত্রুটিগুলি জেনে রাখা চিরদিনের জন্য কম্বলটির তলদেশে বয়ে যেতে পারে এটি মোকাবেলার জন্য দুর্দান্ত প্রেরণা।
স্টিভ জ্যাকসন

2

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

  • যদি আপনার বস খুব বেশি টিকিট খোলার বিষয়ে চিন্তা করে তবে প্রথমে তুচ্ছ জিনিসগুলি তৈরি করবেন না। আপনার প্রেগাম্যাটিক হওয়া উচিত এবং কোনও সুবিধা / বৈশিষ্ট্য যুক্ত করা উচিত নয় যার কোনও সুবিধা নেই। যদি এটি আপনার কোডকে কিছু কোড পোলিশ করতে বা ইউআইকে টুইঙ্ক করা সহজ করে তোলে তবে অবশ্যই এটি যুক্ত করুন। পণ্যটিতে সামান্য ত্রুটিগুলি ঠিক করার চেষ্টা করে নিজের জন্য কাজ করবেন না, কিছুই সঠিক নয়।
  • বর্তমান মাইলফলকে গুরুত্বহীন বাগ / বৈশিষ্ট্যগুলি রাখুন তবে কম অগ্রাধিকারের অধীনে। যদি সমস্যা সম্পর্কে আরও অভিযোগ / অনুরোধ উল্লেখ করা থাকে তবে আপনি অগ্রাধিকারটি বন্ধ করতে পারেন।
  • আপনি যা ঠিক করতে পারবেন না তা বন্ধ করুন / সমাধান করুন, পুনরুত্পাদন করতে পারবেন না, নকল ইত্যাদি Some কিছু বাগগুলি সংশোধন করার জন্য খুব তুচ্ছ বা এগুলি বৈশিষ্ট্য অনুরোধ যা অনেক বেশি সময় নেয়। কখনও কখনও আপনাকে এই সংশোধন / বৈশিষ্ট্যগুলির জন্য অনুরোধকারী ব্যক্তিকে কেবল বলতে হবে "না দুঃখিত, আমাদের সময় নেই"।
  • বাগ হিসাবে প্রয়োজনীয় হিসাবে অগ্রাধিকার দিন এবং আপনার টিকিট তালিকাটি অগ্রাধিকার এবং মাইলফলক অনুসারে বাছাই করুন।
  • যদি তারা মাইলফলক তৈরি করতে না যায় তবে তাদের ভবিষ্যতের মাইলফলক হিসাবে সরিয়ে দিন।
  • টিকিট যদি অন্য কোনও টিকিটের কাজ শেষ হওয়ার উপর নির্ভরশীল থাকে তবে এটিকে অবরুদ্ধ হিসাবে চিহ্নিত করুন বা টিকিটটিকে একটি শ্রেণিবিন্যাসে व्यवस्थित করুন যাতে এটি টিকিট-এক্স এবং টিকিট-y এর সাথে সম্পর্কিত obvious
  • যদি কোনও টিকিটের জন্য কারও কাছ থেকে কিছু প্রতিক্রিয়া প্রয়োজন হয় তবে সেটিকে সেই ব্যক্তির কাছে বরাদ্দ করুন।

শেষ পর্যন্ত আপনার কাছে সর্বদা কম অগ্রাধিকারের টিকিট থাকবে, তবে উপরের পয়েন্টগুলি আপনাকে এটি হ্রাস করতে সহায়তা করবে।


2

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

স্থগিত ইস্যুগুলির তালিকাটি এমন কিছু যা আমি পর্যায়ক্রমে পর্যালোচনা করি (তবে প্রায়শই নয়) প্রয়োজনমতো পুনরায় খোলার জন্য।


1

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

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