Pairing Programming dan ISO 27001

16

Saya telah bekerja di tim pemrograman eXtreme dan melakukan pemrograman pasangan selama lebih dari 7 tahun di lingkungan windows. Ketika kami pertama kali mulai melakukannya, seseorang akan masuk dengan kredensial windows mereka dan karenanya semua akses ke sumber daya domain, dan lebih khusus lagi kontrol versi, akan bertanggung jawab kepada pengguna windows itu. Akhirnya kami telah berevolusi untuk membuat akun pemasangan windows untuk stasiun pemasangan tertentu (mis. PairA, pairB, PairC dll ...). Semua pengembang tahu kata sandi untuk akun ini. Akuntabilitas untuk komitmen (check-in) dicapai dengan menempatkan inisial programer dalam komentar selama komit.

Sampai sekarang ini bekerja dengan baik bagi kami, tetapi perusahaan saya saat ini sedang menjalani audit ISO 27001 dan ini ditandai oleh auditor sebagai risiko. Saya memiliki sejumlah solusi yang mungkin seperti membuat akun pasangan untuk setiap kombinasi pasangan, tetapi saya benar-benar ingin tahu apakah ada orang lain yang mengalami masalah ini dan bagaimana mereka menyelesaikannya?

Solusi apa yang dapat diterima oleh auditor?

pair-programming iso

— Martin Hughes
sumber

11

Saya rasa sebagian besar orang yang menggunakan praktik pemrograman berpasangan berpikir bahwa semua yang dilakukan ISO adalah format tanggal dan pengkodean karakter.

— Lars Viklund

6

Mengapa Anda harus memiliki akun pasangan? Tidakkah itu berhasil untuk membuat akun individual yang dapat Anda masuki di mesin apa pun?

— Garrett Hall

Anda tidak dapat menggunakan akun individual karena apa yang terjadi jika seseorang masuk kerja lebih awal / pergi ke toilet dll dan mesin login sebagai pengguna lain?

— John Sibly

@JohnSibly Apakah maksud Anda jika ingin melanjutkan pekerjaan yang sedang berjalan pada akun itu? Kalau tidak, Anda harus dapat membuka sesi lain di komputer sebagai pengguna Anda sendiri.

— Sinjo

2

@ JohnSibly, lalu pengemudi log off, dan membiarkan rekan login. Jika mereka pergi ke kamar kecil, kunci mesin jika Anda tidak mempercayai rekan-rekan Anda. Namun, tidak ada kepercayaan adalah masalah yang lebih besar yang harus diperbaiki.

— CaffGeek

13

Saya berasumsi bahwa para auditor akan lebih suka bahwa pengembang masuk sebagai diri mereka sendiri dan bukan sebagai "pasangan" yang memiliki kata sandi bersama. Risiko harus jelas - pengembang menambahkan beberapa kode berbahaya sebagai "PairA" dan menempatkan inisial orang lain dalam komentar (atau tidak berkomentar sama sekali). Bagaimana Anda melacak kembali ke pengembang jahat?

Saya akan merekomendasikan bahwa siapa pun yang mengemudi terlebih dahulu (dalam satu sesi) masuk dengan ID-nya sendiri, dan pasangan terus memasukkan kedua inisial mereka di komentar - dengan begitu, kode tetap dapat dilacak kembali ke pengembang yang sebenarnya.

— Matthew Flynn
sumber

+1, ini yang dilakukan di perusahaan saya. Kami memiliki pilihan ulasan kode peer atau pemrograman pasangan. Kasus pemrograman pasangan hanyalah kasus khusus dari peer review, di mana rekan telah meninjau terus menerus saat kode ditulis.

— Daniel Pryden

@Daniel terima kasih telah berbagi pengalaman Anda. Ketika kami pertama kali mulai memasangkan, itu adalah driver yang akan login. Namun sesi pairing kami sekarang lebih promiscuous dan cukup sering pair akan bertukar sebelum tugas sepenuhnya selesai. Meskipun ini tidak ideal, kadang-kadang diperlukan untuk mengatur pertukaran kami karena semua orang diharuskan untuk berpasangan dengan kode produksi. Ini berarti 'pengemudi' asli harus pergi dan keluar. Kita bisa mendapatkan kode itu masuk tanpa mereka, tetapi gangguan pada pasangan, yang berpotensi di tengah debug aplikasi, tidak terlalu dianggap enteng.

— Martin Hughes

7

Saya akan menyimpan akun sebagaimana adanya, biasanya hanya satu orang yang mengemudi, dan bahkan jika orang lain menggunakan mesin (tidak resmi) orang yang masuk harus tetap waspada dengan apa yang terjadi pada mesin mereka.

Namun Checkins masih membutuhkan komentar untuk menunjukkan siapa pasangan itu.

— CaffGeek
sumber

Apakah maksud Anda menyimpan akun pasangan ("pertahankan akun apa adanya"), atau gunakan akun individual ("orang yang masuk")?

— Caleb

@ Caleb, individu sebagai orang yang masuk yang melakukan mengemudi

— CaffGeek

6

Alih-alih membuat akun terpisah sehingga pekerjaan tidak dikunci untuk pengguna yang mungkin tidak ada, gunakan sistem kontrol versi Anda. Saat pasangan mulai bekerja, buat cabang tugas. Komit kode ke cabang tugas setiap kali tes lulus. Saat tugas selesai, gabungkan kembali dan tutup cabang tugas.

— kevin cline
sumber

5

Sampai sekarang ini bekerja dengan baik untuk kami, tetapi perusahaan saya saat ini sedang menjalani audit ISO 27001

ISO 27001 atau tidak, sistem Anda saat ini hanya berfungsi karena Anda adalah perusahaan kecil di mana terdapat tingkat komunikasi dan rasa saling percaya yang tinggi. Hal semacam itu tidak meningkat dengan sangat baik, jadi Anda mungkin harus mempertimbangkan opsi lain di beberapa titik di masa depan.

Membuat akun terpisah untuk setiap pasangan yang memungkinkan tampaknya bahkan kurang praktis: Anda membutuhkan 90 akun untuk sekelompok 10 pengembang, dan masing-masing dari 10 pengembang tersebut harus mengetahui 9 kombinasi login / kata sandi yang berbeda.

Satu-satunya solusi praktis adalah menggunakan akun individual, seperti yang disarankan orang lain, dan melacak identitas orang kedua dalam pasangan dengan cara lain (komentar dalam komit kontrol versi Anda, bidang dalam sistem pelacakan masalah, dll.).

— Caleb
sumber

2

Demi Pete, biarkan anggota penggerak pasangan mengambil kredit / tanggung jawab atas dorongan / komit. Lain kali anggota lain akan mengemudi. "Pengemudi" tidak akan melakukan apa pun yang tidak dia setujui bersama ko-pilot.

Pemrograman adalah upaya kolaboratif. Tidak ada akta pemrograman yang 100% individual. Tidak perlu menjadi rewel ingin mencerminkan bahwa dorongan / komitmen yang diberikan dilakukan oleh Tom dan Harry dan bukan hanya Tom. Manfaat pemrograman pasangan layak mengabaikan nuansa itu.

Auditor benar, akun "kumpulan" harus dihindari.

— Tulains Córdova
sumber