Saya membutuhkan bayi ini dalam sebulan - kirimi saya sembilan wanita!

Dalam keadaan apa - jika ada - apakah menambahkan programmer ke tim sebenarnya mempercepat pengembangan proyek yang sudah terlambat?

Keadaan yang tepat jelas sangat spesifik untuk proyek Anda (misalnya tim pengembangan, gaya manajemen, kematangan proses, kesulitan materi pelajaran, dll.). Untuk memperluas ini sedikit lebih baik sehingga kita dapat membicarakannya dengan cara lain selain menyederhanakan terlalu banyak, saya akan menyatakan kembali pertanyaan Anda:

Dalam keadaan apa, jika ada, dapat menambahkan anggota tim ke proyek pengembangan perangkat lunak yang berjalan terlambat menghasilkan pengurangan tanggal pengiriman aktual dengan tingkat kualitas yang sama dengan jika tim yang ada dibiarkan bekerja sampai selesai?

Ada beberapa hal yang saya pikir perlu , tetapi tidak cukup, agar hal ini terjadi (tanpa urutan tertentu):

• Individu yang diusulkan untuk ditambahkan ke proyek harus memiliki:
  • Setidaknya pemahaman yang wajar tentang domain masalah proyek
  • Mahir dalam bahasa proyek dan teknologi spesifik yang akan mereka gunakan untuk tugas yang akan diberikan
  • Kecakapan mereka harus / tidak / jauh lebih sedikit atau lebih besar dari anggota yang ada terlemah atau terkuat masing-masing. Anggota yang lemah akan mengeringkan staf Anda yang ada dengan masalah tersier sementara orang baru yang terlalu kuat akan mengganggu tim dengan bagaimana semua yang telah mereka lakukan dan lakukan salah.
  • Memiliki keterampilan komunikasi yang baik
  • Bermotivasi tinggi (mis. Mampu bekerja secara mandiri tanpa dorongan)
• Anggota tim yang ada harus memiliki:
  • Keahlian komunikasi yang sangat baik
  • Keterampilan manajemen waktu yang sangat baik
• Pimpinan / manajemen proyek harus memiliki:
  • Prioritas yang baik dan kemampuan alokasi sumber daya
  • Tingkat penghormatan yang tinggi dari anggota tim yang ada
  • Keahlian komunikasi yang sangat baik
• Proyek harus memiliki:
  • Spesifikasi desain perangkat lunak yang baik, lengkap, dan terdokumentasi
  • Dokumentasi yang baik tentang hal-hal sudah diterapkan
  • Desain modular untuk memungkinkan bagian-bagian tanggung jawab yang jelas diukir
  • Proses otomatis yang memadai untuk jaminan kualitas untuk tingkat cacat yang diperlukan. Ini mungkin mencakup hal-hal seperti: uji unit, uji regresi, penyebaran build otomatis, dll.)
  • Sistem pelacakan bug / fitur yang saat ini di tempat dan digunakan oleh tim (misalnya trac, SourceForge, FogBugz, dll).

Salah satu hal pertama yang harus didiskusikan adalah apakah tanggal kapal dapat dilewati, apakah fitur dapat dipotong, dan jika beberapa kombinasi dari keduanya akan memungkinkan Anda untuk memenuhi rilis dengan staf Anda yang ada. Banyak kali fitur pasangan yang benar-benar memonopoli sumber daya tim yang tidak akan memberikan nilai sama dengan investasi. Jadi berikan prioritas serius pada proyek Anda sebelum hal lain.

Jika hasil paragraf di atas tidak mencukupi, maka kunjungi daftar di atas. Jika Anda mengetahui selesainya jadwal lebih awal, penambahan anggota tim yang tepat pada waktu yang tepat dapat menyimpan rilis. Sayangnya, semakin dekat Anda dengan tanggal pengiriman yang Anda harapkan, semakin banyak hal yang salah dengan menambahkan orang. Pada satu titik, Anda akan melewati "point of no return" di mana tidak ada jumlah perubahan (selain pengiriman cabang pengembangan saat ini) dapat menyimpan rilis Anda.

