কীভাবে ব্যবহারকারীর গল্পগুলিতে প্রয়োজনীয়তা থাকতে পারে না (যখন কোনও কার্ডে লেখা থাকে) এবং এখনও কার্যকর হতে পারে implement

Question

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

কোনও কম প্রয়োজনীয়তা না থাকলে কীভাবে কোনও গল্প থেকে বিকাশকারীরা বিকাশ করতে পারে? পরীক্ষকরা কীভাবে কোনও গল্পের উপর ভিত্তি করে পরীক্ষার কেসগুলি (বিস্তারিতগুলি) লিখতে পারেন? ডিবি বাধা, ক্ষেত্রগুলির বৈধতা ইত্যাদির মতো প্রয়োজনীয়তা যেখানে ব্যবহারকারী গল্পের বাইরে থাকে?

Comments

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

— গসডোর

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

— jonrsharpe

gnat: আসলে না। আমি জিজ্ঞাসা করেছি কারণ এসসিআরইউএম-এর ব্যাপক ব্যবহারের প্রেক্ষিতে আমি নিশ্চিত যে এটি কীভাবে সঠিকভাবে করা যায় আমি সত্যই আগ্রহী, এটি অবশ্যই অনেক দলের পক্ষে একটি সমস্যা হতে পারে।

— ব্যবহারকারী 144171

@ ম্যাপেল_শ্যাফ্ট "রেন্টিশ" উপাদানগুলির সমস্যা হ'ল এগুলি হতাশ উত্তরগুলি আকর্ষণ করে। আমি সম্মত সেখানে কোন যুক্তিসম্মত কোর আছে যে, যদি এটা হতে পারে আশ্চর্যের কিছু সম্পাদন করা ইডি ঠিক যে কোর রাখা এবং ranty উত্তর আমন্ত্রণ আউট মুছা

— মশা

এখানে একটি ভাল প্রশ্ন আছে, তবে এটি রেন্ট হিসাবে লেখা হয়েছে। আমি একটি সম্পাদনায় চেষ্টা করেছি।

— DA01

Answer 1

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

এই উত্তরটি ধরে নিয়েছে যে আপনি স্ক্রমে বোর্ডে আছেন তবে এখনও এটি আপনার পক্ষে কাজ করার কোনও উপায় খুঁজে পায়নি।

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

তবে এর অর্থ এই নয় যে এই বিবরণগুলি কোথাও রেকর্ড করা উচিত নয়।

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

এর অর্থ কি নিম্ন স্তরের বিবরণগুলি ব্যবহারকারী গল্পগুলিতে রেকর্ড করা উচিত? না (এবং হ্যাঁ)

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

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

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

Comments

+1 স্বীকৃতি মানদণ্ড আরও বিশদ যুক্ত করে

— ভগ্নাংশ

Answer 2

হ্যাঁ, এর বিএস। এবং স্ক্রাম চটজলদি নয়।

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

চটপটে চটফটে হতে চলেছে।

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

সুতরাং এই ক্ষেত্রে, যদি কার্ডগুলিতে ব্যবহারকারীর প্রয়োজনীয়তা রাখলে আপনাকে প্রয়োজনীয় কোডটি লিখতে, পরীক্ষা করতে, ডকুমেন্ট করতে এবং প্রদর্শন করতে সহায়তা করে ... কার্ডটিতে প্রয়োজনীয়তা রাখুন এবং গুরুকে বলুন যে দল সর্বদা সঠিক is

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

Comments

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

— ফ্রাঙ্ক

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

— ব্যবহারকারী 144171

ক্লায়েন্ট একটি 8 বিট পূর্ণসংখ্যার সাথে সম্মত হয়েছে, সুতরাং এটি আমার দোষ নয়।

— JeffO

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

— জর্জিও

@ অ্যালেক্স তিনি এসসিআরএম এবং চৌকস প্রক্রিয়ার প্রসঙ্গে অনেক জিজ্ঞাসা করছেন।

— gbjbaanb

Answer 3

একে এটিকে একটি ইউজার স্টোরি বলবেন না এবং সবাই খুশি হবে।

আমি মনে করি উত্তরটি হ'ল আপনি যেখানে খুশি লিখতে পারেন।

সাধারণভাবে, কয়েকটি কার্যকর কারণে নির্দিষ্ট বাস্তবায়নগুলি একটি ব্যবহারকারী গল্পের অন্তর্ভুক্ত নয়:

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

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

Comments

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

— ব্যবহারকারী 144171

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

— জেফো

এবং যদি কোনও ইনপুটটির দৈর্ঘ্য সামঞ্জস্য করার জন্য এটি একটি বৃহত্তর উদ্যোগ গ্রহণ করা হয়, তবে আপনার কোড যাইহোক চতুর নয়, তাই খুব কম বা কোনও ডকুমেন্টেশন খুব বেশি পার্থক্য আনবে না।

