Bagaimana saya bisa meyakinkan programmer koboi untuk menggunakan kontrol sumber?

PEMBARUAN
Saya bekerja pada tim kecil devs, 4 orang. Mereka semua menggunakan kontrol sumber. Sebagian besar dari mereka tidak tahan dengan kontrol sumber dan malah memilih untuk tidak menggunakannya. Saya sangat percaya kontrol sumber adalah bagian penting dari pengembangan profesional. Beberapa masalah membuatnya sangat sulit untuk meyakinkan mereka untuk menggunakan kontrol sumber:

• Tim tidak terbiasa menggunakan TFS . Saya sudah memiliki 2 sesi pelatihan, tetapi hanya diberikan 1 jam yang tidak cukup.
• Anggota tim langsung memodifikasi kode di server. Ini menjaga kode tidak sinkron. Membutuhkan perbandingan hanya untuk memastikan Anda bekerja dengan kode terbaru. Dan masalah gabungan yang kompleks muncul
• Perkiraan waktu yang ditawarkan oleh pengembang mengecualikan waktu yang diperlukan untuk memperbaiki semua masalah ini. Jadi, jika saya katakan nono akan memakan waktu 10x lebih lama ... Saya harus terus-menerus menjelaskan masalah ini dan mengambil risiko sendiri karena sekarang manajemen mungkin menganggap saya "lambat".
• File fisik di server berbeda dalam cara yang tidak diketahui lebih dari ~ 100 file. Penggabungan membutuhkan pengetahuan tentang proyek yang ada dan, oleh karena itu, kerja sama pengembang yang tidak dapat saya peroleh.
• Proyek lain tidak sinkron. Pengembang terus memiliki ketidakpercayaan terhadap kontrol sumber dan karenanya menambah masalah dengan tidak menggunakan kontrol sumber.
• Pengembang berpendapat bahwa menggunakan kontrol sumber boros karena penggabungan cenderung kesalahan dan sulit. Ini adalah poin yang sulit untuk diperdebatkan, karena ketika kontrol sumber sedang sangat salah digunakan dan kontrol sumber terus menerus dilewati, itu memang rawan kesalahan. Karena itu, bukti "berbicara untuk dirinya sendiri" dalam pandangan mereka.
• Pengembang berpendapat bahwa secara langsung memodifikasi kode server, melewati TFS menghemat waktu. Ini juga sulit untuk diperdebatkan. Karena penggabungan yang diperlukan untuk menyinkronkan kode untuk memulai adalah memakan waktu. Lipat gandakan ini dengan 10+ proyek yang kami kelola.
• File permanen sering disimpan dalam direktori yang sama dengan proyek web. Jadi penerbitan (publikasi penuh) menghapus file-file ini yang tidak dalam kendali sumber. Ini juga mendorong ketidakpercayaan untuk kontrol sumber. Karena "penerbitan merusak proyek". Memperbaiki ini (memindahkan file yang disimpan keluar dari subfolder solusi) membutuhkan banyak waktu dan debugging karena lokasi ini tidak diatur di web.config dan sering ada di beberapa titik kode.

Jadi, budaya itu tetap ada. Praktik buruk menghasilkan lebih banyak praktik buruk. Solusi buruk mendorong peretasan baru untuk "memperbaiki" masalah yang jauh lebih dalam, lebih memakan waktu. Server, ruang hard drive sangat sulit didapat. Namun, ekspektasi pengguna meningkat.

Apa yang bisa dilakukan dalam situasi ini?

Ini bukan masalah pelatihan, ini masalah faktor manusia. Mereka tidak mau, dan menciptakan blok jalan. Berurusan dengan dinamika kelompok yang terpecah, apa penyebab utama keberatan mereka - biasanya ketakutan, apakah hanya takut akan perubahan, atau lebih menakutkan.

Tidak ada pengembang profesional hari ini, atau selama 20 tahun terakhir, yang menolak kontrol sumber. Suatu ketika, sekitar 30 atau 40 tahun yang lalu, ketika komputer lambat, kontrol sumber bahkan lebih lambat dan program terdiri dari satu file 500 baris, itu menyakitkan dan ada alasan yang sah untuk tidak menggunakannya. Keberatan ini hanya bisa datang dari jenis koboi terburuk yang bisa saya pikirkan.

Apakah sistem memaksa mereka membuat hidup mereka sulit dalam beberapa cara? Cari tahu apa itu, dan ubah sistem untuk membatalkan keberatan. Ulangi sampai selesai.

