Pemrograman pasangan adalah praktik umum dalam tim Agile. Meskipun sudah ada sejak lama (Coplien, 2015), namun dipopulerkan oleh Kent Beck sebagai bagian dari Extreme Programming (XP) (Beck & Andres, 2004). Namun praktiknya tetap kontroversial. Gagasan membiarkan dua pengembang berpasangan pada satu tugas tampaknya sia-sia dibandingkan dengan pemrograman tunggal di mana setiap pengembang mengerjakan tugas mereka sendiri. Namun, pendukung pair programming berpendapat bahwa itu meningkatkan kualitas, kecepatan, dan pembelajaran, dan dengan demikian produktivitas secara keseluruhan.

Kami selalu menjadi penggemar pemrograman berpasangan. Kami telah belajar banyak dengan bekerja sama dalam membuat kode dengan pengembang lain dan dapat mengajari orang lain melalui itu. Ada sesuatu yang sangat memuaskan tentang mengoper keyboard bolak-balik dan berbagi ruang pikiran untuk suatu masalah dengan orang lain. Jadi, meskipun keyakinan kami pasti bahwa pemrograman berpasangan adalah praktik penting dalam pengembangan perangkat lunak Agile, kami juga ingin menantang keyakinan kami dengan bukti empiris .

Jadi dalam postingan ini, kami mengeksplorasi wawasan dari lebih dari 25 studi akademis yang kami baca saat mempersiapkan postingan ini. Kami meringkasnya dalam empat wawasan inti dan juga menawarkan lima rekomendasi praktis. Wawasan dapat mendukung keyakinan Anda atau menantangnya.

Posting ini adalah bagian dari seri "mendalam" kami . Setiap posting membahas penelitian ilmiah yang relevan dengan pekerjaan kami dengan tim Scrum dan Agile. Kami berharap dapat berkontribusi pada lebih banyak percakapan berbasis bukti di komunitas kami dan ketergantungan yang lebih kuat pada penelitian yang kuat atas pendapat pribadi. Seperti yang Anda bayangkan, butuh banyak waktu untuk menyusun posting berbasis bukti tersebut. Jika menurut Anda konten kami berharga, dan menurut Anda kami harus menulis lebih banyak lagi, Anda dapat mendukung kami di Patreon .

Apa itu pemrograman berpasangan?

Dalam bentuk formalnya, pair programming mengacu pada praktik di mana dua pengembang bekerja sama di satu workstation pada satu masalah (Beck, 2004). Dalam pasangan ini, satu pengembang bertindak sebagai pengemudi dan menulis kode sementara yang lain sebagai navigator dan meninjau setiap baris kode. Pasangan-pasangan ini harus dinamis karena pasangan sering berganti dengan pasangan lain untuk menyebarkan pembelajaran ke seluruh tim.

Beck (1999) awalnya beralasan bahwa pair programming memiliki tiga keuntungan dibandingkan solo programming: 1) kualitas kode lebih tinggi karena dua pikiran meninjaunya secara bersamaan, 2) pengembang belajar bersama dan dari satu sama lain, dan 3) durasi keseluruhan untuk menyelesaikan tugas lebih singkat karena pengembang dapat bekerja lebih efektif. Tentu saja, manfaat ini membebani biaya (dangkal) karena dua pengembang menghabiskan waktu berjam-jam untuk tugas yang seharusnya dilakukan oleh satu pengembang.

Beck & Andres (2000) berpendapat bahwa pair programming memiliki banyak manfaat sehingga harus dipraktikkan untuk semua kode yang ditulis. Penulis lain mengambil pendekatan yang lebih pragmatis dan merekomendasikannya untuk tugas-tugas kritis pada khususnya. Banyak tim juga mempraktikkan bentuk pemrograman pasangan ad-hoc di mana perbedaan antara pengemudi dan navigator tidak ditegakkan secara ketat. Ada juga versi yang lebih besar dari pair programming, yang disebut mob programming atau ensemble programming , di mana satu pengemudi memiliki lebih banyak navigator (biasanya seluruh tim).

