যদি দুটি স্ক্র্যাম টিম একই সফ্টওয়্যার উপাদান ব্যবহার করে তবে সেই উপাদানটির সুস্পষ্ট স্থাপত্য দৃষ্টি সরবরাহ করার জন্য এবং কোড বেসটি বিকশিত হওয়ায় এই দৃষ্টিভঙ্গিটি বজায় / বিকাশের জন্য কে দায়বদ্ধ? স্ক্রমে আপনার একটি সম্মিলিত কোডের মালিকানা থাকার কথা, সুতরাং কীভাবে নিশ্চিত করা যায় যে টিম এ দ্বারা করা উন্নয়ন টিম বি দ্বারা পরিচালিত বিকাশের সাথে হস্তক্ষেপ করবে না?
উত্তর:
আমি কোনও স্ক্রাম বিশেষজ্ঞ নই, তবে আফাইক "সমষ্টিগত কোডের মালিকানা" বলতে প্রতি দল এবং প্রতি পণ্য হিসাবে বোঝানো হয়েছে (এবং আমি মনে করি যে আপনার প্রশ্নটি স্ক্রমের সাথে সুনির্দিষ্ট নয়, এটি কোনও "শেয়ার্ড কোড" বিকাশ প্রক্রিয়াতে প্রয়োগ করা যেতে পারে)।
আপনার দুটি টি, এ, বি, দুটি পণ্য এ, বি এবং একটি ভাগ করা উপাদান সি থাকলে বিভিন্ন সম্ভাব্য পরিস্থিতি রয়েছে are হতে পারে ভাগ করা উপাদানটি মূলত পণ্য এ এর সাথে সম্পর্কিত (এবং কেবলমাত্র পণ্য বি এর জন্য দল দ্বারা এটি পুনরায় ব্যবহার করা হয়, তবে বিকশিত হয় না)। এই পরিস্থিতিতে টিম এ আর্কিটেকচারাল ভিশনের জন্য স্পষ্টভাবে দায়বদ্ধ। বা তদ্বিপরীত: এটি পণ্য বি এর সাথে স্পষ্টভাবে অন্তর্ভুক্ত - তাই দায়বদ্ধতা সেখানে। টিম টি যদি দায়ী হয় তবে টিম বি জরুরী বাগ-ফিক্সগুলি অনুমোদনের জন্য উপাদানটির একটি কাঁটাচামচ ব্যবহার করতে পারে (সেগুলি সি এর মূল লাইনে পুনরায় সংহত করার একটি উপায়ও থাকতে পারে), তবে বি উপাদানটির আরও বড় বিবর্তন করা এড়ানো উচিত।
তবে এ এবং বি উভয় পণ্যই যদি সি এর জন্য প্রচুর "ড্রাইভিং প্রয়োজনীয়তা" থাকে তবে আপনার নিজের সংস্করণ, প্রকাশনা ব্যবস্থাপনা, পরিবর্তন ব্যবস্থাপনা, ইউনিট পরীক্ষা ইত্যাদির সাথে সি সম্পূর্ণ আলাদা পণ্য হিসাবে পরিচালনা করতে হবে এবং একটি পৃথক দল রয়েছে যা যে উপাদান জন্য দায়িত্ব। টিমটি কেবল একটি "ভার্চুয়াল দল" হতে পারে, টিম এ, বি বা উভয় থেকেই পৃথক ডেভ নিয়ে গঠিত। এই দলে সি এর জন্য "শেয়ার্ড কোডের মালিকানা" রয়েছে এবং "আর্কিটেকচারাল ভিশন" এর দায়বদ্ধতা রয়েছে। তৃতীয় পক্ষের বিক্রেতার দ্বারা সরবরাহ করা কোনও উপাদানকে মৌচাক করার জন্য কেবল ভাবেন।
স্ক্রাম বা চটপটে "স্পষ্ট আর্কিটেকচারাল ভিশন" এর কোনও ধারণা নেই!
আমি দীর্ঘদিন থেকে একজন স্থপতি হয়েছি এবং এটি আমার কাছে স্পষ্ট যে কোনও স্থাপত্য দৃষ্টি রাখতে হলে ভবিষ্যতের প্রয়োজনীয়তার বিষয়ে একটি স্পষ্ট দৃষ্টিভঙ্গি থাকা দরকার। যেহেতু বেশিরভাগ ক্ষেত্রে প্রয়োজনীয়তাগুলি একেবারে পরিষ্কার হয় না, তাই একটি নির্দিষ্ট দৃষ্টিভঙ্গি বোধ করার কোনও মানে হয় না।
প্রয়োজনীয় একটি হ'ল একটি আর্কিটেকচার যা পরিবর্তনের প্রয়োজনীয়তার সাথে যথেষ্ট মানিয়ে যায়। অন্য কথায়, জিনিসগুলি পরিবর্তন হয় এবং আর্কিটেকচারের পরিবর্তন ঘটে - আমি কোনও "নরম" আর্কিটেকচারের পক্ষে পরামর্শ দিচ্ছি না যা পুনর্গঠনযোগ্য। আমি আজ এটির যে আর্কিটেকচারটি পেয়েছি তা শীঘ্রই অচল হয়ে যাবে এবং পরিবর্তিত হওয়া দরকার, তাই কারও সাথে এটি "বিবাহ" করা উচিত নয়।
সমষ্টিগত কোডের মালিকানার অর্থ প্রত্যেককে - তাত্ত্বিকভাবে - যে কোনও কিছু পরিবর্তন করতে সক্ষম হওয়া উচিত। এটি "সিলোসের বিপরীত" হিসাবে বুঝতে হবে। অন্য কথায়, জায়গায় দক্ষতার বাধা থাকতে পারে যা স্বাভাবিক এবং প্রত্যাশিত - প্রত্যেকেই অভিজ্ঞ ডিবিএ নয় যা এসকিউএল কোয়েরিগুলিকে জরিমানা করতে পারে, উদাহরণ দেওয়ার জন্য - তবে এ থেকে এটি অনুসরণ করে না যে কেবল কোনও ডিবিএ পারে হাত অনুকূল জিজ্ঞাস্য। একটি "বৈশিষ্ট্যযুক্ত ডোমেন বিশেষজ্ঞ" থাকবে যা অন্যান্য লোককে দক্ষ হতে সাহায্য করতে পারে, তবে কাজগুলি এখনও সবার উপরে পড়ে।
উদাহরণস্বরূপ: যদি আমি বৈশিষ্ট্য "এ" এর ডোমেন বিশেষজ্ঞ হয়ে থাকি তবে আমি এখনও অন্য কারও "এ" বৈশিষ্ট্যটিতে কাজ করার আশা করি তবে বড় পরিবর্তনগুলি যখন ঘটে বা মানুষের সহায়তা প্রয়োজন তখন আমার সাথে পরামর্শ করা হতে পারে। বৈশিষ্ট্য "এ" অবশ্যই আমার বৈশিষ্ট্য হবে না । এটি এমন একটি বৈশিষ্ট্য হবে যা আমি ভাল করে জানি। আরও অনেক বৈশিষ্ট্য জানার আগ্রহ আমার এবং এই বৈশিষ্ট্যটি জানার জন্য অন্যান্য ব্যক্তির আগ্রহ।
সংশ্লেষণে: আর্কিটেকচারটি বিকাশকারীরা প্রয়োজনীয়তাগুলি উত্থাপিত ও পরিবর্তনের সাথে সাথে একাধিকবার ডিজাইন ও নকশাকৃত হয়। প্রত্যেকেই তাদের দক্ষতা অনুযায়ী প্রয়োজনীয় প্রয়োজনীয় পরিবর্তনগুলি প্রত্যাশা করে এবং কখন সাহায্যের জন্য জিজ্ঞাসা করবে তা জেনে রাখা হবে। আর্কিটেকচারে দীর্ঘমেয়াদী দৃষ্টি নেই কারণ আমরা জনগণকে বিশ্বাস করি এবং আমরা প্রয়োজনীয়তাগুলিতে বিশ্বাস করি না ।
উদাহরণস্বরূপ, স্পটফাইটি সরাসরি ডকুমেন্ট থেকে সমস্যাটি সমাধান করতে "সিস্টেমের মালিক" নামে একটি ভূমিকা ব্যবহার করে:
প্রযুক্তিগতভাবে, যে কোনও সিস্টেমকে সম্পাদনা করার অনুমতি রয়েছে edit যেহেতু স্কোয়াডগুলি কার্যকরভাবে বৈশিষ্ট্যযুক্ত দল, তাই তাদের সাধারণত নতুন বৈশিষ্ট্যটি উত্পাদনে আনতে একাধিক সিস্টেম আপডেট করতে হবে। এই মডেলটির সাথে ঝুঁকিটি হ'ল যদি কেউ সামগ্রিকভাবে সিস্টেমের অখণ্ডতার দিকে মনোনিবেশ না করে তবে কোনও সিস্টেমের আর্কিটেকচার গণ্ডগোল হয়ে যায়।
এই ঝুঁকি হ্রাস করতে, আমাদের "সিস্টেমের মালিক" নামে একটি ভূমিকা আছে। সমস্ত সিস্টেমে একটি সিস্টেমের মালিক, বা সিস্টেম মালিকদের একজোড়া থাকে (আমরা জোড় জোড়কে উত্সাহিত করি)। ক্রিয়াকলাপ সমালোচনামূলক সিস্টেমগুলির জন্য, সিস্টেমের মালিক হ'ল ডেভ-অপস জুটি - অর্থাত্ একজন বিকাশকারী দৃষ্টিভঙ্গি সহ এক ব্যক্তি এবং অপারেশন দৃষ্টিকোণ সহ এক ব্যক্তি।
সিস্টেমের মালিক হ'ল সেই সিস্টেমের সাথে সম্পর্কিত কোনও প্রযুক্তিগত বা আর্কিটেকচারাল সমস্যার জন্য "যান" ব্যক্তি (গুলি)। তিনি একজন সমন্বয়কারী এবং সেই সিস্টেমে কোড করা লোকদের যাতে তারা একে অপরের উপর হোঁচট খায় না তা নিশ্চিত করার জন্য গাইড করে। তিনি গুণমান, ডকুমেন্টেশন, প্রযুক্তি debtণ, স্থিতিশীলতা, স্কেলাবিলিটি এবং রিলিজ প্রক্রিয়া ইত্যাদির উপর মনোনিবেশ করেন।
সিস্টেমের মালিক কোনও বাধা বা আইভরি টাওয়ার স্থপতি নয়। তাকে ব্যক্তিগতভাবে সমস্ত সিদ্ধান্ত নিতে হয় না, বা সমস্ত কোড লিখতে হয় না বা সমস্ত প্রকাশ করতে হয় না। তিনি সাধারণত একটি স্কোয়াড সদস্য বা অধ্যায়ের নেতৃত্ব, যার সিস্টেমের মালিকানা ছাড়াও অন্যান্য প্রতিদিন-দিনের দায়িত্ব রয়েছে। তবে সময়ে সময়ে তিনি একটি "সিস্টেমের মালিক দিবস" নেবেন এবং সেই সিস্টেমে গৃহকর্মের কাজ করবেন। সাধারণত আমরা এই সিস্টেমটির মালিকানা কোনও ব্যক্তির সময়ের দশমাংশেরও কম রাখার চেষ্টা করি তবে এটি অবশ্যই সিস্টেমের মধ্যে অনেকটাই পরিবর্তিত হয়।
আমি এই ধারণাটি সত্যিই পছন্দ করি, সংস্থার পর্যায়ে (কেবল দলীয় স্তরে নয়) তবে এই ব্যবস্থাগুলি মালিকদের কিছু স্থাপত্যের অখণ্ডতা নিশ্চিত করার চেষ্টা করার সাথে সুবিধাগুলি বা সম্মিলিত কোডের মালিকানা রয়েছে।
সম্পূর্ণ নথির একটি লিঙ্ক: https://dl.rodboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf , এটি স্কেলিং সম্পর্কে বাস্তব অভিজ্ঞতার ভিত্তিতে একটি ছোট কিন্তু খুব আকর্ষণীয় নথি document
এটি সমাধান করা একটি কঠিন সমস্যা এবং এটি অবশ্যই স্ক্রাম দ্বারা সমাধান করা হয়নি যা একটি প্রকল্প পরিচালনার পদ্ধতি, কোনও উন্নয়ন পদ্ধতি নয়।
আমার সর্বাধিক কার্যকর সমাধানটি হ'ল ভাল প্যাকেজ পরিচালনা (নুগেট / জহরত / ইত্যাদি) এবং সংস্করণ। অন্য দলে এটি ব্যবহারের জন্য প্রস্তুত না হওয়া পর্যন্ত কোনও পরিবর্তন কখনই প্রয়োগ করবেন না। আপনি নতুনটিতে যাওয়ার সময় তাদের পুরানো বিল্ডটি ব্যবহার করতে দিন।
আপনার কাছে এমন একটি সংস্করণ কৌশল রয়েছে যা নিশ্চিত করে যে কোন পরিবর্তনগুলি ভেঙে যাচ্ছে এবং কোনটি এক্সটেনশন।
এছাড়াও, আপনি যখন কোনও পরিবর্তন করেন, প্রতি টিম কাউকে কোড পর্যালোচনা চাপুন। তাদের এগুলি কীভাবে প্রভাবিত হতে পারে তা তাদের দেখে নেওয়া যাক, তারা এটি ব্যবহার করতে বাধ্য করা হয়েছিল, যাতে তারা তাদের নিজস্ব পরিবর্তনগুলি শীর্ষে প্রয়োগ করতে পারে।
এবং, যখন জিনিসগুলি সত্যই অগোছালো হয়ে যায়; যখন একটি দল পরিবর্তন করতে হবে এবং সহজেই অন্য পরিবর্তনটি গ্রাস করতে পারে না (এটি সত্যই বিরল ঘটনা হওয়া উচিত), কোডটি শাখা করুন, একে একে সম্পূর্ণ আলাদা প্যাকেজ তৈরি করুন, তবে যত তাড়াতাড়ি সাধারণ কোডে ফিরে আসার বিষয়টিকে অগ্রাধিকার দিন অনুমতি.
উত্তর যেটা সবসময় সুস্পষ্ট হয় না তা হ'ল দলগুলি সিদ্ধান্ত নিতে দেয় যে তারা কোনও প্রদত্ত উপাদান কীভাবে ভাগ করবে।
উদাহরণস্বরূপ, আমার দল সম্প্রতি একটি নতুন পণ্য লাইন বিকাশ করা শুরু করেছে যা দীর্ঘদিন ধরে একই জাতীয় পণ্য বিকাশ করছে এমন দুটি অন্যান্য দলের সাথে প্রচুর কোড ভাগ করে দেয়। আমাদের পণ্য কয়েকটি উপায়ে আলাদা, তাই আমাদের মাঝে মাঝে সাধারণ কোডটিতে কাস্টমাইজেশন পয়েন্ট যুক্ত করার উপায়গুলি বের করতে হয়।
আমরা সেই কোডটি নিয়ে কিছু সংঘাত পেয়েছি এবং সাধারণ মালিকানা নিয়ে কাজ করার কয়েকটি পৃথক উপায়ে চেষ্টা করেছি। তারপরে একটি নতুন নতুন বৈশিষ্ট্য উপস্থিত হওয়ার সাথে সাথে আমরা স্থির করেছিলাম যে একই দলকে একই পৃষ্ঠায় নামার জন্য আমাদের সমস্ত দলকে একত্রিত করা দরকার, যার ফলশ্রুতিতে প্রতিটি দলের কয়েকজন সদস্যের সমন্বয়ে একটি ছোট গ্রুপ তৈরি হয়েছিল।
আমাদের দলগুলি যে সমাধান নিয়ে এসেছিল তা অন্য কোনও পরিস্থিতিতে কাজ নাও করতে পারে। আপনার আরও কিছু সাধারণ, বা আরও কিছু আনুষ্ঠানিকর প্রয়োজন হতে পারে। মুল বক্তব্যটি হল, আপনি সম্মিলিত মালিকানা গ্রহণ করেন এবং আপনার জন্য কী কাজ করে তা নির্ধারণ করুন।
আমি ধরে নিতে স্বাধীনতা গ্রহণ করব:
যদি উপরের অনুমানগুলি সঠিক হয় তবে মাঝে মধ্যে মাঝে মাঝে এমন সময় থাকতে হবে যখন দুটি দল একে অপরের সাথে হস্তক্ষেপ করবে। তারা নিম্নলিখিত উপায়ে ব্যবহার করে এটি সমাধান করতে পারে: