Bagaimana meyakinkan rekan satu tim, yang memandang diri sendiri sebagai senior, untuk mempelajari dasar-dasar konseptual SVN? [Tutup]

Untuk memulai dengan latar belakang tertentu, saya mengambil posisi pengembang baru musim panas ini dan akhirnya menjadi anggota terbaru di tim, namun dengan sebagian besar pengalaman di bawah ikat pinggang.

Sejauh ini saya telah berhasil mendorong inisiatif kewarasan melalui cukup mudah karena biaya adopsi yang rendah (dalam hal waktu dan usaha). Namun semuanya naik sedikit.

Salah satu rekan tim saya, meskipun berpengalaman, tidak benar-benar mengerti SVN. Secara alami, area kosong pada peta mentalnya yang menggambarkan lautan SVN menyebabkan dia mengadopsi pola penggunaan yang agak aneh.

Misalnya, ia telah menyatakan kebijakan "1 SVN komit per hari per pengembang" karena jika tidak, "server akan segera kehabisan ruang disk". Ketika saya menjelaskan kepadanya bahwa komitmen SVN adalah delta, bukan salinan lengkap, dia menjawab dengan keraguan dan bahkan hari ini saya tidak sepenuhnya yakin apakah dia mengerti apa artinya.

Kami juga memiliki argumen panas tentang apakah akan memasukkan .projectkonfigurasi Eclipse di SVN. Rekan satu tim saya bersikeras bahwa kita harus melakukannya, walaupun itu telah menyebabkan banyak konflik yang tidak berguna. Saya menentang menjaga file konfigurasi pengembang individual di SVN. Akhirnya, ternyata rekan tim saya memiliki praktik checkout ulang seluruh pohon sumber setelah setiap komitmen untuk memastikan "kode yang dikomit ke dalam karya repositori". Itulah alasan dia sangat bersikeras dalam menjaga konfigurasi proyek di SVN - jadi akan mudah untuk mengimpor kembali proyek. Ketika saya menjelaskan bahwa komit menyinkronkan copy pekerjaan ke byte-demi-byte jarak jauh yang membuat checkout kembali tidak perlu, rekan tim saya menjawab dengan keraguan lagi dan akhirnya melambaikan seluruh masalah sebagai tidak signifikan.

Menurut pendapat saya, tim kami membuang-buang waktu dengan menyelesaikan konflik SVN dalam file konfigurasi proyek yang hanya berisi pengaturan khusus pengembang yang tidak perlu dibagi ke SCM sama sekali. Semua ini berantakan karena seseorang menyesuaikan proses dengan asumsi yang salah.

Bagaimana saya bisa meyakinkan teman satu tim, yang melihat diri sendiri sebagai senior, untuk mendapatkan pemahaman yang lebih baik tentang dasar-dasar SVN?

IMO yang terbaik adalah memisahkan masalah-masalah yang menyebabkan masalah / kerusakan langsung pada proyek dari yang hanya mempengaruhi pengembang tunggal itu . Misal, jika dia lebih suka checkout semuanya beberapa kali sehari, itu akan memperlambatnya, tetapi sebaliknya tidak akan mempengaruhi orang lain. Jadi Anda bisa membiarkannya melakukan itu (sampai ada kelambatan kinerja yang terlihat dalam karyanya), dan menyelamatkan diri Anda dari kesulitan memperdebatkannya.

Masalah lain yang Anda sebutkan, seperti menyimpan .projectfile Eclipse di repo, atau 1 komit per hari, adalah di mana Anda harus fokus, untuk memungkinkan tim berkembang semulus mungkin. Pertama-tama, Anda harus meminta / mengumpulkan umpan balik dari anggota tim lain , apakah ini juga menimbulkan masalah bagi mereka. Jika ada yang lain, bersama-sama Anda dapat melakukan lebih banyak tekanan , dan jika perlu, Anda dapat dengan mudah meningkatkan masalah ke arah manajemen.

Mengenai "SVN kehabisan ruang disk", akan mudah untuk menyangkal keyakinannya dengan melakukan percobaan (berpotensi dalam repo tes terpisah). Anda hanya perlu memantau ukuran hierarki file repo fisik sebelum dan sesudah melakukan perubahan menjadi satu file teks besar, atau bahkan banyak file. Jika itu tidak meyakinkannya, tidak ada yang bisa.

