স্ক্র্যাম দল YAGNI নীতি অনুসরণ করছে না

Question

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

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

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

বেশিরভাগ সময় আমরা এমন জিনিসগুলি নিয়ে বিতর্ক করতাম যা স্প্রিন্টের অংশ ছিল না বা মকআপগুলিতে উল্লিখিত হয়নি। বর্ণিত সমস্যাগুলি হ'ল "ভবিষ্যতে বিপণন কি হবে ...", "যদি ব্যবসায় আমাদের চাই ..." what

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

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

এটি উল্লেখ করার মতো বিষয় যে পণ্যটি একটি প্রাথমিক পর্যায়ে এমভিপি।

Comments

I'm afraid if such thing can become a precedence for upcoming, more complicated debates?- এটিও YAGNI লঙ্ঘন করে: এমন ভবিষ্যতের বিষয়ে উদ্বিগ্ন যেটি ঘটে না। আপনি যদি নিজের মাঠে দাঁড়াতে যাচ্ছেন তবে আপনার ইতিমধ্যে এটি করা উচিত ছিল।

— রবার্ট হার্ভে

@ গ্যাनेट: এটি সময়ের সীমাবদ্ধতার মতো বলে মনে হচ্ছে না।

— রবার্ট হার্ভে

HAL- কমপ্লায়েন্ট হওয়া কি YAGNI এর অধীন নয়?

— ম্যাথু

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

— জ্যাসেক কোবাস

নমনীয়তা জটিলতা যোগ করে। দল যতক্ষণ বুঝতে পারে, কেউ এগিয়ে যেতে পারে।

— জন রেয়নর

Answer 1

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

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

ঘটনাটি হ'ল, যতক্ষণ না দল পরিবর্তন হয় না ততক্ষণ আপনি এ বিষয়ে অনেক কিছু করতে পারবেন না , যদি জিনিসগুলি গণতান্ত্রিক থেকে যায় তবে তাই হয়

• এটি সঙ্গে বসবাস করতে শিখুন
• এক বা দুই বছর দলের সাথে কাজ করুন, নিজের দক্ষতা ভাগ করুন এবং আশা করি তারা সময়ের সাথে সাথে YAGNI এবং KISS এর মান শিখবে
• আপনার নিজের "বিক্রয়" ডিজাইনের দক্ষতা বা দলে কৌশলগত সিদ্ধান্ত নিয়ে কাজ করুন
• আপনার নিজস্ব দক্ষতার স্তরটি পুরো দলের গড়ের কাছাকাছি যেখানে কোনও আলাদা (সম্ভবত আরও ছোট) টিমে স্যুইচ করার চেষ্টা করুন

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

Comments

বেশিরভাগ লোককে গরমটি শিখতে এবং এটি স্পর্শ না করতে চুলার স্পর্শ করতে হয়। সফটওয়্যার অনেক একই। ++

— রাবারডাক

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

— রবি ডি

@ রবিডি: নিশ্চিত, যদি এটি দলকে ইয়াজিএনআই এবং কেআইএসএস সম্পর্কে জানতে সহায়তা করে।

— ডক ব্রাউন

3 য় বুলেট (একটি নকশা "বিক্রয়" আপনার নিজস্ব দক্ষতার উপর কাজ করে) যথেষ্ট মনোযোগ পায় না। এ কারণেই বিকাশকারীদের এখনও যোগাযোগের ভাল দক্ষতা (বা কাজ করা) দরকার।

— রেন্ডাল স্টুয়ার্ট

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

— ডক ব্রাউন

Answer 2

ফরোয়ার্ড সামঞ্জস্যতা বৈধ উদ্বেগ

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

অন্যান্য প্রয়োজনীয়তার মতো আপনারও গ্রহণযোগ্যতার মানদণ্ড প্রয়োজন

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

এটি রায় রায় হওয়া উচিত নয়

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

Comments

প্রশ্নটিতে আপনি কোথায় পড়েছেন যে ওপির দলটি সামনের সামঞ্জস্যের প্রয়োজনীয়তার কারণে YAGNI এর পথ ছেড়েছে?

— ডক ব্রাউন

ফরোয়ার্ড সামঞ্জস্য কি Content-Typeহেডার জন্য

— জ্যাক

আমি চাইলে এটিকে অন্য কিছু বলতে চাই, সম্ভবত এক্সটেনসিবিলিটি। বিষয়টি একই; এটি এখনও একটি এনএফআর।

