Halo semuanya, ini Dima Vdovin lagi. Dalam artikel saya sebelumnya tentang mengintegrasikan Jun ke dalam sebuah tim, saya secara singkat menyentuh pemrograman berpasangan sebagai praktik belajar mengajar yang efektif. Sekarang saya ingin berbicara lebih detail tentang praktik pemrograman berpasangan dalam tim. Saya mencoba berbagai variasi pada proyek yang berbeda, dan hari ini saya hanya ingin berbagi apa yang saya lihat sebagai keuntungan dari pendekatan ini.
Pasangkan pemrograman
Bagi saya, untuk menjelaskan cara kerja pemrograman berpasangan, kita dapat mengambil contoh balapan reli. Ada seorang pengemudi (driver) dan seorang navigator (navigator). Pengemudi fokus langsung pada mengemudi. Navigator mengontrol kemana tujuan kita sekarang dan memberi tahu pilot tentang belokan dan lompatan yang akan datang.
Hal yang sama terjadi pada pemrograman berpasangan.
Pengemudi berfokus pada penulisan kode, di sini dan sekarang. Pada saat ini, navigator memegang seluruh gambar di depannya, memeriksa apakah pengemudi tidak membuat kesalahan, dan mengatakan ke mana dan bagaimana harus melanjutkan.
Satu-satunya perbedaan utama dari balapan reli adalah bahwa dalam pemrograman berpasangan, pengemudi dan rekan pengemudi harus berpindah tempat secara berkala. Distribusi fungsi bertepatan hampir sepenuhnya.
Keikutsertaan penuh kedua peserta dalam pemrograman berpasangan dalam proseslah yang membedakan metode ini dari metode pembelajaran dan kontrol lainnya. Di satu sisi, kami tidak mengizinkan pengemudi untuk menulis kode sepenuhnya secara mandiri dan tidak memberikan "produk" yang sudah jadi ke ulasan navigator bersyarat. Pada saat yang sama, pengemudi difokuskan tidak hanya pada baris kode tertentu, tetapi harus melihat area yang dibuatnya dalam perspektif yang luas. Hal yang sama berlaku untuk navigator kami.
Selain skema pemrograman pasangan klasik ini, beberapa pendekatan yang lebih efektif telah dibuat selama bertahun-tahun keberadaan industri. Misalnya, pendekatan ping pong atau navigator kursi belakang yang populer. Beberapa orang umumnya mempraktikkan teknik pencampuran yang berbeda. Ini normal. Keefektifan metode ini atau itu tergantung pada tujuan dan komposisi peserta: siapa yang berpartisipasi dalam pasangan, apa yang ingin mereka capai, seberapa berpengalaman kedua pembuat kode. Omong-omong, pemrograman berpasangan cukup dapat diterapkan tidak hanya pada pasangan mentor-junior, yang telah saya bicarakan di artikel sebelumnya, tetapi juga pada pasangan dari dua pembuat kode berpengalaman dengan tingkat yang hampir sama.
Selanjutnya, mari kita bahas opsi pengaturan driver + navigator sedikit lebih luas, tergantung pada tujuan pemrograman pasangan.
Pelatihan pemula
Pemrograman berpasangan sangat bagus untuk mengajar pemula dan paling sering digunakan hanya untuk itu. Namun, saat menggunakan metode pelatihan Jun Anda, Anda harus memahami bahwa Anda mengorbankan kecepatan pengembangan fitur langsung jika pengembangan berlangsung dalam potongan kode yang sebenarnya. Pada saat yang sama, tim benar-benar menang dalam jangka panjang: pemrograman berpasangan dengan kolega berpengalaman secara serius meningkatkan kecepatan orientasi dan mempelajari Jun.
Namun dalam konteks kasus "pelatihan pemula", June tidak selalu muncul. Misalnya, pemrograman berpasangan dapat digunakan untuk mengaktifkan pekerja tengah bersyarat yang baru direkrut yang perlu segera terhubung ke sebuah proyek. Dalam hal ini, kecepatannya tidak turun terlalu banyak, dan mentor bisa menjadi rekan kerja yang sebanding dengan pendatang baru di proyek dalam hal tingkat keahlian. Di sini kita sudah berbicara tentang transfer pengalaman dan pengetahuan bukan dalam pemrograman, tetapi pengetahuan tentang proyek tertentu.
Di sisi lain, pengkodean dalam sepasang dua tengah sedikit lebih berisiko daripada pasangan Juni + Tengah atau Juni + Signor. Pemimpin dalam pasangan dua tengah harus mendekati proses dengan tanggung jawab yang besar, tetapi jika semua kondisi terpenuhi, manfaat bagi seluruh tim cukup nyata.
Berbagi pengetahuan dan likuidasi "Menara"
Masalah umum bagi banyak tim adalah ketersediaan spesialis yang tak tergantikan. Hal ini paling sering berlaku untuk pemula atau kelompok kecil pengembang yang terisolasi yang diam-diam melihat beberapa fitur atau proyek terpisah. Seorang spesialis yang tak tergantikan adalah orang yang memahami secara menyeluruh dan individual baik bagian tertentu dari kode / proyek, atau hanya dia yang memiliki pemahaman lengkap tentang bagaimana semuanya bekerja. Kumpulan pengetahuan tentang proyek spesialis semacam itu juga disebut "Menara Pengetahuan".
Spesialis yang tidak tergantikan atau "Menara" adalah penghambat berbahaya yang harus dihindari dengan cara apa pun. Karena cuti sakit yang dangkal selama integrasi fitur-fitur baru ke dalam bagian pertempuran proyek (atau selama perpindahan, atau pada tahap serius lainnya) - dan pekerjaan tim lumpuh. Belum lagi pemecatan pengembang tersebut.
Untuk menghilangkan hambatan seperti itu, para ahli yang sangat diperlukan harus berbagi pengetahuan mereka dengan pengembang lain.
Seperti yang sudah jelas, pemrograman berpasangan sekali lagi bagus untuk berbagi pengetahuan. Hanya dalam kasus ini, kami tidak menerima pelatihan dan orientasi lanjutan untuk pemula, tetapi transfer pengetahuan tentang aspek proyek dalam tim itu sendiri. Jika Anda membuat fitur berpasangan, maka setidaknya sudah ada dua orang yang mengetahuinya, ditambah lagi, dalam proses penulisan, latar belakang salah satu anggota pasangan akan diperketat.
Likuidasi "Menara Pengetahuan" memiliki keuntungan lain yang tidak jelas bagi banyak orang. Selain mendesentralisasikan pengetahuan tentang fitur dan area tertentu dari proyek, kami juga mengurangi beban pengembang, di sekitar siapa “Menara” ini awalnya dibangun. Memang, lebih sering daripada tidak, jika tim memiliki spesialis yang tak tergantikan, dia sering harus bekerja dalam mode usang, dengan lembur, tujuh hari seminggu selama rilis, dan secara umum, tersedia 24/7. Semua tekanan konstan ini cepat atau lambat mengarah pada kelelahan profesional atau, paling banter, keinginan untuk mencari pekerjaan yang lebih tenang.
Menggunakan pemrograman berpasangan secara proaktif juga merupakan cara yang bagus untuk menghindari pembuatan Menara Pengetahuan secara tiba-tiba. Sirkulasi pengetahuan yang konstan tentang fitur dan berbagai bagian proyek dalam tim merupakan proses normal, yang sayangnya, mulai diatur hanya pada saat pemecatan karyawan kunci. Benar, pemrograman berpasangan bukanlah satu-satunya cara untuk menangani "Menara" dan meningkatkan tingkat pemahaman proyek dalam tim, tetapi ini adalah cerita yang sama sekali berbeda.
Memecahkan masalah yang kompleks
Pemrograman berpasangan dapat digunakan seperti alat curah pendapat lokal, yaitu, secara harfiah menerapkan pepatah "satu kepala baik, dua lebih baik." Pemrograman berpasangan sangat bagus untuk kasus-kasus ketika Anda perlu menerapkan fitur atau logika yang kompleks sesuai dengan persyaratan bisnis proyek. Di sini kami tidak lagi berbicara tentang transfer pengetahuan dari pemimpin ke pengikut, tetapi kami membuat sistem dua pengembang, yang setara dalam pengalaman dan pemahaman tentang proyek, yang menggabungkan upaya mereka.
Beberapa pengembang mungkin berpendapat bahwa mereka lebih nyaman bekerja di area yang kompleks saja, tetapi praktik menunjukkan bahwa dua pembuat kode yang kuat berpasangan lebih mungkin menghasilkan kode berkualitas tinggi daripada bekerja secara terpisah.
Kekuatan pemrograman berpasangan dalam situasi ini berada di luar proses pengkodean. Sebaliknya, keuntungan dicapai melalui kemampuan untuk secara aktif berdiskusi dengan pijakan yang sama kemungkinan solusi untuk masalah - proses penulisan kode dalam kasus seperti itu adalah sekunder dan bukan masalah. Tapi bagaimana dan apa sebenarnya yang harus ditulis adalah masalahnya. Kemungkinan komunikasi langsung, diskusi, dan perselisihan yang dibuktikan antara dua spesialis memiliki efek positif pada kualitas keputusan yang dibuat. Waktu yang dibutuhkan untuk menemukan solusi yang berhasil untuk masalah kita juga berkurang.
Tugas campuran
Kasus terakhir adalah tim dari semua kasus yang dijelaskan di atas. Di sini kami memiliki dua pengembang berpengalaman dengan bidang keahlian berbeda yang bekerja sama untuk mengerjakan satu tugas. Mungkin salah satu dari mereka menulis kode dengan baik, dan yang lainnya benar-benar paham dengan persyaratan proyek. Selain itu, tidak perlu ada dua programmer. Ini bisa berupa pasangan pembuat kode dan insinyur QA atau pembuat kode dan analis.
Di sini kita mendapatkan situasi win-win murni: dalam kasus masalah campuran, setiap anggota pasangan saling melengkapi. Dengan cara ini kami memeras potensi maksimal dari kedua spesialis, menghilangkan kelemahan mereka dan hanya menggunakan kekuatan mereka.
Pada saat yang sama, solusi dari masalah campuran mencakup semua kasus yang dijelaskan sebelumnya: onboarding, jika kita berbicara tentang pengetahuan yang tidak memadai tentang persyaratan proyek, dan likuidasi "Menara", dan menyelesaikan kasus yang kompleks.
Total
Penting untuk dipahami bahwa pemrograman berpasangan bukanlah peluru perak dan jawaban untuk masalah dan tantangan pengembangan apa pun. Di hampir semua kasus, metode ini menyebabkan penurunan kecepatan pengembangan, jadi sebaiknya gunakan pendekatan ini dengan hati-hati.
Juga, kita tidak boleh melupakan faktor manusia: jika kita berbicara tentang mengajar Jun, maka pendamping berpasangan harus dapat berinteraksi dengan pemula pada tingkat yang tepat agar proses pembelajaran tidak berubah menjadi pemukulan dan ejekan. Jika kita mencoba menghilangkan "Tower", maka komposisi pasangan harus disesuaikan agar transfer pengetahuan berlangsung ke arah yang benar. Hal yang sama berlaku untuk masalah yang kompleks dan beragam: Anda tidak dapat menempatkan dua pengembang acak di satu komputer dan menunggu, mereka akan memberi Anda solusi siap pakai dalam N jam.
Tetapi bahkan dengan kesulitan yang disuarakan, pemrograman berpasangan adalah praktik hebat yang tidak hanya memecahkan masalah orientasi dan mengajar pendatang baru, tetapi juga memungkinkan Anda menjembatani kesenjangan pengetahuan anggota tim lain tentang proyek atau secara efektif memecahkan masalah yang kompleks.