Catatan tentang biaya versus manfaat

Kontroversi utama dari pair programming adalah apakah manfaatnya melebihi biayanya. Apakah layak, dalam jangka panjang, memiliki dua pengembang menghabiskan waktu untuk tugas yang seharusnya dilakukan oleh satu pengembang? Kami secara pribadi telah berurusan dengan beberapa pengembang yang merasa bahwa pemrograman berpasangan itu sia-sia. Demikian pula, manajemen tidak selalu setuju karena - dalam pikiran mereka - itu diterjemahkan menjadi "dua kali waktu untuk separuh pekerjaan".

Kami telah memperhatikan bahwa skeptisisme seperti itu sering diabaikan oleh para pendukung pemrograman berpasangan. Kami pasti sudah berkali-kali. Sementara para pendukung sering mengakui bahwa pemrograman berpasangan dapat menghasilkan lebih banyak jam kerja orang yang dihabiskan untuk suatu tugas, peningkatan kualitas dan pembelajaran bersama sangat berharga dalam pikiran mereka. Setiap skeptisisme terhadap pemrograman berpasangan kemudian dibingkai sebagai upaya untuk "memeras sebanyak mungkin pekerjaan dari pengembang". Tapi ini adalah karakterisasi yang sederhana, dan mungkin tidak adil. Sangat mudah untuk mengatasi masalah keuangan seperti itu jika Anda bukan orang yang membayar gaji pengembang.

Kami senang bekerja dengan banyak pemilik perusahaan yang merupakan (pensiunan) pengembang itu sendiri. Meskipun mereka benar-benar menyadari manfaat pemrograman pasangan, kadang-kadang mereka masih merasa sulit untuk membenarkan kasus bisnis. Lagi pula, biaya langsung dari pair programming (lebih banyak orang-jam) jauh lebih terlihat dan jelas daripada manfaat masa depan (yang diharapkan) dari peningkatan kualitas, lebih sedikit bug, dan pembelajaran bersama. Hal ini menjadikan pair programming sebagai strategi investasi. Dan seperti yang diketahui oleh semua pengusaha, terkadang Anda dapat melakukan investasi, dan terkadang Anda tidak bisa.

“Sangat mudah untuk mengatasi masalah keuangan seperti itu jika Anda bukan orang yang membayar gaji pengembang.”

Harapan kami adalah postingan ini berkontribusi pada perdebatan seputar kontroversi ini. Kami berharap ini akan memberi Anda cara yang lebih baik untuk berbicara tentang biaya dan manfaat pemrograman berpasangan di organisasi Anda. Penelitian ilmiah juga memiliki hal-hal untuk dikatakan tentang apa yang dapat membuatnya lebih efektif.

Wawasan #1: Pemrograman berpasangan membutuhkan waktu sedikit lebih lama daripada pemrograman tunggal

Pertanyaan pertama adalah bagaimana pair programming dibandingkan dengan solo programming dalam hal kecepatan. Apakah dua pengembang bekerja sebagai pasangan lebih cepat pada tugas yang sama dengan pengembang individu? Ini adalah bagian dari argumen asli Beck (1999) untuk pair programming, meskipun tidak dipegang kuat dalam publikasi yang lebih baru.

Banyak studi ilmiah mengambil pendekatan eksperimental untuk pertanyaan ini. Mereka membawa pengembang ke pengaturan laboratorium terkontrol dan meminta mereka untuk memecahkan masalah pengkodean, baik sendiri atau berpasangan. Para peneliti kemudian mengukur waktu yang diperlukan untuk menyelesaikan tugas atau, dalam beberapa kasus, hingga standar kualitas tertentu terpenuhi. Dalam banyak kasus, studi ini dilakukan dengan siswa (ilmu komputer), sementara di lain waktu pengembang profesional dipekerjakan atau diundang untuk berpartisipasi. Biasanya, studi ini mengukur berapa banyak waktu yang dibutuhkan dua pengembang untuk menyelesaikan masalah pengkodean dibandingkan dengan satu pengembang. Dalam kasus lain, solusi harus memenuhi tingkat kualitas tertentu sebelum diterima.

