Kiat / trik untuk mengelola tim baru dengan kode baru [ditutup]

9

Bagaimana Anda menangani diri Anda sendiri dalam tim baru di mana Anda adalah pengembang paling senior dan sebagian besar lainnya di tim itu junior bagi Anda selama beberapa tahun. Tugas di depan tim adalah sesuatu yang belum pernah dilakukan oleh siapa pun termasuk Anda dalam karier mereka sebelumnya.

Manajemen menekankan produktivitas yang lebih tinggi dari seluruh tim, dan sebagai pengembang senior Anda bertanggung jawab.

Adakah tip untuk keluar dari ancaman dalam situasi seperti ini? Jelas, seluruh tim perlu waktu untuk belajar dan jangan lupa tim yang baru. Namun, tenggat waktu ada di depan juga ...

project-management productivity product-management

— Fanatic23
sumber

Harus di pm.stackexchange.com

— JBRWilkinson

5

@ JBRWilkinson saya tidak setuju. Ini tentang menjadi pemimpin teknologi pengembang junior dengan tenggat waktu yang ketat. Saya setuju jika ini tentang bagaimana mengelola proyek pengembang junior, namun menjadi pemimpin teknologi berbeda dari menjadi seorang PM.

— maple_shaft

13

Jangan biarkan tenggat waktu yang ketat atau kebaruan proyek mengganggu praktik rekayasa yang baik. Menyiapkan repositori perangkat lunak, menyetujui gaya pengkodean, membuat test suite, dll. Kebaruan tugas tidak boleh sebesar itu selama Anda memiliki orang-orang berkualitas di bawah Anda yang bersedia untuk bekerja keras dan pelajari tugas di depan mereka.

Atau dengan kata lain: Anda ditugaskan karena manajemen percaya bahwa latar belakang dan pengalaman Anda telah memberi Anda alat yang diperlukan untuk membangun perangkat lunak berkualitas. Jangan tiba-tiba melupakan keahlian Anda hanya karena tugas ini tampaknya menakutkan sekarang.

— chrisaycock
sumber

Pastikan bahwa setiap orang dalam tim memiliki kesempatan untuk memperkirakan semua tugas yang akan ditugaskan kepada mereka, sehingga mereka memiliki tenggat waktu hingga tenggat waktu. Karena tim Anda masih mempelajari seluk-beluknya, jangan berkomitmen siapa pun selama lebih dari lima jam per hari, ketika Anda mengubah perkiraan menjadi waktu yang telah berlalu. Dan jika tenggat waktu tidak dapat dipenuhi, pastikan Manajemen mengetahuinya secepatnya.

— Dawood ibn Kareem

1

@ David - Bagaimana Anda bekerja 5 jam (Ini sebenarnya bukan angka yang buruk untuk digunakan, tetapi bagaimana kita mengetahuinya)? Hanya mengakui bahwa memperkirakan proyek semacam itu adalah omong kosong dan memberitahu manajemen.

— mattnz

3

Saya pikir kebanyakan orang produktif sekitar 6 hingga 6,5 jam per hari. Beberapa mengelola lebih dari ini, tetapi saya pikir ini adalah rata-rata yang baik. Tetapi karena tim ini baru, setidaknya satu jam sehari akan dihabiskan untuk belajar. Dan saya benar-benar percaya pada estimasi - walaupun tidak semua orang mahir dalam melakukan estimasi, itu harus lebih baik dari sekadar melompat dan pemrograman tanpa mengetahui berapa lama suatu tugas akan dilakukan.

— Dawood ibn Kareem

Ini membantu untuk menerima jika Anda meminta anggota tim untuk mengembangkan perkiraan mereka sebelum melihat waktu yang direncanakan dan mereka tidak secara signifikan melebihi rencana. Membuat mereka memperkirakan sebelum melihat perkiraan lain juga akan menghindari bias estimasi.

— BillThor

