Bagaimana cara menambahkan pengembang baru ke tim


24

Saya menjalankan perusahaan kecil yang hanya terdiri dari 2 pengembang. Kami sedang membangun aplikasi yang sangat besar untuk salah satu klien kami. Pengembangan proyek ini telah berlangsung selama 1,5 tahun.

Sekarang klien ini telah mendapatkan sponsor penting, dan mereka menyelenggarakan acara yang berkaitan dengan proyek ini. Jadi sekarang kami memiliki tenggat waktu dalam 2 bulan dan kami tidak bisa melewatkannya.

Kami sedang berpikir untuk menambahkan pengembang baru ke tim, dan saya bertanya-tanya apa yang bisa kita lakukan untuk membantu integrasinya.

Inilah situasinya:

  • Kami sedang mendekati ambang hukum Brooks - titik ketika menambahkan pengembang baru akan menjadi kontra-produktif.
  • Aplikasi ini relatif dirancang dengan baik, tetapi implementasinya kacau di beberapa titik (terutama kode lama).
  • Ada unit test hanya untuk kode yang lebih baru. Ketika proyek ini dimulai, kami tidak secara teratur melakukan tes.
  • Dokumentasi dan komentar tidak lengkap.
  • Aplikasi ini besar dan kompleks.
  • Klien telah menulis hampir setiap detail tentang proyeknya, dengan cara yang sangat jelas dan "ramah-programmer".

Apakah ide yang bagus untuk menambahkan seseorang sekarang? Jika demikian, apa yang dapat kita lakukan untuk membantu pengembang baru berintegrasi ke dalam tim?

EDIT:

Sponsor ini mengadakan acara olahraga berbasis internet untuk musim semi mendatang. Itu harus dimulai pada hari tertentu dalam setahun. Kami tidak bisa mengubahnya.

Yang perlu kita lakukan adalah pengembang (saya salah satu dari keduanya) adalah:

  • Menyelesaikan aplikasi yang ada (sekitar 25% dari pekerjaan yang harus dilakukan).

  • Membuat modul baru, penting untuk organisasi acara ini (sekitar 75% dari pekerjaan yang harus dilakukan). Modul baru ini tidak dapat dikembangkan tanpa memahami API program utama.

Saya tidak dapat melakukan estimasi waktu yang tepat, tetapi kami berada dalam situasi yang berisiko.


11
Anda tidak berada di ambang hukum anak sungai, yang telah disahkan lebih dari setahun yang lalu.
Ryathal

3
Anda tidak menulis sepatah kata pun tentang tujuan apa yang Anda miliki untuk tenggat waktu itu. Tambahkan beberapa fitur khusus untuk sponsor itu? Membuat presentasi produk untuk acara tersebut? Buat paket instalasi? Perbaiki beberapa masalah yang paling penting? Masalah apa yang Anda miliki yang tidak dapat Anda selesaikan dengan tim Anda saat ini?
Doc Brown

Berapa lama waktu yang menurut kedua pengembang itu akan mereka butuhkan sendiri? 3 bulan (perhitungan menjadi 2 devs * 3 bulan sama dengan 3 devs * 2 bulan)?
scarfridge

@DocBrown Saya menambahkan rincian lebih lanjut ke pertanyaan. Saya harap ini lebih jelas sekarang.
lortabac

"Dokumentasi dan komentar tidak lengkap" ... "Klien telah menulis hampir setiap detail tentang proyeknya, dengan cara yang sangat jelas dan" ramah-programmer ". Dapatkan orang baru untuk menerjemahkan tulisan-tulisan klien ke dalam dokumentasi desain, lalu "Ada tes unit hanya untuk kode yang lebih baru. Ketika proyek ini dimulai, kami tidak secara teratur melakukan tes" membuatnya untuk menulis & menjalankan tes. Dia tidak akan menghalangi Anda dan akan berkontribusi pada proyek
Mawg

Jawaban:


24

Hal terbaik yang harus dilakukan adalah tidak membuang pengembang baru ke api, tetapi sebaliknya mengukir beberapa fungsi dan / atau perbaikan bug bahwa pengembang seharusnya tidak mengalami kesulitan melompat masuk ke. Temukan area yang membutuhkan pekerjaan yang tidak mengharuskan seseorang untuk mengetahui seluruh arsitektur, persyaratan, dan basis kode sekaligus. Mungkin minta dia mengerjakan dokumentasi untuk mempelajari sistem lebih cepat.


