Terlalu banyak senior dalam satu tim? [Tutup]

Bisakah terlalu banyak programmer senior dalam satu tim berubah menjadi hal yang buruk?

Karena suka mengatakan, 4-5 programmer senior dalam tim 6-7 orang. Berapa angka / rasio optimal dalam situasi semacam ini?

Bisakah ini menyebabkan terlalu banyak filsafat dan argumen tentang ide?

Adakah yang punya pengalaman seperti itu, yang bisa membaginya dengan saya?

Jika saya bisa memilih, saya akan memiliki 6-7 senior di tim (dengan asumsi proyek membutuhkan banyak).

Satu-satunya waktu saya dapat melihat ini menjadi masalah adalah jika senior hanya senior dalam persepsi diri dan bukan etos kerja.

Tidak ada yang lebih baik daripada bekerja dengan sekelompok orang yang menghargai bahwa setiap bagian dari pengembangan perangkat lunak itu penting - dokumentasi, perencanaan, kode, kopi, semuanya penting dan dibutuhkan pengembang dewasa (benar-benar senior) untuk menjadi "di atas tidak ada "dan menyelesaikan pekerjaan dengan benar.

EDIT : Banyak jawaban lain mengatakan bahwa terlalu banyak pemimpin adalah masalah - tetapi mengapa ada persepsi bahwa seorang senior harus memimpin? Seorang senior harus cukup dewasa untuk memilih seorang pemimpin dan mengikuti. Ini adalah proyek yang penting - pilih / dapatkan peran dan goyang itu konyol!

Masalah terbesar yang saya lihat saat memuat tim dengan pemrogram senior adalah bahwa hal itu dapat melemahkan tim lain. Jika Anda memiliki pengembang junior di tim lain yang membutuhkan bimbingan dan bimbingan, maka Anda mungkin perlu mengubah orang.

Bisakah ini menyebabkan terlalu banyak filsafat dan argumen tentang ide?

Tentu bisa , tetapi mereka harus cukup dewasa untuk mengetahui perbedaan apa yang penting dan mana yang tidak. Jika Anda telah menunjuk pemimpin tim yang disegani, argumen filosofis semacam ini harus dijaga seminimal mungkin dengan sedikit usaha.

Bisakah terlalu banyak programmer senior dalam satu tim berubah menjadi hal yang buruk?

Pastinya.

Saya seorang pendukung besar pola tim bedah Fred Brooks .

Dan dengan itu dikatakan, jika senior di tim pengembangan tidak tahu siapa "ahli bedah kepala" itu, maka mereka akan berbenturan dengan keputusan arsitektur penting dan akan menarik ke arah yang berbeda dengan merugikan tim.

PS Kebutuhan tim pengembangan untuk "ahli bedah kepala" mirip dengan kebutuhan orkestra untuk seorang konduktor. Dalam kedua kasus itu, Anda mungkin memiliki banyak veteran; tetapi Anda akan memiliki kekacauan yang baik tanpa satu orang yang bertanggung jawab.

Itu tergantung pada bagaimana tanggung jawab didistribusikan. Jika SEMUA dari Sr Devs seharusnya memiliki tanggung jawab desain yang sama, review kode, dll ... maka itu bisa menjadi masalah. Jika mereka diberi tanggung jawab yang berbeda sehingga mereka dapat bekerja tanpa memperebutkan kendali atas domain masing-masing, maka itu seharusnya tidak menjadi masalah - misalnya, seorang Senior Dev mendapat tanggung jawab utama dari desain proyek, yang lain bertanggung jawab atas mengatur dan memelihara repositori sumber, yang lain bertanggung jawab atas pengujian unit, dll ...

Bisakah terlalu banyak programmer senior dalam satu tim berubah menjadi hal yang buruk?

Belum tentu. Saya telah bekerja pada tim kecil pengembang senior yang sangat produktif. Tingkat wacana sangat tinggi, dan tidak ada dendam.

Dengan TDD, ada sangat sedikit komitmen besar untuk arsitektur perangkat lunak, jadi ada sedikit kebutuhan untuk berdebat tentangnya. Keputusan desain dapat diselesaikan dengan hanya menerapkan kedua pendekatan dan melihat mana yang paling berhasil. Karena pengembangnya sangat cepat, biaya uji coba ini sangat rendah.

Ya, mungkin ada masalah memiliki terlalu banyak koki di dapur untuk satu metafora yang mungkin berlaku. Mungkin juga cukup mahal jika mereka semua mengharapkan gaji tinggi. Perhatikan bahwa ini hanya memverifikasi keberadaan kasus yang buruk dan tidak mengatakan apa-apa tentang kemungkinannya.

Optimal tergantung pada sejumlah variabel yang tidak Anda ungkapkan. Metrik apa yang ingin Anda gunakan menyadari bahwa ada peluang bagus untuk bermain game di sini. Demikian pula, kendala apa yang Anda miliki dalam dunia Anda yang mungkin membuatnya berbeda dari apa yang dimiliki Google atau Microsoft.

Terlalu banyak pengembang senior dapat memiliki masalah baik tanpa konvensi atau terlalu banyak konvensi. Sementara beberapa pengembang senior mungkin pandai beradaptasi, jika tidak ada satu pun dari mereka yang mungkin memperkenalkan konvensi, di mana tim akan mulai? Sebaliknya, mungkin ada beberapa pengembang senior yang merupakan penggemar berat dari beberapa konvensi yang mungkin memerlukan beberapa resolusi konflik untuk menyelesaikannya.

Saya pikir itu tergantung pada kepribadian para senior. Jika mereka sombong dan argumentatif, maka itu bisa menjadi hal yang buruk. Tetapi jika mereka semua saling menghormati, terbuka terhadap sudut pandang lain, dan mau belajar dari satu sama lain, maka Anda memiliki tim yang hebat.

Saat ini saya bekerja di tim 8, di mana 5 atau 6 adalah senior, dan itu bekerja dengan sangat baik bagi kami. Kami rukun, belajar dari satu sama lain, dan ini adalah lingkungan bimbingan yang bagus untuk orang-orang baru yang kami miliki.

Saya bekerja di sebuah tim di mana ada 1 pengembang utama, 4 pengembang senior, dan 1 pengembang menengah. Dan karena alasan bahwa salah satu anggota "senior" dari tim itu bukan orang yang benar-benar matang (pengembang yang baik), itu ternyata menjadi mimpi buruk. Dia berusaha membuktikan sepanjang waktu (secara implisit atau eksplisit) bahwa anggota tim lainnya tidak cukup senior. Dia juga gagal memahami prinsip-prinsip dasar pengembangan perangkat lunak dan spesifikasi produk kami, dan, oleh karena itu, dengan sombong dan keras kepala berusaha membuktikan bahwa dia benar. Akibatnya, hal itu sangat memengaruhi efektivitas tim. Bagian yang menyedihkan adalah bahwa itu bahkan tidak terlalu banyak argumen tentang ide / solusi - itu adalah argumen tentang apa - apa . Sebagai contoh:

• yang merusak bangunan (yang sebagian besar berwarna hijau dan, secara teknis, tidak rusak. UI yang sering gagal berfungsi dengan baik karena solusi arsitektur yang buruk)
• mengapa ada regresi (modul tidak dicakup oleh unit-tes yang kami tidak memiliki akses untuk berkontribusi ke)
• berdebat tentang solusi arsitektur dalam modul yang merupakan tanggung jawab orang lain tanpa mengetahui tentang persyaratan dan spesifik modul.
• ...

Tapi saya akui itu agak pengecualian. Saya ingin percaya bahwa para manula berperilaku baik hampir setiap saat :)