Bagaimana rasanya bekerja di tim pemrograman besar?

Saya selalu merasa beruntung bekerja di tim pemrograman kecil. Saya pikir yang paling saya kerjakan adalah 11 programmer. Seperti apa rasanya mengerjakan proyek dengan ratusan pengembang? Ribuan? Apa skala dan apa yang tidak?

EDIT: Terima kasih atas semua tanggapannya! Tampaknya ada sangat sedikit hal positif:

• mungkin untuk bekerja pada basis kode mega-besar
• pengembangan karir internal yang lebih baik
• perlindungan karyawan terhadap manajemen yang kasar (ini lebih dari kecil pada + ve pada umumnya)

Apakah ada manfaat lain untuk tim besar?

Saya menemukan skala birokrasi dengan sangat baik.

Selain itu, tidak banyak. Proyek besar memiliki tim besar karena tidak ada cara lain, bukan karena lebih efisien (per pengembang). Anda membayar biaya begitu Anda menambahkan orang kedua ke dalam campuran dalam hal ketidakefisienan (yaitu transfer pengetahuan dan komunikasi).

Proyek terbesar yang saya kerjakan memiliki 70 atau lebih develoeprs di 5 situs yang berbeda. Bahkan perubahan satu baris memakan waktu minimum satu hari walaupun itu sebagian karena fakta bahwa pembangunannya membutuhkan waktu 45 menit lebih melalui tautan jaringan dari Zurich ke London dan memulai aplikasi membutuhkan waktu 45 menit. Check-in membutuhkan waktu sekitar 5 menit per file. Aku tidak bercanda. Pengembang London bisa melakukan ini dalam waktu singkat.

Bagaimanapun, apa yang cenderung Anda temukan adalah bahwa pada proyek-proyek besar Anda akan memiliki banyak anggota tim yang tidak terlalu banyak berinteraksi dengan Anda. Ini lebih seperti kumpulan proyek mini yang terafiliasi longgar. Saya pernah membaca bahwa pengembangan Microsoft cenderung memecah proyek menjadi tim 5-7 pengembang, bahkan untuk proyek besar seperti Microsoft Office.

Bagian dari perbedaan juga perbedaan antara perusahaan kecil dan besar: yang lebih besar cenderung memiliki lebih banyak proses, lebih banyak aturan, lebih sedikit fleksibilitas, dan sebagainya. Tapi itu sama sekali tidak dijamin.

Ini bisa baik untuk pengembangan karir. Dalam sebuah perusahaan kecil seseorang harus pergi atau mati sebelum Anda bisa mendapatkan promosi (atau perusahaan harus tumbuh sedemikian rupa sehingga tim berkembang dan Anda bergerak ke atas) sedangkan di departemen dev yang lebih besar Anda dapat bergerak di antara tim dan sebagainya.

Selain itu Anda kadang-kadang dapat menemukan beberapa orang yang benar-benar pintar untuk melampirkan diri Anda dan belajar darinya. Dalam perusahaan kecil yang begitu terisolasi dan mandiri dapat kondusif bagi pemrogram yang sedikit "aneh", agak seperti seorang pertapa.

Komunikasi adalah apa yang saya temukan sebagai hal terbesar yang mulai menurun ketika ukuran tim bertambah. Menjadi lebih sulit untuk mengeluarkan komunikasi, dan lebih sulit untuk memastikan bahwa semua orang masih pada halaman yang sama. Saya bekerja secara tidak langsung pada tim yang terdiri dari sekitar 75 pengembang, kami menggunakan basis kode yang umum, tetapi banyak dari 75 yang terbagi menjadi kelompok yang lebih kecil untuk "aktivitas" individual. Bagi kami komunikasi hanyalah mimpi buruk.

