কোডিংয়ের আগে কার্যকারিতা জানা কতটা গুরুত্বপূর্ণ?


9

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

যখন প্রয়োজনীয়তা আসে, তীরে টিম ক্লায়েন্টদের সাথে কথা বলে এবং প্রয়োজনীয় কাগজপত্র তৈরি করে আমাদের জানায়। প্রয়োজনীয়তা অধ্যয়নের পরে আমরা নকশার নথি তৈরি করি (আমরা theতিহ্যবাহী জলপ্রপাতের মডেলটি অনুসরণ করি)।

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

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

আমার প্রশ্ন আপনি যদি অ্যাপটির কার্যকারিতা পুরোপুরি না জানেন তবে আপনি কীভাবে উন্নয়ন কাজ করবেন?

হালনাগাদ

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



এটি একটি ব্যক্তিগত মতামত, তবে আপনি যে পরিবেশটি বর্ণনা করছেন তার জন্য আপনি ঠিক ভুল সফ্টওয়্যার বিকাশ পদ্ধতি (জলপ্রপাত) ব্যবহার করছেন। আরএডি, বা চটপটে আপনার আরও ভাল মানায়।
ড্যাশ

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

1
@ মার্কব্যানিস্টার "এই প্রশ্নটিতে বোঝা যাচ্ছে যে এখানে একটি বৃহত, বিদ্যমান অ্যাপ্লিকেশন রয়েছে যা স্ক্র্যাচ থেকে নতুন অ্যাপ্লিকেশন তৈরি করার পরিবর্তে সংশোধন করা দরকার - এটি কি সঠিক?" সঠিক?
মাইনাসসভেন

1
আসুন আমরা এই আলোচনাটি

উত্তর:


6

সংক্ষিপ্ত সংস্করণ:

কী করতে হবে তা জানা your আপনার গ্রাহককে জানা।

এটি কল্পনা করুন: আপনি রিয়েল এস্টেট বিকাশের সাথে সম্পর্কিত একটি সংস্থা। আপনি আপনার সঙ্গীকে একটি বৃহত জটিল তৈরি করতে বলেছেন। অংশীদারটি বলেছে যে আপনি তাকে যে সমস্ত নথি দিয়েছেন তা সত্ত্বেও তাকে এই কমপ্লেক্সের ফ্ল্যাটগুলি কেনার লোকদের সাথেও সরাসরি কথা বলা উচিত। সিরিয়াসলি?


দীর্ঘ সংস্করণ:

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

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

অন্যদিকে, নির্দিষ্ট ডোমেনটির কোনও বোঝাপড়া না করে তৈরি একটি সফ্টওয়্যার পণ্য সর্বোত্তম, ভাল, কিছুটা অব্যর্থ

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

  1. প্রযুক্তিবিদগণ (উদাহরণস্বরূপ বিকাশকারীরা যারা বলবেন যে একটি নির্দিষ্ট বৈশিষ্ট্যটি অসম্ভব, এইভাবে করা গেলে এই অন্যটি আরও ভাল হতে পারে, এবং আরও সস্তা বিকল্প থাকা অবস্থায় এটির হাজার হাজার ডলার ব্যয় হবে),

  2. প্রকল্প পরিচালনায় বিশেষত ব্যক্তি,

  3. গ্রাহকের ডোমেনে বিশেষজ্ঞ ব্যক্তিরা , যাদের এই ডোমেন এবং গ্রাহকের সুনির্দিষ্ট প্রয়োজন সম্পর্কে সম্পূর্ণ জ্ঞান রয়েছে। অবশ্যই এটি গ্রাহক নিজেই হতে পারে।

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


আপনার নির্দিষ্ট ক্ষেত্রে হিসাবে, আপনি নিজেই সমস্যার কারণ বর্ণনা করেছেন:

প্রয়োজনীয়তা সুস্পষ্ট না হওয়ায় আমরা নকশার নথির সাথে লড়াই করি।

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

এটি জেনে, আপনাকে আলাদাভাবে অভিনয় করতে হবে:

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

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

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


11

আপনি যে সমস্যার মুখোমুখি হচ্ছেন সেগুলির জন্য আপনি ঠিক ভুল উন্নয়ন পদ্ধতি ব্যবহার করছেন method

জলপ্রপাত ব্যবহার করে আপনি প্রতিশ্রুতিবদ্ধ:

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

যদি এটি সম্ভব হয় তবে এই প্রকল্পটি পরিচালনা করার একটি ভিন্ন উপায় ব্যবহার করুন Consider Agile সফ্টওয়্যার ডেভলপমেন্টে বেশ কয়েকটি বৈশিষ্ট্য রয়েছে যা আপনার মুখোমুখি সমস্যাগুলি মোকাবেলার জন্য ডিজাইন করা হয়েছে।

জলপ্রপাত বনাম অ্যাগিলের একটি সুনির্দিষ্ট তুলনা কিছুক্ষণ আগে লেখা হয়েছিল, এটি থেকে কয়েকটি উদ্ধৃতি নেওয়া যাক যা আপনার সমস্যাগুলি তুলে ধরে:

নিখোঁজ চিহ্ন:

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

নিচে বাঁধা...

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