Saya sarankan melihat GIT atau Mercurial. Anda dapat membuat repositori di setiap pohon kode sumber, mereka bahkan tidak akan melihat dan dapat terus meretas seperti yang mereka lakukan sekarang. Anda dapat melacak perubahan yang telah mereka retas ke dalam basis kode, membuat komitmen, menggabungkannya ke pohon sumber lain, dll. Ketika mereka melihat Anda melakukan upaya gabungan selama beberapa minggu ke dalam produk lain dalam hitungan detik, mereka mungkin mengubah gagasan mereka. Ketika Anda memutar kembali salah satu sekrup mereka dengan satu perintah, dan menyimpan pantat mereka, mereka bahkan mungkin akan berterima kasih (jangan mengandalkannya). Paling buruk, Anda terlihat baik di depan bos dan, untuk bonus, membuat mereka terlihat seperti para koboi.

Penggabungan tidak hanya akan membutuhkan pengetahuan besar tentang proyek

Dalam hal ini, saya khawatir Anda sudah sampai di sungai pepatah tanpa dayung. Jika penggabungan bukan opsi, tidak juga mengimplementasikannya, jadi Anda mengatakan bahwa Anda tidak bisa lagi menambahkan fitur yang sudah Anda miliki di satu cabang (istilah digunakan secara longgar) ke yang lain.

Jika saya jadi Anda, saya akan mempertimbangkan kembali prospek karir saya ...

Terkadang, masalah dunia nyata membuatnya tidak praktis untuk digunakan.

Salah.

Jika tim tidak terbiasa menggunakan kontrol sumber, masalah pelatihan dapat muncul

Itu tidak ada hubungannya dengan kontrol kode sumber dan semuanya berkaitan dengan pelatihan. Pelatihannya mudah, murah, efisien dan dilakukan dalam hitungan jam. Gagal menggunakan kontrol kode sumber mahal, berisiko, tidak efisien, dan masalah tetap ada selamanya .

Jika anggota tim memodifikasi kode secara langsung di server, berbagai masalah dapat muncul.

Itu masalah pelatihan. Lagi. Tidak ada hubungannya dengan kontrol kode sumber dan semuanya terkait dengan pelatihan.

Pengembang terus memiliki ketidakpercayaan terhadap kontrol sumber dan karenanya menambah masalah dengan tidak menggunakan kontrol sumber

Mereka perlu dilatih tentang cara menggunakan kontrol kode sumber. Ini mengurangi biaya, mengurangi risiko, menyederhanakan hal-hal dan lebih efisien. Ini adalah investasi satu kali yang membayar dividen setiap saat.

Apa yang bisa dilakukan dalam situasi seperti ini?

Mulai latih semua orang tentang cara menggunakan kontrol kode sumber.

Memperbarui

Pengembang berpendapat bahwa memodifikasi kontrol sumber secara langsung menghemat waktu.

Karena mereka salah, penting untuk mengumpulkan data untuk menunjukkan dengan tepat betapa salahnya ini.

Sayangnya, bagaimanapun, manajemen tampaknya menghargai tanggapan langsung yang mahal dalam jangka panjang.

Satu-satunya cara untuk mengatasi sistem imbalan ini adalah dengan

A) Identifikasi bahwa biaya jangka panjang lebih tinggi dari nilai jangka pendek yang tampak.

B) Identifikasi imbalan aktual yang sebenarnya ada di tempat yang membuat korupsi jangka pendek (yaitu, perubahan langsung) tampak lebih berharga daripada kontrol kode sumber jangka panjang yang benar. Siapa yang menepuk kepalanya karena melakukan hal yang salah? Apa jenis tepukan di kepala yang mereka dapatkan? Siapa yang memberikannya? Untuk memperbaiki hal-hal, Anda harus menyebutkan hal-hal yang salah dan manajer spesifik yang mendorong orang.

C) Rekomendasikan sistem hadiah yang direvisi yang menghargai nilai jangka panjang dan bukan respons cepat jangka pendek. Tepukan yang berbeda di kepala untuk alasan yang berbeda.

D) Latih orang-orang dalam hadiah yang Anda temukan untuk nilai jangka panjang; nilai yang jelas lebih besar dari respons cepat jangka pendek.

Pengembang yang menolak untuk menggunakan kontrol sumber / versi harus dipecat, sesederhana itu. Seperti yang telah Anda tunjukkan, risiko dan biaya yang melekat dari TIDAK menggunakannya melebihi biaya overhead yang dikeluarkan oleh banyak, banyak pesanan besar. Siapa pun yang berusaha menentang hal ini seharusnya tidak terlibat dalam pengembangan perangkat lunak dan saya akan menolak untuk bekerja dengan orang-orang seperti itu.

