Mengapa menambahkan lebih banyak orang ke proyek terlambat membuatnya nanti?

25

Ini adalah pepatah yang cukup umum bahwa menambahkan lebih banyak programmer ke proyek akhir akan memperburuk keadaan. Kenapa ini?

project-management

— Henry
sumber

14

Istilah untuk ini adalah Hukum Brooks ( en.wikipedia.org/wiki/Brooks's_law ).

— Macneil

7

Saran: baca Brooks '"The Mythical Man-Month". Ini akan menunjukkan dari mana pepatah itu berasal, itu adalah buku yang sangat mudah dibaca, dan semua orang di lapangan harus tetap membacanya.

— David Thornley

Halaman Wikipedia itu ditulis dengan sangat baik.

— Henry

Untuk bukti bagaimana produktivitas menurun dengan ukuran tim (di luar 7 anggota tim Anda mendapatkan hasil yang semakin berkurang), lihat qsm.com/process_improvement_01.html

— Joeri Sebrechts

33

Pengantar overhead

Setiap pengembang baru harus diperkenalkan dengan basis kode dan proses pengembangan yang tidak hanya memakan waktu orang baru tetapi juga membutuhkan bantuan dari [a] pengembang senior [s] (membimbing mereka melalui proses pembangunan, menjelaskan proses pengujian, membantu mereka dengan jebakan di basis kode, ulasan kode yang lebih rinci, dll) .

Oleh karena itu, semakin banyak pengembang baru yang Anda tambahkan ke proyek, semakin banyak waktu yang dihabiskan untuk membawa mereka ke titik di mana mereka benar-benar dapat berkontribusi pada proyek.

— Baelnorn
sumber

Jadi jika Anda mengoptimalkan 'Pendahuluan' maka dampaknya akan berkurang?

— Henry

9

@ Henry: masalahnya adalah bahwa Anda biasanya tidak dapat mengoptimalkan aspek itu ke tingkat di mana itu bukan hambatan. Seorang programmer baru pada awalnya tahu persis 0 tentang proyek Anda, kode Anda dan proses Anda. Itu adalah overhead yang sama yang selalu diperlukan saat menambahkan anggota tim baru. Tetapi ketika sebuah proyek sudah terlambat, tim seringkali tidak memiliki waktu untuk melakukan perkenalan yang tepat, dan jika itu terjadi maka waktu tersebut hilang dari pengembangan yang sebenarnya. Oleh karena itu biasanya situasi kalah-kalah untuk tim dan orang baru membutuhkan waktu lebih lama sampai dia dapat berkontribusi secara berarti untuk proyek tersebut.

— Baelnorn

Mengenai biaya melakukan pengenalan, tidak bisakah itu direkam video sekali dan kemudian disiarkan ke banyak orang, sehingga dapat melatih banyak programmer baru sekaligus? (Contoh: pertemuan atau konferensi pengembang.)

— rwong

7

@ rwong: Ini bukan ide yang buruk, tetapi ini biasanya tidak praktis. Anda tidak bisa hanya menyajikan informasi, Anda harus memastikan orang-orang baru memahaminya. Plus, jika mereka benar - benar baru (lulusan baru), biasanya ada terlalu banyak informasi untuk disajikan kepada mereka sekaligus. Kami telah menemukan bahwa wiki berfungsi dengan baik, karena semua informasi ada di satu tempat, dan orang-orang dapat memposting pertanyaan jika ada bit yang tidak mereka mengerti.

— TMN

Salah satu kemungkinan adalah menetapkan orang baru yang sangat kompeten, dan meminta mereka melakukan tugas-tugas khusus tanpa mengganggu yang lain. Mereka akan menggelepar buruk dan bekerja lambat, dan beberapa manajer dan / atau tim tidak tahan melihat ini. Namun, pengembang baru bisa menjadi nilai tambah ketika dikelola dengan cara itu.

— David Thornley

32

Selain jawaban lain: Faktor lain yang perlu dipertimbangkan adalah komunikasi.

Kasus terburuk untuk jumlah saluran komunikasi di tim (yang tidak biasa), adalah grafik lengkap . Seperti yang dapat Anda bayangkan, menambahkan hanya dalam 1 pengembang dapat meningkatkan banyak saluran komunikasi. Dengan metode komunikasi yang lebih ramping, dampaknya kurang ... tetapi masih bertambah.

— Steven Evers
sumber

Saya menulis sama pada waktu yang bersamaan! tapi saya tidak baru itu memiliki nama (grafik lengkap) dan penjelasan Anda lebih baik, jadi pilihlah saya.

— Miguel Veloso

+1. Setuju, ini adalah masalah terbesar saat menambah lebih banyak anggota tim.

— Martin Wickman

+1 untuk masalah jangka panjang dengan menambahkan orang ke proyek.

— indyK1ng

23

Masalah yang dikutip dalam buku yang awalnya disahkan undang-undang ini, The Mythical Man-Month , adalah komunikasi. Dia memulai dengan mengatakan:

Pria dan bulan adalah komoditas yang dapat dipertukarkan hanya ketika sebuah tugas dapat dipartisi di antara banyak pekerja tanpa komunikasi di antara mereka. Ini berlaku untuk menuai gandum atau memetik kapas; bahkan tidak kira-kira benar pemrograman sistem.

Dia menyebutkan pelatihan sebagai bagian dari masalah:

Beban komunikasi tambahan terdiri dari dua bagian: pelatihan dan komunikasi antar. Setiap pekerja harus dilatih dalam teknologi, tujuan dari upaya, strategi keseluruhan, dan rencana kerja. Pelatihan ini tidak dapat dipartisi, jadi bagian pekerjaan ini bervariasi secara linier dengan jumlah pekerja.

... tetapi perhatikan bahwa komunikasi jauh merupakan faktor yang lebih besar :

Karena pembangunan perangkat lunak secara inheren merupakan upaya sistem - latihan dalam hubungan timbal balik yang kompleks - upaya komunikasi sangat baik, dan dengan cepat mendominasi penurunan waktu tugas individu yang disebabkan oleh partisi. Menambahkan lebih banyak pria memperpanjang, bukan mempersingkat, jadwal.

Perlu juga dicatat bahwa Fred Brooks (penulis) memang memiliki latar belakang untuk mengetahui apa yang dia bicarakan. Sebagian besar buku ini didasarkan pada pengalamannya mengelola proyek OS / 360 IBM. Meskipun berpuluh-puluh tahun penganutnya mengabarkan segala macam metode manajemen yang "ditingkatkan", dan beberapa bahkan muncul dengan nama-nama keren (eXtreme, Agile, Scrum, dll.) Ketika Anda membahasnya, sedikit esensi ¹ tampaknya telah berubah sejak itu.

¹ Untuk definisi "esensi", lihat penulis yang sama "No Silver Bullet: Essence and Accident in Software Engineering", yang disertakan dalam Edisi Ulang Tahun ^ke - 20 The Mythical Man-Month .

— Jerry Coffin
sumber

12

Ini bukan hanya pepatah; itu bisa diverifikasi. Lihatlah Brooks ' The Mythical Man-Month .

— John
sumber

1

Ini adalah pepatah. Mungkin bisa diverifikasi atau tidak, tetapi itu tidak menghentikannya menjadi pepatah.

— Peter Boughton

3

Saya tidak punya buku ini (jelas). Apakah ini didukung oleh angka keras atau anekdot?

— Henry

2

@ Henry: Sudah lama sejak saya membacanya tetapi IIRC, keduanya hadir dalam jumlah yang cukup untuk membuat titik secara meyakinkan.

— Steven Evers

@ Peter: Diedit jawaban saya.

— Yohanes

@PeterBoughton Ini adalah pepatah. Juga, ini bukan hanya pepatah.

— SantiBailors

6

Berikut adalah beberapa pemikiran tentang masalah ini ...

Perlu menggunakan sumber daya saat ini untuk meningkatkan sumber daya baru pada apa yang terjadi dengan proyek.
Sumber daya baru mungkin tidak terbiasa dengan basis kode, sehingga diperlukan lebih banyak waktu untuk terbiasa dengan kode.

sekarang, menambahkan sumber daya baru untuk pengujian mungkin bukan ide yang buruk ... itu mungkin mempercepat proses pengujian (jika kasus pengujian Anda ditulis dengan baik), dan ya menggunakan alat pengujian akan membantu juga.

— aggietech
sumber

1

+1 untuk menambahkan sumber daya ke pengujian, bukan pengembangan.

— Baelnorn

4

Karena pemrograman bukanlah pekerjaan lini produksi dasar. Memperoleh kecepatan pada proyek perangkat lunak membutuhkan waktu. Orang-orang baru perlu mengajukan banyak pertanyaan yang mengarah pada produktivitas negatif (yaitu orang baru belajar, orang tua mengajar mereka -> tidak ada pekerjaan aktual yang dilakukan).

Untuk menyederhanakannya, bayangkan proyek satu orang yang relatif sederhana yang dijadwalkan berlangsung selama 1 minggu: pada hari Kamis, Anda menyadari bahwa itu tidak akan selesai tepat waktu, bahwa itu akan membutuhkan satu programmer lebih seperti 6-7 hari sebagai gantinya dari 5. Jika Anda menambahkan programmer lain pada saat itu, mereka harus bekerja dengan programmer1 setidaknya selama beberapa jam atau sekitar satu hari, ajukan banyak pertanyaan untuk mempercepat, dll. Anda mungkin tidak akan mendapatkan setiap produktivitas positif bersih untuk sisa minggu ini. Programmer baru kemungkinan akan memperkenalkan beberapa bug tambahan juga (karena mereka tidak akan tahu kode yang ada serta programmer1), sehingga akan meledakkan siklus implementasi dan pengujian satu atau dua hari lagi. Proyek ini akan dengan mudah berlangsung dua minggu penuh, bukan yang asli!

— Tabel Bobby
sumber

Contoh Anda sedikit dibuat-buat oleh tenggat waktu pendek yang tidak realistis yang tersisa untuk proyek tersebut. Ubah menjadi satu bulan dan Anda akan melihat bahwa itu tidak perlu benar. Secara pribadi saya pikir kutipan itu disalahgunakan. Memang benar ketika mempertimbangkan run-of-the-mill, programmer rata-rata / miskin. Jika Anda memiliki programmer yang baik, dan tenggat waktu bukanlah sesuatu yang tidak realistis seperti 1 hari atau 1 minggu, maka penawarannya salah: itu dapat dilakukan (tolong proyeknya).

— n1ckp

@ n1ck Ini generalisasi - seperti "terlalu banyak koki" - intinya adalah bahwa dengan hanya melemparkan tenaga kerja ke proyek tidak akan membuatnya diselesaikan lebih cepat. 1 orang ke 2? Mungkin akan. 2 hingga 4? Terlalu banyak variabel - itu tergantung pada ukuran dan struktur proyek. 4 -> 8? Pasti mendapatkan marjinal (paling tidak dalam hal pengembalian biaya).

— Murph

@ Murph: Anda tampaknya berpikir sebagian besar hal yang sama seperti saya tetapi Anda lupa satu variabel yang sangat penting dalam persamaan Anda: tingkat keterampilan tenaga kerja yang ditambahkan. Itu di komentar terakhir saya, jadi saya merasa aneh bahwa Anda melewatkannya. Menambahkan tenaga secara buta tentu saja bukan solusi. Menambahkan tenaga kerja yang sangat terspesialisasi (Anda tidak perlu banyak) tentu saja dapat membantu dan inilah yang tidak ada dalam kutipan mitos bulan-manusia. Itulah poin saya. Kalau tidak, saya sudah tahu tentang apa artinya kutipan.

— n1ckp

Ok, contohnya bisa lebih baik tetapi generalisasi masih valid?

— Murph

1

Saya telah melalui waktu yang cukup untuk tahu bahwa itu adalah salah satu hal yang MUNGKIN bekerja dalam kasus-kasus yang sangat khusus, tetapi 99% dari waktu itu tidak akan. Tidak peduli seberapa bagus kelihatannya dalam teori saat itu. Yang mengatakan, ya, itu bukan mutlak hitam dan putih. Ini lebih seperti mengatakan, bagaimana hubungan terbuka tidak berhasil. Teorinya bagus, dan menggoda;) .... tetapi sifat binatang itu sedemikian rupa sehingga dalam banyak kasus akhirnya gagal. Semacam hal "pengecualian membuktikan aturan".