Dalam hal itu, sayangnya Anda mungkin memiliki masalah otoritas, di mana orang lain melihat menerima nasihat dari seseorang "di bawah pangkat" sebagai kehilangan martabatnya. Konflik semacam itu tidak dapat diselesaikan dengan argumen logis. Anda perlu meningkatkannya ke manajemen, tetapi hati-hati untuk memastikan Anda memiliki dukungan yang cukup (dari rekan tim dan / atau manajemen) sebelum melakukannya. Langkah seperti itu mungkin dianggap oleh orang lain sebagai serangan terbuka, sehingga dapat memiliki konsekuensi yang bermasalah (untuk Anda, dan / atau kedamaian seluruh tim). Jadi pikirkan tiga kali, dan diskusikan dengan kolega Anda yang mendukung sebelum Anda mengambil langkah itu.

Jika perusahaan Anda menggunakan wiki, tulis beberapa posting berkualitas tinggi tentang SVN:

• Mengapa Anda harus menggunakannya?
• Kapan sebaiknya Anda menggunakannya?
• Masalah apa yang dipecahkan?

dll.

Ini akan menarik perhatian CTO, dan semua orang yang menolak untuk menggunakannya harus menggunakan :)

Sebagai pemimpin, manajer, dan anggota tim, saya harus berurusan dengan penyelesaian konflik profesional dan kepribadian di berbagai tingkatan. Tidak peduli peran apa yang saya pekerjakan, saya biasanya diterima sebagai pemimpin bahkan ketika saya tidak menginginkan peran itu. Alasan untuk ini adalah cara saya menangani konflik ini.

Tidak seperti banyak orang di sini, saya tidak setuju bahwa berurusan dengan situasi ini adalah "menyerah" atau "menunjukkan kepadanya alat baru" atau "menunggu dia jatuh di pantat atau lecetnya". Yang paling penting, tidak pernah merupakan ide yang baik untuk menunggu sampai peran lebih tegas ditentukan. Peran-peran itu didefinisikan oleh orang-orang yang tidak menunggu, dengan keyakinan, etika, dan kemampuan mereka untuk menghadapi situasi kritis apakah mereka melibatkan orang atau tidak.

Ada beberapa metode untuk menghadapi tipe orang yang Anda gambarkan dalam situasi ini. Langkah pertama dan terpenting adalah untuk menyelidiki mengapa ia berperilaku seperti itu. Ini tidak ada hubungannya dengan apa yang dia tahu atau tidak tahu. Dia bisa dengan mudah menemukan informasi ini sebelumnya, jadi pertanyaannya adalah satu dari dua hal: "Kenapa tidak?" atau "Mengapa dia menolak informasi yang diberikan kepadanya?" Ini akan membantu Anda menemukan apa yang sebenarnya perlu ditangani.

Dalam pengalaman saya, programmer (termasuk saya) menolak praktik baik atau alat baru hanya karena beberapa alasan:

• Sumber tidak dapat dipercaya. Dalam sebuah industri yang semakin terpolarisasi setiap hari antara "pemujaan Mac" dan "pemuja MS"; antara "Ideologi Sumber Terbuka" dan "Praktis Kepemilikan" ... dll. - Ada banyak yang selalu ragu tentang informasi yang diberikan dan potensi korupsi yang disebabkan oleh bias pihak pengirim atau penulis, bahkan ketika informasi tersebut diverifikasi sebagai kredibel.
• Pengalaman Buruk yang Berkepanjangan ... dengan teknologi atau praktik yang sama atau bahkan sama. Tidak ada yang sempurna saat dimulai, dan banyak yang memulai dengan kurang dari 1/4 fitur daripada akhirnya. Sangat mungkin bahwa dia memiliki waktu berjam-jam atau berhari-hari atau bahkan berminggu-minggu untuk bekerja dengan produk yang lebih rendah atau yang sama selama fase implementasi yang buruk.
• Sumber "Kredibel" ... bertentangan dengan informasi yang disajikan. Dengan "kredibel", maksud saya adalah seseorang atau entitas yang dia percayai. Banyak orang cenderung mengangkat orang yang kita percayai ke level yang tidak mewakili kenyataan. Sumber ini bahkan tidak harus memaksakan kepercayaan ini pada orang tersebut. Paling sering, kita melakukannya sendiri. Itu sering memberi kita sesuatu atau seseorang untuk dicita-citakan, setidaknya dalam satu aspek.
• Kurangnya keamanan Ini disorot oleh poster sebelumnya. Program kami menjadi aset sejak kami mulai mengerjakannya. Bukan hanya untuk perusahaan tempat kita bekerja, tetapi untuk orang-orang yang bekerja dengan kita. Ini bukan hanya masalah kontrol. Beberapa dari kita ingin dapat menunjukkan hal-hal yang rapi kepada orang yang kita sayangi. Beberapa dari kita ingin memastikan bahwa itu tidak dirugikan oleh orang atau produk luar. Bagi sebagian orang, ini merupakan perpanjangan dari bagaimana kita berpikir dan merasakan, bahkan. Ini menampung beberapa filosofi dan ideologi kami dan memperlihatkan inti intelektual kami. Bagi banyak orang, ini adalah masa depan kita, apakah itu untuk kelas, majikan, atau klien. Bagi sebagian orang itu semua. "Keamanan" dalam pengertian ini tidak berlaku untuk data, tentu, atau kode.