— JeffO

@ ব্যবহারকারী144171 একটি প্রকল্পের জন্য সমস্ত প্রয়োজনীয়তা, বা একটি বৈশিষ্ট্য, সামনের দিকে এবং খুব বিস্তৃত উপায়ে, শেষ পর্যন্ত অবধি লিখে রাখার চেষ্টা করা ঠিক তেমন খারাপ যা ঠিক তেমন প্রয়োজনই নেই। একই জিনিস নকশা জন্য যায়।

— কে_

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

— maple_shaft

Answer 4

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

বিভিন্ন ধরণের সফ্টওয়্যার প্রয়োজনীয়তা কী কী?

ব্যবসায়ের প্রয়োজনীয়তা

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

ব্যবহারকারীর প্রয়োজনীয়তা

এটি আপনার ব্যবহারকারীর গল্পের প্রয়োজনীয়তার সাথে পরিচিত। এগুলি সাধারণত একটি স্টিকি নোটের সাথে ফিট করতে পারে।

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

কার্যকরী বা সিস্টেমের প্রয়োজনীয়তা

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

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

কার্যকরী প্রয়োজনীয়তাগুলি আপনার সমাধানটিকে সংজ্ঞায়িত করে যা আপনার প্রসেসের ফাঁক হিসাবে আপনি কী বর্ণনা করছেন বলে মনে হচ্ছে।

উল্লেখযোগ্য প্রয়োজনীয় প্রকারের উল্লেখ করা প্রয়োজন তবে এটি আপনার প্রশ্নের ক্ষেত্রে অপ্রয়োজনীয়: অ-কার্যকরী প্রয়োজনীয়তা, প্রযুক্তিগত প্রয়োজনীয়তা ইত্যাদি ...

Comments

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

— অ্যালেক্স

@ অ্যালেক্স: ব্যবহারকারী গল্প / প্রয়োজনীয়তা => এটিএম থেকে অর্থ উত্তোলন করতে চান, কার্যকরী প্রয়োজনীয়তা => বিল বিতরণে মোট সময় 30 সেকেন্ডের বেশি হতে পারে না। ব্যবহারকারীর প্রয়োজনীয়তা কার্যকরী প্রয়োজনকে অন্তর্ভুক্ত করে না।

— jmoreno

@ জোমোরনো আপনার উদাহরণের সেই "ব্যবহারকারীর গল্প" কোনও ব্যবহারকারীর কাহিনী নয়, এটি একটি ব্যবহারকারী গল্পের প্রথম দিক point এবং সম্পাদনের সময় সম্পর্কে "কার্যকরী প্রয়োজনীয়তা" ধূসর অঞ্চলে, মূল কার্যকারিতা প্রয়োজন বিলগুলি সরবরাহ করা, সময়ের সীমাবদ্ধতার অনেক উত্স হতে পারে।

— অ্যালেক্স

@ জোরমেনো আসলে এর মতো পারফরম্যান্স মেট্রিককে একটি অ-কার্যকরী প্রয়োজনীয়তা হিসাবে বিবেচনা করা হয় a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors। আচরণে নিজেরাই ফাংশন একটি এর সিস্টেম । ব্যবহারকারীর কাহিনী ব্যবহারকারীর প্রয়োজনীয়তা সংজ্ঞায়নের মাধ্যমে উভয়কেই স্বতন্ত্র করে। একটি ব্যবহারকারী ফাংশন পরিবর্তে কি আমরা একটি জানে ব্যবহারের ক্ষেত্রে এবং না একটি ক্রিয়ামূলক প্রয়োজন।

— maple_shaft

@ অ্যালেক্স উপরে আমার মন্তব্য দেখুন। আমি মনে করি যে কার্যকরী প্রয়োজনীয়তা কী তা সম্পর্কে আপনি উভয়ই বিভ্রান্ত।

— maple_shaft

Answer 5

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

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

আপনার প্রশ্নটির মতো কিছু মিল রয়েছে

আমার এই কারখানা কারখানা রয়েছে এবং আমার এটিও সাইকেল তৈরি করা দরকার, তবে আমাদের ওওডি "গুরু" বলেছেন আমাকে এটি করার অনুমতি নেই not এই বিএস কি !?!

আপনার কোডগুলিতে এবং আপনার প্রক্রিয়াগুলির মধ্যে উভয়ই আপনার নিদর্শনগুলির উদ্বেগ এবং সংহতির বিচ্ছেদকে সম্মান করুন।

Answer 6

আমি মনে করি এই পদ্ধতির উদ্দেশ্য ব্যবহারকারীর গল্পগুলিকে সীমাবদ্ধ করা নয়, তবে খারাপ প্রয়োজনীয়তা রোধ করা।