Menambahkan Unittests untuk kode lama dan memperbaiki bug adalah beberapa ide yang bisa dilakukan oleh pengembang baru - tentu saja dengan dukungan dan ulasan kode oleh yang lain. Mungkin ada kebutuhan untuk tes UI otomatis? Itu juga sesuatu yang bisa dilakukan pengembang baru dan belajar banyak tentang aplikasi tersebut.
Hans-Peter Störr

18

Daripada menambahkan pengembang baru ke tim, pertimbangkan untuk menambahkan konsultan berpengalaman untuk periode dua hingga tiga bulan untuk menangani peningkatan sementara dalam beban kerja perusahaan Anda. Idenya adalah untuk mendapatkan seseorang yang dapat menangani waktu start-up mendekati nol, tetapi pada saat yang sama mungkin tidak selalu menjadi tambahan terbaik untuk tim Anda.

Bahkan jika Anda berpikir bahwa peningkatan beban kerja tidak bersifat sementara, sekarang mungkin bukan waktu terbaik untuk menumbuhkan tim Anda secara organik: menambahkan pengembang ketiga adalah hal yang membuat stres tim bahkan tanpa tekanan dari tenggat waktu proyek; Tenggat waktu yang ketat hanya membuat transisi semakin buruk.

Imbalannya adalah bahwa dengan imbalan bantuan sementara Anda akan mendapatkan kode yang ditulis oleh orang luar. Untuk mengurangi risiko ini, pastikan Anda berdua melakukan semua tinjauan kode dengannya. Pastikan Anda meninjau dan memahami semua tes unitnya juga.


5
Itu tergantung seberapa jauh di belakang mereka. Konsultan akan membutuhkan lebih banyak biaya dan membawa pengetahuan saat dia pergi. Juga menemukan siapa pun yang membutuhkan waktu start-up mendekati nol mungkin adalah angan-angan.
Nik

1
@ Nik Saya setuju, biaya yang lebih tinggi jelas merupakan tradeoff; begitu pula pengetahuan yang mengalir keluar dari proyek. Mendapatkan orang yang hampir nol memulai adalah sulit, terutama dalam waktu singkat, tetapi saya telah melihatnya dilakukan pada beberapa proyek yang kritis waktu. Namun, biaya untuk mempekerjakan mereka cukup tinggi.
dasblinkenlight

Saya akan melakukan riset, tetapi konsultan yang berpengalaman mungkin sulit ditemukan di daerah saya. Apakah Anda pikir mungkin untuk bekerja dengan seseorang dari kota lain? Atau apakah jarak akan memperlambat proses lebih jauh?
lortabac

3
Saya kira hukum Brook berlaku untuk konsultan yang berpengalaman juga, jadi saya tidak berpikir ini akan menjadi solusi nyata untuk masalah tersebut.
Doc Brown

@ lortabac Menambahkan seseorang untuk bekerja dengan Anda dari jarak jauh akan sangat mungkin memperlambat segalanya. Seberapa fleksibel para sponsor dalam memangkas persyaratan untuk modul tambahan? Anda mungkin ingin meminta mereka untuk menyortir fitur-fitur baru sesuai urutan kepentingannya, dan memutuskan apa persyaratan minimum mutlak yang harus Anda terapkan agar acara tersebut masuk akal. Jika Anda tidak bisa mendapatkan "pemadam kebakaran" secara lokal, mengurangi ruang lingkup mungkin merupakan rencana darurat yang baik untuk Anda.
dasblinkenlight

14

Apakah ide yang bagus untuk menambahkan seseorang sekarang?

Tidak. Jika memungkinkan, cobalah membuat klien menyetujui pengurangan ruang lingkup sebagai gantinya.

Menambahkan seseorang selarut ini akan menambah risiko yang signifikan, dan tenggat waktu tidak dapat didorong (sejauh yang saya mengerti).


4
+1. Terlepas dari semua saran lain yang ditujukan dengan baik, dipilih lebih tinggi, saya pikir ini mungkin satu-satunya hal yang benar-benar akan bekerja dalam situasi seperti itu.
Doc Brown