@ BillThor: Tentunya Anda membuat orang itu melakukan pekerjaan untuk memperkirakannya, dan menggunakan angka-angkanya sebagai titik awal. Saya baru saja memperkirakan pekerjaan dan diberi tahu "Kami pikir itu 1/3 dari itu". Mengapa mereka repot-repot bertanya kepada saya apakah mereka tahu berapa lama?

— mattnz

7

Hal pertama yang pertama, mulai menggunakan sistem kontrol kode sumber dari baris kode pertama. Biasakan memeriksa kode lebih awal dan sering.

Kedua, putuskan strategi pengujian . Tentu saja itu berarti tes unit, tetapi Anda juga harus mempertimbangkan bagaimana mengotomatisasi tes penerimaan.

Ketiga, buat server integrasi berkelanjutan sehingga kode Anda dibuat secara teratur dan diuji secara teratur.

Setelah Anda memilikinya, sebagai tim tentukan beberapa standar pengkodean sederhana . Anda ingin kode Anda mudah dibaca oleh semua orang. Tidak masalah apa standarnya. Lekukan dengan tab, lekukan dengan spasi, kurung kurawal pada baris yang sama, apa pun. Tidak masalah apa mereka, hanya saja setiap orang konsisten menerapkannya.

Karena tim ini sebagian besar adalah pengembang junior, rencanakan untuk meninjau kode sering kali untuk memastikan mereka tidak menambahkan terlalu banyak utang teknis ke sistem Anda.

Akhirnya, pertimbangkan untuk menggunakan SCRUM . Jika Anda melakukannya, pekerjakan seorang pelatih atau pergi ke beberapa pelatihan. Karena Anda semua melakukan sesuatu yang belum pernah Anda lakukan sebelumnya, menetapkan tenggat waktu yang realistis adalah mustahil. Dengan SCRUM, manajemen Anda akan memiliki visibilitas terhadap apa yang Anda lakukan setiap hari sehingga mereka dapat melihat kemajuan apa yang dibuat (atau tidak). Dan, karena tenggat waktu Anda tampaknya diberikan kepada Anda, SCRUM setidaknya menjamin bahwa jika Anda tidak dapat memenuhi tenggat waktu, setidaknya Anda menyampaikan cerita yang telah selesai secara bertahap, yang bisa dibilang lebih baik daripada mengakhiri dengan seorang raksasa sistem yang tidak berfungsi sama sekali.

— Bryan Oakley
sumber

2

+1 untuk kontrol versi dan peninjauan kode lebih awal dan sering.

— jmq

2

Saya berpendapat bahwa kontrol sumber adalah proses yang sangat penting yang harus dilakukan terlepas dari susunan tim, terlepas dari apa pun.

— maple_shaft

6

Selain itu untuk menjawab oleh @ chrisaycock ... Jangan meremehkan waktu yang Anda perlukan untuk mengalokasikan untuk pendampingan / pelatihan dll. Sebagai pemimpin, Anda harus belajar melepaskan detail dan memercayai tim Anda. Tugas Anda adalah menjadi enabler, penghilang blok jalan, dan menjalankan interferensi ketika manajemen menyodok masuk. Dalam tim "normal", sekitar 7 atau 8, pemimpin tidak lagi program, Dalam situasi Anda, ini turun menjadi 3 atau 4 (Mungkin bahkan kurang), Anda bukan sumber daya pemrograman untuk proyek.

— mattnz
sumber

+1 pada alokasi waktu untuk pendampingan dan pelatihan. Pimpinan teknologi yang efektif menjadikan pengembang junior produktif.

— maple_shaft

"Anda bukan sumber pemrograman untuk proyek". Aku ingin tahu apakah manajemennya merasakan hal yang sama, heh. Saya harap Anda tidak berakhir sebagai programmer "pahlawan" untuk proyek ini.

— jmq