... এবং সরাতে অক্ষম

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

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

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


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

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

যোগ করা, এটি অসম্ভব নয়, এমনকি "কেবলমাত্র একজন প্রোগ্রামার" হিসাবে অর্থবহ পরিবর্তন আনতে হবে। jamesshore.com/Change-Diary
Shauna

-১, এটি চিত্তাকর্ষণ করার জন্য একটি প্রেমপত্র, কোনও গ্রাহকরা কোনও উন্নয়ন দলের সাথে কাজ করতে রাজি নয় এমন সমস্যার সমাধান নয়। চটপটে যাইহোক এটি ঠিক করে না।
রাইথাল

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

4

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

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

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


-1

সমস্যাগুলি কাটিয়ে উঠতে সহায়তা করবে এমন কিছু বিষয় এখানে:

  1. দুটি দলের মধ্যে যোগাযোগ উন্নত করুন । অন্যান্য দলকে 3 টি শব্দের সাথে সংকোচন করতে বলুন এবং তারপরে প্রোগ্রামার সেই শব্দগুলি বাস্তবায়ন করবে। শব্দগুলি কেবল সঠিক হওয়া দরকার। এই শব্দগুলি ছাড়া কিছুই প্রয়োগ করা হবে না। প্রতিটি শব্দ আপনাকে কোডের 2000 লাইন দেয়। নতুন শব্দটি জানা গেলে বাস্তবায়ন শুরু হয়।
  2. যদি আপনার প্রোগ্রামারদের কাছে কোনও শব্দ অবিলম্বে পরিষ্কার না হয় তবে তাদের একক প্রশ্ন জিজ্ঞাসা করার অনুমতি দেওয়া হয় । প্রশ্ন আবার একটি সঠিক হতে হবে। এর তাত্ক্ষণিক উত্তর প্রয়োজন - উত্তরটি বিশ্বের অন্য দিক থেকে কোনও রাউন্ডট্রিপ অপেক্ষা করতে পারে না, তবে এটি আগে জানা উচিত। উত্তর পাওয়ার সাথে সাথে বাস্তবায়ন শুরু হয় এবং উত্তরটি চিঠির সাথে অনুসরণ করা হবে।
  3. বাস্তবায়নের সময় যদি অস্পষ্ট বা অস্পষ্ট প্রয়োজনীয়তা থাকে তবে এগুলি সমাধানের উপায়টি হ'ল প্রথমে (বিদ্যমান) 3 টি শব্দকে লক্ষ্য করা। যদি এটি এখনও অস্পষ্ট থাকে তবে প্রোগ্রামার সেরা অনুমানকে সম্ভব করে তোলে । এই প্রক্রিয়াটিতে যে কোনও বিলম্ব সম্পূর্ণ নিষিদ্ধ; এবং অন্য দলের কাছে সহায়তা চাওয়া এটি সমাধানের সঠিক উপায় নয় - তাদের কাছে ইতিমধ্যে সঠিক 3 টি শব্দ সিদ্ধান্ত নিয়ে প্রয়োজনীয়তা পরিবর্তন করার সম্ভাবনা ছিল।
  4. যদি এত কিছুর পরেও প্রয়োজনীয়তাটি এখনও অস্পষ্ট বা বাস্তবায়িত করা অসম্ভব হয়ে থাকে, তবে হ্যান্ডেল করার সঠিক উপায় হ'ল এই 3 টি শব্দ যে সমস্যাটি সৃষ্টি করেছিল তা প্রত্যাখ্যান করে পরবর্তী শব্দগুলিতে চলে যাওয়া। যে কোনও প্রত্যাখ্যাত শব্দ সংগ্রহ করা হবে এবং অন্য দলে পাঠানো হবে এবং তাদের সিস্টেমে পুনরায় প্রবেশের আগে শব্দগুলি সংশোধন করতে হবে। শব্দ প্রত্যাখ্যান সর্বদা সময়সীমা সরিয়ে দেয় এবং বাস্তবায়ন আবার পরিকল্পনা করা প্রয়োজন।
  5. কতগুলি প্রত্যাখাত শব্দের ভিত্তিতে দলগুলির মূল্যায়ন করা দরকার। প্রয়োজনীয়তা কার্যকর হওয়ার পরে, এটি চিরতরে স্থির হয়ে গেছে এবং আর পরিবর্তন করা যাবে না । ইতিমধ্যে বাস্তবায়িত বৈশিষ্ট্যগুলি পরিবর্তন করার যে কোনও প্রচেষ্টা প্রত্যাখ্যান করা হবে।
  6. প্রশ্নের আসল সমস্যা হ'ল এটি ধরে নেওয়া হয় যে আরও তথ্যের প্রয়োগ কার্যকর করা সহজ করে দেয়। এটি সত্য নয়। আরো স্বাধীনতা আপনার প্রোগ্রামারদের আছে, সহজ বাস্তবায়ন । প্রয়োজনীয়তাগুলি সংকুচিত করে প্রোগ্রামারদের যা করার অনুমতি দেওয়া হয় তা খুব বেশি সীমাবদ্ধ না করে প্রচুর পরিমাণে তথ্য যোগাযোগের অনুমতি দেয়।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.