Setuju dengan sepenuh hati. Jika Anda memiliki dua bulan tersisa, dan Anda hanya berpikir untuk mempekerjakan seseorang sekarang, Anda tidak akan mendapatkan banyak dari karyawan baru. Kecuali jika Anda benar-benar beruntung atau sudah memiliki seseorang yang kompeten, Anda akan membuang-buang waktu selama dua bulan (dan mengurangi produktivitas Anda sendiri) atau mempekerjakan seseorang yang hanya akan memperburuk keadaan. Jangan terburu-buru mempekerjakan Anda.
jmk

10

Jangan lakukan itu.

Namun.

Pandangan Tradisional

Dalam pertanyaan Anda, Anda merujuk pada hukum Brooks dari Mythical Man-Month .

Menambahkan tenaga kerja ke proyek perangkat lunak yang terlambat membuatnya nanti.

Mengabaikan hukum Brook membawa harga. Jangan melakukan banyak tugas. Fokus pada pengiriman Minimum Viable Product (MVP) Anda. Kemudian fokuskan energi Anda pada merekrut, sumber daya, pelatihan, dan mengelola anggota tim baru.

Dua bulan sangat singkat. Rencanakan rekrutmen dengan daftar burndown dan Anda akan melihat bagaimana memakan waktu.

Larry Page dan Sergei Brin menghabiskan dua tahun memilih tim awal untuk Google. Pilihan Anda untuk karyawan nomor tiga juga harus hati-hati.

Agile, New Millenium View

Persaingan mendorong tim dinamis sekarang lebih daripada di era ketika Mythical Man-Month ditulis (pertengahan 1960-an). Karir panjang di satu perusahaan hilang. Sekarang kami sering bermigrasi antara proyek dan perusahaan. Membangun tim yang cepat menciptakan kesuksesan. Peningkatan yang lambat adalah faktor pembatas yang parah. Contoh-contoh hebat datang dari proyek sumber terbuka, startup, dan peningkatan penggunaan proyek tim dalam kursus ilmu komputer.

Berpotensi, tim Agile menjadi faktor penghambat jadwal mereka. Mereka tidak terlambat karena mereka dioptimalkan untuk sumber daya yang tersedia. Mengintegrasikan staf baru adalah satu lagi kendala, dan dianggap sebagai pertukaran antara tujuan jangka pendek dan jangka panjang. Tim Agile terus mengintegrasikan kode, jadi mengapa tidak orang juga?

Integrasi teknis dan sosial tim yang gesit untuk staf baru dapat menggunakan:

  • scrum harian
  • pemrograman pasangan
  • refactoring
  • menambahkan tes unit yang hilang
  • menggemukkan dokumentasi lean
  • ulasan kode

Domba Pengorbanan

Dalam " Pola Organisasi Pengembangan Perangkat Lunak Agile" James Coplien membahas dinamika kelompok dan biaya penambahan anggota tim baru. Polanya "Domba Pengorbanan" memberikan semua pendampingan dan pelatihan kepada satu orang, menjaga anggota tim lainnya dari gangguan.

Ini adalah strategi yang mungkin ingin Anda pertimbangkan untuk diterapkan.

Strategi lain adalah menugaskan mentor rekrut baru yang meliput pertanyaan dari karyawan baru selama jam tertentu setiap hari. Jika Anda hanya dapat menyisihkan satu orang pria, mungkin dia bekerja tanpa gangguan di pagi atau sore hari dan masing-masing menjawab pertanyaan di sore atau pagi hari. Grup tempat saya bekerja memiliki sepuluh pekerja magang musim panas lalu, jadi banyak orang yang banyak terganggu.

Saat ini pendampingan dilakukan oleh satu orang, terutama selama dan segera setelah scrum pagi kami (8:30 sampai sekitar 9:15 pagi, digabungkan), dan pada sore hari antara jam 12 dan 3:30 (ia bekerja jam 7 pagi - 3:30 sore).


Buku itu agak mahal tapi saya akan memeriksanya.
Hijau

Anda mungkin dapat menemukan kutipan dari buku yang saya sebutkan online, mungkin melalui buku Google. Saya meminjam buku-buku Brooks dan Coplien melalui perpustakaan universitas lokal saya.
PengembangDon

6