Kami memecahkan masalah dengan terlebih dahulu, menyiapkan server integrasi berkelanjutan untuk membangun kontrol sumber kami menjadi dev. Kedua, kunci akses folder hanya untuk membaca, untuk mencegah orang menghindari kontrol sumber dan memodifikasi file secara langsung.

Ini adalah PITA pada hari-hari di mana Anda tidak dapat mereproduksi bug secara lokal, tetapi selain itu lebih baik untuk dapat bekerja, checkin, dan melanjutkan, mengetahui bahwa itu akan didorong ke dev secara otomatis oleh server CI.

Saya mendengar rasa sakit Anda. Saya telah berjalan ke beberapa tempat kerja untuk mencari tahu di sana 'kontrol sumber' adalah folder bersama di drive jaringan. Masalahnya umumnya bukan karena mereka percaya ada pendekatan yang lebih unggul daripada yang lain, itu hanya bekerja dan mereka belum pernah diperkenalkan ke alur kerja yang berhasil mengintegrasikan kontrol sumber.

Dengan struktur tim bumi datar Anda telah menjelaskan mendorong perubahan dari atas ke bawah mungkin bukan cara terbaik untuk mendekati situasi. Salah satu metode yang patut dicoba adalah dengan membeli langsung dari satu atau dua pengembang lain untuk memungkinkan konsep mengumpulkan momentum. Begitu Anda memiliki satu pengembang lain di dalamnya, akan lebih mudah untuk menyebarkannya ke anggota tim lainnya. Perlahan perkenalkan mereka dengan konsep tersebut, katakan mulai bekerja pada proyek sampingan kecil, bangun dan masuk Git , atau bahkan cabut sesuatu yang di-host di GitHub .

Mulai dari yang sederhana, perkenalkan konsep secara perlahan dan terpisah dari alur kerja mereka sehari-hari. Manusia hebat dalam mempelajari berbagai hal dan beradaptasi terhadap perubahan, terutama ketika perubahan itu memberikan manfaat langsung bagi mereka (pikirkan evolusi). Namun, ketika disajikan dengan sejumlah perubahan kecil sekaligus itu menjadi mengasingkan. Setelah mereka memahami cara kerja kontrol sumber dan keuntungan yang diberikannya, cobalah mengintegrasikannya di salah satu proyek internal Anda (jika Anda memulai proyek baru, ini adalah waktu yang jahat untuk memperkenalkannya). Biarkan proyek lain berfungsi dengan cara yang ada jika Anda suka juga, ini akan sangat efektif dalam menyoroti keuntungan dari kontrol kode yang layak.

Jika gagal, jalankan.

Anda jelas memiliki keterampilan teknis untuk mengidentifikasi dan memperbaiki situasi Anda, masalah Anda adalah manusia dan terkait proses.

Orang-orang cenderung merespons jauh lebih baik daripada contoh visi, jadi saya akan menyarankan "memperbaiki" sendiri:

Ambil salinan sumber terbaru, susun ulang untuk menjadi ramah kontrol versi, buat proyek baru dengan struktur yang berguna dan berwawasan ke depan (cari tahu bagaimana Anda akan menangani cabang, tempat Anda meletakkan dependensi pihak ketiga, dll.). Anda mungkin harus melakukan itu di waktu Anda sendiri.

Kemudian seret rekan kerja dan manajemen Anda ke sebuah ruangan dan tunjukkan pada mereka seperti apa pengembangan perangkat lunak di abad ke-21. Ilustrasikan kegagalan dengan sistem Anda saat ini dan tunjukkan bagaimana mereka dihilangkan dengan struktur baru Anda.

Anda juga harus menjadikan diri Anda sebagai Penjaga Sumber - karena Anda tampaknya menjadi satu-satunya yang peduli, terserah pada Anda untuk memaksa orang (dengan cara teknis atau psikologis apa pun yang Anda inginkan) untuk tetap berpegang pada rencana. Pastikan bahwa satu - satunya hal yang pergi ke pelanggan berasal dari mesin build di luar kendali sumber. Ritually mempermalukan orang-orang yang melanggar aturan dan menyebabkan kekacauan. Suap mereka dengan donat ... apa pun yang berhasil.

Jika itu semua sepertinya terlalu banyak usaha maka (seperti yang telah dikatakan dalam setiap jawaban lainnya) - dapatkan pekerjaan lain. Mereka tidak sepadan dengan waktumu.