— Bobby Tables

4

Fred Brooks menulis seluruh buku "The Mythical Man-Month" yang menjawab pertanyaan ini.

Ini versi quick-n-dirty:

1) Ada batasan seberapa banyak Anda dapat memecah proyek menjadi bagian-bagian yang berbeda untuk ditugaskan ke lebih banyak programmer.

2) Memisahkan proyek ke lebih banyak orang meningkatkan jumlah komunikasi yang diperlukan untuk mengoordinasikan semua bagian aplikasi. Lebih banyak komunikasi = Lebih Banyak Pekerjaan.

3) Untuk setiap orang yang Anda tambahkan ke proyek Anda menambahkan lebih dari satu saluran komunikasi yang harus dinavigasi ke tim. Jumlah ini tumbuh secara geometris dan meningkatkan jumlah komunikasi yang harus terjadi. Lebih banyak komunikasi = Lebih banyak pekerjaan.

4) Ada "J-Curve" ketika Anda menambahkan setiap anggota tim. Artinya, sumber daya produktif yang ada harus menghabiskan waktu untuk mempercepat orang-orang baru yang seharusnya mereka habiskan bekerja di proyek. Pada akhirnya Anda dapat meningkatkan kapasitas, tetapi untuk sementara memperlambat proyek. Semakin dalam proyek semakin banyak yang harus dipelajari, sehingga semakin jelas pengaruhnya.