Mencari tahu faktor mana yang sering kali cukup mudah. Bawa orang itu ke tempat netral. Jelaskan kepada orang itu apa yang Anda amati, secara umum. Tanyakan kepada orang itu dengan jujur ​​apa yang menyebabkan perilaku ini. Sekarang, itu tidak selalu berjalan dengan baik, tetapi kebanyakan orang dewasa merespons dengan cukup baik ketika Anda tampaknya ingin membantu seseorang yang tampaknya bertindak tidak rasional. Kemungkinannya dia tidak bertindak irasional, tetapi tidak menyadari bahwa tidak ada yang bisa mengerti apa yang sebenarnya terjadi.

Setelah Anda mengetahui apa masalahnya sebenarnya, Anda dapat melengkapi diri Anda dengan alat yang tepat untuk mengatasinya. Jika ini adalah skenario # 1, dorong dia untuk melakukan penelitian dari sumber yang dia percayai dan (ini penting)kembali kepada Anda dengan temuannya sendiri. Ini akan memberitahunya bahwa informasinya sendiri memiliki nilai bagi Anda. Dalam kasus skenario # 2, berikan perbandingan yang akurat untuk apa yang berbeda sekarang daripada sebelumnya. Dorong dia untuk mencobanya, tetapi miliki rencana cadangan jika itu salah. Untuk skenario # 3, katakan padanya untuk meminta kembali sumbernya dengan informasi ANDA. Peluangnya adalah sumbernya tidak berpegang pada pandangan yang dia pikir dia lakukan, tetapi melakukannya pada satu waktu. Sebagian besar dari kita beradaptasi dari waktu ke waktu, jadi sudut pandangnya mungkin telah berubah. Jika dia tidak mau, dorong dia untuk memperkenalkan Anda dengan sumbernya. Dan akhirnya, untuk skenario # 4, yakinkan dia bahwa kekhawatirannya adalah Anda sendiri. (Mereka harus pada tingkat tertentu) Tunjukkan bagaimana alat "baru" ini dapat melindungi kepentingannya dan meningkatkan keamanannya. Dan jika tidak bisa,

Saya tahu semua ini terdengar terlalu sederhana untuk dikerjakan, tetapi kadang-kadang memang begitu. Bahkan, semakin tulus Anda, semakin sering hal itu terjadi. Dengan menjawab kebutuhannya, Anda menjawab kebutuhan tim, apakah ia seorang "senior" atau tidak, karena ia adalah bagian dari tim. Menunjukkan kepadanya bahwa Anda ingin berada di halaman yang sama dengannya, tetapi sebenarnya tidak, mungkin mendorongnya untuk mulai bekerja sama dengan Anda. Jika Anda telah melakukan semua ini, dan masih belum mencapai resolusi, maka Anda telah melakukan semua yang dapat Anda lakukan dengan berbicara dengan pemimpin tim.

Logika Fuzzical

Ada banyak takhayul di sekitar kontrol sumber. Ini kontra-intuitif, matematika itu misterius, dan itu melibatkan satu-satunya aset terpenting yang dimiliki perusahaan perangkat lunak. Saya harus mengakui ada bagian dari diri saya yang masih tidak percaya. Tetapi saya tidak akan melakukannya tanpa itu selama satu menit.

Salah satu solusi mungkin menawarkan untuk mengambil alih tanggung jawab untuk mengurus repo. Tentu saja, jika Anda menyajikannya sebagai "ini banyak pekerjaan untuk Anda, dan ini kebetulan merupakan area di mana saya memiliki pengalaman", daripada "Anda tidak tahu apa yang Anda lakukan" yang akan memiliki kesempatan kerja yang lebih baik.

Jika "melihat dirinya sebagai senior" berarti apa yang saya pikirkan, dia tidak akan melepaskannya karena dia melihatnya sebagai sumber otoritas dan kontrol. Jadi solusinya bagi Anda mungkin menggunakan Git secara lokal untuk mengelola unit dan cabang komit yang waras, kemudian cukup mendorong untuk svn sekali sehari seperti yang ia minta. Git dirancang sebagai sistem peer-to-peer dan memiliki salinan repo penuh pada setiap mesin lokal. Anda dapat menawarkan git kepada pengembang lain yang lebih suka melakukannya dengan cara itu, dan itu bisa tetap menjadi pelengkap bagi SVN yang digunakan oleh masing-masing kelompok kerja (baik satu atau lebih pengembang, formal atau ad-hoc) secara internal. Dan ketika saatnya tiba bahwa pria senior mengalah, pindah ke departemen atau perusahaan lain, atau mengecat dirinya sendiri ke sudut yang tidak dapat dipulihkan dengan kebijakan SVN-nya, Anda harus mulai membersihkan semuanya.

