স্থপতিরা কীভাবে স্ব-সংগঠিত স্ক্র্যাম দলগুলির সাথে কাজ করতে পারেন?


20

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

উদাহরণস্বরূপ, দলটি গ্রন্থাগার এক্স ব্যবহার করতে বা SOAP এর পরিবর্তে REST ব্যবহার করতে চাইবে, তবে ইএ তা অনুমোদন করে না।

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

স্ক্রাম নির্দেশিকা এটা সম্পর্কে বলার এই আছে:

স্ব-সংগঠিত: কেউ (এমনকি স্ক্রাম মাস্টারও নয়) কীভাবে পণ্য ব্যাকলগকে সম্ভাব্য পুনঃনির্মাণযোগ্য কার্যকারিতা বৃদ্ধিতে রূপান্তর করতে পারে তা উন্নয়ন দলকে বলে না tells

এটা কি যুক্তিসঙ্গত? ইএ টিমটি ভেঙে দেওয়া উচিত? দলগুলিকে অস্বীকার করা উচিত বা কেবল মেনে চলা উচিত?

উত্তর:


20

একটি উন্নয়ন দল 3-9 জন ব্যক্তিকে নিয়ে গঠিত যারা ক্রস-ফাংশনাল দক্ষতা সহ যারা আসল কাজ করেন

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


2
ভাল যুক্তি; তবে আমি দেখতে পাচ্ছি না যে স্থপতিদের সাথে কাজ করার একাধিক দল থাকলে এটি কীভাবে কাজ করতে পারে।
স্লেসকে

1
"আরে, ইএ, এখন আপনি এখানে বসে আছেন এবং এখনও একই লোকের সাথে যোগাযোগ করছেন Just আরও প্রায়ই।" এটি ঠিক কীভাবে ইএ এবং অন্যান্য ডিভাসদের মধ্যে যে কোনও দ্বন্দ্ব সমাধান করতে সহায়তা করে?
ইজকাটা

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

1
@ariwez: "দলের মধ্যে" এন্টারপ্রাইজ আর্কিটেক্ট "গ্রুপকে কেন ভাগ করবেন না?" কারণ আমাদের স্থপতিদের চেয়ে বেশি দল রয়েছে; এছাড়াও স্থপতিরা বেশিরভাগ সমস্যায় কাজ করেন যা একাধিক দলকে প্রভাবিত করে।
স্লেসকে

@ স্লেসকে: "প্রক্রিয়া এবং সরঞ্জামগুলির ওপরে ব্যক্তি এবং ইন্টারঅ্যাকশন"

17

ব্যবহৃত প্রযুক্তির পছন্দটি সফ্টওয়্যারটির প্রয়োজনীয়তার অংশ, যার অর্থ এটি যে বৈশিষ্ট্যর অনুরোধের অংশ, আপনি যে কোনও কারণেই কারণ ব্যবহার না করে নির্দিষ্ট প্রযুক্তি ব্যবহার করবেন না।

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

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

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


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

2
কেউ, কোনও এক সময় সিদ্ধান্ত নিয়েছিলেন যে তারা পারবেন না। এজন্য স্থপতিদের অস্তিত্ব রয়েছে।
জোনাথন ধনী

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

4
@ এরিক এবং যখন তিনটি পৃথক দল তাদের তিনটি, পৃথক, sensক্যমত্য সিদ্ধান্তে পৌঁছে তখন আপনি রেল, জাভা এবং নেট নেট এর মিশ্রণ পেতে পারেন।
মার্কজে

@ মারকজে আপনার যদি একই সার্ভার-সাইড ওয়েব অ্যাপ্লিকেশনটির জন্য পৃথক পৃথক তিনটি টিম কাজ করে থাকে তবে আপনি যা পান তা আপনার প্রাপ্য।
এরিক পুনরায়

6

প্রকল্পটি সম্পন্ন করার জন্য একটি বড় দলের প্রয়োজন এবং চৌকস দলকে ছোট রাখার মধ্যে ভারসাম্য বজায় রাখতে এই ধরণের জিনিসটি প্রয়োজনীয়।

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

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

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


2
অবশ্যই, তবে এটি ঘুরিয়ে দিন: সমস্ত দলকে একই ক্র্যাপযুক্ত প্রযুক্তি ব্যবহার করতে বাধ্য করা এমনকি ন্যাটিয়ার (সমস্ত একই কুৎসিত পথে নেমে গেছে)। যদিও "বৈচিত্র্য" থাকা কমপক্ষে এমন কিছু সমাধান উত্পাদন করতে বাধ্য যেগুলি সাফল্য লাভ করবে।
মার্টিন উইকম্যান

2
@ মার্টিন উইকম্যান মাঝে মধ্যে ক্রেপি প্রযুক্তি বেছে নেওয়ার পিছনে ব্যবসায়ের সিদ্ধান্তও থাকে। যদি কোনও নির্দিষ্ট বাজারের ৮০% বিকাশকারীদের কৃপণ প্রযুক্তির সাথে অভিজ্ঞতা থাকে, তবে এটি বলা প্রযুক্তিটি ব্যবহার করতে অনেক ব্যবসায়িক ধারণা তৈরি করতে পারে কারণ এটি যখন আপনাকে প্রয়োজন হয় ঠিকাদারদের আনতে দেয়। একটি ছোট বাজারে, আপনি পাইথন প্রোগ্রামারগুলিকে তাদের লবণের মূল্য খুঁজে পেতে সক্ষম নাও হতে পারেন।
জোনাথন ধনী

@ জোনাথানরিচ যখন আমি কৃপণ বলি তখন আমার অর্থ ক্রপ্প। এর মধ্যে এটি জানা আছে এমন কাউকে খুঁজে না পারাও অন্তর্ভুক্ত।
মার্টিন উইকম্যান

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

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

