Bagaimana meyakinkan rekan tim saya untuk mengikuti beberapa aturan dasar

Saya punya masalah dengan rekan tim saya. Singkat cerita: Kami adalah tiga siswa yang bekerja di sebuah proyek untuk sebuah kompetisi. Proyek ini terdiri dari 2 aplikasi terpisah: satu untuk Windows (yang saya kembangkan) dan satu untuk Android (kolega saya bertanggung jawab untuk mengembangkannya). Basis kode kami tidak akan pernah berpotongan, aplikasi akan berkomunikasi melalui alat pihak ketiga.

Masalahnya adalah sebagai berikut: Saya punya pengalaman bekerja dalam tim saat saya magang di sebuah perusahaan besar tahun lalu, dan saya mencoba untuk menegakkan beberapa standar pengkodean untuk kode kami. Saya juga menyiapkan perangkat lunak repositori / wiki / kolaborasi git yang dapat kita gunakan untuk mendorong kode / menulis ide, protokol dokumen, dan sebagainya, tetapi sepertinya saya satu-satunya yang menggunakan alat ini.

Saya mencoba memberi tahu mereka bahwa menulis kode kualitas dan mendokumentasikan setiap langkah akan bermanfaat bagi kita dalam jangka panjang, tetapi mereka tampaknya tidak melihat manfaatnya. Saya juga berpikir untuk menambahkan beberapa tes integrasi tetapi dari apa yang saya lihat, selama mereka tidak menggunakan alat saat ini untuk membuat hidup mereka lebih mudah, saya tidak berpikir saya bisa meyakinkan mereka tentang kegunaan tes integrasi.

Sebagian besar kode rekan berada di komputer mereka, mereka tidak berbagi basis kode umum dan ketika saya tahu, mereka mengintegrasikan potongan-potongan mereka dengan bertemu dan berbagi kode melalui usb stick.

Pertanyaan saya adalah: apakah saya terlalu keras dalam hal ini? Apakah saya menegakkan beberapa aturan yang tidak masuk akal? Perlu diingat bahwa ini adalah proyek kecil, persyaratannya sangat jelas (saya membuat dokumen yang menentukan apa yang harus dilakukan aplikasi), tiga pengembang yang terampil dapat melakukan ini dalam 3-4 hari, sehingga mereka mungkin tidak melihat kompleksitas tambahan dari kualitas penulisan kode selama metode mereka saat ini hanya berfungsi.

Apakah ada cara saya bisa menunjukkan kepada mereka manfaat dari mendokumentasikan kode, menggunakan git dan sebagainya?

Pertanyaan saya adalah: apakah saya terlalu keras dalam hal ini?

Anda bisa menuntun kuda ke air, tetapi Anda tidak bisa membuatnya minum.

Sulit untuk mengatakan apakah Anda "terlalu keras," tetapi mungkin tidak realistis untuk mengharapkan rekan tim Anda untuk mengadopsi semua infrastruktur yang Anda harapkan. Dan sungguh, jika tim bekerja sama dengan baik, menggunakan wiki untuk berkomunikasi antara tiga orang mungkin berlebihan.

Kurangi harapan Anda dan cari cara untuk mencapai beberapa tujuan Anda tanpa mengharuskan mereka untuk mulai menggunakan alat yang tidak mereka ketahui. Jika mereka tidak tahu cara menggunakan git, mereka mungkin tidak akan mendapatkan banyak manfaat darinya. Namun, Anda masih ingin memastikan bahwa semua kode dicadangkan jika terjadi kegagalan hard drive atau bencana lain, jadi minta mereka untuk menyalin secara berkala folder proyek mereka ke Google Drive, Dropbox, atau layanan berbagi file online serupa. Pastikan Anda melakukan hal yang sama.

Sikap saya adalah jika Anda dapat belajar melakukan hal-hal ini pada proyek-proyek kecil, Anda akan siap ketika proyek-proyek besar datang.

Jika mereka mengikuti praktik pengembangan yang baik dengan proyek ini, mereka akan memiliki kode untuk dipamerkan kepada pemberi kerja di masa depan, dan mereka akan memiliki pengalaman yang akan membuat mereka berharga sebagai karyawan.