Bicara saja dengan mereka. Dengar, aku pengembang senior, tapi ada hal-hal yang aku tidak tahu. Itulah sifat bisnisnya. Jika mereka menjadi defensif atau agresif itu masalah kepribadian dengan pengembang dalam kasus dan yang harus ditangani oleh pemimpin tim, atau jika mereka adalah pemimpin tim, oleh bos mereka.

Mulailah inisiatif tas coklat, sekali beberapa minggu seseorang mengadakan pembicaraan makan siang tentang sesuatu yang mereka ketahui dan menyajikannya kepada yang lain.

Anda menggunakan ini sebagai alasan untuk menyajikan SVN secara terperinci dan mungkin beberapa pemikiran di balik beberapa alternatif.

Beberapa minggu kemudian orang lain dapat mencobanya.

Saya akan mencoba memberi Anda beberapa petunjuk yang didukung oleh pengalaman pribadi saya.

Salah satu rekan tim saya, meskipun berpengalaman, tidak benar-benar mengerti SVN. Secara alami, area kosong pada peta mentalnya yang menggambarkan lautan SVN menyebabkan dia mengadopsi pola penggunaan yang agak aneh.

Misalnya, ia telah menyatakan kebijakan "1 SVN komit per hari per pengembang" karena jika tidak, "server akan segera kehabisan ruang disk". Ketika saya menjelaskan kepadanya bahwa komitmen SVN adalah delta, bukan salinan lengkap, dia menjawab dengan keraguan dan bahkan hari ini saya tidak sepenuhnya yakin apakah dia mengerti apa artinya.

Bahkan jika ruang disk adalah masalah, Anda selalu dapat melakukan banyak file sekaligus, jadi saya pikir apa yang ia sarankan adalah solusi yang salah. Lebih lanjut, adalah mungkin untuk membuang banyak ruang dengan memeriksa file biner besar karena SVN tidak menyimpan delta untuk file biner. Satu kali check-in per hari juga buruk karena memaksa Anda untuk melakukan perubahan yang tidak termasuk bersama, misalnya jika Anda memperbaiki lebih dari satu bug per hari.

Solusi yang kami adopsi di perusahaan kami adalah ada filter yang menolak komit yang berisi file biner. Kami dapat memaksa komit dengan menggunakan kata kunci khusus di komentar check-in (kami harus menunjukkan kepada SVN bahwa kami tahu apa yang kami lakukan). Sekali dalam satu atau dua tahun manajer proyek mengarsipkan cabang-cabang lama dan memindahkannya dari repositori. Dengan strategi ini kami tidak memiliki masalah ruang yang saya tahu (repositori kami mendukung beberapa proyek berbeda dan memiliki lebih dari 100.000 revisi).

Meringkas, Anda bisa memberi tahu dia bahwa Anda setuju dengannya bahwa ruang disk adalah masalah penting tetapi, di sisi lain, tunjukkan

1. pentingnya check-in terkait fitur daripada satu check-in harian monolitik;
2. fakta bahwa dengan memeriksa dalam satu file biner besar per hari, orang tetap dapat mengisi disk.

Kemudian Anda dapat menyarankan agar Anda mengadakan pertemuan (mungkin dengan pengembang lain atau administrator sistem juga) untuk membahas strategi untuk menjaga penggunaan ruang disk di bawah kendali (mis. Filter file biner, cadangan reguler, dan membersihkan cabang lama yang tidak digunakan).

Kami juga memiliki argumen panas tentang apakah akan memasukkan konfigurasi Eclipse .project di SVN. Rekan satu tim saya bersikeras bahwa kita harus melakukannya, walaupun itu telah menyebabkan banyak konflik yang tidak berguna. Saya menentang menjaga file konfigurasi pengembang individual di SVN. Akhirnya, ternyata rekan tim saya memiliki praktik checkout ulang seluruh pohon sumber setelah setiap komitmen untuk memastikan "kode yang dikomit ke dalam karya repositori". Itulah alasan dia sangat bersikeras dalam menjaga konfigurasi proyek di SVN - jadi akan mudah untuk mengimpor kembali proyek. Ketika saya menjelaskan bahwa komit menyinkronkan copy pekerjaan ke byte-demi-byte jarak jauh yang membuat checkout kembali tidak perlu, rekan tim saya menjawab dengan keraguan lagi dan akhirnya melambaikan seluruh masalah sebagai tidak signifikan.