Manajemen kelompok yang lebih besar juga lebih sulit, karena di sebagian besar lingkungan setelah 8-12 orang anggota manajemen tambahan terlibat, sayangnya ini hanya melebih-lebihkan masalah komunikasi karena biasanya menciptakan lingkungan tipe "silo" di mana masing-masing subset mulai terputus dari kelompok besar dan cobalah untuk menyimpan pengetahuan di dalam kelompok mereka.

Kembali ketika saya membuat perangkat lunak untuk sistem senjata, kami memiliki tim pengembang perangkat lunak BESAR. Karena tidak ada satu orang pun yang dapat memenuhi persyaratan (beberapa di antaranya diklasifikasikan), itu semua tentang tim dan bagaimana tim berinteraksi satu sama lain.

1. Manajemen Konfigurasi - proses pembangunan malam hari - adalah masalah yang sangat besar. Pada hari-hari itu dibutuhkan sebuah cluster komputasi terdistribusi besar untuk mengkompilasi ulang dunia setiap malam.

2. Otorisasi kerja - dan mengisi waktu Anda ke item baris yang benar pada jadwal keseluruhan proyek master - sangat menyebalkan. Turun ke 0,1 jam. kenaikan.

Namun kesepakatan terbesar adalah notifikasi perubahan. Perubahan antarmuka khususnya.

Ini sangat penting, mereka menemukan proses dua lapis yang gila ini. Sebagian besar upaya dilakukan untuk memastikan bahwa Permintaan Perubahan Antarmuka Pemberitahuan (bukan pemberitahuan itu sendiri, tetapi permintaan untuk pemberitahuan) telah menguraikan perangkat lunak pendukung dengan database dan laporan dan apa yang tidak.

Setelah permintaan disetujui, pemberitahuan yang sebenarnya kurang lebih berjalan tanpa berkata. Berarti itu benar-benar proses satu lapis dan permintaan secara efektif adalah pemberitahuan. Tetapi ketika Anda melakukan pengembangan air terjun, semuanya harus dipikirkan lama sebelum pengembang muncul.

Dengan begitu banyak orang yang bekerja secara paralel, ada Dewan Kontrol Konfigurasi. Semua berbagai manajer tim, ditambah sekelompok orang yang pekerjaannya hanya untuk mengoordinasikan perubahan.

Pekerjaan pemrograman "nyata" pertama saya adalah bekerja dengan pasukan lain yang lain untuk mengembangkan sistem kontrol lalu lintas udara internasional. Itu adalah upaya yang sangat sukses dan kami dianggap sebagai lingkungan Tingkat Kematangan Model Level 5. Sejak itu saya berada di toko-toko menengah dan kecil. Jadi, tempat mana yang terbaik? Secara pribadi saya akan mengambil toko yang lebih kecil dari yang besar setiap hari. Sementara beberapa orang mungkin menganggap Level 5 sebagai Cawan Suci, bagi saya itu mencekik. Semuanya harus didokumentasikan, disetujui, ditandatangani, dll. Jangan salah paham, saya melihat nilai di dalamnya, terutama untuk sistem yang sama pentingnya dengan kontrol lalu lintas udara, tetapi pertanyaannya adalah bagaimana Anda ingin menghabiskan hari? Apakah Anda ingin kebebasan untuk dapat memimpikan sesuatu dan kemudian menerapkannya, atau Anda ingin menulis sesuai persyaratan? Mungkin jika saya bertahan lebih lama dengan sistem ATC saya mungkin telah naik ke tingkat kemampuan untuk mendesain dan juga mengembangkan, tetapi bahkan itu membutuhkan X tahun, jumlah Y persetujuan, sejumlah Z promosi - semua ditentukan dengan baik tanpa kemungkinan penyimpangan. Itu mencekik.

Satu hal terakhir, secara umum saya menemukan kualitas pengembang jauh lebih tinggi di perusahaan kecil hanya karena mereka tidak bisa bersembunyi. Tidak sulit untuk menjadi biasa-biasa saja di perusahaan yang sangat besar, tetapi menjadi sangat jelas di perusahaan kecil dan mereka sering tidak bertahan lama.

