Pairing Programming / Kolaborasi di sebuah perusahaan kecil

Saya bekerja di perusahaan pengembangan kecil sebagai pengembang utama. Kami memiliki dua pengembang lain, serta bos saya yang merupakan pengembang, tetapi tidak terlalu banyak melakukan pengkodean yang sebenarnya.

Masalah yang saya coba atasi adalah multifaset. Kami memiliki kecenderungan semua untuk mengerjakan proyek kami sendiri tanpa banyak kolaborasi di antara kami. Faktanya, saya (sebagai pengembang paling maju) meminta pendapat / bantuan orang lain lebih dari yang saya miliki, karena saya menghargai input dari mata luar.

Saya ingin meningkatkan kolaborasi kami, dan telah menyatakannya kepada mereka. Sebagian besar karena saya ingin menunjukkan kepada mereka beberapa hal tentang bagaimana menjadi pengembang yang lebih baik dan mengikuti praktik yang lebih baik. Tetapi mengingat tipe kepribadian pengembang kami yang lain, saya pikir mereka lebih nyaman bekerja sendiri.

Saya telah membaca tentang pemrograman pasangan, dan saya telah membaca (di beberapa forum) bahwa itu tidak berfungsi dengan baik ketika Anda memiliki satu pengembang lebih maju daripada yang lain (yaitu saya). Namun, saya merasa sangat penting bagi kami untuk mulai berkolaborasi agar pekerjaan kami tidak terlalu berbeda.

Pertanyaan saya adalah apakah ada orang yang pernah berada dalam situasi yang sama, dan apa yang berhasil bagi mereka?

Saya menyadari ini bukan situasi satu-ukuran-untuk-semua, tapi saya bersedia untuk mencoba beberapa pendekatan.

Kita semua bekerja di area yang sama, pengembang tidak memiliki kantor / ruang kerja tersendiri.

Karena sudah dibahas dalam jawaban lain mengapa pemrograman berpasangan bukan solusi untuk Anda , saya akan membahas apa yang saat ini kami uji coba, dan puas dengan hasilnya.

Dalam pandangan saya apa yang dapat Anda lakukan untuk meningkatkan kolaborasi adalah memiliki dua orang bersama di setiap proyek. Masing-masing bekerja pada bagian proyek yang berbeda, tetapi karena bagian-bagian ini harus diintegrasikan, kedua pengembang harus berkolaborasi. Ini juga mengharuskan kedua programmer mendiskusikan arsitektur (layering dan interface) dari proyek, dan kemudian memutuskan untuk mengambil peran yang berbeda.

Dan, jika pendekatan ini, membatasi jumlah proyek yang dapat ditangani perusahaan Anda pada satu waktu, Anda dapat menetapkan pasangan ini dua proyek kolaborasi secara bersamaan.

Kami baru-baru ini bereksperimen dengan pendekatan ini, meminta salah satu dari mereka mengembangkan model + integrasi dengan apis dan programmer lain yang menangani pandangan dan pengontrol . Kami telah menemukan keuntungan berikut dari pengaturan ini:

1. Struktur kode menghasilkan cara yang jauh lebih baik daripada jika hanya satu yang mengerjakan semua aspek proyek.
2. Kami tidak perlu mengingatkan mereka tentang melakukan kode ke repositori dll.
3. Mereka harus berusaha menguji kode masing-masing, alih-alih hanya mengandalkan QA khusus kami untuk itu.

Menurut pendapat saya, pemrograman pasangan bukan solusi untuk masalah yang Anda ajukan.

Ada dua peran berbeda dalam pemrograman pasangan. The pengamat ada ulasan dan umpan balik pada kode yang ditulis oleh pengemudi . Jika Anda mencoba menyampaikan ide untuk meningkatkan keputusan yang dibuat oleh programer junior Anda, saya mempertanyakan seberapa efektif Anda dapat menemukan kemampuan mereka untuk secara kritis meninjau kode yang Anda tulis ketika Anda menjalankan peran pengemudi.

Tanpa dinamika ini, manfaat pemrograman pasangan akan hilang.

Sebagai programmer senior, saya sarankan Anda mempertimbangkan program pelatihan dan pengembangan karyawan yang lebih kuat dengan atasan Anda. Programer junior Anda harus diberi kerangka kerja untuk meningkatkan keterampilan mereka. Biasanya Anda dapat menggunakan metode seperti pencerahan, menulis dokumen standar pengkodean, memisahkan tugas mandiri dari pekerjaan Anda sendiri dan memastikan proses peninjauan kode yang tepat tersedia.

