গল্পগুলি দ্বারা প্রয়োজনীয়তার স্পেসিফিকেশনগুলি লেখার পক্ষে কি ভাল ধারণা?

Question

আমরা এই মুহুর্তে আমার বর্তমান প্রকল্পে চতুর পদ্ধতিগুলি ব্যবহার করছি এবং আমাদের কাছে এর মতো গল্পের স্তূপ রয়েছে:

• সহকারী হিসাবে, আমি কোনও গ্রাহককে ফেরত দিতে চাই যাতে তারা অনুরোধ করার সময় তারা কিছু অর্থ পেতে পারে

• একজন গ্রাহক হিসাবে, আমি কোনও ক্রয়ের জন্য অর্থ দিতে চাই যাতে আমি আমার আইটেমটি গ্রহণ করতে পারি।

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

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

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

গল্পের উপর ভিত্তি করে চশমা লেখা কি একটি ভাল ধারণা? আমরা কি গল্পগুলি ভুল উপায়ে লিখেছি?

Comments

আপনি মাইক কোহান পড়তে চাইতে পারেন: ( amazon.com/User-Stories- প্রয়োগ- ডেভেলপমেন্ট- ebook / dp / B000SEFH1A )

— ম্যাথু ফ্লিন

Answer 1

এটি বিতর্কিত হতে পারে তবে এটি এখানে যায়!

---

আমরা রিয়েল টাইম সিস্টেমে কাজ করেছি যেখানে আমার অতীতের একজন বসের পরামর্শ দিয়েছিলেন! সত্যিই এটির উপর ম্যানেজমেন্ট জেতা সহজ ছিল; যাইহোক, এটি করা চেয়ে সহজ ছিল।

গল্পের ধারণাটি ভাল - তবে খুব স্পষ্টভাবে বলতে গেলে এটি বেশ অস্পষ্ট। আসলে কি গল্প? আসল সমস্যাটি হ'ল গল্পগুলি ব্যবহার করার alone(এবং পাশাপাশি ব্যবহারের ক্ষেত্রে একই বিষয়গুলি) বেশ কয়েকটি সমস্যা রয়েছে - নীচে:

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

2. প্রয়োজনীয়তাগুলি আকারে এবং পরিমাণ মতো উপযুক্ত হতে হবে অন্যথায় আপনার কখনই 1 টিরও বেশি বড় গল্পের প্রয়োজন থাকতে পারে না! ঠিক কি 1 গল্প রূপ?

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

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

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

সুতরাং আপনার প্রশ্ন আসছে:

গল্পের উপর ভিত্তি করে চশমা লেখা কি একটি ভাল ধারণা? আমরা কি গল্পগুলি ভুল উপায়ে লিখেছি?

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

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

Comments

পরবর্তী থেকে শেষ অনুচ্ছেদে সরাসরি চৌকস দ্বারা সম্বোধন করা হয়: গ্রাহক / পণ্য মালিক একটি কর্মক্ষম এসডাব্লু সরবরাহ করার জন্য দলের সাথে কাজ করছেন।

— লাডিস্লাভ মৃঙ্কা

এটি পছন্দ করার মতো বলে +1 করুন "গল্পগুলির ধারণাটি ভাল - তবে খুব সামনে দাঁড়ানোর জন্য এটি বেশ অস্পষ্ট।"

— NoChance

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

— লাদিস্লাভ মৃঙ্কা

ককবার্নের বইটি ব্যবহারের ক্ষেত্রে প্রচলিত রেফারেন্স, সুতরাং এটি যদি একমাত্র বিশ্বাসযোগ্য উত্স হয় তবে কমপক্ষে এটি উত্স। ব্যবহারকারীর গল্পগুলির জন্য, মাইক কোহনের ব্যবহারকারীর গল্প প্রয়োগ হয়েছে দেখুন ( amazon.com/User-Stories- প্রয়োগ- ডেভেলপমেন্ট- ebook / dp / B000SEFH1A )

— ম্যাথু ফ্লাইন

Answer 2

> Writing specs by stories? a good idea?

হ্যাঁ আপনি যদি আপনার গল্পের আন্তঃনির্ভরতা এবং অগ্রাধিকারগুলি পরিচালনা করতে পারেন।

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

Answer 3

এই উত্তরটি লেখার সময়, আমি বুঝতে পেরেছি এটি পরীক্ষার বিষয়ে নয়, এটি নথিপত্র সম্পর্কে। আপনার প্রথমে চতুর ইশতেহারটি পড়া উচিত :

[আমরা মূল্যবান] বিস্তৃত ডকুমেন্টেশনের মাধ্যমে কাজের সফ্টওয়্যার

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

গল্পের উপর ভিত্তি করে চশমা লেখা কি একটি ভাল ধারণা?

হ্যাঁ, ইমো এটিকে "আচরণ দ্বারা চালিত বিকাশ" বা "উদাহরণ দ্বারা নির্দিষ্টকরণ" বলা হয়। রুবিতে একটি দুর্দান্ত সরঞ্জাম শসা রয়েছে যা অনেকটা সহায়তা করে।

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

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

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

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

এটি এতটা সাধারণ বিষয় নয় যে কয়েকশ সংখ্যক ইন্টিগ্রেশন টেস্ট একটি জটিল মডিউলে সামান্য পরিবর্তন দ্বারা ভেঙে যায়। ইউনিট টেস্টিং পদক্ষেপ যেখানে।

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

আমরা কি গল্পগুলি ভুল উপায়ে লিখেছি?

আমি মনে করি, আপনাকে কেবল গল্পগুলি ব্যবহারকারীর দ্বারা, যেমন "গ্রাহক", "সহায়ক", বা বৈশিষ্ট্য / পর্দা / ওয়ার্কফ্লোস ("ক্রয়", "ফেরত") দ্বারা মহাকাব্যগুলিতে সংগঠিত করতে হবে।

এবং আবারও, স্পেসিফিকেশন পরীক্ষাগুলি ইউনিট পরীক্ষার প্রতিস্থাপন নয়। আরও পড়ুন

Answer 4

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

গল্প লিখে স্পেক লিখেছেন? একটি ভাল ধারনা?

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

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

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

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

Answer 5

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

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