Langkah 1 - memecat manajer yang tidak kompeten!

Jika Anda tidak dapat melakukan langkah 1, cobalah membuat manajer membatasi penyebaran untuk mendukung hanya skrip yang diambil dari kontrol sumber. Jika pengembang (yang seharusnya tidak memiliki hak produksi pada prod, lihat langkah 1 jika mereka mau) ingin barang-barang mereka digunakan harus berasal dari kontrol sumber. Itu memecahkan masalah kami tentang tidak menggunakan kontrol sumber dengan sangat baik ketika kami pertama kali menggunakannya untuk hal-hal basis data serta kode C #.

Bagaimana mungkin seseorang tidak menginginkan versi berbeda dari file mereka dan kemampuan untuk melihat perbedaannya? Lupakan percabangan dan hal-hal rumit lainnya. Mereka bahkan tidak mendapatkan dasar-dasarnya. Secara langsung memodifikasi file produksi tanpa melakukan perubahan yang paling mendasar dalam lingkungan pengujian adalah gila. Saya telah bekerja dengan beberapa orang dan syukurlah kami tidak pernah bekerja di proyek yang sama.

Rekan kerja Anda terlalu bodoh untuk malas. Itu buang-buang waktu. Yang bisa Anda harapkan adalah melatih manajer Anda. Manajemen harus menyukai kontrol sumber karena mereka menyukai semua bentuk kontrol. Buat mereka merasa penting. Sekrup yang lain; Memperbaiki pemimpin adalah satu-satunya harapan Anda karena Anda tidak dapat menggantikannya. Mulai berjejaring dengan pengembang kompeten lainnya dan cobalah untuk mengajak mereka bergabung dengan tim Anda ketika Anda memiliki pembukaan atau minta mereka untuk mempekerjakan Anda di toko mereka.

Ini adalah contoh yang baik dari proyek di mana praktik-praktik buruk telah digunakan sedemikian luasnya sehingga praktis tidak mungkin untuk memperbaikinya. Memperbaikinya akan membutuhkan pembekuan, sehingga semuanya bisa dibersihkan tanpa gangguan. Sayangnya, proyek seperti itu biasanya (karena alasan yang jelas) terlalu buggy untuk dibekukan selama beberapa bulan, bug kritis harus diperbaiki setiap hari.

Anda mungkin tergoda untuk membayar proyek untuk membuat versi yang bersih sementara versi kotor diperlakukan dengan perbaikan bug harian; tetapi hasil yang paling mungkin adalah bahwa setelah beberapa bulan, ketika versi "bersih" selesai, tidak ada yang bisa memberi tahu Anda mana perbaikan bug dan perubahan yang digabungkan sejak garpu (karena pola pikir yang sama yang membuat orang tergelincir ke dalam praktik seperti itu membuatnya tidak mungkin bahwa mereka menyimpan catatan tentang perubahan yang mereka lakukan). Versi bersih sudah usang, versi kotor masih berfungsi, jadi apa yang terjadi? Versi bersih dibuang, naysays terbukti benar.

Selain yang sudah jelas Temukan pekerjaan baru, saya kira jawabannya lebih dari semuanya di atas.

Pertama pergi ke manajemen untuk membawa mereka ke papan dengan pindah ke dan menegakkan penggunaan kontrol sumber. Kemudian lakukan apa yang perlu dilakukan untuk menjaga hal-hal berjalan, bahkan jika itu berarti bekerja secara langsung di server. Mulai proses untuk mendapatkan semuanya dalam kendali sumber.

Pilihan lain adalah memastikan yang terbaru ada di server (yang harus Anda lakukan terlepas) dan memulai repositori baru sekaligus dari yang terbaru. Anda akan kehilangan sejarah, tetapi pada titik ini adalah kentang kecil.

Tampaknya dari uraian Anda bahwa ada satu atau lebih masalah dengan situasi tersebut - apakah tim pengembang tidak terkendali atau solusi kontrol sumber yang buruk telah diterapkan. Either way, adalah tugas tim dev untuk menggunakan beberapa solusi kontrol sumber - langsung memodifikasi kode sumber pada layanan produksi hanya memohon agar masalah terjadi.