TL; DR : Saya tidak berpikir pemrograman pasangan akan bekerja untuk Anda. Alih-alih, Anda harus mencoba membuat orang khawatir tentang kualitas jangka panjang kode mereka dan membuat mereka ingin menemukan jawaban. Ini harus dilakukan secara informal.

Tentang budaya dan kualitas

Saya merasa masalah ini bukan tentang metodologi pemrograman tetapi tentang budaya . Dalam pengalaman saya, budaya mungkin untuk diarahkan, tetapi jarang dengan memberi tahu orang-orang tentang hal itu. Yaitu, mencoba memaksakan alur kerja tertentu pada orang-orang yang tidak berevolusi secara alami atau terlalu jauh dari praktik yang ada pasti akan memiliki konsekuensi negatif.

Dengan kata lain, Anda tidak ingin terlihat seperti setelan yang datang berdengung buzzwords terbaru, bahkan ketika akhirnya Anda. Kebanyakan programmer yang saya kenal akan secara mental menandai Anda sebagai kebisingan latar belakang. Jangan menjadi lebah perusahaan.

Menurut pendapat saya, pertanyaan utama yang harus Anda tanyakan pada diri sendiri adalah "apakah saya senang dengan kualitas dan nilai bisnis dari kode yang dikeluarkan organisasi saya?" dan jika jawabannya negatif, Anda harus bertanya "bagaimana cara membalikkan ini?".

Pada akhirnya, kualitas dan nilai adalah definisi manusia yang hanya dapat dipikirkan oleh Anda atau orang lain di organisasi Anda.

Memasangkan pemrograman dan manajemen mikro

Jadi, dengan risiko terdengar agak maju dan keras, bagi saya tampaknya membaca tentang pemrograman berpasangan sebenarnya membuat Anda berpikir tentang beberapa bentuk manajemen mikro , atau sebaliknya. MM adalah resep pasti untuk mengasingkan kebanyakan orang.

Mempertahankan pemrograman pasangan: pemrograman pasangan bukan tentang beberapa pria melihat dari bahu pria lain. Itu sama mikronya dengan manajemen. PP adalah tentang menggunakan dua pikiran untuk memikirkan dua level pada saat yang bersamaan - satu orang berurusan dengan masalah gambar besar tingkat tinggi , sementara yang lain menangani mur dan baut yang diperlukan untuk menghasilkan kode kerja. Dan menurut pendapat saya yang sederhana, jarang berhasil dengan baik jika kedua peserta tidak dalam posisi untuk berganti tempat. Mereka harus cukup berpengalaman untuk memiliki arsenal konsep yang serupa dan kosakata profesional yang dibagikan (kita tidak terhubung dengan pikiran - belum , muhahaha).

Untuk situasi Anda, saya katakan karena Anda adalah tim kecil dan Anda adalah satu-satunya yang memiliki pengalaman nyata (seperti itulah pos Anda bagi saya), memprogram pasangan atau meninjau sebagian besar kode sebagian besar waktu. bekerja. Anda hanya punya 24 jam sehari. Sebagai gantinya, beberapa solusi yang dapat Anda pertimbangkan:

• Dorong mereka untuk berpartisipasi dalam SO di bawah tag bahasa yang sesuai, atau memposting beberapa cuplikan kode untuk ditinjau pada Tinjauan Kode SE. Mulailah kontes informal kecil tentang siapa yang bisa mendapatkan poin reputasi SO paling banyak per minggu.

  SO dapat melakukan keajaiban bagi pengembang pemula karena memberikan umpan balik yang konstan dan mengikuti detak jantung komunitas.

• Lihatlah beberapa kode yang mereka periksa dan tantang mereka secara informal dengan beberapa pertanyaan mengenai evolusi jangka panjangnya. Kebanyakan programmer pemula tidak terbiasa untuk berpikir tentang membuat kode mereka dapat dibaca dan dipelihara. Setelah Anda menyelesaikan masalah itu, mereka akan mencari lebih banyak informasi sendiri, dari Anda atau sumber lain.

Saya tidak berpikir bahwa pasangan pemrograman adalah sesuatu yang akan membantu Anda di lingkungan Anda. Ini bukan berarti bahwa hal itu tidak akan membantu membawa para pengembang kurang berpengalaman dalam keterampilan - bahkan ada pertanyaan Programmer tentang pasangan pemrograman dengan insinyur dari berbagai tingkat keterampilan . Meskipun ada manfaat seperti berbagi pengetahuan dan lebih sedikit kesalahan, pasangan pemrograman memerlukan investasi waktu yang lebih besar. Dengan tim tiga pengembang dan hanya empat orang yang memiliki latar belakang pengembangan / pengalaman, mempertahankan rutinitas pasangan pemrograman tampaknya seperti itu akan menjadi kesulitan.