Menurut pendapat saya, tim kami membuang-buang waktu dengan menyelesaikan konflik SVN dalam file konfigurasi proyek yang hanya berisi pengaturan khusus pengembang yang tidak perlu dibagi ke SCM sama sekali. Semua ini berantakan karena seseorang menyesuaikan proses dengan asumsi yang salah.

Apakah Anda menggunakan server build? Kami memiliki server build yang memeriksa proyek lengkap dan mengkompilasinya setiap malam. Pagi berikutnya, penguji memiliki penginstal produk yang siap uji (jika master build berjalan dengan benar) dan kami (pengembang) memiliki laporan build dengan semua peringatan (dan kesalahan, jika ada). Tentu saja, Anda perlu mengatur file konfigurasi standar untuk server build dan memeriksanya. Setiap pengembang kemudian dapat memeriksanya bersama dengan sisa proyek, tetapi mereka tidak diizinkan untuk memeriksa perubahan lokal apa pun .

Dalam skenario ini Anda mengatasi kebutuhannya untuk dapat memeriksa proyek lengkap dan membangunnya kapan saja. Anda juga menghindari menghabiskan waktu untuk menggabungkan perubahan yang seharusnya tidak diperiksa sejak awal karena itu bukan bagian dari produk: produk adalah master build, dan itu harus dijaga kebersihannya. Jika seseorang merusak master build (mis. Memeriksa sendiri file .projectnya), Anda dapat mengembalikan perubahan atau memaksa pengembang untuk memperbaiki masalah.

Mungkin jika dia mengemukakan masalah lagi, Anda dapat kembali menyarankan untuk mengadakan pertemuan (mungkin dengan pengembang lain) dan menemukan strategi bersama bersama.

Bagaimana saya bisa meyakinkan teman satu tim, yang melihat diri sendiri sebagai senior, untuk mendapatkan pemahaman yang lebih baik tentang dasar-dasar SVN?

Saya pikir strategi terbaik adalah untuk menghindari membawa konflik ke tingkat pribadi dan lebih baik membahas masalah yang ada dan solusi yang mungkin. Jika Anda memiliki kesan bahwa dia mencari konfrontasi pribadi, berikut adalah beberapa saran (dari pengalaman pribadi):

• Bagaimana dinamika tim Anda? Apakah kolega Anda yang lain memiliki pengalaman yang sama dengan rekan setim ini? Ada banyak petunjuk kecil, tidak terlalu eksplisit yang dapat diberikan oleh tim kepada salah satu anggotanya untuk mencegah perilaku tertentu (lelucon kecil atau pengamatan) dan mendorong konfrontasi konstruktif (mengusulkan pertemuan, atau mengangkat topik secara informal saat rehat kopi) ). Terkadang tim yang baik dapat dengan cepat mengisolasi elemen yang mengganggu dan membawa semuanya kembali normal.
• Seberapa baik manajemen personalia Anda? Kami memiliki satu kasus konflik di perusahaan kami dan kepala personel harus turun tangan untuk membersihkan situasi. Itu tidak baik, tetapi kadang-kadang suasana kerja memburuk sehingga tidak akan membaik dengan sendirinya. Saya harap ini bukan kasus Anda (saya tidak memiliki kesan itu sudah sejauh ini) tetapi selalu baik untuk mengetahui apakah Anda memiliki administrasi kepegawaian yang baik atau jika Anda harus menyelesaikan konflik sendiri.

Mengapa saya menulis ini? Anda mengatakan bahwa Anda ingin "meyakinkan rekan setim, yang menganggap diri Anda sebagai senior, untuk mendapatkan pemahaman yang lebih baik tentang dasar-dasar SVN". Bagi saya itu terdengar seperti konflik mungkin menjadi terlalu pribadi. Beberapa psikolog berpendapat bahwa 70% dari komunikasi kita berada pada level emosional, jika level ini tidak berfungsi, maka orang-orang berhenti berbicara tentang fakta karena mereka terlalu sibuk berurusan dengan emosi.

Jadi, selain menjelaskan poin Anda, Anda juga bisa mencoba melakukan sesuatu untuk meningkatkan komunikasi. Mengundang kopi atau istirahat makan siang bersama, berbincang-bincang singkat tentang topik yang tidak terkait dengan pekerjaan, dll., Dapat meningkatkan komunikasi dan mengembalikan perhatian rekan kerja Anda ke fakta - fakta penting yang Anda ingin dia pahami. Jika dia menerima komunikasi semacam ini, maka mungkin konflik yang Anda miliki sejauh ini terkait dengan fakta bahwa Anda tidak mengenal satu sama lain dengan baik dan ada beberapa kesalahpahaman kecil tetapi dia mungkin terbuka untuk membangun kolaborasi yang konstruktif. Jika dia menolak, maka mungkin ada permusuhan yang lebih dalam di sisinya.