Saya senang Anda menyebutkan Hukum Brook. Bagus sekali. Masalah utama dengan menambahkan pengembang lain adalah overhead dalam membuat mereka lebih cepat dan overhead sinkronisasi dengan mereka tentang di mana Anda berada dalam proyek. Karena itu, jika Anda memutuskan untuk mendapatkan pengembang ketiga, saya akan mencoba ini:

  • Berikan pria baru itu sebuah area di mana biaya up-to-speed rendah dan dia bisa pergi secepat mungkin. Ini akan sangat tergantung pada siapa yang Anda pekerjakan dan keterampilan apa yang mereka miliki.
  • Pastikan area ini secara longgar digabungkan dengan area lain aplikasi sehingga overhead sinkronisasi kurang. Mengirimnya untuk melakukan pekerjaan DB intens dan mengatur ulang tabel mungkin terlalu banyak.
  • Lakukan apa yang Anda bisa untuk menjaga moral tetap terjaga. Seperti yang telah dicatat oleh orang lain, menambahkan anggota tim baru bisa membuat stres sehingga mungkin investasi dalam minuman bersoda dapat membantu.

mungkin menentukan area yang perlu dikerjakan dan minta orang baru memulai dengan menulis tes untuk kode yang ada, untuk membantu dalam pemahaman mereka tentang sistem sebelum mereka terjun ke dalam perubahan / menambahnya.
StevenV

@StevenV itu adalah ide yang sangat bagus. Menulis tes untuk komponen yang tidak Anda ketahui akan membuat Anda terbiasa dengan mereka dengan sangat cepat. Dan sistem lebih dapat diuji saat Anda selesai. :)
Green

5

Jika Anda benar-benar mengikuti Hukum Brook, kemungkinan besar Anda tidak akan pernah mengembangkan tim Anda.

Triknya adalah membawa orang baru tanpa terkena terlalu banyak perlambatan di tim Anda saat ini. Akhirnya orang yang baru akan bergerak dengan kecepatan tinggi, dan Anda bisa mengatasi punuknya.

Dalam kasus Anda? Saya akan merekomendasikan agar orang baru menulis semua tes unit yang hilang.

  1. Itu sangat dibutuhkan sebagai perlindungan terhadap kesalahan regresi, yang akan membakar Anda lebih cepat daripada penurunan Brooks apa pun.
  2. Orang baru akan mempelajari nyali sistem Anda. Ini sedikit percobaan oleh api - tetapi output mereka tidak masuk ke kode produksi, sehingga risiko kecil di sana.
  3. Beri batasan keras pada berapa banyak waktu anggota tim yang dapat mereka ambil. Misalnya, minta mereka mengantri pertanyaan, dan hanya beri waktu 30 menit sehari berinteraksi dengan anggota tim lain sampai batas waktu terpenuhi.

Juga, mari kita hadapi itu: Anda harus mengelola ruang lingkup, dan harapan klien terlepas dari apakah Anda membawa orang baru atau tidak. Imbalannya datang siklus berikutnya.

Ed Yourdon memiliki komentar yang bagus tentang Hukum Brook. Dia berkata: tentu saja, menambahkan orang akan membuat Anda menjadi lebih lambat - tetapi ketika sebuah proyek berisiko adalah satu-satunya manajemen waktu akan membawa orang baru. Jadi: bawa mereka, meminimalkan dampak pada rilis saat ini, dan singkirkan yang berkinerja buruk sesegera mungkin. Dengan cara ini, seiring waktu, Anda dapat membangun tim yang kuat.


3

Jika Anda memiliki pekerjaan pada proyek lain yang dapat Anda berikan kepadanya yang akan meluangkan waktu untuk 2 pengembang saat ini untuk berkonsentrasi pada kiriman tenggat waktu besar yang dapat membantu.


3

Anda mengatakan Anda harus menyelesaikan 25% dari karya asli, ditambah pekerjaan baru. Dan Anda perlu melakukan ini dalam dua bulan - ketika Anda membutuhkan 18 bulan untuk melakukan 75% pekerjaan. Untuk menjadi sangat tumpul, ini menunjukkan kepada saya bahwa kemampuan estimasi Anda adalah tentang rata-rata untuk programmer yang berfokus pada kode - yaitu, Anda berpikir hal-hal akan membawa Anda sekitar setengah hingga sepertiga selama mereka benar-benar melakukannya.