Cara terbaik untuk mengumpulkan hasil dari banyak penelitian ilmiah adalah melalui meta-analisis. Analisis semacam itu menggunakan teknik statistik canggih untuk mengumpulkan temuan dari banyak studi individu dan menarik kesimpulan yang luas. Beberapa meta-analisis telah dilakukan untuk pair programming. Sejauh ini studi yang paling sering dikutip dilakukan oleh Hannay et. Al. (2009). Mereka mengumpulkan hasil dari 18 studi empiris. Mereka menyimpulkan bahwa dalam studi-studi ini, pair programming memerlukan sedikit waktulebih banyak waktu daripada pemrograman tunggal, dan membutuhkan lebih banyak usaha (jam-orang). Namun, meta-analisis yang lebih baru oleh Salge & Berente (2016) dari 15 studi empiris tidak menemukan perbedaan yang signifikan dalam durasi. Hal ini konsisten dengan studi terkenal oleh Williams et. Al. (2000) yang menunjukkan peningkatan durasi 15% dibandingkan dengan pemrograman solo. Tetapi penulis juga menemukan bahwa hasilnya meningkat karena pasangan lebih banyak bekerja sama, dan berpotensi menjadi dua kali lebih cepat dari pengembang solo. Namun, penelitian ini tidak ditinjau sejawat dan menggunakan sampel kecil siswa. Kami harus mencatat bahwa penelitian ini menggunakan sampel kecil siswa, dan kesimpulannya jauh lebih kuat dan tidak dapat digeneralisasi daripada meta-analisis yang disebutkan di atas.

Sebagian besar studi akademik menunjukkan bahwa pemrogram berpasangan membutuhkan lebih banyak waktu untuk menyelesaikan tugas yang sama dengan pengembang tunggal. Namun, pola yang konsisten di seluruh studi ini adalah bahwa pengalaman pengembang dan kompleksitas masalah penting bagi hasilnya. Pengembang junior tampaknya menjadi sedikit lebih cepat saat dipasangkan (Hannay et. al. 2009). Memasangkan juga mengurangi durasi dibandingkan dengan pemrograman solo untuk masalah kompleks ( ibid ).

“Mayoritas studi akademis menunjukkan bahwa pair programmer membutuhkan lebih banyak waktu untuk menyelesaikan tugas yang sama dengan seorang developer tunggal. Namun, pola yang konsisten di seluruh studi ini adalah bahwa pengalaman pengembang dan kompleksitas masalah penting bagi hasilnya.”

Jadi untuk kecepatan saja, gambaran keseluruhan yang muncul dari hal ini adalah developer yang bekerja berpasangan sedikit lebih lambat dibandingkan developer yang bekerja sendiri dalam suatu tugas. Jadi bukti tidak mendukung gagasan bahwa pemrograman pasangan segera meningkatkan kecepatan, dan tidak menghasilkan kasus bisnis yang kuat dengan sendirinya.

Salah satu batasan dari studi ini adalah bahwa mereka hanya mempertimbangkan durasi pengkodean, tetapi bukan waktu siklus tugas di semua tahap pengembangan. Mungkin durasi pemrograman solo lebih pendek, tetapi dengan peninjauan kode tambahan yang perlu dilakukan setelahnya dan bug yang harus diperbaiki, mungkin masih membutuhkan waktu lebih lama daripada pemrograman berpasangan. Sayangnya, saya tidak menemukan bukti yang mendukung atau menolak pernyataan ini.

