কীভাবে টাইট টাইমলাইন এবং সময়সূচী চাপ টিসিও এবং বিতরণের সময়কে প্রভাবিত করে?

Question

একজন সফ্টওয়্যার ইঞ্জিনিয়ারিং ম্যানেজারের এক বন্ধুর বাবা দৃ emp়তার সাথে বলেছিলেন, "সময়সূচী অতিক্রম করার প্রথম কারণ হ'ল চাপ নির্ধারণ।"

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

সফ্টওয়্যার ইঞ্জিনিয়ারিং সাহিত্যের যে কোনও লিঙ্কের প্রশংসা করা হবে।

Comments

এই প্রসঙ্গে টিসিও বলতে কী বোঝায়?

— অ্যান্ড্রেস এফ।

আমি ধরে নিচ্ছি যে টিসিও হ'ল মালিকানার মোট ব্যয় । এটা কি সঠিক?

— থমাসের মালিক

@ থমাস ওভেনস তাই আমি অনুমান করেছি, কিন্তু প্রকল্পের সময়সূচী এবং বাজেটের প্রসঙ্গে কি তা বোঝা যায়? আমি ভেবেছিলাম টিসিও কোনও পণ্যের মালিকানা বোঝায় , উন্নয়ন নয় not

— আন্দ্রেস এফ।

@AndresF। আমার উপলব্ধিটি হ'ল এটি ব্যাপক - ডিজাইন, বিকাশ, চালান, রক্ষণাবেক্ষণ এবং আপগ্রেড। তবে আমি আর্থিক বিষয়গুলিতে বিশেষজ্ঞ (বা কোনও পরিমাপযোগ্য পরিমাণ অভিজ্ঞতাও নেই) নই।

— টমাস ওয়েন্স

@ থমাস ওভেনস উইকিপিডিয়া থেকে এই লিঙ্কটি বিচার করে, আমি যে ধারণা পেয়েছি তা নয়। প্রযুক্তি এবং সফ্টওয়্যার পণ্যগুলি (এবং স্থাপনা এবং রক্ষণাবেক্ষণের মতো সম্পর্কিত উদ্বেগ) সত্ত্বেও বিকাশের অবশ্যই উল্লেখ করা হয়নি (অনুসন্ধান করুন!) Is টিসিও মালিকানার সাথে সম্পর্কিত , এটি এমনকি নামেও বলে! আমার বোঝার যে TCO বিবেচনা তা চয়ন করার যা পণ্যে হয় কিনতে , যা পণ্যের না বিল্ড ।

— আন্দ্রেস এফ।

Answer 1

সময়সূচী ছাড়িয়ে যাওয়ার এক নম্বর কারণ হ'ল চাপ নির্ধারণ।

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

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

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

Comments

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

— আন্দ্রেস এফ।

স্টিভ ম্যাককনেল ক্লাসিক সফ্টওয়্যার ডেভলপমেন্ট অনুশীলন ভুলগুলির মধ্যে একটি এবং প্রকল্প সমস্যার একটি প্রধান উত্স হিসাবে "অত্যধিক আশাবাদী সময়সূচী "কে প্রশংসিত করেছেন; এটি প্রথম স্থানে নির্ধারিত সময়সীমার কারণ হবে। stevemcconnell.com/rdenum.htm

— কেবল আপনি

Answer 2

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

আপনার প্রশ্নটি যেভাবে প্রণয়ন করা হয়েছে তা বোঝায় যে সময়টি আপনার পরিবর্তনশীল এবং অন্য তিনটি (গুণমান, সংস্থানসমূহ এবং বৈশিষ্ট্যগুলির সংখ্যা) সমস্ত স্থির। সময়টি ঠিক করে ^* এবং মানকে ভাসিয়ে দেওয়ার মাধ্যমে দৃষ্টিকোণটি কিছুটা পরিবর্তন করে প্রশ্নটি উপকৃত হতে পারে ।

এখন আপনার প্রশ্নটি এটি হয়ে যায়: "সময় নির্ধারণের কারণে মানের উপর নেতিবাচক প্রভাব রয়েছে"? এই প্রশ্নের উত্তর একটি উজ্জীবিত "হ্যাঁ": গবেষণাটি নিশ্চিত করে যে লোকেরা গণিত সম্পর্কিত সমস্যাগুলির উপর চাপের মধ্যে আরও খারাপ আচরণ করে ^** যে তারা এর আগে ব্যাপকভাবে অনুশীলন করেনি (অর্থাত পঞ্চাশ বার বা তার বেশি চেষ্টা করা হয়েছে), তাই আপনার বন্ধুর বাবা ঠিক বলেছেন।