— জন উ

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

— ডক ব্রাউন

... সুতরাং এটি কীভাবে সম্ভবত সৃজনশীল বিকাশকারীদের একটি দলকে এনএফআর সম্পর্কে অনুমান করা থেকে বিরত রাখতে এবং কিছুকে আবিষ্কার করার বিষয়ে রয়েছে।

— ডক ব্রাউন

Answer 3

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

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

Comments

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

— আমন

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

— ডক ব্রাউন

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

— মার্টিন মাট

@ মার্টিনম্যাট তারা যে আমার সাথে দ্বিমত পোষণ করেছে তাতে আমি কিছুটা হতাশ হয়েছিলাম। কেন এমন হল বুঝতে পারলাম না। প্রতিদিনের কাজের সময় আমি তাদের কোড পর্যালোচনা ইত্যাদিতে সহায়তা করি We আমরা প্রায়শই তর্ক করি তবে আমি এটি পছন্দ করি কারণ চূড়ান্ত ফলাফলটি আরও ভাল is আমি জানি যে তারা আমার মতামতকে সম্মান করে; আমি সবসময় বৈধ যুক্তিগুলি ব্যবহার করার চেষ্টা করি যা আমার তত্ত্বগুলিকে সমর্থন করে। শেষ পর্যন্ত তারা সর্বোত্তম বিকল্পটি চয়ন করে এবং এর জন্য দায়ও নেয়। দলটি যা করার কথা ছিল তা করেছিল - তারা সমস্যাটি সমাধান করেছিল। এটি আমার এবং পণ্য মালিকের ভুল ছিল যে বিষয়টি প্রথম থেকেই খুব বিস্তৃত এবং দুর্বল বর্ণিত।

— জ্যাসেক কোবাস

Answer 4

ঠিক আছে, আমার মতে গণতন্ত্র সঠিকভাবে কাজ করছে না - না কোনও রাজনৈতিক ব্যবস্থাতে, না এমন একটি দলে যেখানে বেশিরভাগ প্রোগ্রামার জুনিয়র বা মধ্যম।

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

সর্বোপরি, আপনার দায়িত্ব অন্য ব্যক্তির পক্ষে বেশি। এটি কেবল কোড লিখতে নয়, মানুষকে গাইড করার জন্য।

Comments

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

— ডক ব্রাউন

@ ডকব্রাউন আপনি কেবল একই বাক্যে নিজেকে বিরোধিতা করেছেন। আইএমও কিছু সিদ্ধান্ত মানুষের সিদ্ধান্ত নেয় না। ওপি যা ব্যাখ্যা করেছে সেগুলির মধ্যে একটি। লোকেরা ইয়াগনি ব্যবহার করছে না বলে আর্মস্ট্রংয়ের উদ্ধৃতি দিতে: আপনি একটি কলা চেয়েছিলেন তবে যা পেয়েছেন তা হল কলা এবং পুরো জঙ্গলটি ধরে রাখা

— Јовић

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

— ডক ব্রাউন

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

— oopexpert

@oopexpert সমস্যাটি হ'ল: আপনার তাদের প্রয়োজন হতে পারে । ইয়াজিএনআই ওভার ইঞ্জিনিয়ারিংয়ের বিরুদ্ধে কথা বলে। যথাযথ বিমূর্ততা একটি জিনিস, আপনার প্রয়োজন নাও হতে পারে এমন জিনিসগুলি যুক্ত করা বিভিন্ন বিষয়।

— BЈовић

Answer 5

মনে হয় YAGNI সম্পর্কে কিছুটা বিভ্রান্তি রয়েছে।

বিকাশকারীরা প্রায়শই মনে করেন যে তারা YAGNI অনুসরণ করে যখন তারা এমন বিমূর্ততা বাদ দেয় যা সিস্টেমটিকে "সংশোধন করার জন্য বন্ধ করে দেবে এবং এক্সটেনশনের জন্য উন্মুক্ত" রাখবে।

যদি আপনি "স্পষ্টত" অনুরোধকৃত কার্যকারিতা সহ সিস্টেমটিকে "প্রসারিত" না করেন তবে আপনি YAGNI এর সাথে চুক্তি করবেন না। বিমূর্ততাগুলির প্রবর্তন যেখানে প্রসার ঘটতে পারে তা ইতিমধ্যে উল্লিখিত "ফরোয়ার্ড সামঞ্জস্য"।