Wawasan #2: Pemrograman berpasangan menghasilkan kode berkualitas lebih tinggi daripada pemrograman tunggal, tetapi tidak selalu

Tapi bagaimana dengan kualitas? Ini mungkin manfaat paling penting di benak para pendukung, serta Beck (1999) dan penulis lain tentang pemrograman berpasangan (Coplien, 2015, Kim et. al. 2021, Williams et. al. 2003). Asumsinya di sini adalah ketika dua pengembang berpasangan pada suatu tugas, ada lebih banyak dorongan untuk mempertahankan standar kualitas yang terkait dengan kode bersih, pengujian, dan dokumentasi. Jika pengembang bekerja sendiri, mereka mungkin lebih cenderung melonggarkan standar mereka, terutama ketika terdesak waktu. Pemrograman pasangan juga bertindak sebagai tinjauan kode yang berkelanjutan dan real-time, di mana kedua pengembang meninjau dan meningkatkan kode seperti yang tertulis.

Sebagian besar penyelidikan ilmiah tentang pemrograman pasangan mengukur kualitas dengan menguji solusi terhadap kasus uji yang ada. Beberapa penelitian mengukur kualitas melalui metrik kode (seperti SQALE). Sekali lagi, kesimpulan yang paling konsisten berasal dari meta-analisis dari banyak studi akademik. Hanay et. Al. (2009) mengumpulkan 18 studi empiris dan menemukan sedikit peningkatan kualitas ketika membandingkan pair programming dengan solo programming. Meta-analisis lain dari 15 studi empiris oleh Salge & Berente (2016) juga menemukan efek positif sedang. Untuk mengilustrasikan perbedaannya, Williams et. Al. (2000) menemukan bahwa pengembang tunggal lulus antara 73-78% kasus uji dengan solusi mereka, sedangkan pengembang berpasangan lulus 86-94%.

Seperti halnya kecepatan, ada bukti jelas bahwa pengalaman pengembang dan kompleksitas tantangan memoderasi efek ini. Lonjakan kualitas paling menonjol saat pengembang junior berpasangan (Hannay et. al., 2009), paling spektakuler sebesar 149% untuk tantangan kompleks. Pengembang perantara juga mendapat manfaat dari pemrograman berpasangan, tetapi hanya untuk tugas-tugas kompleks (naik 92%). Menariknya, tidak ada manfaat yang jelas bagi pengembang senior. Kualitas kode mereka kebanyakan sama, berpasangan atau solo.

“Hannay et. Al. (2009) mengumpulkan 18 studi empiris dan menemukan sedikit peningkatan kualitas ketika membandingkan pair programming dengan solo programming.”

Jadi gambaran keseluruhan yang muncul untuk kualitas adalah bahwa pair programming meningkatkan kualitas, terutama untuk pengembang junior dan menengah, dan khususnya untuk masalah yang kompleks. Dyba et. Al. (2014) meringkas ini sebagai: “Dua kepala lebih baik dari satu kepala untuk mencapai kebenaran pada tugas pemrograman yang sangat kompleks“.

Wawasan #3: Pemrograman berpasangan menghasilkan lebih banyak pembelajaran daripada pemrograman tunggal

Manfaat ketiga yang sering dikutip dari pair programming adalah memungkinkan pengembang untuk berbagi pembelajaran dengan bekerja sama. Ini cocok dengan pengalaman kami sendiri; kami sering belajar tentang cara menulis kode yang lebih baik dengan bekerja sama dengan pengembang lain dengan perspektif lain. Jelas, ada banyak cara untuk mengukur pembelajaran. Sebagian besar penelitian menggunakan survei singkat untuk menanyakan kepada pengembang berapa banyak yang mereka pelajari dari mengerjakan kode secara berpasangan atau sendiri.