Saya bisa terus dan terus tetapi saya pikir saya mencapai poin utama. Di luar proyek dan dalam hal karir Anda, kesuksesan masa depan perusahaan, dll. Salah satu hal yang harus Anda lakukan adalah mencari tahu mengapa Anda terlambat, jika ada yang bisa dilakukan mengingatkan Anda sebelumnya, dan langkah-langkah apa yang Anda butuhkan untuk mencegahnya di masa depan. Proyek yang terlambat biasanya terjadi karena Anda adalah:

• Terlambat sebelum Anda mulai (lebih banyak barang daripada waktu) dan / atau
• menyelinap 1 jam, 1 hari pada waktunya.

Semoga itu bisa membantu!

Ini hanya membantu jika Anda memiliki proyek berbasis sumber daya.

Sebagai contoh, pertimbangkan ini:

Anda harus melukis poster besar, misalnya 4 kali 6 meter. Sebuah poster sebesar itu, Anda mungkin dapat menempatkan dua atau tiga orang di depannya, dan membuat mereka cat secara paralel. Namun, menempatkan 20 orang di depannya tidak akan berhasil. Selain itu, Anda akan membutuhkan orang-orang yang terampil, kecuali Anda menginginkan poster yang jelek.

Namun, jika proyek Anda adalah untuk mengisi amplop dengan surat yang sudah dicetak (seperti You MIGHT telah menang! ) Maka semakin banyak orang yang Anda tambahkan, semakin cepat berjalan. Ada beberapa overhead dalam membagikan tumpukan pekerjaan, sehingga Anda tidak bisa mendapatkan manfaat sampai pada titik di mana Anda memiliki satu orang pr. amplop, tetapi Anda bisa mendapatkan manfaat dari lebih dari hanya 2 atau 3 orang.

Jadi, jika proyek Anda dapat dengan mudah dibagi menjadi potongan-potongan kecil, dan jika anggota tim dapat mempercepat dengan cepat (seperti ... secara instan), maka menambahkan lebih banyak orang akan membuatnya berjalan lebih cepat, hingga titik tertentu.

Sedihnya, tidak banyak proyek seperti itu di dunia kita, itulah sebabnya ujung buku catatan tentang buku Mythical Man-Month adalah saran yang sangat bagus.

Mungkin jika ketentuan berikut berlaku:

1. Programmer baru sudah memahami proyek dan tidak memerlukan waktu tambahan.
2. Programmer baru sudah mahir dengan lingkungan pengembangan.
3. Tidak diperlukan waktu administratif untuk menambahkan pengembang ke tim.
4. Hampir tidak ada komunikasi yang diperlukan antara anggota tim.

Saya akan memberi tahu Anda saat pertama kali saya melihat semua ini sekaligus.

Menurut Mythical Man-Month, alasan utama menambahkan orang ke proyek yang terlambat membuatnya nanti adalah overhead komunikasi O (n ^ 2).

Saya telah mengalami satu pengecualian utama untuk ini: jika hanya ada satu orang dalam sebuah proyek, itu hampir selalu hancur. Menambahkan yang kedua mempercepatnya hampir setiap waktu. Itu karena komunikasi tidak berlebihan dalam hal itu - ini adalah kesempatan yang bermanfaat untuk mengklarifikasi pikiran Anda dan membuat lebih sedikit kesalahan bodoh.

Juga, seperti yang Anda ketahui saat memposting pertanyaan Anda, saran dari Mythical Man-Month hanya berlaku untuk proyek yang terlambat . Jika proyek Anda belum terlambat, sangat mungkin bahwa menambahkan orang tidak akan berhasil nanti. Dengan asumsi Anda melakukannya dengan benar, tentu saja.

Jika programmer yang ada benar-benar tidak kompeten, maka menambahkan programmer yang kompeten dapat membantu.

Saya bisa membayangkan situasi di mana Anda memiliki sistem yang sangat modular, dan programmer yang ada (s) bahkan belum mulai pada modul yang sangat terisolasi. Dalam hal itu, menetapkan hanya sebagian dari proyek untuk programmer baru mungkin bisa membantu.

Pada dasarnya referensi Mythical Man Month benar, kecuali dalam kasus yang dibuat-buat seperti yang saya buat. Mr. Brooks melakukan penelitian yang solid untuk menunjukkan bahwa setelah titik tertentu, biaya jaringan dan komunikasi untuk menambahkan programmer baru ke proyek akan lebih besar daripada manfaat apa pun yang Anda peroleh dari produktivitas mereka.