Dari pengalaman saya, langkah pertama yang harus dilakukan segera adalah menyinkronkan kontrol sumber dengan server produksi. Langkah ini bisa sesederhana mengambil salinan kode produksi dan memeriksanya - kode prod mungkin merupakan basis yang dikembangkan tim Anda. Langkah ini mungkin perlu ditambah dengan penggabungan dengan kode yang mengambang di dalam sistem kontrol sumber yang ada. Kode harus mengalir dari dev ke integrasi / QA (atau keduanya), dan kemudian ke tahap atau tahap / produksi.

Selanjutnya, manajemen perlu mengamanatkan penggunaan kontrol sumber. Sederhananya, jika build tidak berasal dari sistem kontrol sumber, kode tidak boleh digunakan untuk produksi. Akses produksi perlu dibatasi hanya untuk tim pendukung saja, dengan akses terbatas diberikan kepada pengembang untuk memecahkan masalah produksi. Pengembang umumnya tidak boleh melakukan penyebaran kode panas ke produksi - masalah produksi pasti bisa terjadi, terutama jika pengembang berada di bawah tekanan.

Manajemen jelas perlu mendapatkan penanganan yang lebih baik tentang masalah-masalah di sini - hampir tidak mungkin untuk mempertahankan pengembangan jika kode diterapkan ke prod secara langsung (dan tidak masuk ke kontrol sumber).

Masalah sebenarnya bukanlah coders koboi tidak menggunakan kontrol versi. Masalah sebenarnya adalah bahwa mereka telah memilih beberapa cara untuk melakukan sesuatu, dan Anda mencoba mengubah proses mereka. Proses yang dipilih tidak termasuk kontrol versi. Semua perubahan proses sulit, kecuali jika programmer sendiri melihat adanya masalah. Jika ada perasaan bahwa sistem yang ada cukup baik, mencoba memaksakan beberapa sistem yang berbeda hanya sia-sia. Kami adalah borg, Anda akan berasimilasi. Tentu saja mereka berusaha berjuang menjadi borg.

Untuk kewarasan Anda sendiri, saya sarankan menyiapkan Git atau DVCS lain di mesin Anda sendiri sehingga Anda dapat melacak perubahan. Impor perubahan rekan kerja Anda ke dalam repositori Anda sesering mungkin. Selesaikan konflik sebaik mungkin. Ini sebagian akan melindungi Anda dari kegilaan rekan kerja Anda.

Anda telah menyebutkan bahwa manajemen telah mengatakan bahwa pengembang harus menggunakan kontrol sumber. Jika Anda ingin menjadi jahat, Anda bisa memberlakukan ini dengan memeriksa perubahan ke TFS dan menerbitkan repositori secara berkala, sehingga menghambat setiap perubahan yang tidak ada di TFS. (Jika Anda juga mempertahankan DVCS Anda sendiri, Anda harus tetap menyinkronkan keduanya.) Pembenaran Anda untuk melakukannya adalah Anda mengikuti perintah dari manajemen. Jika rekan kerja Anda bosan ditimpa perubahannya, undang mereka untuk menggunakan TFS. Dan tetap lakukan perubahan yang tidak diinginkan yang belum diperiksa. Lanjutkan sampai rekan kerja Anda mengalah atau Anda dipecat.

Kunci semua server selain dari pengembangannya. Gunakan manajer konfigurasi. Lakukan build yang dapat diidentifikasi secara teratur (terhadap tag). Tag setiap set perubahan (yaitu 1 set perubahan per bug). Kami juga memberi tag pada setiap bangunan. Memiliki sistem tipe QA antara dev dan produksi (minimal). Lakukan build ke sistem QA menggunakan tag build yang benar. Beri mereka kesedihan karena "menghancurkan bangunan".

Saya tidak pernah mengalami situasi di mana saya tidak dapat membuat kembali / memperbaiki masalah (yang hanya terlihat pada produksi). Ya, saya telah menghabiskan berjam-jam mendapatkan masalah untuk diciptakan kembali pada sistem pengembangan (ditambah ketika Anda mengetahuinya, Anda dapat menambahkannya ke tes regresi Anda).

Kami melakukan proyek dengan sekelompok kontraktor koboi yang melakukan semua hal buruk itu. Saya menghabiskan 4 minggu membersihkan setelah itu dan kemudian menempatkan praktik di atas. Proyek itu tidak memiliki masalah dengan hal-hal itu sejak saat itu.

Mengutip:

Tim tidak terbiasa menggunakan TFS

TFS ternyata adalah Microsoft Team Foundation Server.

Insting pertama saya mengatakan: "ini adalah rilis terbaru dari Microsoft Visual SourceSafe"

Saya akan berada di sisi Anda rekan kerja dan benar-benar menentang ini.