Pairing Programming / Kolaborasi di sebuah perusahaan kecil

20

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.

— Ryan Williams
sumber

2

Apakah Anda dan pengembang lain memiliki kantor, bilik, atau duduk di area bersama?

@hatchet Kita semua bekerja di area yang sama.

— Ryan Williams

12

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:

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

— Ozair Kafray
sumber

1

Saya akan memikirkan ini juga. Saya sangat suka pemisahan pengembangan pandangan dan pengontrol dari model, karena memaksa pengembang untuk datang dengan API yang baik untuk model. Agar dapat bekerja secara bersamaan, itu juga memaksa penulisan tes yang relevan.

— Ryan Williams

1

Saya telah memutuskan untuk menerima jawaban ini karena setelah membahasnya dan membicarakannya dengan beberapa anggota tim, saya yakin cara terbaik untuk mendorong kolaborasi adalah dengan membagi peran pada proyek yang sama. Ini mungkin tidak berhasil, tetapi sepertinya ini yang paling cocok yang pernah saya dengar.

— Ryan Williams

7

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.

Saya akan mempertimbangkan pemikiran Anda. Agak sedikit untuk menguraikan dan memperbaiki mental terhadap apa yang kita lakukan saat ini. Perasaan jujur yang saya miliki adalah sedikit rasa tidak aman di posisi saya sebagai pemimpin pengembang. Bukan karena saya tidak nyaman dari sudut pandang keterampilan, tetapi lebih karena kedua pengembang kami yang lain lebih tua dari saya (satu secara signifikan, satu tidak), dan satu bahkan memiliki beberapa tahun pengalaman lebih. Karena itu, ulasan kode tradisional akan terasa canggung, karena saya tidak ingin terlihat seperti sedang bernafas. Kemudian lagi, mungkin itu yang harus saya lakukan.

— Ryan Williams

Satu hal lagi. Apakah Anda pikir ada manfaat yang lebih sedikit daripada layak untuk memasangkan program dengan mereka, di mana ketika saya pengemudi? Itu masih bisa digunakan sebagai cara untuk menunjukkan praktik terbaik, dan masih memiliki beberapa masukan dan umpan balik tentang apa yang saya lakukan (bahkan jika hubungan itu pasti tidak seimbang).

— Ryan Williams

Jika hubungan pemrograman pasangan adalah satu cara, saya sarankan itu tidak akan menarik dan bahkan mungkin sedikit menggurui rekan kerja Anda. Bergantung pada bagaimana Anda memodelkannya, ini bisa dengan mudah muncul sebagai, "ini adalah bagaimana saya memprogram dan ini adalah pendekatan terbaik". Anda tidak akan benar-benar menyebut pemrograman pasangan ini karena tidak memiliki kedua komponen.

Saya kira itulah yang saya takutkan. Terima kasih atas pemikirannya. Saya akan menerima jawaban Anda sebagai yang pertama. (Ada beberapa yang bagus juga.)

— Ryan Williams

Ulasan @RyanWilliams Code bukan tentang "mematahkan leher mereka". Ini bukan tentang Anda mengendalikan mereka. Di tempat kami, kami menggunakan ReviewBoard sebagai platform dan mengomentari setiap kode lainnya . Tidak ada "hierarki". Pembelajaran dalam hal ini adalah "implisit". Mereka belajar dari membaca kode Anda dan mereka, dari pertanyaan Anda dan para dev lainnya dan jawaban / komentar untuk pertanyaan-pertanyaan itu. Dan mereka mengenal bagian lain dari basis kode, yang merupakan IMHO cukup menguntungkan.

— Johannes S.

5

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.

— idoby
sumber

Seperti, semua orang, saya menghargai masukan Anda. Satu hal yang saya sadari dalam memposting ini adalah saya merasa tidak nyaman dengan menjadi orang yang melihat ke belakang. Mereka berdua sebenarnya lebih tua dari saya dan satu memiliki pengalaman yang lebih signifikan. Jadi saya tidak membayangkan mereka sebagai orang yang akan berkeliling CE dan meminta ulasan kode. Mereka bukan pemula. Tetapi mereka berasal dari bahasa yang berbeda, dan praktik yang tidak lazim.

— Ryan Williams

Saya melihat. Saya pikir itu baik Anda tidak merasa nyaman melihat ke atas bahu mereka karena saya tidak berpikir Anda harus. Tidak ada yang mau ada orang yang menebak setiap keystroke yang mereka buat (melebih-lebihkan).

— idoby

4

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. .

— Thomas Owens
sumber

Tampaknya menjadi pendapat populer. Saya suka ide ulasan kode. Tetapi dalam pikiran saya, saya akan menebak bahwa dengan kepribadian dan tingkat keterampilan mereka, itu akan saya yang melakukan peninjauan, dan mereka hanya mendengarkan (kebanyakan tidak terlibat). Tapi mungkin ada cara untuk mendapatkan mereka lebih terlibat. Saya kira saya harus merenungkan hal itu.

— Ryan Williams

Juga, untuk menjadi jelas, saya tidak berbicara tentang pemrograman pasangan sebagai sesuatu yang kita lakukan sepanjang waktu. Alih-alih, curahkan sebagian besar, tetapi bukan bagian besar dari minggu kerja untuk fitur yang lebih besar atau lebih kompleks. (Itu sebagian karena keperluan praktis. Saya punya tuntutan sendiri yang harus dipenuhi.)

— Ryan Williams

2

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.

— dcaswell
sumber

Saya khawatir adalah bahwa aku tidak begitu yakin mereka ingin "dibimbing". Mereka berdua lebih tua dari saya dan satu (secara signifikan lebih tua) sebenarnya memiliki pengalaman beberapa tahun lebih banyak daripada saya. Tapi saya suka bagian kedua dari saran Anda.

— Ryan Williams

Dan itu wajar untuk khawatir sebelum Anda melakukan sesuatu - karena Anda tidak memiliki informasi. Pengalaman saya adalah bahwa jika Anda melakukannya, orang akan merasakan bahwa Anda tidak khawatir, dan bahwa Anda santai dan mereka akan mengikuti. Dan kemudian jika bekerja - terus, dan jika tidak - mencoba sesuatu yang lain.

— dcaswell

Mungkin melibatkan mereka dalam proyek yang lebih besar yang biasanya saya lakukan sendiri bisa sedikit meringankan. Sebagai contoh, kita mengulangi CMS kami segera. Butuh sedikit dari saya untuk terbiasa dengan ide itu.

— Ryan Williams

0

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.

— Ryan Williams
sumber