Jika Anda ingin lebih banyak bahan untuk meyakinkan mereka, saya akan merujuk ke Programmer Pragmatis , atau Kode Lengkap .

Di sisi lain, pertimbangkan untuk mengendurkannya. Jika proyek ini adalah bukti konsep yang semakin bined setelah kompetisi, maka Anda harus mempertimbangkan membiarkan mereka melakukan apa yang mereka mau. Mereka mungkin berjuang hanya untuk menulis kode di tempat pertama, tanpa overhead mental praktik yang baik.

Saya khawatir aturan yang Anda jelaskan tidak mendasar sama sekali.

Tugas termudah IMO adalah meyakinkan rekan tim Anda untuk menggunakan beberapa standar pengkodean. Dan cara sederhana untuk mencapai ini adalah dengan menunjukkan kepada mereka potongan kode yang sama setelah diformat dengan baik dan kemudian ditata dengan buruk, minta mereka membaca kode, memahami apa yang dilakukannya dan membiarkan mereka menilai diri mereka sendiri.

Apa yang terjadi dengan menggunakan repositori git, ini bisa menyulitkan para pemula. Ketika saya bekerja dalam tim yang terdiri dari 3 orang pada proyek Android, kami mengalami banyak masalah dengan sistem kontrol versi kami pada awalnya. Jadi saya berharap rekan satu tim Anda akan mengalami kesulitan juga.

Anda telah menyebutkan bahwa akan memakan waktu 3-4 hari bagi pengembang berpengalaman untuk menyelesaikan proyek (saya berasumsi bahwa itu akan memakan waktu tim Anda 2-3 kali lebih lama). Ini adalah periode yang sangat singkat, sehingga argumen bahwa menggunakan alat baru akan membantu dalam jangka panjang tidak akan berhasil.

Yang dapat Anda lakukan adalah membuat demo singkat dan sederhana untuk menunjukkan bagaimana alat tersebut digunakan. Tutupi fungsi paling dasar pada awalnya, duduklah di samping mereka dan bantu mereka menggunakan alat. Bersiaplah untuk melakukan semua tugas seperti mengkonfigurasi git, membuat struktur halaman wiki, dll.

Sunting : Sebagai balasan atas komentar, saya pikir menetapkan tugas, perkiraan, dan tenggat waktu yang jelas serta melacak waktu yang dihabiskan lebih penting daripada menggunakan git atau alat serupa. Jika Anda berencana untuk mengerjakan aplikasi nanti, sangat penting untuk melacak apa yang sudah dilakukan dan berapa lama setiap fitur. Jadi saya sarankan Anda mulai dari manajemen tugas, dan kemudian lanjutkan ke alat yang ingin Anda gunakan.

Saya sebenarnya suka dengan pemikiran Joel Spolsky sendiri, ketika dia menjelaskan dalam Getting Things Done When You're Only a Grunt . Untuk meringkas:

1. Lakukan saja - Tulis makefile, buat server build harian, dll.
2. Tidak ada yang menggunakan kontrol sumber atau database bug? Mulailah menggunakannya sendiri. Jika seseorang melaporkan bug terhadap pekerjaan Anda, minta mereka dengan sopan untuk menggunakan database bug untuk melaporkan bug kepada Anda sehingga Anda dapat melacaknya; jika tidak, Anda tidak akan bisa membiarkannya lurus di kepala dan memperbaikinya. Pada proyek non-sepele apa pun, akan ada situasi yang hanya dapat dipecahkan dengan kontrol sumber: gunakan kontrol sumber untuk kode Anda sendiri dan dengan gagah berani menyelamatkan hari ketika situasi seperti itu terjadi. Setelah ini terjadi beberapa kali, mereka akan menjadi yakin
3. Buat Pocket of Excellence - Lakukan hal yang benar untuk diri Anda sendiri: menentukan, menjadwalkan dll. Karena ini sepertinya bukan proyek kerja, sepertinya Anda tidak dapat menerima saran ini sepenuhnya, karena Anda tidak dapat mempekerjakan anggota tim baru yang percaya pada pesan Anda
4. Menjadi Tak ternilai - Tunjukkan bahwa Anda adalah kontributor besar untuk memperkuat pengaruh Anda di tim. Kalau tidak, Anda berisiko dikenal sebagai orang yang menghargai proses dan alat dibandingkan hasil