আমার ব্যক্তিগত মতামতটি হল যে ডোমেনের কেবল গভীর জ্ঞানই বিমূর্ততার সিদ্ধান্ত নিতে এবং কোথায় এটি সনাক্ত করতে সহায়তা করবে।

Answer 6

ইয়াগনি এবং কিস-এর সমস্যাটি হ'ল তারা সম্পূর্ণরূপে বিষয়গত এবং অস্পষ্ট।

JSON ?? YAGNI! শুধু একটি CSV স্ট্রিং প্রেরণ!

বস্তু ?? KISSTUPID !!! শুধু গোটোস ব্যবহার করুন !!

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

• কোডের জন্য ইউনিট পরীক্ষা
• এপিআইএসের জন্য সংহতকরণ পরীক্ষা
• শেষ পণ্যটির জন্য স্বয়ংক্রিয় ইউআই পরীক্ষাগুলি
• কর্মক্ষমতা এবং স্কেলিং প্রয়োজনীয়তা

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

এরপরে এটি কেবল একই কিন্তু দ্রুত করার জন্য চাপ দিচ্ছে

Answer 7

দলে সবাই আবশ্যক সম্মত সম্পন্ন সংজ্ঞা । এটি ব্যতীত, আপনি প্রচুর পরিমাণে স্কোপ ক্রাইপ, দৃষ্টিকোণ এবং মূল প্রয়োজনীয়তার বস্টার্ডাইজেশন প্রবণ।

এর ওপরে এবং এর উপরে যে কোনও কিছু সরবরাহ করা অবশ্যই ব্যাকলগে থাকতে হবে যা নিজে থেকেই এর নিজস্ব সংজ্ঞা থাকবে।

অগ্রাধিকার হিসাবে, MoSCoW পদ্ধতি সর্বদা আমাদের ভালভাবে পরিবেশন করেছে - ওয়াইএমএমভি।

Answer 8

এই সম্পর্কে আমার প্রথম চিন্তাটি ... দলটি কেন পরিবর্তন সম্পর্কে উদ্বিগ্ন? তাদের কাছে কি প্রোডাক্ট মালিক সম্পর্কে এমন কিছু historicতিহাসিক বোঝাপড়া রয়েছে যা তাদের অনুভব করে যে ভবিষ্যতের বর্ধনগুলি আরও সহজ করার জন্য কিছুটা আরও কনফিগার করার জন্য তাদের প্রথম সমাধানটি তৈরি করা দরকার? যদি আপনার সমাধানটি 2 দিন সময় নেয় এবং তাদের 5 দিন হয় তবে হ্যাঁ, এটি দ্বিগুণ হয়ে গেছে। তবে যদি আপনার পরিকল্পনার পরিবর্তনে প্রতিবার 2 দিন সময় লাগে তবে তাদের বর্ধিতকরণের জন্য 1 দিন সময় লাগে তবে তাদের পরিকল্পনাটি দীর্ঘসূচীর চেয়ে আরও কার্যকর বলে মনে হচ্ছে। আমি মনে করি না যে এই প্রশ্নে একটি সঠিক বা ভুল সিদ্ধান্ত আছে। এটি অন্যান্য বিষয়গুলির উপর নির্ভর করে, আইএমএইচও। তবে, এই মানসিকতার বিষয়ে আপনি সঠিক, যদি অন্য সমাধানের ক্ষেত্রে তারা কোনও সরাসরি নির্দেশিকা ব্যতীত এলওইকে দ্বিগুণ করেন (কিছু প্রমাণ যে অতিরিক্ত জটিলতার জন্য স্কেলাবিলিটি, দৃust়তা ইত্যাদি প্রয়োজন) required আমার পরামর্শ হ'ল পণ্য মালিককে এই কথোপকথনে আনতে হবে, কারণ তাদের অগ্রাধিকারে সহায়তা করা দরকার। যদি আপনার সমাধানটি 5 পয়েন্ট হয় এবং এটি এখন প্রয়োজন মেটাবে তবে তারা যা করতে চায় তার জন্য 50 পয়েন্ট এবং দুটি স্প্রিন্ট বা আরও বেশি প্রয়োজন হবে, পিও বলতে পারে "ধরে রাখুন, আমাদের এই এমভিপি পরিকল্পিতভাবে একটি উচ্চ অগ্রাধিকার রিলিজ রয়েছে এবং রোডম্যাপে নেই এমন কার্যকারিতা তৈরি করতে 2 সপ্তাহ ব্যয় করতে পারে না! "