Dalam hal ini, saya pikir Anda harus menunggu sampai peran Anda menjadi lebih jelas. Jika rekan setim Anda tidak secara resmi memiliki peringkat lebih tinggi dari peringkat Anda, ia tidak perlu merasa kesal dengan upaya Anda untuk memperbaiki keadaan. Seiring waktu ia harus menerimanya atau membodohi dirinya sendiri jika terus berusaha menunjukkan bahwa ia lebih tahu. Jika dia memang memiliki peringkat yang lebih tinggi, Anda harus menemukan cara untuk membuatnya mengerti bahwa ini tidak sedang dibahas: pengamatan Anda ditujukan untuk meningkatkan produktivitas dan tidak merusak posisinya, ini harus 100% jelas. Ketika peran telah diklarifikasi, jika dia masih tidak dapat menerima saran atau kritik yang membangun, maka dia benar-benar harus memiliki beberapa masalah dengan harga diri atau sesuatu seperti itu.

Jadi, jika semua strategi di atas gagal dan Anda terus merasa frustrasi, saya khawatir satu-satunya hal yang masuk akal untuk dilakukan adalah mengepak barang-barang Anda dan mencari tempat yang lebih baik. Saya membuat pengalaman ini tiga tahun lalu dan menemukan perusahaan yang jauh lebih baik di mana saya sangat puas sekarang. Mungkin ini bukan kasus Anda (saya harap tidak tentu saja) tetapi cobalah untuk memahami hal ini juga.

Hanya 2 sen saya.

Arahkan dia ke beberapa bahan pembelajaran tentang cara kerja SVN dan apa praktik terbaik saat menggunakan SVN.

Seperti yang dikatakan @Peter - pilih pertempuran Anda dengan hati-hati dan jangan buang energi Anda untuk bertarung dengan seseorang yang jelas tidak mengerti dasar-dasarnya. SVN bukan teknologi mutakhir dan sudah ada di sini untuk sementara waktu sehingga ada cukup informasi tentangnya.

Coba simpan log 'Pemborosan waktu SVN'. Setiap kali ada masalah konflik / checkout / versi yang perlu diselesaikan, catat berapa lama Anda / tim untuk menyelesaikannya. Jika ternyata Anda menyia-nyiakan banyak waktu setiap minggunya, lanjutkan dengan dia dan manajemen. Saya yakin manajemen akan segera meminta solusi jika mereka menyadari produktivitas dapat ditingkatkan dengan perubahan sederhana dalam proses kerja.

Atau cobalah meyakinkan kolega Anda untuk mengadakan minggu percobaan di mana tim menggunakan sistem checkin Anda (jika itu mudah dicapai dengan proyek dan basis kode Anda saat ini). Berjanjilah kepadanya bahwa jika tidak berhasil, Anda dapat beralih kembali ke sistem lama setelah seminggu berakhir. Tapi dia mungkin datang setelah mencobanya sendiri.

1. Biarkan Subversion memecahkan masalah untuk Anda. Cara Anda mengatakannya, rekan kerja Anda relatif tidak canggih dalam hal Subversion. Dalam hal ini, solusi teknis bisa menjadi pilihan yang baik. Jika anggota tim lainnya setuju dan Anda bisa mendapatkan restu manajer Anda, tambahkan global-ignoresbidang ke file konfigurasi repositori sehingga Anda dapat mengecualikan file proyek. Dan yang lain yang tidak Anda inginkan di bawah kontrol versi.

2. Bantu dia keluar. Alih-alih memaksakan cara Anda melakukan sesuatu padanya, cobalah untuk membantu pria itu melakukan sesuatu dengan caranya sendiri tanpa menimbulkan masalah bagi orang lain. Jika rekan kerja Anda bekerja di cabangnya sendiri, Anda seharusnya tidak peduli dengan apa yang dia lakukan. Jika ia ingin mengkomit file proyeknya sehingga ia dapat memeriksa salinan baru seluruh direktori, itu tidak masalah bagi Anda. Satu-satunya hal yang harus Anda perhatikan adalah bahwa ia tidak menggabungkan file proyeknya kembali ke cabang pengembangan umum. Itu harus mudah dikelola, sekali lagi, dengan menyetel properti abaikan pada cabang pengembangan untuk mengecualikan file proyek.

