Bagaimana mendorong adopsi kontrol versi


21

Saya baru-baru ini mulai bekerja di tim di mana tidak ada kontrol versi. Sebagian besar anggota tim tidak terbiasa dengan kontrol versi apa pun. Saya telah menggunakan lincah secara pribadi untuk melacak pekerjaan saya. Saya ingin mendorong orang lain untuk menerapkannya, dan setidaknya mulai versi kode mereka saat mereka mengembangkan perubahan. Adakah yang bisa memberi saya saran tentang bagaimana saya dapat mendorong adopsi kontrol versi terdistribusi seperti lincah. Setiap saran tentang bagaimana memenangkan orang termasuk manajer untuk DVCS akan sangat dihargai.


4
Saya akan menambahkan jawaban, tetapi saya tidak bisa. Saya tidak bisa berkata-kata (atau lebih tepatnya, tidak mengetik). Sudah hampir 40 tahun sejak SCCS pertama kali muncul. Apakah masih ada organisasi di luar sana yang tidak menggunakan kontrol versi untuk apa pun kecuali proyek yang paling sederhana? (Sekarang ini adalah ekstrim lainnya; beberapa orang memiliki direktori home sebagai repositori git.)
David Hammen

11
Jangan mendorongnya; menuntutnya.
Steven Evers

1
Perusahaan tempat saya bekerja sekarang berkonsultasi dengan perusahaan-perusahaan yang jauh lebih besar dari kita dan saya belum menemukan perusahaan yang menggunakan kontrol sumber ... Setelah memikirkan pernyataan itu, tiba-tiba saya dapat melihat mengapa mereka membutuhkan orang lain untuk memperbaiki masalah mereka. Hal pertama yang kita lakukan biasanya adalah meminta mereka mengaturnya sehingga kita dapat menggunakannya untuk mengintegrasikan dan mengelola perubahan mereka dan perubahan kita. Seperti @SnOrfus nyatakan, minta itu. Anda dapat menunjuk ke semua dokumentasi yang mencatatnya sebagai praktik terbaik juga.
Joshua Dale

7
Saya dengan SnOrfus. Ada beberapa jawaban yang baik di sini, tapi pada akhirnya, jika Anda tidak mendapatkan reaksi positif segera , waktu itu untuk pergi. Seperti David Hammen, saya tidak dapat berkata apa-apa bahwa pada tahun 2011 setiap pengembang berada dalam situasi di mana mereka perlu menangani masalah seperti ini. Kurangnya kontrol versi adalah disfungsi yang tidak dapat diterima.
Carson63000

2
Menyelinap dalam satu malam dan menghapus hard drive mereka. Tidak, maaf Selang profesionalisme sementara di sana.
DJClayworth

Jawaban:


7

Anda perlu membuat kasus untuk penggunaan kontrol versi, dan pertama-tama mencoba menjualnya kepada rekan kerja Anda, dan jika itu gagal, naik rantai ke kepemimpinan proyek dan lebih tinggi.

Untuk sesama insinyur perangkat lunak, kasus Anda harus difokuskan pada bagaimana menghemat waktu dan sakit kepala dalam jangka panjang. Temukan waktu dari masa lalu Anda sendiri, atau cerita yang diterbitkan (blog, artikel di majalah, buku putih) tentang bagaimana penggunaan kontrol versi membuat hidup Anda lebih mudah. Jika Anda dibakar dengan tidak memiliki kontrol versi, buat itu menjadi pribadi. Jika rekan pengembang Anda berada dalam situasi yang sama, mereka harus melihat cahaya dan bagaimana alat ini dapat membantu mereka.

Ini adalah taruhan terbaik Anda. Walaupun saya tidak dapat menemukan sumbernya saat ini, saya telah membaca (di beberapa tempat) bahwa perubahan paling efektif untuk proses berasal dari pengembang, yang harus berurusan dengan perubahan. Jika Anda bisa mendapatkan pengembang, Anda mencapai dua hal. Pertama, Anda telah menerima dukungan dari orang-orang yang akan terkena dampak perubahan proses. Kedua, ada sekelompok orang untuk meyakinkan manajemen bahwa ini adalah upaya yang bermanfaat dan akan meningkatkan produk dan proyek.