— JohnFx
sumber

4

Faktor lain yang belum saya lihat disebutkan adalah bahwa beberapa tugas perlu dilakukan dalam urutan tertentu. Anda tidak dapat melakukan tugas 4 sampai tugas 3 selesai karena tergantung pada 3. Tidak ada gunanya mempekerjakan seseorang untuk melakukan tugas 4 pada saat yang sama seseorang melakukan tugas 3. Seringkali pada akhir proyek , tugas-tugas yang perlu diselesaikan terlebih dahulu adalah tugas yang tersisa.

Mereka juga sering merupakan beberapa tugas paling kompleks yang perlu dilakukan, tugas yang membutuhkan pemahaman terbaik dari seluruh desain untuk menghindari melanggar apa yang telah diselesaikan. Mereka juga biasanya membutuhkan pengetahuan domain bisnis yang paling luas. Saya mungkin setelah mengerjakan proyek selama berbulan-bulan dapat melakukan tugas dalam seminggu atau kurang. Seseorang yang baru akan menghabiskan lebih dari seminggu untuk mempercepat (dan menarik saya dari tugas-tugas saya untuk mendapatkan kesempatan yang baik untuk menjawab pertanyaan-pertanyaan) dan kemungkinan bahkan jika sangat terampil membutuhkan waktu lebih lama untuk melakukan tugas itu. Bukan karena dia tidak kompeten tetapi karena tidak terbiasa dengan struktur sebenarnya dari proyek atau database backend.