3. Cari dukungan dari atas. Jangan berdebat "Anda bukan bos saya" dengan lelaki itu, tetapi jika perilakunya menyebabkan masalah bagi Anda, pastikan manajer Anda mengetahui situasinya. Jika Anda tidak yakin bagaimana mendekati manajer Anda, cobalah meminta nasihat: "Mike, saya sudah mencoba untuk berbicara dengan Larry, tapi saya tidak berhasil. Ia bersikeras pada X, Y, dan Z, dan kita semua menghabiskan banyak waktu yang tidak perlu untuk mengatasi masalah yang timbul. Bisakah Anda memberi saya petunjuk tentang cara berurusan dengan pria itu? "

4. Abaikan dia. Mengapa ada orang di tim yang mendengarkan orang ini? Apakah dia memiliki otoritas aktual atas proyek tersebut? Siapa yang peduli jika ia mengumumkan kebijakan satu-komitmen-per-pengembang jika ia tidak memiliki kekuatan untuk menegakkannya? Biarkan dia berpikir dia Yertle the Turtle jika itu membuatnya merasa lebih baik, tapi jangan biarkan dia membuat masalah nyata untukmu.

Dapatkan pria dipecat dan dilakukan dengan menyeret tumitnya dan noda jelas terhadap teknologi yang lebih baru. Atau benar-benar meledakkan pikirannya dan mulai menggunakan GIT. Jika dia tidak dapat memahami SVn maka dia pasti akan terpesona oleh GIT.

Anda tampaknya bertempur dalam kekalahan tetapi Anda bisa melakukannya. Machiavelli dalam The Prince menggambarkan betapa sulitnya bagi seseorang untuk mengubah status quo. Saya akan menyarankan membaca bab itu lagi dan kemudian mungkin tidak melakukan apa yang dia sarankan - itu bisa keras.

Anda harus membawa masalah Anda ke pengembang senior secara pribadi dan memastikan Anda mengkritik secara konstruktif cara melakukan sesuatu dan bukan dia atau pengembang lain. Kemudian tawarkan untuk berbicara dan menulis panduan praktik terbaik. Tunjukkan pada mereka bagaimana memahami SVN dengan lebih baik akan membuat hidup mereka lebih mudah. Pada akhirnya, ini semua tentang biaya dan efisiensi. Jika Anda dapat membuktikan bahwa cara Anda memperbaiki keadaan tanpa menginjak kaki maka Anda dapat memenangkan yang ini.

Cobalah untuk memahami mengapa orang senior menggunakan repositori apa adanya. Apa yang menjadi perhatian mereka? Apa yang mereka coba capai? Bagaimana Anda dapat membantu mereka menjadi lebih produktif? Yang terpenting, cobalah untuk tetap menggunakan pendekatan yang tenang dan profesional. Mudah frustrasi. Bersikap asertif: Ketegasan di Tempat Kerja: Panduan Praktis untuk Menangani Situasi Canggung oleh Ken Back dan Kate Back adalah bacaan yang bagus. Akhirnya, pikirkan "bagaimana saya meyakinkan diri saya untuk beralih?". Jadilah advokat iblis yang jujur ​​dan itu dapat membantu Anda mendapatkan jawaban dan pertanyaan yang bagus untuk diajukan.

Sebagai catatan, saya akan berhati-hati untuk menggunakan humor. Ini mungkin bekerja keajaiban atau mungkin membuat Anda terdengar seperti seorang bajingan. Jadi, saya akan menghindarinya.

Pada dasarnya, pilih pertempuran Anda dengan hati-hati karena Anda mungkin tidak memenangkan yang ini. Jika itu masalahnya, jangan pedulikan lagi atau cari pekerjaan yang berbeda. Harsh, saya tahu.

Saya pernah berada di posisi terbalik sekitar 8 tahun yang lalu ketika SVN adalah teknologi yang agak baru. Saya adalah pengembang senior dan diminta / disadap untuk menginstal SVN oleh junior dev (sebenarnya dia lebih akurat mendukung TI daripada dev). Saya mengambil pikiran terbuka meskipun ada kecurigaan awal saya tentang peningkatan beban kerja, kerumitan yang tidak perlu, dll ... dan kemudian menjadi penggemar beratnya.

Dalam pandangan saya, dari apa yang telah Anda jelaskan masalah ini pasti datang ke kepribadian tim - sikap keras kepalanya membuktikan halangan bagi tim secara keseluruhan tentang masalah ini. Anda mungkin lebih baik mundur saja pada saat ini dan membiarkan tekanan dari anggota tim lainnya membangun secara alami untuk memaksa tangannya.

Ini cukup banyak kasus "kurangnya otoritas" dan seseorang yang menerapkan kekuatan ketakutannya sendiri untuk menjaga hal-hal "di bawah kendali"

