বড় প্রোগ্রামিং দলে কাজ করা কেমন?


16

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

সম্পাদনা: সমস্ত প্রতিক্রিয়া জন্য ধন্যবাদ! খুব কম ইতিবাচক বলে মনে হচ্ছে:

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

বড় দলগুলিতে অন্য কোনও সুবিধা আছে কি?


1
এটি স্তন্যপান। সব খরচ এ এটা করবেন না।
পল টমলিন 13

4
আমি ১১ জনকে একটি বড় দল হিসাবে বিবেচনা করব ... আমি এর সাথে কাজ করেছি সবচেয়ে বড় 3 টি! :-)
ব্রায়ান নোব্লাচ

কিছু দৃষ্টিকোণ অর্জনের জন্য 'পৌরাণিক পুরুষ মাস' পড়ুন ... যদিও এটি আমার কাছে আবেদন করে নি (সবচেয়ে বেশি আমি এর সাথে কাজ করেছি 4 অন্যান্য বিকাশকারী, আরও 3 পরীক্ষক এবং একটি বিকাল)। বড় দলগুলি শোনা যাচ্ছে যে এটি সভার পরে সভার পরে মিলিত হচ্ছে :(
workmad3

আমি রাজী. 11 একটি বড় দল। আইএমএইচও 3 সেরা।
জোশুয়া পার্টোগি

উত্তর:


11

আমলাতন্ত্রের স্কেলগুলি আমি খুব ভালভাবে পাই।

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

আমি যে বৃহত্তম প্রকল্পে কাজ করেছি তার মধ্যে 5 টি বিভিন্ন সাইট জুড়ে 70 বা তাই ডেভেলপার ছিল। এমনকি এক লাইনের পরিবর্তনতেও একদিন সর্বনিম্ন সময় লেগেছিল যদিও এটি অংশটি জুরিখ থেকে লন্ডন পর্যন্ত একটি নেটওয়ার্ক লিঙ্কে 45+ মিনিট সময় নিয়েছে এবং অ্যাপ্লিকেশন শুরু করতে আরও 45 মিনিট সময় নিয়েছিল এই কারণে এই অংশটি ছিল। চেক-ইনগুলি প্রতি ফাইল প্রতি 5 মিনিট সময় নেয়। আমি মজা করছি না. লন্ডনের বিকাশকারীরা সময়ের কিছু অংশে এটি করতে পারতেন।

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

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

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

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


আমার সময়ে আমি এই স্ট্র্যাংজিদের কয়েকটি দেখেছি
বাইনারি

2
কখনও কখনও আমি আশঙ্কা করি আমি তাদের মধ্যে একজন হতে পারি
ইয়েস্রোয়েল

1
"আমি আমলাতন্ত্রের স্কেলগুলি খুব ভালভাবে পাই।" উক্তিটি ভালোবাসি!
এইচএলজিইএম

5

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

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


5

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

  1. কনফিগারেশন ম্যানেজমেন্ট - রাত্রি বিল্ড প্রক্রিয়া - এটি একটি খুব বড় বিষয় ছিল। সেই দিনগুলিতে প্রতি রাতে বিশ্বকে পুনরায় সংকলন করতে এটি একটি বিশাল বিতরণ করা কম্পিউটিং ক্লাস্টার নিয়েছিল।

  2. কাজের অনুমোদন - এবং মাস্টার সামগ্রিক প্রকল্পের সময়সূচীতে আপনার সঠিক সময় লাইন আইটেমটি চার্জ করা - ঘাড়ে একটি বড় ব্যথা ছিল। নীচে 0.1 ঘন্টা। বাড়তি।

তবে সবচেয়ে বড় চুক্তি ছিল পরিবর্তন নোটিফিকেশন। বিশেষত ইন্টারফেস পরিবর্তন।

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

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

সমান্তরালে অনেক লোক কাজ করার সাথে সাথে একটি কনফিগারেশন কন্ট্রোল বোর্ড ছিল। সমস্ত বিভিন্ন টিম ম্যানেজার, প্লাস লোকদের গ্রুপ যারা কাজটি করেছে কেবল পরিবর্তনের সমন্বয় সাধন করা।


4

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

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


2

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

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

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


2

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

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


2

বড় প্রকল্পগুলির সাথে আমি যে পার্থক্যটি লক্ষ্য করেছি তা হ'ল অফিসের রাজনীতি। যত বড় প্রকল্পগুলি তত বেশি প্রভাবশালী রাজনীতি।

বিদ্যালয়ের বাইরে আমার প্রথম প্রকল্পটি কয়েকশো বিকাশকারী ছিল। স্কুল থেকে সতেজ একটি কৌতুকপূর্ণ এবং নিষ্পাপ বিকাশকারী হিসাবে আমি সত্যিই এর জন্য প্রস্তুত ছিল না । শুধু যে আমার hiney সংরক্ষিত (এবং এটি শুধুমাত্র জিনিস যে হবে কি কখনো সত্যিই তোমাকে রক্ষা) বন্ধুদের পরিমাণ আমি তৈরি ছিল।

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


1

আমি একবার এক বছরে 500 টিরও বেশি লোক নিয়ে একটি দলে কাজ করে কাটিয়েছি, এর মধ্যে প্রায় 200 জন বিকাশকারী ছিলেন। আমরা একটি EOA সরবরাহ করছিলাম, বেশ কয়েকটি বিভিন্ন SOA সমাধান সংহত করে।

অনুশীলনে কোথাও 30 থেকে 50 টি দলের মধ্যে ছিল, প্রত্যেকটিতে বিভিন্ন সংখ্যক প্রোগ্রামার (আমাদের দলে 3) ছিল, যার প্রতিটি সামগ্রিক বিতরণযোগ্যতার ভিন্ন দিকটির জন্য দায়বদ্ধ।

আমি সর্বকালের সবচেয়ে বড় দলটিতে প্রায় 15 জন লোক ছিল (এটি কেবল 3 বা 4 মাসের জন্য ছিল, একটি আলাদা সংস্থায়)। আমি দলে প্রযুক্তিগত নেতৃত্ব পেয়েছি, এবং সকাল 7 টায় কাজে লাগতে নেমেছি, অন্য সবাইকে quiteোকার আগে বেশ কয়েক ঘন্টা আগে পেয়ে যাচ্ছিলাম, আমার নিজের কোনও কাজ সম্পন্ন করার একমাত্র উপায় ছিল।

আমি 8 বা 10 টিরও বেশি বিকাশকারীদের নিয়ে একটি দলে কাজ করতে চাই না, 15 কোনও একক দলের পক্ষে অনেক বেশি ছিল (দলটি সহজেই দু'ভাগে বিভক্ত হতে পারে, দুর্ভাগ্যক্রমে আমার কল নয়), 3 বা 4 দেব একটি সুন্দর আরামদায়ক আকার IMHO

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