আমার অভিজ্ঞতায় ব্যবহারকারীরা সাধারণত লেখার প্রয়োজনীয়তার অক্ষম থাকেন। বিকাশকারীরা সাধারণত প্রয়োজনীয় লেখার অক্ষম are মুরগি, আসুন আমরা সরাসরি এটি স্বীকার করি: প্রয়োজনীয়তাগুলি লেখা শক্ত!

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

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

Comments

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

— maple_shaft

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

— আমটন কর্ট - মনিকা পুনরায়

Answer 7

আপনার নিজের সিদ্ধান্ত নিন

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

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

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

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

Answer 8

টি এল; ডিআর

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

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

ব্যবহারকারীর গল্পগুলি নির্দিষ্টকরণ নয় Not

মূল পোস্টার (ওপি) নিম্নলিখিত প্রশ্ন জিজ্ঞাসা করেছে :

[একটি] গ্রাহক বিভিন্ন ক্রেডিট কার্ডের জন্য একটি পৃথক প্রসেসিং চান, এমন কঠোর প্রয়োজনীয়তা রয়েছে যা প্রয়োগ করতে হবে এবং তা জেনে রাখা উচিত যাতে পরীক্ষার কেসগুলি লিখিত হতে পারে ... আমি স্টোরিতে না থাকলে এটি কোথায় রাখা উচিত?

একটি ইউজার স্টোরি এমন একটি বৈশিষ্ট্য যা মান সরবরাহ করে , বাস্তবায়ন সম্পর্কে কথোপকথনের জন্য কিছু প্রসঙ্গ সরবরাহ করে এবং মান ভোক্তার সাথে বাঁধা দৃষ্টিভঙ্গি সরবরাহ করে যা বৈশিষ্ট্যটি সরবরাহ করা মূল্য থেকে উপকৃত হবে।

ব্যবহারকারীর গল্পের পুরো বিষয়টি হ'ল বাস্তবায়নের বিশদটি প্রেসক্রিভটিভ নয়। দলটি কোনও উপায়ে বৈশিষ্ট্যটি কার্যকর করতে উপযুক্ত যা উপযুক্ত প্রসঙ্গে মান ভোক্তার কাছে চিহ্নিত মান সরবরাহ করে।

একটি কাজ উদাহরণ

একটি নমুনা ব্যবহারকারী গল্প

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

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

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

বিশ্লেষণ এবং বাস্তবায়ন

আসল বাস্তবায়ন দলের উপর নির্ভর করে। দলটি নির্ধারণ করতে কিছু বিশ্লেষণ করতে হবে:

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

Agile ইশতেহারের অন্যতম মূল নীতি হ'ল গ্রাহক সহযোগিতা। একটি ক্রস-ফাংশনাল, স্ব-সংগঠিত দলটি গ্রাহকের সাথে ব্যবহারকারী কাহিনী দ্বারা সরবরাহিত নির্দেশিকাগুলির মধ্যে প্রয়োগের বিশদটি প্রকাশের জন্য সহযোগিতা করতে সক্ষম হবে বলে আশা করা হচ্ছে ।

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

পরীক্ষা-চালিত এবং আচরণ-চালিত নকশা

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

• পরীক্ষামূলক দৃশ্যের সাথে শসা বৈশিষ্ট্যগুলি।

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

• আরএসপেক পরীক্ষাগুলি যা নতুন কোড বৈশিষ্ট্যগুলির আচরণ (অভ্যন্তরীণ প্রয়োগের বিবরণ নয়) বৈধ করে ।

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

নির্দিষ্ট সরঞ্জামগুলি কোনও বিষয় নয়। আপনি যদি শসা বা আরএসপেক পছন্দ করেন না, তবে আপনার দলের পক্ষে যে কোনও সরঞ্জাম বা পদ্ধতি কার্যকরভাবে ব্যবহার করুন use যাইহোক, মুল বক্তব্যটি হ'ল বাস্তবায়নের বিশদগুলি ব্যবহারকারীর কাহিনীর ভিত্তিতে , তবে এটি দ্বারা নির্ধারিত হয় না । পরিবর্তে, বাস্তবায়ন (বা স্পেসিফিকেশন, আপনি যদি চান তবে) সহযোগী ফ্যাশনে বৈশিষ্ট্য বিকাশের সময় কাজ করা বিশদ।

Answer 9

এখানে অনেক ভাল উত্তর। আশা করি আমি অন্যটির সাথে কিছু মান যোগ করতে পারি ...

আমি মনে করি যে আপনার দলে একটি হ্যাঙ্গআপ থাকতে পারে এটি একটি অ-চতুর পদ্ধতি থেকে মাইগ্রেশন করছে।

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

তবে এটি সর্বদা কার্যকর হয় না। প্রায়শই এটি কাজ করে না। কারন? কারণ প্রয়োজনীয়তা খুব কমই বাস্তবতার সাথে সারিবদ্ধ হয়। কিছু পরিবর্তন. অতএব Agile দিকে অগ্রসর।

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

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