Saya telah bekerja (secara singkat) di sebuah organisasi dengan setidaknya ratusan pengembang. Tapi tentu saja (?), Organisasi dipartisi secara internal sehingga Anda sebagai karyawan tunggal tidak memiliki kontak langsung dengan yang lain, itu akan sangat sulit untuk diimbangi.

Di tempat itu, perangkat lunak dipecah menjadi beberapa komponen, dengan tim dibentuk di sekitar komponen. Beberapa tim akan bekerja dengan hanya satu komponen (besar), sementara banyak tim memiliki tanggung jawab untuk sekelompok komponen (lebih kecil).

Tentu saja ini menyiratkan segala sesuatu yang bekerja dengan basis kode yang sangat besar tidak; hal-hal seperti manajemen konfigurasi, pembangunan, integrasi, dan sebagainya menjadi hal-hal penting, besar, yang pada gilirannya dibuat oleh departemen khusus. Dan Anda kagum pada mereka, karena mampu mengumpulkan semua output departemen pengembang dan secara teratur (seminggu sekali, di mana saya bekerja) mengintegrasikan semuanya menjadi satu kesatuan yang kohesif yang benar-benar berfungsi.

Saya tidak pernah bekerja untuk tim besar pemrogram , tetapi hasil dari organisasi yang bertambah besar biasanya lebih banyak aturan. Ini tidak selalu selalu merupakan hal yang buruk! Selain aturan yang membuat hidup semua orang sulit, ada juga lebih banyak aturan untuk melindungi karyawan dan memastikan proses yang baik.

Saya telah melihat manajer dalam organisasi kecil lolos dengan hal-hal yang akan segera membuat mereka diberhentikan oleh departemen SDM perusahaan.

Satu perbedaan yang saya perhatikan dengan proyek-proyek besar adalah politik kantor. Semakin besar proyek, semakin dominan politiknya.

Proyek pertama saya di luar sekolah adalah beberapa ratus pengembang. Sebagai pengembang sombong dan naif yang baru lulus sekolah, saya benar-benar tidak siap untuk itu. Satu-satunya hal yang disimpan hiney saya (dan itu adalah satu-satunya hal yang akan pernah benar-benar melindungi Anda) adalah jumlah teman-teman saya membuat.

Itu pelajaran terbesar yang saya pelajari dari itu. Cobalah berteman dengan semua orang . Bahkan tersentak. Khususnya, jika Anda memiliki kesempatan untuk berhenti bekerja sebentar dan berbicara dengan seseorang yang belum pernah Anda ajak bicara sebelumnya, lakukanlah.

Saya pernah menghabiskan satu tahun bekerja di sebuah tim dengan lebih dari 500 orang di dalamnya, sekitar 200 di antaranya adalah pengembang. Kami memberikan EOA, mengintegrasikan beberapa solusi SOA yang berbeda.

Dalam praktiknya ada sekitar 30 hingga 50 tim, masing-masing dengan jumlah programmer yang berbeda-beda (3 di tim kami), masing-masing dengan tanggung jawab untuk aspek yang berbeda dari pengiriman keseluruhan.

Tim terbesar yang pernah saya kerjakan adalah sekitar 15 orang (ini hanya selama 3 atau 4 bulan, di sebuah perusahaan yang berbeda). Saya memimpin teknis di tim, dan mulai bekerja pada jam 7 pagi, saya akan mendapat 2 jam sebelum semua orang masuk, itu satu-satunya cara saya bisa menyelesaikan tugas saya sendiri.

Saya tidak ingin bekerja di tim dengan lebih dari 8 atau 10 pengembang, 15 terlalu banyak untuk satu tim (tim bisa dengan mudah dibagi menjadi dua, bukan panggilan saya sayangnya), 3 atau 4 pengembang adalah IMHO ukuran nyaman yang bagus