Dokumentasi, Wiki, perangkat lunak versi, metodologi dll. Adalah pengalaman dan pelajaran dari waktu ke waktu; mengerjakan beberapa proyek dan mungkin beberapa tim. Dan itu biasanya melekat pada mereka yang sudah bekerja atau yang menganggap serius industri mereka. Mereka adalah pelajar, sehingga minat mereka mungkin terbatas, tidak seperti apa yang terjadi di masa depan. :)

Tetapi untuk mencoba dan menjawab pertanyaan Anda:

Jika Anda berada dalam tim bersama mereka, Anda perlu menerapkan apa yang menurut Anda penting dengan cara yang menguntungkan minat mereka. Sebagai contoh: Haruskah mereka mengeluh tentang kode mereka banyak rusak ketika usb-share? Maka mungkin memberi mereka cara sederhana (tidak rumit) menggunakan SVN (bukan git) sebagai alat versi.

Saya juga setuju dengan komentar dari arnaud.

Anda melihat manfaat dari semua alat ini ketika Anda bekerja dengan mereka dan itu adalah bagaimana Anda melihat nilai di dalamnya dan mengapa Anda memahami penggunaannya. Jika rekan tim Anda tidak melihat nilai tambah dalam cara mereka melakukan sesuatu saat ini, maka mereka tidak akan menerapkannya. Dan yang menyedihkan adalah ini bahkan diperhitungkan untuk tim yang terbuat dari orang-orang dengan tingkat pengalaman apa pun.

Pendekatan tersebut memiliki masalah:

1. Pendekatan Anda tidak simetris. Anggota tim Anda yang lain perlu berubah, tetapi Anda tidak mempelajari praktik terbaik mereka. Menegakkan aturan dalam situasi seperti ini sulit. Pendekatan yang lebih baik adalah mengumpulkan aturan dan praktik yang baik dari semua anggota tim dan kemudian semua orang hanya membaca dokumen yang dihasilkan.

2. Belajar itu sulit. Aturan orang lain tidak masuk akal karena aturan tersebut tidak memiliki struktur logis yang diharapkan oleh programmer Anda. Menegakkan aturan yang tidak masuk akal bukanlah kegiatan yang bermanfaat.

3. Setiap orang mempelajari hal-hal yang berbeda. Wajar jika programmer yang berasal dari latar belakang yang berbeda telah mempelajari hal-hal yang berbeda. Kekuatan mereka berbeda, dan gaya penulisan kode berbeda. Alat yang mereka gunakan berbeda. Menegakkan satu set aturan / alat / gaya akan menjadi mimpi buruk karena keterbatasannya kehilangan kekuatan yang telah dipelajari para pengembang selama bertahun-tahun.
4. Perubahan butuh waktu. Sementara orang yang menemukan aturan yang Anda terapkan memiliki waktu yang cukup mudah untuk mengikuti aturan, semua orang menderita, dan menghabiskan waktu mempelajari aturan baru. Ini adalah salah satu alasan mengapa semua orang di tim harus dapat mengubah aturan.
5. Memilih alat / konvensi pengkodean atau gaya untuk seluruh tim adalah kegiatan yang sulit . Ini hanya dapat dilakukan secara perlahan seiring waktu, menguji hal-hal apa yang berfungsi dan apa yang tidak berfungsi. Memberi tim 2 minggu untuk mulai mengikuti 50 aturan tidak akan berhasil.

Saya menemukan masalah ini di universitas. Banyak orang tidak mau belajar cara kerja yang berbeda (dan mungkin lebih profesional).

Namun, jika Anda memiliki sistem dan menjelaskan cara menggunakan sistem, maka banyak orang yang mau mencobanya. Saya juga berpikir bahwa repositori sangat di bawah alat yang digunakan dan orang-orang umumnya hanya akan menggunakan sesuatu seperti dropbox