Saya berpikir bahwa alternatif yang lebih baik dalam situasi Anda adalah ulasan kode, terutama jika Anda penjahit mereka secara tepat. Peninjauan kode dapat terdiri dari apa pun dari satu orang yang melihat sedikit kode dan memberikan umpan balik kepada banyak orang (bahkan seluruh tim) dalam satu ruangan selama satu atau dua jam untuk memeriksa desain dan implementasi seluruh komponen. Ini dapat bervariasi sesuai untuk pekerjaan yang sedang dilakukan, terutama berdasarkan pada pengetahuan, pengalaman, dan kebutuhan tim. Anda masih bisa mendapatkan aspek berbagi pengetahuan dengan mengajak banyak orang ikut serta dalam kajian untuk tujuan menemukan masalah, memberikan saran, dan mendapatkan pengetahuan dengan membaca output ulasan untuk memasukkan komentar ke dalam pekerjaan mereka sendiri, sebelum mereka memeriksanya. .

Pertanyaan saya adalah apakah ada orang yang pernah berada dalam situasi yang sama, dan apa yang berhasil bagi mereka.

Karena Anda mengundang pengalaman inilah yang saya lakukan. Saya memilih pendekatan risiko rendah dan meminta seseorang yang puluhan tahun lebih muda dari saya untuk meluangkan waktu bekerja bersama. Kami tidak memberi label aktivitas. Tidak ada seorang pun, kecuali saya, yang tahu kami sedang mencoba teknik baru.

Saya tidak tahu persis detail apa yang harus saya hubungkan, tetapi prosesnya bekerja dengan sangat baik. Dia ingin dibimbing, yang merupakan sesuatu yang tidak saya ketahui sebelumnya. Jadi itu membuka komunikasi di kedua arah dengan cara yang sangat positif.

Faktanya, saya (sebagai pengembang paling maju) meminta pendapat / bantuan orang lain lebih dari yang saya miliki, karena saya menghargai input dari mata luar.

Sepertinya Anda bisa membingkai ini sebagai perkembangan logis dari apa yang sedang Anda lakukan.

Beberapa bulan setelah mengajukan pertanyaan ini, saya harus mengatakan saya senang dengan hasil kami. Tapi itu tidak persis yang saya diterima di awal. Perlu diingat ini adalah tim kecil, sehingga solusi ini tidak akan cocok semua orang satu.

Saya menemukan yang terbaik adalah membiarkan semua orang melakukan pekerjaan mereka sendiri. Dan seiring waktu kami telah mengembangkan kepercayaan satu sama lain di mana jika kami mengalami masalah, kami memanggil yang lain untuk membantu kami. Saya tidak berpikir ada orang yang mau bekerja dengan seseorang yang mengawasi dari bahu mereka. Saya kadang-kadang duduk di belakang seseorang dan kadang - kadang membantu mereka mengatasi masalah tanpa diminta. Terkadang saya tidak perlu menambahkan, dan saya mungkin sedikit mengganggu mereka. Tetapi mereka mengerti bahwa saya tidak ada di sana untuk bermain-main dengan mereka. Saya sebagian besar ada untuk mengambil istirahat dari apa yang saya lakukan dan memperkenalkan sedikit kolaborasi.

Apa yang saya temukan adalah bahwa orang-orang KANAN dari waktu ke waktu (dalam tim kecil) mengambil dan menyinkronkan dengan yang dilakukan orang lain. Tidak perlu mengelola mikro atau memberi tahu seseorang apa yang mereka lakukan salah sepanjang waktu.

Dari waktu ke waktu, duduklah bersama seseorang dan selesaikan masalah, di mana Anda adalah seorang ahli atau seseorang yang sedang belajar, atau keduanya. Jelaskan mengapa Anda mau atau tidak mau melakukan sesuatu dengan cara yang bertentangan dengan yang lain. Gagasan bagus biasanya muncul, sementara yang lain ketinggalan. Dan pada akhirnya Anda memiliki sekelompok orang yang produktif dan kohesif yang mungkin mengerjakan hal-hal yang berbeda tetapi berbagi tujuan yang sama.