Saya mendapat kesan bahwa OP hanyalah pengembang paling senior dan tidak memiliki jabatan atau tugas khusus (yaitu, dia bukan "pemimpin teknologi" atau "arsitek"). Dalam hal ini, ia tentu saja adalah sumber daya pengembangan, dan mungkin diharapkan menjadi yang paling produktif.

— TMN

@TMN: Saya merefleksikan kenyataan dari apa yang terjadi dalam tim dengan satu orang yang ahli / berpengalaman dan yang lainnya secara signifikan kurang terampil. Tidak diragukan lagi orang yang berpengalaman, jika dia kode, akan menjadi yang paling produktif, dan diharapkan kode. TIM akan menjadi paling produktif jika tidak. Dalam sebuah organisasi yang tidak tercerahkan, para manajer mengukur kinerja individu, sehingga orang paling top terlihat buruk melakukan yang terbaik - membuat TIM tampil, dan mendapat sedikit hadiah untuk itu. Dia lebih baik menggantung para junior dan membuatnya tampak hebat.

— mattnz

1

Fokus pada komunikasi di dua bidang.

Tidak mudah melakukan ini, dan itulah salah satu alasan mengapa pekerjaan ini sulit. Jika memenuhi tenggat waktu berarti fitur pemotongan maka lanjutkan itu. Satu hal yang Anda coba hindari dalam semua ini adalah kode cepat untuk membuat tenggat waktu. Itulah awal dari akhir basis kode yang tidak akan bertahan dengan baik dan awal dari utang teknis yang tersedak.

2) Komunikasi antar tim. Tetapkan praktik formal seperti yang direkomendasikan Bryan dan lainnya. Pastikan Anda bertemu secara teratur sebagai tim, misalnya seminggu sekali di samping scrum harian. Dapatkan rasa hormat dan kepercayaan dengan mendengarkan , alat Anda yang paling penting. Pastikan Anda fokus untuk membantu. Hindari kritik negatif di semua biaya. Bila perlu gunakan kritik dan dorongan positif, misalnya "itu hebat, sekali hal yang mungkin ingin Anda pertimbangkan adalah X" lebih dari "itu bukan yang kita butuhkan, Anda perlu melakukan X sebagai gantinya"

— bermutu rendah
sumber

0

Apa yang telah saya lakukan adalah mengidentifikasi yang mampu dan memecah dan menaklukkan. Saya mengambil 2 atau 3 teratas dan membuat mereka menjadi kapten. Yang lain kemudian dibagi secara merata menjadi tim mengikuti kapten ke tim kecil mereka sendiri.

Saya memberikan potongan atau modul kapten untuk melakukan suatu program.

Para kapten memberikan tugas-tugas pemrograman atau penelitian yang lebih kecil kepada para pemula sambil menjelaskan pada diri mereka sendiri apa yang mereka lakukan sehingga pendampingan terjadi saat melakukan.

Saya mencoba mengatur ruangan sehingga setiap orang berada di ruang terbuka yang sama tetapi setiap tim memiliki lingkaran komputer mereka sendiri. Saya suka berada dalam jarak berteriak ke semua orang sehingga semuanya bergerak cepat.

Ini bekerja dengan baik untuk sekitar 10-20 programmer sejauh ini. Kelompok yang lebih kecil lebih baik berada dalam satu kelompok dan saya belum bekerja dengan yang lebih besar.

— Jason Sebring
sumber

Divide & Conquer memiliki perangkapnya. Saya telah melihat ini pada akhirnya karena setiap subteam menciptakan kembali roda (buruk) untuk masalah serupa yang dihadapi seluruh tim.

— NWS

Ya jika Anda berada di gedung terpisah terutama jadi saya mencoba untuk menjaga semua orang di ruang terbuka dan berjalan-jalan secara teratur. Apa yang saya lakukan adalah membangun tanda tangan API inti dan mengatur tim untuk membangunnya sehingga semuanya terhubung.

— Jason Sebring