বৈশিষ্ট্যের মালিকানা কি একটি ভাল অনুশীলন?


22

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

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

যদিও আমি স্বীকার করি যে এটি স্বল্প মেয়াদে উত্পাদনশীলতা বৃদ্ধি করবে, আমার অনুভূতি আছে (এবং আমি মনে করি এটি আমি বিশ্ববিদ্যালয়ে শিখেছি) যে এটি অনেক কারণে খারাপ অভ্যাস:

  • কোড পর্যালোচনা মান হারায়।
  • ন্যূনতম জ্ঞান ভাগ করে নেওয়া।
  • ঝুঁকি বৃদ্ধি।
  • দলের নমনীয়তা হ্রাস।

আমি ঠিক আছি নাকি আদৌ এটি খারাপ অভ্যাস নয়?


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

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

@ জেনসিজি: মেহ, আমার একটি অভিজ্ঞতাগত তত্ত্ব আছে যে আমার সবচেয়ে বেশি প্রয়োজন ব্যক্তি ("ডাব্লুটিএফএফ? কেন তিনি সেভাবে এটি লেখেন?") এবং আমি "যে জিনিসগুলি লিখে রাখা উচিত ছিল তার স্মরণে রাখার জন্য বাসের উপাদান সময় "এ 0. এটা ঠিক অধিক উল্লেখযোগ্য যখন আমি কারো না কারো দ্বারা অবরুদ্ধ করছি, কারন আমি গোড়া থেকে বিদ্যমান কোড পুনরায় পরীক্ষা করার নিজস্ব যথার্থতা ;-) উপর পরিবর্তে এটি সম্পর্কে জ্বালাতন
স্টিভ জেসপ

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

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

উত্তর:


37

আমার 20 বছরের অভিজ্ঞতায় ডিজাইনারদের মধ্যে কোডের মালিকানা ঘুরিয়ে দেওয়ার দায়িত্ব বা কমপক্ষে মালিকদের জুড়ি রাখা ভাল। একক বৈশিষ্ট্যের মালিকানাতে নিম্নলিখিত বিষয়গুলি রয়েছে, যার মধ্যে বেশ কয়েকটি আপনি উল্লেখ করেছেন:

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

6
একেবারে। একমাত্র ব্যক্তির মালিকানা সহ একক স্পষ্টতম সমস্যা হিসাবে বাসের বিষয়টিকে উল্লেখ করা গুরুত্বপূর্ণ factor
জেনসজি

1
বাস ফ্যাক্টরটি ব্যয় এবং YAGNI এর বিপরীতে লেনদেন করা দরকার, যদিও এবং বাসটি সত্যিই আপনার সংস্থাকে পঙ্গু করে দেবে বা কেবল প্রচুর ঝামেলা সৃষ্টি করবে। যদি এটি হারাতে পছন্দ হয়, তবে বলুন, সপ্তাহে 3 ঘন্টা চিরতরে নিশ্চিত হয়ে নিন যে দু'জন লোক কেবলমাত্র একটির পরিবর্তে নির্দিষ্ট কোডের বিষয়ে শিক্ষিত, বা হারানো, বলুন, কেউ নিজেকে উত্থাপন করার জন্য 60 ঘন্টা এক-অফ হিসাবে ইভেন্টটির গতি বাড়ানোর জন্য আপনার বিকাশকারীদের মধ্যে একটি আঘাত হানে, তারপরে অনেক ক্ষেত্রে আপনি ওয়ান-অফ ব্যয়টি বেছে নিতে চান। তবে বর্ণিত কারণগুলির জন্য, জ্ঞান সিলোগুলির অন্যান্য অসুবিধাগুলি আরও গুরুত্বপূর্ণ (যদিও স্বল্প প্রমাণিত হোক) have
স্টিভ জেসপ

13

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

তবে আপনি সে বিষয়ে কথা বলছেন না। আপনি একটির একটি নতুন দল তৈরি করার কথা বলছেন - এই ব্যক্তিকে বাকী কোড থেকে কেটে ফেলুন। এটি দুর্দান্ত নয়। এটি তাদের কেরিয়ার সীমাবদ্ধ করে। এটি প্রকল্প / সংস্থায় ঝুঁকি যুক্ত করে। এটি কমরেডির ক্ষতি করে।

সুতরাং কিছু সংযম হতে পারে যাতে এটি একটি খারাপ ধারণা থেকে সরে যায়।


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

1
@ জেসন - অবশ্যই, দলে কিছু লোক থাকতে হবে যারা আরামদায়ক এবং কোডের একটি অংশে কাজ করতে সক্ষম। তবে একজন ব্যক্তি কেবলমাত্র সবচেয়ে বেশি কাজ করা থেকে বিষয় বিশেষজ্ঞকে শেষ করবেন।
তেলস্তিন

সম্মত হন যে এটি প্রায়শই ঘটে থাকে, সম্ভবত বেশিরভাগ পরিস্থিতি এবং বিষয়টির দক্ষতা একটি ভাল বিষয় - কেবলমাত্র মতভেদ হ'ল এটি অনিবার্য কারণ কেবল বেশিরভাগ লোকের সাথে একটি অঞ্চলে এসএমই হওয়ার কারণে যথেষ্ট পরিমাণে ওভারল্যাপ করে ভাল সাফল্য পেয়েছি
জেসন কে ।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.