Namun, jika Anda tidak bisa mendapatkan dukungan dari tim pengembangan dan Anda masih merasa sangat kuat tentang penerapan kontrol versi, maka Anda dapat naik ke manajemen. Tetapi menjadi lebih berisiko jika Anda bersolo karier, karena Anda tidak hanya harus khawatir tentang menjual peningkatan, tetapi juga menghadapi serangan balik dari kolega Anda.

Untuk proyek, program, dan manajemen organisasi, kasusnya harus pada bagaimana menyebarkan kontrol versi dapat menghemat waktu dan uang organisasi. Orang-orang di tingkat ini peduli tentang berapa banyak biaya yang dikeluarkan proyek, di mana ia berdiri dibandingkan dengan perkiraan, dan seterusnya. Cari kertas putih, buku, artikel, dan dokumen dan publikasi profesional lainnya yang menjelaskan bagaimana menggunakan kontrol versi telah menghemat waktu dan uang organisasi lain dalam jangka panjang. Anda juga dapat memperkenalkan perspektif kualitas di sini, jika organisasi Anda tertarik dengan kualitas perangkat lunak.

Anda secara khusus menyebutkan bahwa Anda ingin menggunakan sistem kontrol versi terdistribusi. Jangan memaksakan itu di tenggorokan tim atau organisasi. Perkenalkan mereka ke kontrol versi dan opsinya. Meskipun Anda secara pribadi mungkin lebih suka menggunakan DVCS (seperti Mercurial), itu mungkin bukan yang terbaik untuk tim dan organisasi Anda. Menggunakan alat yang keliru hanya akan memperburuk masalah dengan meronta-ronta.

Juga, waspadai risiko proses pengenalan yang terlambat . Meskipun penggunaan kontrol versi adalah praktik terbaik yang diterima secara umum, mungkin sudah terlambat untuk memperkenalkannya secara efektif pada proyek saat ini tanpa risiko besar untuk penyelesaian proyek. Sebaliknya, saya akan merekomendasikan fokus pada peningkatan status quo untuk proyek dan tim masa depan.

Juga, ini adalah pendekatan umum yang dapat Anda ikuti untuk melakukan setiap proses atau peningkatan teknologi.


5

Pertanyaan pertama adalah: apa yang mereka lakukan saat ini? Tentunya setiap pengembang tidak memiliki kode sumber yang tersangkut di kotaknya sendiri yang ia ubah sesuka hati. Setelah Anda memiliki proses yang saat ini mereka ikuti, Anda dapat menyarankan beberapa alat yang meningkatkan proses ini - biasanya SCM sangat ideal untuk membantu mereka dalam hal ini, daripada membuat mereka mengikuti proses yang berbeda.

Poin utama di sini adalah, jika mereka memiliki cara kerja semu-SCM, mungkin menyimpan versi saat ini di server di suatu tempat, maka Anda perlu menentukan apakah DVCS atau CVS lebih tepat, jangan mencoba untuk menjualnya Mercurial jika SVN lebih cocok.


3

Cara tercepat adalah meyakinkan manajemen bahwa itu diperlukan.

Lakukan beberapa perhitungan:

Biaya perangkat lunak kontrol versi - gratis.
Biaya perangkat keras untuk mendukung repositori - satu server.
Biaya penerapan perangkat lunak - beberapa hari kerja untuk tim kecil, naik untuk tim yang lebih besar.

Biaya tidak menerapkan kontrol versi:

Kasus terbaik - hari hilang karena penyuntingan hilang, menimpa satu sama lain berubah dll, bug berulang dan sebagainya.
Kasus terburuk - namun bertahun-tahun upaya tim Anda telah menghabiskan sejauh ini.

Angka terakhir ini adalah skenario terburuk dari Anda kehilangan semua pekerjaan Anda karena kegagalan server dll. Tetapi bahkan skenario "kasus terbaik" harus membawa pulang kepada mereka mengapa itu diperlukan. Biaya bug berulang bisa lebih besar karena dapat menyebabkan kehilangan pelanggan.

Tim pengembang juga harus memahami biaya-biaya ini dan mengingat bahwa sebagian besar (jika tidak semua) perangkat lunak kontrol versi terintegrasi secara mulus dengan IDE hari ini, mereka bahkan tidak akan menyadari bahwa ada sebagian besar waktu di sana.