• Jika orang baru fokus pada pengujian
• Jika Anda dapat mengisolasi fitur independen yang tidak membuat dependensi baru
• Jika Anda dapat melakukan orthogonalise beberapa aspek proyek (terutama tugas non-coding seperti desain visual / tata letak, penyetelan / pengindeksan database, atau konfigurasi server / konfigurasi jaringan) sehingga satu orang dapat mengerjakannya sementara yang lain melanjutkan dengan kode aplikasi
• Jika orang-orang saling mengenal, dan teknologi, dan persyaratan bisnis, dan desain, cukup baik untuk dapat melakukan hal-hal dengan pengetahuan tentang kapan mereka akan menginjak kaki masing-masing dan bagaimana menghindari melakukannya (ini, tentu saja, cukup sulit untuk mengaturnya jika belum terjadi)

Hanya ketika Anda memiliki pada tahap akhir itu beberapa tugas independen (hampir 0% interaksi dengan bagian lain dari proyek) tugas yang belum ditangani oleh siapa pun dan Anda dapat membawa pada tim seseorang yang merupakan spesialis dalam domain tersebut. Penambahan anggota tim harus meminimalkan gangguan selama sisa tim.

Daripada menambahkan programmer, orang dapat berpikir tentang menambahkan bantuan administratif. Apa pun yang akan menghilangkan gangguan, meningkatkan fokus, atau meningkatkan motivasi dapat membantu. Ini termasuk sistem dan administrasi, serta hal-hal biasa seperti makan siang.

Jelas setiap proyek berbeda tetapi sebagian besar pekerjaan pengembangan dapat dipastikan memiliki sejumlah kolaborasi antara pengembang. Dalam hal ini pengalaman saya adalah bahwa sumber daya segar sebenarnya dapat secara tidak sengaja memperlambat orang yang mereka andalkan untuk mempercepat mereka dan dalam beberapa kasus ini bisa menjadi orang-orang kunci Anda (kebetulan itu biasanya orang 'kunci' yang akan mengambil waktu untuk mendidik newb). Ketika mereka adalah sampai dengan kecepatan, tidak ada jaminan bahwa pekerjaan mereka akan masuk ke mapan 'aturan' atau 'budaya kerja' dengan seluruh tim. Jadi sekali lagi, itu bisa lebih berbahaya daripada kebaikan. Selain itu, ini adalah situasi di mana itu mungkin bermanfaat:

1) Sumber daya baru memiliki tugas yang ketat yang membutuhkan interaksi minimum dengan pengembang lain dan serangkaian keterampilan yang telah ditunjukkan. (mis. porting kode yang ada ke platform baru, eksternal refactoring modul mati yang saat ini dikunci dalam basis kode yang ada).

2) Proyek ini dikelola sedemikian rupa sehingga waktu anggota tim yang lebih senior lainnya dapat dibagikan untuk membantu meningkatkan kecepatan dan membimbing mereka sepanjang jalan untuk memastikan pekerjaan mereka sesuai dengan apa yang sudah dilakukan.

3) Anggota tim lainnya sangat sabar.

Saya kira menambahkan orang menjelang akhir pekerjaan bisa mempercepat jika:

1. Pekerjaan bisa dilakukan secara paralel.

2. Jumlah yang dihemat oleh sumber daya tambahan lebih dari jumlah waktu yang hilang dengan memiliki orang yang berpengalaman dengan proyek menjelaskan hal-hal kepada mereka yang tidak berpengalaman.

EDIT: Saya lupa menyebutkan, hal seperti ini tidak terlalu sering terjadi. Biasanya ini adalah hal yang cukup mudah, seperti layar admin yang melakukan CRUD sederhana ke sebuah tabel. Saat ini jenis alat ini sebagian besar dapat di-autogenerasi.

Hati-hati dengan manajer yang menyerahkan jenis pekerjaan ini. Kedengarannya hebat, tetapi pada kenyataannya biasanya tidak cukup memangkas waktu yang signifikan dari proyek.

