অনুশীলনে নব্বই নব্বইয়ের নিয়ম

Question

কোডের প্রথম 90 শতাংশ প্রথম সময়ের জন্য 90% সময় বার করে। কোডের বাকী 10 শতাংশ অন্য 90 শতাংশ সময়ের জন্য অ্যাকাউন্টে।

- টম কারগিল, বেল ল্যাবস

বাস্তবে এর অর্থ কী? এই অগ্রগতিবিদরা যথেষ্ট পরিমাণে কাজ করে এবং তারা নিজের থেকে 180% দিচ্ছে নাকি?

Comments

আমরা সকলেই জানি যে 100 %কে এটি অতিক্রম করে পুনরায় সংজ্ঞায়িত করা হয়, বা এটি একটি ज्ञিত পরিমাণের 1.8 গুণ বেশি। তবে এক্ষেত্রে আমি বলব এটি সম্ভবত হাইপারবোল। দ্বিতীয় নব্বই শতাংশ সেখানে এটিকে স্মরণীয় করে রাখার জন্য, এবং উদ্ধৃতিটির শেষে একটি পাঞ্চ-লাইন যুক্ত করুন।

— এজেফারাডে

বাক্যটির মাঝামাঝি সময়ে বিকাশের সময়টির অনুমান পরিবর্তন হয়।

— মিলেনিয়ামব্যাগ

১৮০% হ'ল সময় এবং বাজেটের প্রকল্পটির ব্যয় শেষ হয়।

— এজেন্ট_এল

আমি মনে করি বিশ্রী চূড়ান্ত বাক্য থাকা সত্ত্বেও এই প্রশ্নটি কী জিজ্ঞাসা করছে তা পুরোপুরি পরিষ্কার।

— ম্যাথু জেমস ব্রিগেস

এই উক্তিটি একটি রসিকতা হিসাবে পড়ার কথা রয়েছে, সেই প্রসঙ্গে এটি বোধগম্য হয়। এটি বলছে যে শেষ 10% আপনার কল্পনার চেয়ে অনেক বেশি সময় নেবে

— রিচার্ড টিঙ্গল

Answer 1

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

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

Comments

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

— রাম্বলিউড

+1 তবে আমি অনুভব করছি যে দ্বিতীয় অনুচ্ছেদে কিছু গা bold় পাঠ্যের প্রয়োজন কারণ এটি পাঠের সত্যই গুরুত্বপূর্ণ অংশ :)

— বব টিওয়ে

Answer 2

এটি একটি সাধারণ দৃশ্যের একটি রেফারেন্স, এটি দুঃখজনকভাবে আজও ঘটে:

1. দলটিকে সমস্ত কোড লেখার জন্য প্রয়োজনীয় পরিমাণের অনুমান (যেমন অনুমান) করতে বলা হয়,
2. প্রকল্পটি "সময় এবং বাজেটে থাকার জন্য" অসংখ্য অভ্যন্তরীণ এবং বাহ্যিক চাপ নিয়ে এগিয়ে যায়,
3. সুতরাং প্রকল্পের উল্লেখযোগ্য শতাংশের জন্য, "টার্গেটে" রিপোর্ট করা হয়েছে। ভাল অগ্রগতি হয়েছে তা নিশ্চিত করার জন্য প্রথমে সহজ কাজগুলি বাছাই করে এটি প্রায়শই জটিল হয়।
4. তারপরে কিছু পর্যায়ে, একটি সমালোচনামূলক বিন্দুতে পৌঁছে যায় যেখানে বাস্তবতাটি মেনে নিতে হয়: প্রকল্পটি সময়মতো সম্পন্ন হবে না এবং মুক্তির তারিখটি পিছনে ফিরে আসে (প্রায়শই বহুবার)।

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

Comments

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

— blrfl

@ ব্লারফ্লার উত্তরটি বোঝায় না যে চঞ্চল অনুমানের সমস্যাটি শক্ত হওয়ার সমাধান করে তবে এটি ছোট অনুমান করে তার পরিণতি প্রশমিত করে।

— এরিক

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

— টিম

আমার সাথে বিশ্বাস করুন এমনকি এগিল ছিটে ফ্যানকে মারলে এবং ফুঁসে উঠবে!

— জোনএইচ

চতুর সম্পর্কে পরবর্তী চিন্তাভাবনা সরানো হয়েছে কারণ এটি উত্তরের মূল বক্তব্য থেকে স্পষ্টতই লোককে বিভ্রান্ত করছে।

— ডেভিড আরনো

Answer 3

আমি এর একটি আলাদা সংস্করণ শুনেছি (এটিকে "90-90 বিধি" বলা হয়) যা এরকম হয়:

আমি কার্যকারিতা 90% বাস্তবায়িত হয়েছে, আমার এখনও বাস্তবায়ন করতে হবে অন্যান্য 90% ।

উভয় সংস্করণই সফ্টওয়্যার পণ্যগুলি বিকাশের জন্য সঠিকভাবে অনুমানের প্রচেষ্টা এবং লোকেদের মধ্যে যে সাধারণ সমস্যাগুলি পড়ে থাকে সেগুলি উল্লেখ করে:

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

Answer 4

এই বিধিটি 80-20 বিধিটিকে পরিপূরক করে। এখন, ৮০-২০ নিয়মের অনেকগুলি ভিন্ন ব্যাখ্যা রয়েছে, তবে আমি যে দুটিটি সবচেয়ে বেশি পছন্দ করি তা হ'ল:

1. প্রথম 80% পণ্য বিকাশ 20% প্রচেষ্টা নেয়।
2. 80% ত্রুটি কোডের 20% এ রয়েছে।

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

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

নীচের লাইনটি এটি লক্ষ্যে পৌঁছানোর চেয়ে লক্ষ্যটির কাছে আসা আরও সহজ।

Comments

৮০-২০ বিধিটি এন.ইউইকিপিডিয়া.র.ইউ হিসাবে পরিচিত: উইকিপিডিয়া_প্রেটো_প্রিন্টেল

— পিটার এম - মনিকার জন্য

Answer 5

আমি উইকিপিডিয়া ব্যাখ্যাটি বেশ আলোকিত মনে করি:

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

Answer 6

বাস্তবে এর অর্থ কী? এই অগ্রগতিবিদরা কাজ পরিমাণ মতো করে এবং তারা নিজের থেকে 180% দিচ্ছে নাকি?

না, প্রোগ্রামাররা সর্বদা সময়কালে একই পরিমাণের কাজ করে। উদ্ধৃতিটি হ'ল আন্ডার-অ্যাসেটিং ব্যয় এবং অতিরিক্ত পরিমাণগুলি সম্পর্কে। 180% হল সময় এবং অর্থের পরিমাণ যা প্রকল্পের ব্যয় শেষ হয়।

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

Answer 7

বাস্তবে এর অর্থ হ'ল লোকেরা নিজেরাই মিথ্যা বলে।

যদি কোনও প্রোগ্রামার "আমরা 90% সম্পন্ন" হয়েছি এর অর্থ বৈশিষ্ট্যগুলি তৈরির 90% প্রচেষ্টা ব্যয় করা হয়েছে।

যদি কোনও প্রকল্প পরিচালক বলেন "আমরা 90% সম্পন্ন করেছি, আমার কেবল এটি শেষ করার জন্য একজনের দরকার" এর অর্থ তারা বাজেটের 90% হয়ে থাকে (এবং সম্ভবত 50% সম্পন্ন হয়েছে)। এটি কোনও অর্থ, উচ্চ প্রত্যাশা এবং খারাপ দৃষ্টিভঙ্গিহীন এক ক্লায়েন্ট।

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

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