Untuk mengatasi ini temukan seseorang yang telah menginspirasi rekan setim Anda atau seseorang yang ia hormati dan yang mampu menjelaskan urgensi menggunakan sesuatu seperti SVN. Dengan cara itu rasa takutnya akan perubahan dan pada dasarnya "kehilangan otoritas" tidak berlaku karena bukan anggota tim yang mengatakan kepadanya apa yang harus dilakukan. Saya akan menahan diri untuk tidak menggunakan seseorang seperti manajer untuk berbicara dengan orang ini karena itu hanya menambah tekanan dan bahkan mungkin menciptakan situasi yang lebih menegangkan untuk diri Anda sendiri.

Saya baru-baru ini membaca Mengemudi Perubahan Teknis: Mengapa Orang-Orang di Tim Anda Jangan Bertindak atas Ide-Ide Bagus, dan Bagaimana Meyakinkan Mereka Seharusnya , yang diterbitkan oleh Programmer Pragmatis. Buku ini memberikan latar belakang yang harus Anda ketahui sebelum mencoba memperkenalkan perubahan teknis, sejumlah pola pada orang yang menentang atau menolak untuk berubah, teknik untuk menerapkan perubahan, dan kemudian strategi untuk memaksimalkan penggunaan teknik ini dan semua orang di sekitar kamu.

Berdasarkan pada posting Anda, saya akan mengatakan bahwa rekan setim Anda mungkin jatuh ke dalam pola informasi yang kurang informasi atau sinis, tetapi dia mungkin juga merupakan kasus Irasional. Beberapa teknik yang direkomendasikan untuk melawan tipe orang ini adalah untuk mendapatkan pengalaman dalam lingkungan target sehingga Anda dapat menemukan masalah dan menyajikan jawaban untuk masalah yang akan dihadapi orang lain sebelum terjadi, memecahkan masalah yang tepat, menyampaikan pesan dengan penuh semangat tetapi tanpa terlalu rajin, mendemonstrasikan teknik dengan jelas menunjukkan keuntungan dari metode dan alat Anda dan menjualnya secara organik (tetapi jangan membuat masalah hanya untuk menyelesaikannya), dan dapatkan publisitas dan membeli dari sisa tim Anda. Namun, jika dia tidak rasional, '

Akhirnya, kemudian Anda mulai menggunakan teknik-teknik ini, Anda memerlukan strategi keseluruhan. Sangat penting untuk tidak membiarkan mereka yang secara aktif bermusuhan atau tidak rasional memperlambat Anda - abaikan mereka. Alih-alih, temukan orang yang dapat Anda tunjukkan dan yakinkan bahwa Anda memiliki cara yang lebih baik dan menerapkan teknik yang tepat berdasarkan pada mereka sebagai individu. Setelah lebih banyak orang melihat peningkatan yang ditawarkan pengetahuan Anda, gunakan itu untuk terus meyakinkan orang lain. Akhirnya, gunakan upaya akar rumput ini untuk meyakinkan manajemen bahwa ada cara yang lebih baik, tetapi pastikan untuk memasukkannya ke dalam istilah yang dapat mereka pahami (waktu, uang, kualitas).

Jangan mencoba "meyakinkan" orang ini tentang apa pun. Orang-orang (bahkan programmer) tidak akan menanggapi atau menghargai argumen yang masuk akal / logis dari seseorang yang mereka anggap junior kepada mereka. Jadi jangan buang nafasmu. Alih-alih, berusahalah membangun tingkat kepercayaan dengan orang ini. Orang ini akan mendengarkan apa yang Anda katakan hanya ketika dia terbuka untuk itu.

Sementara itu, Anda memiliki masalah nyata:

1. Pria itu memeriksa file proyeknya ke dalam repo: abaikan saja. Anda tidak perlu memodifikasi file, begitu pula orang lain di tim yang lebih tahu. Biarkan saja. Jika itu memberikan "anggota senior" Anda perasaan hangat dan bahagia seperti selimut keamanan maka jadilah itu.
2. Ada anggaran yang dirasakan pada ruang disk: Inilah alasan Pak Senior menentukan 1 komit sehari. Apakah kekurangan ruang nyata atau dirasakan? Bahkan jika itu hanya dirasakan, mungkin ada sesuatu yang dapat Anda lakukan untuk mengubah persepsi itu. Itu harus segera ditangani - jika Anda mengambil inisiatif itu juga membantu membangun kepercayaan.

Saya mungkin juga menambahkan bahwa orang ini akan bersedia untuk mengadopsi praktik SVN yang lebih baik ketika dia pikir itu adalah idenya. Itu akan membutuhkan beberapa pemikiran ke depan pada Anda, dan dia kemungkinan akan mengambil kredit untuk membangun praktik yang lebih baik - tetapi Anda setuju dengan itu.