• Modul mandiri yang belum dimulai
• Kekurangan alat pengembangan yang dapat mereka integrasikan (seperti build manager otomatis)

Terutama saya memikirkan hal-hal yang membuat mereka tetap keluar dari jalan orang yang sedang berkembang. Saya setuju dengan Mythical Man-Month, tetapi saya juga berpikir ada pengecualian untuk semuanya.

Saya pikir menambahkan orang ke tim dapat mempercepat proyek lebih dari menambahkan mereka ke proyek itu sendiri.

Saya sering mengalami masalah memiliki terlalu banyak proyek bersamaan. Salah satu dari proyek itu dapat diselesaikan lebih cepat jika saya dapat fokus pada proyek itu sendiri. Dengan menambahkan anggota tim, saya dapat beralih dari proyek lain.

Tentu saja, ini mengasumsikan bahwa Anda telah merekrut pengembang yang mampu dan memiliki motivasi diri, yang mampu mewarisi proyek besar dan belajar secara mandiri. :-)

Jika sumber daya tambahan melengkapi tim Anda yang ada, itu bisa menjadi ideal. Misalnya, jika Anda akan mengatur perangkat keras produksi Anda dan memverifikasi bahwa database benar-benar disetel sebagai lawan hanya mengembalikan hasil yang baik (yang tim Anda kenal sebagai pakar domain) meminjam waktu dari dba yang baik yang bekerja pada proyek selanjutnya untuk Anda dapat mempercepat tim tanpa banyak biaya pelatihan

Sederhananya. Itu datang ke membandingkan waktu yang tersisa dan produktivitas yang akan Anda dapatkan dari seseorang tidak termasuk jumlah waktu yang dibutuhkan sumber daya tambahan untuk mempercepat dan menjadi produktif dan mengurangi waktu yang diinvestasikan dalam mengajar mereka dengan sumber daya yang ada. Faktor utama (dalam urutan signifikansi):

1. Seberapa baik sumber daya dalam mengambilnya. Pengembang terbaik dapat berjalan ke situs baru dan menjadi bug perbaikan yang produktif hampir secara instan dengan sedikit bantuan. Keterampilan ini jarang tetapi bisa dipelajari.
2. Keterpisahan tugas. Mereka harus dapat bekerja pada objek dan fungsi tanpa tersandung pengembang yang ada dan memperlambat mereka.
3. Kompleksitas proyek dan dokumentasi tersedia. Jika itu adalah aplikasi ASP.Net praktik terbaik vanili dan skenario bisnis yang terdokumentasi dengan baik, maka pengembang yang baik bisa langsung terjebak. Faktor ini lebih dari apa pun akan menentukan berapa banyak waktu sumber daya yang ada harus berinvestasi dalam pengajaran dan oleh karena itu dampak negatif awal dari sumber daya baru.
4. Jumlah waktu yang tersisa. Ini sering salah estimasi juga. Logikanya sering kali adalah kita hanya memiliki x minggu tersisa dan dibutuhkan x + 1 minggu untuk membuat seseorang lebih cepat. Pada kenyataannya proyek IS akan tergelincir dan pada kenyataannya memiliki 2x minggu dev tersisa untuk pergi dan mendapatkan lebih banyak sumber daya lebih cepat daripada nanti akan membantu.

Jika tim sudah terbiasa memasangkan pemrograman, kemudian menambahkan pengembang lain yang sudah terampil dalam pemasangan mungkin tidak memperlambat proyek, terutama jika pengembangan dilanjutkan dengan gaya TDD.

Pengembang baru perlahan-lahan akan menjadi lebih produktif karena mereka lebih memahami basis kode, dan kesalahpahaman akan ditangkap sangat awal baik oleh pasangan mereka, atau oleh test suite yang dijalankan sebelum setiap check-in (dan idealnya harus ada pemeriksaan setidaknya setiap sepuluh menit).

Namun, efek dari overhead komunikasi ekstra perlu diperhitungkan. Penting untuk tidak melemahkan pengetahuan proyek yang ada terlalu banyak.

Menambahkan pengembang masuk akal ketika produktivitas yang dikontribusikan oleh pengembang tambahan melebihi produktivitas yang hilang karena pelatihan dan pengelolaan pengembang tersebut.