— HLGEM
sumber

+1. Ini adalah masalah besar pada pekerjaan terakhir saya. Manajemen sedang dalam "man month menambahkan" kegemaran untuk proyek besar tanpa memikirkan semuanya. Pada satu titik, tim kami dibor karena lambat - karena barang-barang kami perlu diintegrasikan dengan proyek besar itu. Tapi kemudian, karyawan baru pada proyek besar tidak bisa mempercepat dengan cukup cepat, jadi KAMI terlalu jauh ke depan (pada hal-hal yang membutuhkan backend mereka selesai). Pada satu titik, kami mengembangkan ujung depan untuk backend setengah matang dan test harness. Bukan aliran yang bagus.

— Bobby Tables

2

Pepatah yang selalu berhasil bagi saya adalah Anda tidak bisa mendapatkan sembilan wanita untuk menghasilkan bayi dalam satu bulan.

— memutarkan lagi
sumber

Jika Anda berpikir proyek perangkat lunak seperti bayi, Anda tidak hidup di dunia nyata. Ada beberapa kebenaran dalam kutipan tetapi ini adalah contoh sempurna untuk mengambil hal-hal di luar konteks: -1

— n1ckp

1

Jelas tidak. Tetapi mereka orang-orang yang Anda jual jangka waktu juga tidak mengerti pengembangan perangkat lunak. Analogi persis untuk tujuan itu yang menghubungkan konsep yang tidak diketahui dengan entitas yang tahu.

— jalankan kembali

2

Analogi lain yang dibuat Brooks adalah makanan di restoran. Dapur yang dikelola dengan baik dapat menghasilkan banyak makanan secara paralel, tetapi ada batasan seberapa cepat dapat membuat satu kali makan tanpa dimasak atau dibakar.

— David Thornley