5

প্রশ্ন: এই আর্কিটেক্ট টিমটি থাকার কারণ কী? আমি মনে করতে পারি শুধুমাত্র কারণ বিভিন্ন দলের মধ্যে আন্তঃযোগিতা কার্যকর করা। অথবা টিমগুলি একক পণ্যের বিভিন্ন অংশে কাজ করছে এবং প্রতিটি অংশকে একসাথে কাজ করে রাখার জন্য এই আর্কিটেক্ট টিমটি বিদ্যমান।

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

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


5

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

এর সাথে সম্পর্কিত, ডিল লেফিংওয়েল-এর সাম্প্রতিক অ্যাগ্রিল সফ্টওয়্যার প্রয়োজনীয়তার বইটি এই বিষয়টিতে একটি ভাল পঠন, আমি নিজেই এটি পড়ছি।


4

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

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

আর্কিটেক্টদের দলগুলির উপর কোনও আনুষ্ঠানিক কর্তৃত্ব নেই , এবং কেবল তাদের পরাস্ত করতে পারে না। সাধারণত, স্থপতিরা সিদ্ধান্ত নেয় যা সমস্ত পণ্যের ক্ষেত্রে প্রযোজ্য এবং দলগুলি তাদের পণ্যটির জন্য সিদ্ধান্ত নেয়। যদি কোনও বিরোধ হয়, তবে আর্কিটেক্ট এবং দলকে কেবল একটি চুক্তিতে পৌঁছানো বা পরিচালনাতে এগিয়ে যাওয়া প্রয়োজন (যদিও এটি খুব কমই ঘটে)।

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


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

3

আমি এখানে কোন বিরোধ দেখছি না। আমি যা বুঝতে পেরেছি তা থেকে সমস্ত ইএ (কর্ণধার হিসাবে একটি শিরোনাম হিসাবে আমি মনে করি) কিউএই বোঝা যাচ্ছে। প্রত্যেকেরই এটি সম্পর্কে সচেতন হওয়া উচিত।

আপনার বিবেচনা করা উচিত, যে কোনও উন্নয়ন পদ্ধতিতে (এটি বিবেচিত হওয়ার দাবিদার) প্রয়োজনীয়তা জড়ো করা একটি গুরুত্বপূর্ণ পদক্ষেপ, তা তা পুনরুক্তি বা সামনের দিকেই হোক।

এর মধ্যে কিছু প্রয়োজনীয়তা কোম্পানির নীতি দ্বারা সেট করা হয়। এবং এগুলি মূল নিয়মগুলি সেট করে:

  • দলটিকে অন্য যে কোনও প্রয়োজন অনুসারে তাদের মেনে চলতে হবে। নীতিটিকে চ্যালেঞ্জ জানানো কেবলমাত্র প্রকল্পের ক্ষেত্রের বাইরে এবং আলাদাভাবে পরিচালনা করা উচিত।
  • EA এর কাজ হ'ল এই প্রয়োজনীয়তাগুলি প্রয়োগ করা এবং তাদের ব্যক্তিগত অভিনবতা চাপানো নয়। তারা এক্স পছন্দ করে না তবে এটি তাদের ব্যক্তিগত মতামত। বেশিও না কমও না. অন্য মতামতের মত এটি আচরণ করুন। যাইহোক, যদি EA প্রদর্শন করতে পারে যে এক্স ব্যবহার করা একটি বিদ্যমান প্রয়োজনীয়তা লঙ্ঘন করে, তবে তারা এক্স ব্যবহার নিষিদ্ধ করার অধিকারের মধ্যে রয়েছে এবং যদি তারা কোনও কার্যক্ষম বিকল্প জানেন এবং দলটি না করে, তবে এটি কার্যকর করার তাদের অধিকার।

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


তারা পরিষ্কারভাবে কিউএর চেয়ে বেশি কাজ করছে। তারা সরঞ্জাম ব্যবহার সম্পর্কে সিদ্ধান্ত নিচ্ছে।
এরিক পুনরায়

@ এরিক রেপ্পেন: আমি কিছুটা অস্পষ্ট ছিলাম। আমি বোঝাতে চেয়েছিলাম কিউএই তাদের করণীয়।
back2dos

@ back2dos: আমি মনে করি আপনার মানকতার জন্য QA পরিবর্তন করা দরকার। আপনি কী বলছেন তা আমি জানি তবে কিউএ সম্পূর্ণ ভিন্ন এবং আপনার বক্তব্যকে বিভ্রান্ত করছে।
gbjbaanb

2

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

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


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

2

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

আপনি স্ক্র্যাম গাইডটির উদ্ধৃতি দিয়েছিলেন: "কেউ (এমনকি স্ক্রাম মাস্টারও নয়) কীভাবে সম্ভাব্য পুনঃনির্মাণযোগ্য কার্যকারিতা বৃদ্ধির ক্ষেত্রে প্রোডাক্ট ব্যাকলগকে পরিবর্তন করতে পারে তা বিকাশকারী দলকে বলে না" "

এটি পুরোপুরি কোম্পানির প্রযুক্তি এবং ব্যবসায়ের প্রয়োজনীয়তা এবং অন্যান্য দলের প্রয়োজনীয়তা বিবেচনা না করে স্ক্র্যাম দলের জন্য যা ইচ্ছা (যতক্ষণ এটি তা সরবরাহ করবে) করার লাইসেন্স নয়।

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


0

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

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


এটি উত্তরের চেয়ে বেশি অভিজাতের মতো পড়ে।
ব্রায়ান ওকলে 21

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