রক্ষণাবেক্ষণে ব্যয় করা সময়ের জন্য শিল্প গড়

Question

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

তাহলে কি নতুন কোড বিকাশের বিরুদ্ধে বাগ ফিক্সিংয়ের জন্য সময় মতো কোনও মেট্রিক রয়েছে? বা সামগ্রিকভাবে শিল্পের জন্য বাগ ফিক্সিংয়ের কোনও অভিজ্ঞতাগত বিশ্লেষণ আছে কি? 50% কি বাগ ফিক্সিং ব্যয় খুব বেশি, বা ঠিক? প্রায় 20% বা 33%?

আমি ব্যক্তিগত অভিজ্ঞতা থেকে অজানা প্রমাণগুলি গ্রহণ করতে পেরে আনন্দিত কারণ এটি এখানে কিছু পরিসংখ্যানের অংশ হিসাবে তৈরি হয়েছিল যে আমি আমাদের পারফরম্যান্সের সাথে তুলনা করতে পারি।

Comments

আপনার পরিচালক খুব অজ্ঞ মনে হচ্ছে। রবার্ট এল গ্লাসের সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের বিষয়গুলি এবং ভ্রান্তিগুলির ক্ষেত্রে বিশেষত "ফ্যাক্ট 43. রক্ষণাবেক্ষণ একটি সমস্যা নয়, সমাধান" like Wikipedia নিবন্ধটি 80% প্রচেষ্টা সফ্টওয়্যার রক্ষণাবেক্ষণ ব্যয় উল্লেখ

— মশা

কি বাস্তব সমস্যা? আপনার কি কোনও মানের সমস্যা আছে? আপনার প্রক্রিয়া কি আসলেই অদক্ষ? অথবা আপনার ম্যানেজার কি কেবল এই সফটওয়্যারটির জন্য এতটা ব্যয় করতে চান নি?

— কেভিন ক্লিন

@gnat: আপনার মন্তব্যটি সেরা উত্তর

— কেভিন cline

@kevincline ধন্যবাদ - উত্তর রূপান্তরিত মন্তব্য

— মশা

রক্ষণাবেক্ষণটি কেবল বাগ (ত্রুটিগুলি) ঠিক করার বিষয়ে নয় এবং এর পরিমাণ পৃথক প্রকল্পগুলির জন্য (= কোনও নির্দিষ্ট উত্তর নেই) প্রচুর পরিমাণে পরিবর্তিত হয়। আমার কাছে মনে হচ্ছে আপনার বরং মানের সমস্যা আছে।

— মার্চ

Answer 1

একজন পরিচালক সম্প্রতি ঘোষণা করেছিলেন যে বাগগুলি ঠিক করতে অনেক বেশি সময় ব্যয় করছিলেন।

উপরের শব্দগুলি খুব অজ্ঞ। রবার্ট এল গ্লাসের সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের বিষয়গুলি এবং ভ্রান্তিগুলির ক্ষেত্রে বিশেষত "ফ্যাক্ট 43. রক্ষণাবেক্ষণ একটি সমস্যা নয়, সমাধান" like

উইকিপিডিয়া নিবন্ধে সফ্টওয়্যার রক্ষণাবেক্ষণে ব্যয় করা ৮০% প্রচেষ্টা উল্লেখ করা হয়েছে।

আমার ম্যানেজার দিলবার্টের পিএইচবি প্রতিভা হিসাবে দেখায় :)

হুঁ দেওয়া উপরে আমিও বিশ্লেষণ মধ্যে কিছু প্রচেষ্টা নিতাম সমস্ত অনুরোধ আপনাকে যা কিনা বাগ প্রকৃতপক্ষে।

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

Comments

বাগ ফিক্সিং! = রক্ষণাবেক্ষণ! বাগ ফিক্সিংয়ের অর্থ আপনি সিস্টেমে ত্রুটিগুলি কোড করেছিলেন এবং সঠিক কার্যকারিতা পুনরুদ্ধার করার জন্য সেগুলি ঠিক করা দরকার । রক্ষণাবেক্ষণের দ্বারা আমি বোঝাতে চাই যে সমস্ত কাজ যেমন বাগ ফিক্স, স্কেলাবিলিটি উন্নতি, হার্ডওয়্যার স্থানান্তরকরণ, এবং কর্মক্ষমতা উন্নতি ইত্যাদি I আমি বলব যে কেবল বাগ ফিক্সগুলিতে ব্যয় করা 25-30% এরও বেশি সময় অবিলম্বে একটি প্রশাসনের কল প্রয়োজন। মাঝারি আকারের এন্টারপ্রাইজ সিস্টেমের জন্য রক্ষণাবেক্ষণ সামগ্রিকভাবে 40-50% ব্যয় করা ব্যয় যুক্তিযুক্ত বলে মনে হয়।

— অপুরভ খুরসিয়া

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

— স্টিভটেক

