চতুর পদ্ধতি ব্যবহার করার সময় কীভাবে ভাল নকশা পাবেন?


15

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

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

সমস্যা: একটি ভাল নকশা পেতে অসুবিধা

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

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

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

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

সম্পাদনা - দ্রষ্টব্য

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

উদাহরণস্বরূপ, আমি যদি খুব সাধারণ ডিজাইনটি (1) যত তাড়াতাড়ি সম্ভব প্রস্তুত করা আবশ্যক, (2) শুধুমাত্র একবার ব্যবহার করা যাচ্ছে, (3) না হয় ভাল ডিজাইন সম্পর্কে (খুব বেশি) যত্ন নেই সিস্টেমের অন্যান্য অংশ (YAGNI) দ্বারা ব্যবহৃত।

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


5
The only well-designed module I could produce recently I obtained by taking a different approach- আপনি আপনার নিজের প্রশ্নের উত্তর দিয়েছেন। আপনার এখনও কিছু আপ-ফ্রন্ট ডিজাইন প্রয়োজন; আপনি রিফ্যাক্টরিং থেকে জৈবিকভাবে বাড়ার জন্য কোনও ভাল ডিজাইন আশা করতে পারেন না। এটি সেভাবে কাজ করে না।
রবার্ট হার্ভে

1
না। কারণ সম্ভবত আমি সঠিকভাবে এসসিআরএম প্রয়োগ করছি না।
জর্জিও

3
"SCRUM সঠিকভাবে" বলে কোনও জিনিস নেই no কেবলমাত্র সেই প্রক্রিয়াটিই কাঙ্ক্ষিত ফলাফল দেয়।
রবার্ট হার্ভে

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

উত্তর:


13

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

তাহলে সেটা করবেন না।

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

আরও সাধারণ ক্ষেত্রে, 3 টি জিনিস রয়েছে যা আমি Agile এ ভাল নকশা পাওয়ার জন্য দেখেছি:

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

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

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


3
"তাদের যদি সেই বাক্সে চাপিয়ে দেওয়া কেবল সমস্যার কারণ হয় তবে" +1 (+10 যদি আমার একাধিক ভোট হয়!)
জর্জিও 21

17

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

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


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

2
আসলে আপনি যোগ করা উচিত প্রযুক্তিগত ঋণ গল্প এবং যখন আসলে পণ্যের মালিক সঙ্গে এটি কাজ করার জন্য, এই কি দ্বারা বোঝানো হয় আলোচনা প্রযুক্তিগত ঋণ

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

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

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

6

"সু-নকশাকৃত" বিষয়গত j

কী "ভাল ডিজাইন" আপনি এর অর্থ? পণ্য মালিককে? খরিদ্দারের প্রতি?

হয় "ভাল ডিজাইন পণ্যের মালিকের একটি লক্ষ্য"? গ্রাহকের একটি লক্ষ্য? নাকি শুধু তুমি?

কি আপনি বিবেচনা "ভাল ডিজাইন নয়" এখনও প্রোডাক্ট ওনার্স প্রত্যাশা পূরণের এবং গ্রাহক খুশি উপার্জন? তারপরে এটি বেশ "ভাল ডিজাইন করা"

গুড ইনফ এবং ইয়াগনি

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

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

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

স্ক্রাম

এগ্রিল মেথডোলজি যা লিখে রাখা যেতে পারে, তা এগ্রিল মেথডোলজি নয় "" - জারোদ রবারসন

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

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

যে গল্পগুলি 20 বলার চেয়ে বড় সেগুলি সাধারণত 3 - 5 পয়েন্টের গল্প না হওয়া পর্যন্ত সাধারণত ভাঙা হয়। এর মধ্যে একটি গল্প হ'ল "একটি দল হিসাবে আমাদের কীভাবে এই বৈশিষ্ট্যটি ডিজাইন করতে চলেছি তা আলোচনা করার জন্য আমাদের মিলিত হওয়া প্রয়োজন, যাতে সময় বরাদ্দের পরে আমাদের যতটা সম্ভব প্রযুক্তিগত debtণ হবে।"

সাধারণত

সাধারণভাবে একটি "ভাল ডিজাইন করা" সিস্টেমটি হ'ল গুড ইনফ এবং হ'ল ইয়াজিএনআই অনুসরণ করে।

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

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


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

3
কি হতাশাজনক উত্তর। এটি মূলত একটি ধূসর গু এর
রবার্ট হার্ভে

@ জর্জিও যে কোনও লক্ষ্য নয়, এটি অন্তর্নিহিত প্রত্যাশা।

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

1
ঠিক আছে, তবে আপনি "অন্তর্নিহিত প্রত্যাশা" খেতে পারবেন না। এটাই কেবল হাত বোলানো। "এটি ভালভাবে আর্কিটেক্ট করা হবে কারণ আমি পেশাদার এবং আমি জানি আমি কী করছি।" (আমার সেরা বিল মারে ভয়েস ব্যবহার করে) হ্যাঁ, ঠিক আছে।
রবার্ট হার্ভে

3

আমরা বেশ কয়েক মাস ধরে স্ক্রামের সাথে কাজ করছি এবং আমি আপনার সমস্যার বিষয়ে আমার অভিজ্ঞতা ভাগ করে নিতে চাই।

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

আমি পুরো ওয়ার্কফ্লো এবং ডিবি কাঠামো এবং ক্লাসগুলি পরে ডিজাইন করেছি।

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

এই অভিজ্ঞতার পরে আমি পুরোপুরি নিশ্চিত যে এটির শুরুতে একটি গ্রহণযোগ্য নকশা তৈরি করা ভাল, আশা করি কিছু অলৌকিক কাজ শেষে আপনি এটি পেয়ে যাবেন।


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

1

হিন্দ-দর্শন 20-20। পুরো জিনিসটি বের করে আনার জন্য প্রকল্পের শুরুতে যদি আপনার কাছে তথ্য নিষ্পত্তি হয় এবং কয়েক সপ্তাহের মধ্যে কোডটি লিখে রাখেন তবে আমি আপনাকে পরামর্শ দিয়েছি যে এটি করুন।

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

সফল জল-পতনের প্রকল্পগুলির ইতিহাস সহ যে কেউ কেন একটি চৌকস পদ্ধতিতে স্যুইচ করবে?


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

0

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


ডিজাইন ব্যবহারকারীর গল্প নির্ধারণ করা কি একটি ভাল অনুশীলন ?
জর্জিও

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

1
কেউ যদি নিম্নমানের হয় তবে দয়া করে একটি কারণ দিন
জেমস

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