Hanya meta-analisis Salge & Berente (2016) yang mencakup pembelajaran sebagai hasil berpasangan. Berdasarkan 15 studi empiris, mereka menyimpulkan bahwa memang ada efek positif moderat dari pair programming pada pembelajaran dibandingkan dengan solo programming. Namun, tidak jelas bagaimana keahlian dan kompleksitas masalah berperan dalam hal ini. Beberapa penelitian menunjukkan bahwa pembelajaran tampak jauh lebih tinggi ketika pengembang dengan tingkat pengalaman yang berbeda dipasangkan, tetapi tidak terlalu berbeda.

“Berdasarkan 15 studi empiris, mereka menyimpulkan bahwa memang ada efek positif sedang dari pemrograman berpasangan pada pembelajaran dibandingkan dengan pemrograman tunggal.”

Jadi dalam hal pembelajaran, dapat disimpulkan bahwa pemrograman berpasangan menciptakan lebih banyak kesempatan belajar bagi pengembang daripada pemrograman tunggal.

Wawasan #4: Manfaat lain dari pair programming

Hingga saat ini, kami membahas kecepatan/durasi, kualitas, dan pembelajaran. Tapi bagaimana dengan manfaat lain dari pair programming? Williams et. Al. (2000) menemukan bahwa pengembang yang berpasangan melaporkan kepuasan dan kesenangan yang jauh lebih tinggi daripada pengembang yang bekerja sendiri. 90% peserta dalam eksperimen mereka lebih suka berpasangan daripada bermain solo sesudahnya. Sebuah studi longitudinal oleh Vanhanen, Lassenius & Mäntylä (2007) menemukan bahwa pair programming meningkatkan semangat tim dan kepuasan kerja. Menariknya, penelitian ini juga mendukung pengamatan umum bahwa pengembang sering awalnya skeptis terhadap pemrograman berpasangan, tetapi menjadi pendukungnya setelah mengalaminya.

Meninjau kembali kasus bisnis untuk pair programming

Hasil tersebut menunjukkan bahwa pemrograman pasangan bermanfaat untuk kualitas dan pembelajaran, terutama untuk pengembang junior dan menengah, dan khususnya untuk tugas-tugas kompleks. Namun, pair programming cenderung lebih lambat daripada solo programming, meskipun perbedaan ini dapat berkurang karena pengembang terbiasa dengan pairing (Williams et. al., 2000).

Jadi apa artinya ini bagi kasus bisnis pemrograman berpasangan? Kami pikir masuk akal untuk menyimpulkan bahwa pemrograman berpasangan lebih mahal daripada pemrograman tunggal jika kami hanya mempertimbangkan jam kerja orang. Sederhananya, jika satu pengembang menghabiskan dua jam kerja untuk menyelesaikan tugas, pengembang berpasangan menghabiskan biaya lebih dari empat jam untuk tugas yang sama. Hasil dapat bervariasi dari kasus ke kasus, tetapi ini adalah pola luas yang didukung oleh bukti. Namun, peningkatan biaya diimbangi dengan kualitas kode yang lebih tinggi, lebih banyak pembelajaran, dan potensi peningkatan kecepatan di masa mendatang karena pengembang menjadi lebih terbiasa dengan pemasangan.

“Menurut kami masuk akal untuk menyimpulkan bahwa pemrograman berpasangan lebih mahal daripada pemrograman tunggal jika kami hanya mempertimbangkan jam kerja orang.”

Sayangnya, kedua sisi dari analisis biaya-manfaat dari pemrograman pasangan bervariasi dalam seberapa mudah mereka diukur dalam bentuk uang. Biaya langsung dalam jam kerja sudah jelas, tetapi pengurangan biaya karena lebih sedikit bug, lebih banyak kode yang dapat dipelihara, kepuasan kerja yang lebih tinggi, dan kurva pembelajaran yang lebih cepat untuk pengembang jauh lebih sulit untuk diukur saat ini .

