যেখানে স্ক্র্যামগুলি প্রয়োজনীয় প্রকল্পগুলি পরিবর্তন হয় না এমন প্রকল্পগুলির জন্য অতিরিক্ত ওভারহেড তৈরি করে?

Question

আমি স্ক্রাম পড়ছি - গুন্থার ভারহেইনের একটি পকেট গাইড এবং এতে বলা হয়েছে:

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

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

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

সুতরাং, স্ক্রম কী এমন কোনও প্রকল্পের জন্য অতিরিক্ত ওভারহেড তৈরি করবে যেখানে প্রয়োজনীয়তাগুলি পরিবর্তন হয় না?

Comments

সামরিক প্রকল্পের প্রয়োজনীয়তা অবিচ্ছিন্নভাবে পরিবর্তিত হয় - যা তারা বাজেটের মাধ্যমে ব্যাপকভাবে শেষ হয় এবং বিলম্বিত হয়

— হুরাসকোল

একমাত্র প্রকল্প যেখানে প্রয়োজনীয়তা পরিবর্তন হয় না বাতিল বা বাতিল প্রকল্পগুলি। এটি এমনও হতে পারে যে কোনও কোনও শিল্পে ধারণা থেকে নিযুক্ত পণ্যগুলিতে চক্র অন্যান্য শিল্পের তুলনায় দীর্ঘ হয়, তবে ধারণা বা প্রয়োজনীয়তা ক্রমাগত পরিবর্তিত হয় এমনটি পরিবর্তিত হয় না।

— বার্ট ভ্যান ইনজেন শেহানাউ

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

— আলেফজেরো

CHAOS প্রতিবেদনে সমস্যা রয়েছে - দেখুন, উদাহরণস্বরূপ কয়েকটি.vu.nl/~x/chaos/chaos.pdf - এবং ভারসাম্য বজায় রাখার সময়, চৌকস এবং স্ক্রাম পদ্ধতির কার্যকারিতা সম্পর্কে গবেষণা একটি ইতিবাচক প্রভাব দেখায়, সেখানে সিস্টেমেটিক সমস্যা রয়েছে তুলনামূলক গ্রুপগুলি যেহেতু "অ-চতুর" সাথে তুলনা করা হচ্ছে তার চেয়ে কম সংজ্ঞাযুক্ত।

— জ্যাক এইডলি

@ এসেনইউইউ এই ধারণাটি প্রকাশ করেছেন যে একজন ইঞ্জিনিয়ার "তাদের কাজকে প্রতিদিন একটি নন প্রযুক্তির কাছে ব্যাখ্যা করতে বাধ্য করা হয়" পরামর্শ দেয় যে আপনি কখনই স্ক্র্যাম গাইডের কথা বলে যা সাদৃশ্যযুক্ত কিছুই করেননি। দুঃখের বিষয়, যারা স্ক্র্যাম করেছে বলে দাবি করে তাদের মধ্যে এটি খুব সাধারণ।

— এরিক

Answer 1

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

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

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

Comments

প্রতিক্রিয়া চক্র লেন্থ প্রভাব সম্পর্কে আরও পড়ুন blog.codinghorror.com/boyds-law-of-iteration

— StuperUser

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

— সাইমন বি

Answer 2

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

আরও সম্পূর্ণ উত্তর হ'ল:

সাধারণভাবে বলতে গেলে প্রক্রিয়া নিয়ন্ত্রণের তিনটি রূপ রয়েছে: সংজ্ঞায়িত প্রক্রিয়া নিয়ন্ত্রণ, পরিসংখ্যান প্রক্রিয়া নিয়ন্ত্রণ এবং এমেরিকাল প্রক্রিয়া নিয়ন্ত্রণ। সংজ্ঞায়িত প্রক্রিয়া নিয়ন্ত্রণ এখন পর্যন্ত সবচেয়ে সস্তা। ঘন ঘন পুনরাবৃত্তিযোগ্য কাজের সাথে এটি সম্ভব কাজটি করার "সেরা" উপায়টি খুঁজে পেতে সময়ের সাথে সাথে সংশোধন করা হয়েছে। সফটওয়্যার বিকাশের সিআই / সিডি এই বিভাগে আসে। আপনি আপনার বিল্ড প্রক্রিয়ায় প্রকরণ চান না যাতে আপনি প্রক্রিয়াটি মানক করে নিন, আপনি এতে খুশি না হওয়া পর্যন্ত সামঞ্জস্য করুন, তারপরে এটি স্বয়ংক্রিয় করুন। স্বয়ংক্রিয়ভাবে প্রক্রিয়াটি মোতায়েনের মাধ্যমে ম্যানুয়ালি লড়াইয়ের চেয়ে বেশি কম ব্যয় করা উচিত।

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

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

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

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

Answer 3

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

তবে সফ্টওয়্যার প্রকল্পের সিংহভাগ এটির মতো নয়।

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

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

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

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

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

Answer 4

আমি মনে করি এটি @ কর্ট অ্যামোনের যা বলছে তা ভালভাবেই বর্ণনা করতে পারে, তবে এখানে আমার নেওয়া:

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

Comments

হ্যাঁ আমি জলপ্রপাত প্রকল্পগুলিতে কাজ করেছি যেখানে নির্মাণের সময় কোনও একক প্রয়োজনের পরিবর্তন হয় নি, তবে একজন ব্যক্তি অসুস্থতা, ছুটি, অপ্রত্যাশিত প্রযুক্তিগত সমস্যাগুলির অনুমতি দেওয়ার জন্য প্রকল্প পরিকল্পনা পরিবর্তন করতে প্রায় সারা দিন ব্যয় করেছিলেন।

— ওয়েন্ডিজি

Answer 5

এটি বিবেচনা করুন:

• এমনকি স্থির ক্রিয়ামূলক প্রয়োজনীয়তার সাথে আপনার এগুলি প্রযুক্তিগত প্রয়োজনগুলিতে ছড়িয়ে দিতে হবে। এবং এটি পুনরাবৃত্তির দ্বারা আরও ভাল করা যেতে পারে। আপনি প্রকল্পের মাঝখানে সমস্যা সমাধানের আরও ভাল উপায় আবিষ্কার করতে পারেন।

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

• কিছু প্রয়োজনীয়তা উন্নত হতে পারে। 200 মিঃ তে প্রতিক্রিয়া জানানো ভাল হতে পারে তবে 100 ভাল হতে পারে। আপনি সেরা সম্ভাব্য ফলাফল লক্ষ্য করতে পারেন তবে প্রকল্পের সময় প্রয়োজনে এটি ত্যাগ করতে পারেন।

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

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

• শীঘ্রই কিছু সরবরাহ করা একীকরণে সহায়তা করবে এবং দেখাবে যে এই প্রকল্পটি ফলাফল সরবরাহ করতে পারে।

Answer 6

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

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

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

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

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