প্রকল্পের শুরুতে একটি জটিল গল্প ভাঙা


9

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

"একজন ব্যবহারকারীর একটি পণ্য ট্যাগ করতে সক্ষম হওয়া উচিত"

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

আমার সমস্যাটি এই গল্পে লুকিয়ে থাকা কাজের পরিমাণ নিয়ে। গল্পটি সম্পন্ন করার জন্য আমি কার্যগুলি সংজ্ঞায়িত করতে পারি তবে পুরো গল্পগুলি 1-2 দিনের কাজ হওয়ার কথা? আমি কেবল আইসবার্গের ডগা প্রকাশ করার গল্পটি সম্পর্কে সঠিক মনে করি না তবে এটি কেবলমাত্র ব্যবহারকারীর সাথে সম্পর্কিত part

আপনি কিভাবে এই ধরণের জিনিস কাটিয়ে উঠবেন? সেরা অনুশীলনগুলি কী কী?

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


1
সর্বাধিক যে কাজগুলিতে কাজ শুরু করা 1-2 দিনের কাজ স্পষ্টভাবে একটি ভাল ধারণা, এবং মানুষের অনেক এটা অপরিহার্য এর বলতেন। তবে, কার্যগুলি! = ব্যবহারকারীর গল্প । কার্যগুলি ব্যবহারকারীর গল্পগুলি সম্পাদন করার জন্য আপনার প্রয়োজন বিকাশের স্বতন্ত্র বিট এবং একটি একক ব্যবহারকারীর কাহিনীতে অনেকগুলি কাজ থাকতে পারে।
ওয়াঘানড্রয়েড

1
@ বাউকেটা তবে এটির গল্পটি কীভাবে অনুমান করে? এবং এই পয়েন্টগুলি দলের গতি হিসাবে ট্র্যাক করা হয়, অন্ততপক্ষে এটি পিভোটাল ট্র্যাকারে সেটআপ হয়।
ম্যাথহের্ক

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

উত্তর:


7

আপনি আপনার গল্প প্রয়োজন ডেভেলপার কাজ প্রতিটি 1 2 দিন হতে, সম্ভবত আপনি নির্দিষ্ট ব্যবহারকারীর যে কাজগুলো প্রতিটি গল্প ভাঙ্গা উচিত হয় ডেভেলপার কাজ 1 থেকে 2 দিন।

নিম্নলিখিত "ব্যবহারকারীর গল্প" বিবেচনা করুন

কোনও ব্যবহারকারীর একটি ক্রয়কৃত পণ্য থেকে একটি চালান গ্রহণ করতে সক্ষম হওয়া উচিত।

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

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

  • ব্যবহারকারী কার্টে পণ্য রাখে
  • ব্যবহারকারী পরিমাণ নির্দিষ্ট করে
  • ব্যবহারকারী শিপিংয়ের ধরণ নির্দিষ্ট করে

ইত্যাদি। সংক্ষেপে, আপনার ব্যবহারকারীর গল্পগুলি সূক্ষ্ম বিশদে বিভক্ত করতে হবে।


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

7

গল্পগুলি "1-2 দিনের কাজ" হওয়ার কথা নয়। স্ক্রমের আওতায় গল্পগুলি সাধারণত স্টোরি পয়েন্টস, একটি আপেক্ষিক আকারের সিস্টেম ব্যবহার করে অনুমান করা হয়। আপনি যদি পরিকল্পনার জুজু গল্পগুলি ব্যবহার করেন তবে একটি পয়েন্টের মান দেওয়া হয় - গল্পটি বাস্তবায়নে যে সময় লাগে তা নির্ভর করে আপনার দলটি যে গতিবেগ প্রতিষ্ঠা করেছে তার উপর।

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

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

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


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

আমি এখনও পাশে আছি, "এটি করবেন না" :)। স্ক্রাম একটি নির্দিষ্ট পদ্ধতি যা ওপি স্ক্র্যাম নীতিগুলির বিরুদ্ধে চলে।
ডেভ হিলিয়ার

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

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

7

দেখে মনে হচ্ছে আপনি গল্প এবং কাজ গুলিয়ে ফেলছেন।

ব্যবহারকারী গল্প

একটি ইউজার স্টোরি হ'ল একটি সম্পূর্ণ "বৈশিষ্ট্য", এমন কিছু যা পণ্য যুক্ত করা হয় তখন পণ্যটিকে আরও বেশি মান সরবরাহ করে।

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

কার্য

স্প্রিন্টের পরিকল্পনার দ্বিতীয় পর্বের সময়, বিকাশকারীরা গল্পটিকে কার্যগুলিতে ভাগ করে দেয় । কাজগুলি হ'ল উন্নয়নের কাজ। এগুলি "ডাটাবেসে কলাম যুক্ত করুন", "পরিষেবা প্রসার x" ইত্যাদির মতো জিনিস হতে পারে A কোনও কাজ একদিনে শেষ হওয়ার চেয়ে বড় হওয়া উচিত নয়।

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

মনে রাখবেন, ব্যবহারকারী গল্পগুলি অংশীদারদের ব্যবসায়ের মান উপস্থাপন করে। অংশীদারদের কাজের গল্পগুলি না করে ব্যবহারকারীর গল্প সমাপ্তিতে আগ্রহী হওয়া উচিত।

কার্য বিভাগটি স্প্রিন্ট পরিচালনা করার জন্য, একটি স্প্রিন্টের সময় ব্যবহারকারীর গল্পগুলির অগ্রগতি পর্যবেক্ষণ এবং সম্ভাব্য সমস্যাগুলি কল্পনা করার জন্য উন্নয়ন দলের পক্ষে একটি সরঞ্জাম।

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

মহাকাব্য

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

মনে রাখবেন যে কোনও ব্যবহারকারীর গল্প শেষ ব্যবহারকারীর কাছে মূল্য যুক্ত করে, তাই একটি মহাকাব্যটিকে "ফ্রন্ট-এন্ড" এবং "ব্যাক-এন্ড" গল্পে বিভক্ত করা সঠিক উপায় নয়। কোনও নতুন বৈশিষ্ট্যের জন্য ব্যাক-এন্ড যুক্ত করা শেষ ব্যবহারকারীদের নিজস্ব মান দেয় না।

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

পিভোটাল ট্র্যাকার ব্যবহার করা

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


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

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

4

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

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

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

... এবং আমি যেতে পারে।

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

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

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

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

এগুলির প্রত্যেকটি পরীক্ষামূলক - যদি তাদের নিজস্ব ক্ষেত্রে বিশেষভাবে মূল্যবান না হয়।


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

এই ক্ষেত্রে আমি একজন ব্যবহারকারীর দ্বারা পরীক্ষামূলক able
নিক

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

2

আপনার প্রয়োজনীয়তা বর্ণনা করার এবং এটি ভেঙে দেওয়ার সঠিক উপায় খুঁজে বের করার একমাত্র উদ্দেশ্যে অনুসন্ধান করা বই রয়েছে। সুতরাং এটি কোনও সহজ কাজ নয়।

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

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

দেব দলের জন্য এটি উত্সাহিত হয়: আমরা গল্পটি উপলব্ধি করার জন্য একটি সহজ পদ্ধতির সন্ধান করতে পারি, তবে এখনও একটি দৃ architect় আর্কিটেকচার থাকতে পারে যা ভবিষ্যতের বৈশিষ্ট্যগুলির সাথে আপস না করে আজ কাজটি সম্পাদন করে।

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.