Namun, banyak studi akademik telah menunjukkan bahwa kode berkualitas rendah meningkatkan biaya dalam waktu dekat karena bug lebih mudah terjadi dan lebih sulit untuk diselesaikan (Khomh et. al. 2012, Li & Shatnawi, 2007, Politowski, 2020). Selain itu, pair programming berkontribusi pada pemahaman bersama tentang kualitas dan pembelajaran bersama, yang membuat tim Scrum lebih efektif dalam memenuhi kebutuhan pemangku kepentingan (Verwijs & Russo, 2022).

Rekomendasi Praktis

Jadi apa artinya semua ini dalam praktiknya? Di bawah ini, kami menguraikan rekomendasi yang paling masuk akal berdasarkan bukti.

Rekomendasi #1: Fokus pada peningkatan kualitas dan pembelajaran

Jika Anda perlu meyakinkan orang lain tentang manfaat pair programming, sebaiknya Anda berfokus pada peningkatan kualitas dan pembelajaran. Bukti dengan jelas mendukung hal ini, sedangkan manfaat penghematan waktu yang diantisipasi kurang jelas dan mungkin atau mungkin tidak terwujud di masa depan. Namun, Anda tidak boleh menghindari peningkatan biaya pemrograman berpasangan. Suka atau tidak suka, berapa banyak biaya kerja merupakan pertimbangan penting dalam setiap keputusan yang diambil oleh bisnis (komersial), khususnya untuk orang-orang di posisi manajemen atau tim yang memiliki kendali keuangan. Anda akan merasakan hal yang sama jika Anda membayar gaji dan tagihan.

Narasi yang lebih baik adalah membingkai pemrograman berpasangan sebagai investasi dalam kualitas dan pembelajaran. Ini sangat berguna di pasar tenaga kerja yang ketat di mana pengembang yang baik sulit didapat. Memasangkan developer junior dan menengah dengan developer yang lebih berpengalaman adalah cara berbasis bukti untuk meningkatkan pembelajaran dan meningkatkan keterampilan tenaga kerja yang ada.

“Narasi yang lebih baik adalah membingkai pemrograman berpasangan sebagai investasi dalam kualitas dan pembelajaran. Ini sangat berguna di pasar tenaga kerja yang ketat di mana pengembang yang baik sulit didapat.”

Rekomendasi #2: Dorong pasangan pada tugas-tugas kompleks

Bukti menunjukkan bahwa memasangkan paling bermanfaat untuk tugas yang rumit, meskipun sebagian besar pengembang junior juga mendapat manfaat dari memasangkan pada tugas yang lebih sederhana. Untuk pengembang yang lebih berpengalaman, memasangkan pada tugas-tugas sederhana bahkan dapat menyebabkan hasil yang lebih buruk daripada pemrograman tunggal (Hannay et. al., 2009).

Dengan demikian, bukti tidak mendukung keyakinan bahwa pasangan harus digunakan untuk menulis semua kode, seperti yang direkomendasikan pada awalnya (Beck, 1999). Sebaliknya, sebagai alat, pair programming tampaknya paling cocok untuk masalah yang kompleks dan untuk membantu pengembang yang kurang pengalaman untuk menulis sendiri kode yang bagus. Tentu saja, penilaian tentang apa yang kompleks berkembang seiring dengan pengalaman. Jadi idealnya ini adalah penilaian yang harus dibuat oleh tim bersama saat mereka mengoordinasikan pekerjaan mereka. Daily Scrum adalah kesempatan ideal untuk membuat penilaian dan mengeluarkan undangan berpasangan.

Rekomendasi #3: Fokus pada pencegahan bau kode

Satu area yang tidak kami bahas dalam posting ini adalah bagaimana memanfaatkan pair programming secara maksimal. Salah satu rekomendasi berbasis bukti adalah memfokuskan sesi berpasangan pada pencegahan bau kode, terutama yang menghasilkan kelas yang panjang dan berantakan (mis. “Kelas Blob” dan “Kode Spaghetti”). Seperti yang telah kami tulis di artikel mendalam lainnya , bukti ilmiah mendukung keyakinan bahwa bau kode semacam itu meningkatkan bug, membutuhkan lebih banyak waktu untuk melakukan perubahan, dan mempersulit untuk memahami kode.