Heroics mungkin memungkinkan Anda untuk mengirimkan produk yang telah Anda kontrakkan, tetapi itu tidak akan membantu Anda atau pelanggan Anda. Ini akan menjadi jelek dan penuh bug di bawah kondisi ini, dan Anda akan menggunakan asap.

Ingatlah bahwa waktu yang Anda habiskan untuk merekrut juga akan berdampak besar pada ketersediaan Anda - ini bukan sesuatu yang bisa Anda lakukan di akhir pekan, perlu waktu untuk menemukan karyawan berbakat yang cocok. Berharap untuk menghabiskan setidaknya beberapa minggu mencari, mewawancarai, dll. Berharap bahwa Anda dan karyawan Anda yang ada akan kehilangan sekitar 10 jam seminggu waktu produktif saat Anda mencari.

Rekomendasi saya:

Duduklah bersama pelanggan Anda, jelaskan bahwa Anda berada di atas kepala Anda, dan bekerja dengannya untuk mengurangi ruang lingkup hingga minimum.

Sunting Baru saja melihat tanggalnya di sini. Jadi bagaimana akhirnya? (Terima kasih Ars Technica untuk memposting pertanyaan tiga bulan;)


Beberapa hari setelah memposting pertanyaan ini saya meninggalkan perusahaan. Seperti yang ditunjukkan beberapa komentar tentang Ars Technica, ada masalah yang lebih dalam yang belum saya sebutkan dalam pertanyaan. Saya hanya ingin mendapatkan pendapat tentang masalah khusus ini.
lortabac

2

Ada beberapa cara berbeda yang saya pertimbangkan untuk menyelidiki:

  1. Tunda mempekerjakan pengembang baru sampai setelah batas waktu berlalu sehingga akan lebih mudah untuk fokus meneruskan pengetahuan domain ke orang baru. Ini akan menjadi pilihan saya karena bisa sedikit menantang dalam beberapa cara.

  2. Ajak pengembang baru untuk mengerjakan dokumentasi, tes unit, dan hal-hal lain yang tidak mengubah kode apa pun yang ada. Ini akan menjadi apa yang saya sarankan jika Anda membawa orang baru untuk mencoba meminimalkan dampak pada beban kerja saat ini.


2

Tanggal telah berlalu, tetapi bagi siapa pun yang membaca ini nanti.

Hal utama yang perlu dipertimbangkan adalah bahwa klien dalam situasi ini memiliki lebih banyak kehilangan daripada Anda. Mereka telah menghabiskan banyak uang, dan mereka memiliki acara penting yang mungkin membuat atau menghancurkan bisnis mereka. Anda sudah memiliki uang mereka, dan kehilangan satu klien seharusnya tidak menghancurkan bisnis Anda. Jika ya, maka Anda memiliki masalah bisnis serius lainnya di luar manajemen proyek yang mengerikan.

Taruhan terbaik Anda adalah menegosiasikan subset fungsionalitas yang penting dan kemudian bekerja lembur untuk menyelesaikannya. Jika Anda tidak dapat membuat subset yang lebih kecil terjadi atau tidak mau bekerja lembur dalam situasi itu, Anda mungkin tidak boleh dalam bisnis. Ini mungkin berarti menunda klien lain, namun saya menduga klien lain Anda belum membayar selama 3 tahun, jadi letakkan sumber daya Anda di tempat uang itu berada.

Jika mereka tidak mau menegosiasikan cakupan ke bawah, maka Anda akan gagal.

Tidak ada peluang untuk mengirimkan proyek ini sepenuhnya dalam jangka waktu. Jika Anda berpikir Anda memiliki 25% yang tersisa pada proyek yang telah memakan waktu 18 bulan untuk menghasilkan sejauh ini, maka Anda memiliki setidaknya 6 bulan tersisa (dari ~ 2 pengembang). Menambahkan orang lain tidak akan mengubah ini secara signifikan.

Seperti yang telah ditunjukkan, perekrutan membutuhkan waktu. Pengalaman saya adalah yang membutuhkan waktu minimal sebulan. Kemudian tambahkan pelatihan dan waktu Anda sudah habis.

Saya harap ini berhasil untuk Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.