আপনার উইকিপিডিয়া নিবন্ধের উদ্ধৃতি ভুল! এটি বলে যে "80% রক্ষণাবেক্ষণের প্রচেষ্টা অপরিশোধক ক্রিয়াকলাপের জন্য ব্যবহৃত হয়" তবে এটি নকশা বা কোডিং বা অন্যান্য কাজের তুলনায় রক্ষণাবেক্ষণের সময় সম্পর্কে কিছুই বলেনি।

— টোবিয়াস কানৌস

Answer 2

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

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

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

Comments

আপনারা যা বর্ণনা করেন তা হ'ল আমাদের কাছে যা আছে তবে এতে কোনও পরিবর্তন হয় না :(

— gbjbaanb

Answer 3

এটি আপনার কতগুলি কোড আছে, কতক্ষণ এটি চলেছে ইত্যাদি উপর নির্ভর করে etc.

সফ্টওয়্যারগুলিতে বাগগুলি স্থির করতে ব্যয় করা সময়টি মুক্তির প্রথম front-১২ মাসের মধ্যে সামনের ভার হওয়া উচিত, তবে সময় অসীমের কাছে যাওয়ার সাথে সাথে প্রাথমিক বিকাশে ব্যয় করা সময় বনাম রক্ষণাবেক্ষণে ব্যয় করা সময়টি 100% ছাড়িয়ে যাবে - এটাই উপায় হবে।

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

Answer 4

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

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

আশ্চর্যের বিষয়, যখন তথ্যটি প্রকাশিত হয়েছিল, আমরা হঠাৎ করেই বলেছিলাম যে আমরা আর জিরা ব্যবহার করব না এবং এটি প্রতিস্থাপনের জন্য একটি নতুন পণ্য আনা হবে।

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

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

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

অবশ্যই, এটি জিরার মতো জটিল কিছু হতে হবে না।

আপনি যদি কম উত্পাদনের সমাধান চান তবে আপনি টাস্ক / টিকিট / বাগ / বৈশিষ্ট্য অনুরোধ ইত্যাদি ট্র্যাক করার জন্য একটি গুগল-ডক্স স্প্রেড শীট এবং জিডোকস বিজ্ঞপ্তি এপিআই ব্যবহার করতে পারেন

জিডোকস নিজেই এখন ওয়েব-হুক এবং সমস্ত ধরণের জিনিস জারি করতে পারে।

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

তবে সাধারণভাবে, পণ্য প্রাকৃতিক আজীবনের 100% এর মধ্যে গ্রিনফিল্ড দেব এবং রক্ষণাবেক্ষণের মধ্যে বিভাজন সাধারণত 20/80 হয়, আ.ল.এম. (অ্যাপ্লিকেশন লাইফটাইম ম্যানেজমেন্ট) চক্রের বেশিরভাগ ব্যয় রক্ষণাবেক্ষণ এবং সহায়তা ব্যয়ের জন্য নেওয়া হয়।

বাগ ফিক্সিংয়ের জন্য অতিরিক্ত সময় ব্যয় করার মতো কোনও জিনিস নেই, বগ-ফ্রি কোড লেখার পক্ষে কেবল এটি সম্ভব নয় be

ভাল পরীক্ষা এবং অবিচ্ছিন্ন একীকরণ নীতিগুলি ঘাটতি হ্রাস করবে, তবে আপনি কখনই এটি পুরোপুরি মুছে ফেলবেন না।

যে কেউ অন্যথায় (আইএমএইচও) বিশ্বাস করে তার যথাযথ রায় দেওয়ার পক্ষে পর্যাপ্ত জ্ঞান নেই, বা অন্ধ (আরও সাধারণ ক্ষেত্রে) আসলে সফ্টওয়্যারটি লেখার পক্ষে কতটা কঠিন।

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

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

Comments

"বাগ ফিক্সিংয়ের জন্য খুব বেশি সময় ব্যয় করার মতো কোনও জিনিস নেই" - কী পরিমাণ বাজে। আপনার সংস্থাটি বাজারে প্রতিযোগিতামূলক থাকতে না পারার কারণে যে বাগগুলি স্থির করে তার জন্য পর্যাপ্ত সময় ব্যয় করে (কারণ আপনি জিনিসগুলি না করে বাগ ফিক্স করে যাচ্ছিলেন ), আপনি বাগ ফিক্সিংয়ের জন্য অনেক বেশি সময় ব্যয় করেছেন ...

— টেলাস্টিন

আর বিকল্প? - আপনি বাগ ফিক্সিংয়ের জন্য পর্যাপ্ত সময় ব্যয় করবেন না এবং আপনার অ্যাপটি ক্র্যাশ, জ্বলতে এবং আপনার প্রতিযোগী আপনাকে কার্যকরভাবে বাজারের জায়গা থেকে দূরে সরিয়ে আপনার সমস্ত কাস্টম গ্রহণ করে। কৌতুকটি (এবং এগুলির সব থেকে শক্ত অংশ) আসলে একটি গ্রহণযোগ্য ভারসাম্য খুঁজে পাওয়া।

— shawty

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

— shawty

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

— টেলাস্টিন

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

— শাওটি