Rekomendasi #4: Hindari kesenjangan pengalaman yang besar

Sebagian besar studi akademik menunjukkan bahwa memasangkan pengembang dengan tingkat pengalaman yang berbeda lebih menguntungkan, asalkan jaraknya tidak terlalu besar. Namun, developer junior yang dipasangkan mungkin juga lebih efektif bersama daripada sendirian untuk tugas yang tidak terlalu rumit. Kalau tidak, ada risiko “orang buta menuntun orang buta”. Namun, memasangkan pengembang dengan pengalaman yang sangat rendah dengan pengembang dengan banyak pengalaman juga tampaknya tidak terlalu efektif (Hannay et. al., 2009, Bowman et. al. 2019). Jadi jika Anda punya pilihan, bentuk pasangan pengalaman campuran yang jaraknya tidak terlalu jauh.

Rekomendasi #5: Buat perjanjian kerja

Komunikasi yang baik jelas penting untuk memasangkan pemrograman (Zarb & Hughes, 2015). Seperti semua pekerjaan yang terjadi dalam tim, penting untuk membuat perjanjian kerja penting agar interaksi tersebut menyenangkan dan efektif. Khusus untuk pair programming, pola dan panduan dari Zarb & Hughes ( ibid ) yang kami bagikan di artikel lain sangat berguna. Alternatifnya, Anda bisa membuatnya sendiri. Banyak tips yang bisa Anda temukan dalam artikel mendalam tentang ilmu perjanjian kerja ini. Contoh perjanjian kerja tersebut dapat berupa:

• “Tugas yang paling cocok untuk memasangkan pemrograman di tim kami adalah…”
• “Kita dapat mengundang orang lain untuk berpasangan dengan kita dengan…”
• “Kami membatasi sesi pemrograman pasangan kami hingga … menit”

Beberapa orang bersumpah dengan pemrograman berpasangan, yang lain membencinya. Praktik ini telah ada sejak awal 1990-an dan mendapat banyak perhatian dari para akademisi. Namun, hal ini kontroversial karena pertukarannya antara biaya membuat dua pengembang mengerjakan tugas di satu sisi, dan kualitas serta pembelajaran di sisi lain.

Sampai saat ini, bukti ilmiah sangat menunjukkan bahwa pemrograman berpasangan membutuhkan waktu sedikit lebih lama daripada pemrograman tunggal, dengan upaya hampir dua kali lipat dalam jam kerja orang. Namun, investasi waktu ini diimbangi dengan peningkatan yang jelas dalam kualitas, pembelajaran, dan kesenangan, yang pada gilirannya juga mempercepat perkembangan. Kami juga membahas bagaimana pemasangan tampaknya paling berguna untuk tugas-tugas kompleks, dan ketika pengembang kurang berpengalaman.

Kami memesan posting ini dengan lima rekomendasi praktis untuk meningkatkan pemrograman berpasangan untuk tim Anda.

Harapan kami adalah postingan ini memberi Anda titik awal yang lebih baik, berbasis bukti, untuk membahas biaya dan manfaat pemrograman berpasangan di tim dan organisasi Anda. Mungkin beberapa hasil menantang keyakinan dan pengalaman Anda sendiri, yang dapat mengarah pada beberapa refleksi. Bagaimanapun, selamat memprogram pasangan dan pemrograman solo!

Posting ini memakan waktu lebih dari 35 jam untuk meneliti dan menulis . Jika menurut Anda konten kami berharga, dan menurut Anda kami harus menulis lebih banyak lagi, Anda dapat mendukung kami di Patreon . Temukan lebih banyak postingan berbasis bukti di sini .

