আর্কিটেকচার থেকে বিকাশের দিকে হস্তান্তর সম্পর্কে কি কোনও সেরা অনুশীলন রয়েছে?

Question

আমরা আর্কিটেকচার থেকে উন্নয়নের দিকে কাজ হস্তান্তর প্রক্রিয়াটির উন্নতির দিকে তাকিয়ে আছি।

স্কেলের এক প্রান্তে এটির কোনও আর্কিটেকচার গাইডেন্স নেই যা আপনার বিশৃঙ্খলা হওয়ার ঝুঁকিপূর্ণ, প্রতিটি বিকাশকারী তার মতো কাজ করে।

স্কেলটির অন্য প্রান্তে যেখানে সমস্ত কিছু নির্দিষ্ট করা আছে, স্পেসিফিকেশনটি বিকাশের চেয়ে বেশি সময় নেয় এবং আপনার খুব বিরক্তিকর বিকাশের কাজগুলি হওয়ার ঝুঁকি রয়েছে।

এই চরমগুলির মধ্যে কেউ কি সর্বোত্তম মধ্যম জায়গা খুঁজে পেয়েছে? আপনি কোন শিল্পকর্মগুলি উন্নয়নে সরবরাহ করেন? উদাহরণস্বরূপ: মডিউল, বর্গ কাঠামো, বা অনুক্রম ডায়াগ্রাম?

Comments

আমি এখানে কোথাও একটি মন্তব্য পড়েছি যা বলেছিল যে আর্কিটেকচারটি একটি দলের খেলাধুলা। আপনি যদি স্থপতিদের কাছ থেকে ডেভেলপমেন্ট টিমের হাতে তুলে দিচ্ছেন, আপনি সম্ভবত এটি ভুল করছেন।

— পিঁপড়া

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

— এস। রোবিন্স

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

— ডেভিড থর্নলি

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

— maple_shaft

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

— জেমস অ্যান্ডারসন

Answer 1

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

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

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

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

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

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

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

প্রকৃত এবং বাস্তব সফ্টওয়্যার ডিজাইন আর্কিটেকচার গ্রুপের অত্যন্ত উচ্চ স্তরের দিকনির্দেশনা অনুসারে সমস্ত সফ্টওয়্যার বিকাশকারীদের জড়িত একটি সম্প্রদায় প্রক্রিয়া হবে।

Comments

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

— এস রবিনস

@ এস রবিনস যথাযথ সম্মানের সাথে, ওপির প্রশ্নটি ছিল কীভাবে সমস্যাটি সমাধান করবেন (এই সাইটের সমস্ত প্রশ্ন কীভাবে সমস্যা সমাধান করবেন সে সম্পর্কে)। দলের কাঠামো পরিবর্তন করা সমস্যার সমাধানের একমাত্র সত্য উপায়। অন্যান্য পরামর্শগুলি দুর্দান্ত, তবে সেগুলি কেবল ব্যান্ড-এইডস। তারা দীর্ঘমেয়াদে সহায়তা করে না।

— maple_shaft

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

— কেভিন ক্লিন

Answer 2

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

• সফ্টওয়্যার আকার
• জটিলতা
• আপনার প্রতিষ্ঠানের সংস্কৃতি
• বিশ্বাস.

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

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

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

আশাকরি এটা সাহায্য করবে.

Answer 3

আমি জানি এটি খুব জনপ্রিয় হবে না তবে আপনি যে মন্তব্য করেছেন

স্কেলের অন্য প্রান্তে যদি সবকিছু নির্দিষ্ট করা থাকে তবে স্পেসিফিকেশনটি বিকাশের চেয়ে বেশি সময় নেয়। এবং আপনার খুব বিরক্তিকর বিকাশের কাজগুলি হওয়ার ঝুঁকি রয়েছে।

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

Comments

বাস্তবায়ন যদি এটি প্রতিফলিত না করে তবে বিশ্বের সেরা বৈশিষ্টটি সম্পূর্ণ অকেজো। বাস্তবায়নের সাথে জড়িত নয় এমন লোকদের দ্বারা যখন নকশার নির্দিষ্টকরণগুলি করা হয় তখন এটি ঘটে।

— maple_shaft

এটা খুব সত্য। কৌশলটি, তবে সঠিক ভারসাম্য খুঁজে পাচ্ছে।

— মাইকেল 13

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

— বিল গ্রিবল

Answer 4

আমি ম্যাপেল_শ্যাফটের উত্তরের সাথে পুরোপুরি একমত নই, তবে মন্তব্যে আমার সম্পূর্ণ কিছু বলার মতো পর্যাপ্ত জায়গা নেই! ;-)

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

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

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

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

Comments

+1 এবং আরও 1000 যদি আমি পারতাম! আপনি আমার উত্তরটি আরও স্পষ্টভাবে ব্যাখ্যা করেছেন। আমি বিশেষত এই উক্তিটি ভালবাসি architects should first and foremost be facilitators & communicators, and designers second,। আমি আমার উত্তরে যা বলছি তা মূলত এটি। স্থপতিরা বিকাশকারীদের নকশার চশমা সরবরাহ করছে তা মূলত ভুল এবং স্থপতি কীভাবে কোনও সংস্থাকে মূল্য দেয় তা বিরুদ্ধে যায়। এই কারণেই আমি আমার উত্তরে বরং কঠোরভাবে আদেশ দিচ্ছিলাম যে একটি দল পুনর্গঠনই একমাত্র উত্তর।

— maple_shaft

Answer 5

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

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

Answer 6

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

এছাড়াও নতুন টিম অবৈধ অনুমান করার জন্য জায়গা আছে।

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

Answer 7

আমি বলব যে ক্লাস ডায়াগ্রামগুলি একটি মডেল তৈরি করার পাশাপাশি কোডগুলিও একটি সমাধান is শ্রেণীর চিত্রটি আপনার প্রকল্পের স্থাপত্যের স্থির দৃশ্যের প্রতিনিধিত্ব করে। আমি বলতে চাইছি আপনার প্যাকেজ> ক্লাস, ইন্টারফেস, এনাম> বৈশিষ্ট্য, মেহটডস ইত্যাদি ...> ইত্যাদি etc

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

এটি সত্যই ভাল কাজ করে এবং ইউএমএল সম্পর্কে জানার প্রয়োজন নেই কারণ শ্রেণি চিত্রটি খুব সহজ এবং বিপরীত প্রকৌশল কাজটি করবে এবং কোডটির গ্রাফিকাল ভিউ তৈরি করবে। সরল নেভিগেশন, উন্নত এবং বিস্তারিত দর্শন যেখানে ডায়াগ্রামের সাথে প্রচুর মন্তব্যগুলি সর্বদা আপ টু ডেট থাকে এবং সরাসরি প্রকল্পে সিভিএসে দৃশ্যমান হতে পারে। আমার ইউএমএল শ্রেণির চিত্রটি এখন যাদু :-)