---

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

^** এখানে একটি অন্তর্নিহিত ধারণা আছে যে প্রোগ্রামিং গণিত করার অনুরূপ; আমি মনে করি এই ধারণাটি ন্যায্য।

Answer 3

আপনার যত শিডিয়ুলিং চাপ রয়েছে, প্রসবের সময়টি তত বেশি এবং আরও টিসিও?

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

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

Answer 4

ডান থেকে বাম শিডিউলিং।

পরিচালনার কেউ সর্বদা ভাবেন যে তারা তার বিখ্যাত বাস্তবতা বিকৃতি অঞ্চল সহ স্টিভ জবস। প্রোডাক্ট ডেভলপমেন্টের কেউ তাদের শিক্ষিত না করা পর্যন্ত নন-টেকনিক্যাল ম্যানেজারদের সময়সূচী সম্পর্কে প্রায়শই মতামত থাকতে পারে যা প্রাথমিক ফরাসি চলচ্চিত্র "লে ভয়েজ ড্যানস ল লুন" ("একটি ট্রিপ অব দ্য মুন") রকেট বিজ্ঞানের জন্য ছিল।

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

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

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

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

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

ক্রিয়েটিভ কমন্স লাইসেন্স - দেখুন http://en.wikedia.org/wiki/File:Scrum_process.svg

Comments

কেবল একটি রেফারেন্স নয়, একাধিক রেফারেন্স যুক্ত করার জন্য +1!

— ক্রিস্টোস হেওয়ার্ড

Answer 5

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

একটি অনুমান কেবল এটিই, একটি অনুমান। এটি সুনির্দিষ্ট নয়, এটির নিশ্চয়তা নেই। কোনও অনুমানের জন্য, কিছুটা সম্ভাবনা রয়েছে যে আপনি এটিকে কমিয়ে আনবেন বা নাকে আঘাত করবেন এবং কিছুটা সম্ভাবনাও যে আপনি এটিকে ছাড়িয়ে যাবেন।

সম্ভাব্যতা 101: পি (আন্ডাররান বা ঠিক হিট) + পি (ওভাররান) = 100%।

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

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

এখন এটি সম্পর্কে চিন্তা করুন: আপনি যদি সময়সূচীটি টানেন তবে আপনার তফসিলটি হ্রাস বা সঠিকভাবে হিট হওয়ার সম্ভাবনা হ্রাস পাবে। মোট এখনও 100% যোগ করতে হবে। সেই সম্ভাবনা কোথায় যায়? উত্তর, এটি ওভাররন সম্ভাবনার মধ্যে যায়।

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

Comments

এখনও অবধি সেরা উত্তর - সময় নির্ধারণ এবং অনুমান করা সম্পূর্ণ দুটি ভিন্ন সমস্যা। অনেক লোক এটি উপলব্ধি করতে ব্যর্থ।

— mattnz

Answer 6

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

তবে, চাপটি যদি বাস্তবসম্মত না হয়, বা পরিচালনা এবং প্রযুক্তিগত লোকের মধ্যে যোগাযোগ যদি সঠিকভাবে কাজ না করে তবে হ্যাঁ, একটি ঝুঁকি রয়েছে যে নির্ধারিত চাপের ফলে খারাপ মানের এবং / অথবা দেরীতে ডেলিভারি হয়।

একজন অভিজ্ঞ ডেভেলপার জানবে যে তিনি / সে নির্ভুল সমাধান বরং একটি সমাধান পাওয়া যাবে যে উত্পাদন আশা করা হয় না যথেষ্ট । সুতরাং এই জাতীয় বিকাশকারী দ্বারা প্রদত্ত অনুমানটি ইতিমধ্যে একটি নির্দিষ্ট প্রকল্পের জন্য যথেষ্ট ভাল কি তা বোঝার প্রতিফলন ঘটবে will

যথেষ্ট কারণের সংজ্ঞা প্রভাবিত করে এমন অনেকগুলি কারণ রয়েছে।

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

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

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

এটি প্রথমবার যথাযথভাবে করার জন্য পর্যাপ্ত সময় কখনওই পাওয়া যায় না, তবে পরে এটি ঠিক করার জন্য যথেষ্ট সময় রয়েছে।

Comments

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

— ক্রিস্টোস হেওয়ার্ড

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

— জর্জিও