Biaya perangkat lunak kontrol versi tidak gratis. Perangkat lunak itu sendiri mungkin gratis (tergantung pada pilihan Anda), tetapi dalam suatu organisasi yang tidak memiliki apa-apa, Anda perlu pelatihan untuk para insinyur, Anda mungkin memerlukan perangkat keras untuk tempat tinggal, dan jika organisasi memberikannya kepada semua orang, peningkatan pendanaan TI untuk mendukung persyaratan perangkat keras dan perangkat lunak yang baru. Belum lagi risiko tinggi proses penggelaran di akhir proyek.
Thomas Owens

@ Thomas - maka baris saya tentang biaya pelaksanaannya (yang mungkin meremehkan)
ChrisF

Hasil edit membuatnya jauh lebih baik.
Thomas Owens

1

Manajemen biasanya sangat peduli tentang menghemat uang. Tekankan bagaimana kontrol versi dapat menguntungkan tim secara finansial dan Anda akan segera mendapatkan perhatian mereka!


Manajemen memang demikian, tetapi selalu lebih mudah untuk mendapatkan perhatian manajemen jika Anda memiliki sekelompok orang yang mengatakan sesuatu, daripada seorang individu.
Thomas Owens

@Thomas memang, lebih banyak suara membuat lebih banyak suara dan dengan demikian lebih mungkin untuk mendapatkan manajemen perhatian
rrazd

1

Ada satu aspek yang belum disentuh orang lain di sini yang menurut saya sudah Anda miliki - Anda berbicara tentang kontrol versi terdistribusi - pada dasarnya, Anda dapat menyelinapnya ke dalam praktik de facto, satu pengembang pada suatu waktu. Dengan kontrol versi yang lebih rumit, seperti apa yang kami gunakan di kantor saya (MS Visual SourceSafe), Anda akan kesulitan untuk naik ke orang di kubus di seberang tambang dan menjualnya, satu-satu pada manfaat dari kontrol versi. Namun, dengan (apa saja) DVCS, Anda bisa mengatakan "hei, coba ini, dan lihat apakah Anda suka. Saya akan tunjukkan tali, dan saya akan dengan senang hati menjawab pertanyaan, menuntun Anda, blah blah bla ". Dengan begitu, Anda tidak perlu "proses" dari bawah ke atas, Anda dapat membangun mandat akar rumput, satu orang pada satu waktu.


0

Membangun jawaban gbjbaanb.

Kuncinya di sini adalah Anda harus menyesuaikan proses kontrol versi dengan proses apa pun yang ada dan menunjukkan bagaimana ia menyimpan sisa upaya tim.

Saya pribadi menyukai Mercurial juga, tetapi saya tidak akan ingin mengibarkannya pada orang-orang yang tidak terbiasa dengan kontrol versi karena sedikit lebih sulit untuk dipahami daripada sistem kontrol versi versi penguncian server kuno. Yang mengatakan jika itu adalah situs greenfields yang sebenarnya mungkin lebih baik untuk pergi seluruh babi, lewati tahun '80 -an & '90 -an dan pergi dengan Mercurial. Saya juga akan melihat beberapa hal siklus hidup perangkat lunak pihak ke-3 yang dibangun di sekitar Mercurial - saya yakin ada satu tapi namanya luput dari saya;)

Saya menduga Anda bekerja untuk sebuah perusahaan kecil & bahwa Anda relatif baru di tim sehingga mungkin sulit menjual - terutama jika anggota tim lainnya sudah berakar dan memiliki kepercayaan manajemen. Mungkin lebih baik membiarkan mereka memasukkan sesuatu dengan buruk lalu datang untuk menyelamatkan. Itu tidak berarti sabotase, tunggu saja yang tak terhindarkan.


Terima kasih atas semua tanggapan Anda, dapatkah pertanyaan ini dijadikan pertanyaan komunitas? Kekuatan yang memungkinkan saya untuk berbicara singkat / demo 15 menit tentang bagaimana saya telah menggunakannya. Satu rintangan adalah siapa yang menggunakannya? Apakah itu shareware / bloatware dari internet? Saya ingin menenangkan ketakutan dengan menunjuk beberapa perusahaan terkenal yang menggunakan / mendukung Mercurial (DCVS) secara komersial. Adakah yang bisa membantu saya mengutip beberapa perusahaan yang menggunakan Hg? Atau produk terkenal lainnya yang menggunakannya. Ada resistensi (mata tak terucapkan melirik) ke open-source, beberapa manajer tampaknya curiga terhadap perangkat lunak yang tidak mereka bayar.
Man Wa kileleshwa
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.