@rerun: masalah dengan analogi Anda adalah bahwa tidak ada analogi pekerja untuk wanita hamil. Para wanita dalam kasus Anda bisa lebih mudah dibandingkan dengan perusahaan , bukan pekerja. Itu sebabnya itu sangat gagal menurut saya. Yang paling dekat yang bisa saya pikirkan adalah makanannya tetapi itu lebih seperti garis kode, jadi tidak, bukan pekerja.

— n1ckp

1

@ n1ck: Kesan saya adalah Anda tidak setuju karena Anda tidak memahaminya, jujur saja. Brooks tidak berbicara tentang mengganti orang yang tidak berguna dengan orang yang kompeten, karena ia berada dalam situasi di mana semua orang yang masih bekerja dianggap kompeten.

— David Thornley

2

Saya juga menyarankan "Peopleware" oleh DeMarco dan Lister.

Dan "The Deadline" oleh DeMarco menyajikan ini, dan sejumlah penyakit manajemen proyek perangkat lunak lainnya dan kekeliruan dengan cara yang ringan dan sangat mudah dibaca.

Ini juga menggali dinamika orang yang melakukan pekerjaan proyek / tim, dan masuk ke beberapa detail tentang hanya BAGAIMANA hal-hal seperti komunikasi dan pengantar menghabiskan waktu kerja tim yang tersedia.

Buku-buku ini cukup murah, saya sarankan Anda mendapatkannya (Amazon atau The Book Depository memilikinya) dan baca. Jawaban singkat di sini tidak bisa benar-benar adil untuk pertanyaan yang diajukan.

— dengan cepat_now
sumber

2

Karena tidak ada yang meluangkan waktu untuk memiliki proses yang dipikirkan dengan matang, terencana, teruji untuk: merekrut, melatih, mengembangkan dan mengawasi programmer, apalagi menyatukan mereka dengan cepat pada proyek tertentu.

Jika Anda mengelola tim pengembang, Anda harus memiliki beberapa kontak saat ini dari orang-orang yang ingin Anda pekerjakan jika Anda memiliki pembukaan. Bergabunglah dengan grup pengembang.

Seberapa cepat Anda bisa mendapatkan setup mesin pengembangan baru dan siap untuk pergi?

Pernahkah Anda menguji dokumentasi dan spesifikasi proyek Anda dengan menunjukkannya kepada pengembang di proyek lain? Apakah mereka melihatnya dan menentukan bahwa mereka dapat mulai mengerjakan proyek jika perlu?

Seberapa up to date jadwal proyek?

Menabung untuk hari hujan karena ketika sebuah proyek jatuh di belakangnya lebih seperti badai.

— JeffO
sumber

1

Selain masalah komunikasi (yang saya pikir semua jawaban lain bicarakan), juga sangat mungkin bagi seseorang yang ditambahkan ke proyek untuk membuat bug, karena mereka belum mengetahui kodenya dengan baik.

Setiap kali saya ditambahkan ke proyek, saya selalu berusaha sangat keras untuk tidak merusak barang-barang. Ini berarti saya lebih lambat memperbaiki hal-hal pada awalnya.

— Paul D. Waite
sumber

0

Saya ingin menunjukkan sesuatu yang sama sekali diabaikan sejauh ini oleh jawaban yang lain.

Pada saat orang ditambahkan ke proyek yang terlambat, biasanya banyak yang salah di seluruh organisasi. Manajemen dan klien tidak senang. Orang-orang telah ditekan untuk melanjutkannya. Semuanya cukup tegang.

Sekarang bayangkan Anda berada di tim itu. Jelas ini bukan salahmu. Perencanaan (tidak ada yang menjadi milik Anda) terlalu optimis. Semua keputusan yang salah dibuat tanpa berkonsultasi dengan Anda. Anda mencoba untuk melakukan yang terbaik dan tiba-tiba sekelompok orang baru sedang didorong. Pesan apa yang disampaikannya?

Orang-orang di lantai atas jelas kehilangan kepercayaan pada Anda. Mereka memanggil bocah-bocah besar untuk menebus apa yang Anda buat kacau.

Apakah Anda masih termotivasi untuk membuat ini sukses? Atau ... apakah Anda akan semakin frustrasi dan apakah Anda lebih suka melihat semuanya hancur?

Gunakan waktumu :-).

— Martin Maat
sumber