Kami berterima kasih kepada semua penulis makalah referensi dan studi untuk pekerjaan mereka.

Referensi

Beck, K. (1999). Merangkul perubahan dengan pemrograman ekstrim. Komputer , 32 (10), 70–77.

Beck, K., & Andres, C. (2004). Pemrograman ekstrem menjelaskan: Rangkullah perubahan. edisi ke-2.

Bowman, NA, Jarratt, L., Culver, KC, & Segre, AM (2019, Juli). Bagaimana pengalaman pemrograman sebelumnya memengaruhi pengalaman dan hasil pemrograman pasangan siswa. Dalam Prosiding Konferensi ACM 2019 tentang Inovasi dan Teknologi dalam Pendidikan Ilmu Komputer (hlm. 170–175).

Coplien, J. (1995). Sebuah proses pengembangan bahasa pola generatif. Pola Bahasa Desain Program .

Dyba, T., Arisholm, E., Sjoberg, DI, Hannay, JE, & Shull, F. (2007). Apakah dua kepala lebih baik dari satu? Tentang efektivitas pemrograman berpasangan. perangkat lunak IEEE , 24 (6), 12–15.

Hannay, JE, Dybå, T., Arisholm, E., & Sjøberg, DI (2009). Efektivitas pemrograman pasangan: Sebuah meta-analisis. Teknologi informasi dan perangkat lunak , 51 (7), 1110–1122.

Kim, G., Humble, J., Debois, P., Willis, J., & Forsgren, N. (2021). Buku pegangan DevOps: Cara membuat kelincahan, keandalan, & keamanan kelas dunia dalam organisasi teknologi . Revolusi TI.

Khomh, F., Di Penta, M., Guéhéneuc, YG, & Antoniol, G. (2012). Sebuah studi eksplorasi tentang dampak antipola pada perubahan kelas dan rawan kesalahan. Rekayasa Perangkat Lunak Empiris , 17 (3), 243–275.

Li, W., & Shatnawi, R. (2007). Studi empiris tentang bau busuk dan probabilitas kesalahan kelas dalam evolusi sistem berorientasi objek pasca-rilis. Jurnal sistem dan perangkat lunak , 80 (7), 1120–1128.

Politowski, C., Khomh, F., Romano, S., Scanniello, G., Petrillo, F., Guéhéneuc, YG, & Maiga, A. (2020). Studi empiris skala besar tentang dampak kode spageti dan anti-pola blob pada pemahaman program. Teknologi Informasi dan Perangkat Lunak , 122 , 106278.

Salge, CADL, & Berente, N. (2016). Pemrograman berpasangan vs. pemrograman tunggal: Apa yang kita ketahui setelah 15 tahun penelitian?. Pada Konferensi Internasional Hawaii ke-49 tentang Ilmu Sistem (HICSS) 2016 (hlm. 5398–5406). IEEE.

Williams, L., Kessler, RR, Cunningham, W., & Jeffries, R. (2000). Memperkuat kasus untuk pemrograman berpasangan. Perangkat lunak IEEE , 17 (4), 19–25.

Vanhanen, J., Lassenius, C., & Mantyla, MV (2007, Agustus). Masalah dan taktik saat mengadopsi pemrograman berpasangan: Studi kasus longitudinal. Dalam Konferensi Internasional tentang Kemajuan Rekayasa Perangkat Lunak (ICSEA 2007) (hlm. 70–70). IEEE.

Verwijs, C., & Russo, D. (2021). Teori efektivitas tim scrum. pracetak arXiv arXiv:2105.12439 .

Williams, L., & Kessler, RR (2003). Pasangan pemrograman menyala . Addison-Wesley Profesional.

Zarb, M., & Hughes, J. (2015). Mendobrak penghalang komunikasi: pedoman untuk membantu komunikasi dalam pemrograman berpasangan. Pendidikan ilmu komputer , 25 (2), 120–151.