Saya telah bekerja sebagai pemimpin tim / pengembang di lingkungan perusahaan keuangan besar selama lebih dari tiga tahun. Proses rilis produksi kami adalah mimpi buruk karena berputar di sekitar Clearcase. Kami memiliki grup manajemen perubahan yang mengeksekusi semua rilis dan yang hanya akan mengizinkan kode menjadi produksi yang diambil darinya.
Salah satu hal pertama yang saya lakukan ketika bergabung adalah mengatur tim saya dengan Git. Semua orang setuju bahwa Clearcase mengerikan dan tidak praktis untuk menangani masalah kontrol sumber sehari-hari. Jadi kami membuat semacam repositori "tidak resmi" pada mesin lokal saya dan saya menulis naskah untuk menyinkronkan repositori git dan Clearcase sekitar waktu rilis.
Berita ini menyebar ke tim lain dan beberapa telah mengadopsi proses yang sama. Menggunakan git dengan cara "tidak resmi" untuk kegiatan sehari-hari dan "secara resmi" menggunakan Clearcase untuk rilis. Saya menjadi semacam orang yang suka berurusan dengan Git.
Jadi saya mengadakan pertemuan minggu ini dengan SVP tentang perubahan infrastruktur yang secara khusus ingin saya menjelaskan kepadanya manfaat Git. Rupanya tersiar kabar buruk tentang Clearcase. Jika dia menerima argumen saya, saya akan memiliki kesempatan nyata untuk membantu majikan saya membebaskan diri dari kekejian ini.
Pengalaman saya dengan eksekutif memberi tahu saya bahwa mereka a) ingin penjelasan yang sangat singkat untuk semuanya b) hanya tertarik pada fakta yang melibatkan angka dolar
Untuk seorang pengembang saya dapat menjelaskan manfaat dari Git atas Clearcase (atau sistem kontrol versi lain APAPUN atas Clearcase dalam hal ini), tetapi saya menarik kosong tentang bagaimana melakukan ini kepada seorang eksekutif teknis tanpa latar belakang teknis (dia memiliki MBA dan gelar sarjana di bidang geografi).
Saya merasa setiap argumen yang saya buat kepadanya akan terdengar seperti omong kosong teknis atau bahwa saya menginjili preferensi pribadi saya.
Apa yang saya coba temukan adalah fakta nyata yang menunjukkan pengembang bekerja lebih efektif dengan Git, atau sistem kontrol sumber modern APAPUN.
Saya pikir fakta bahwa tim-tim lain sudah mulai menggunakan Git secara internal adalah tanda yang bermakna, tetapi itu masih belum cukup kuat karena masih dapat dianggap sebagai pilihan pribadi.
Yang benar-benar saya butuhkan adalah sesuatu yang cukup kuat untuk menerobos "Proses ini telah bekerja selama 20 tahun, mengapa kita harus mengubahnya?" argumen.
Jawaban:
Saya pernah berada dalam situasi yang sangat mirip (dalam industri dirgantara dan otomotif). Jangan berharap untuk berkembang sangat jauh dalam pertemuan ini atau berikutnya. Kedua situasi ini melampaui keinginan saya untuk terus berjuang untuk perbaikan, tetapi di sini adalah taktik terbaik yang pernah saya lihat sejauh ini ...
Anda mengatakan "proses ini telah bekerja selama 20 tahun", tetapi apakah itu benar-benar? Mulailah dengan menjabarkan apa yang Anda maksud dengan "proses rilis produksi kami adalah mimpi buruk". Buat daftar masalah dengan proses / alat saat ini yang agnostik dari ClearCase mungkin.
Kemudian, buat daftar "solusi" proses / alat yang sama agnostiknya dengan Git (meskipun Git atau DVCS modern mana pun akan pas dengan tagihan). Menjelaskan mengapa Git lebih baik daripada ClearCase tidak ada artinya bagi non-pengguna.
Izinkan tim infrastruktur untuk mengonfirmasi bahwa pendekatan saat ini memiliki masalah yang Anda identifikasi. Ini kemungkinan akan mengarahkan mereka untuk mencari dukungan dari IBM untuk "memperbaiki" masalah-masalah ini. Tetap terhubung untuk memastikan IBM tidak memihak masalah. Karena ClearCase tidak memiliki properti dasar dari pemahaman modern kita tentang kontrol versi, sebagian besar masalah ini tidak dapat diperbaiki atau akan membutuhkan perubahan infrastruktur besar.
Semoga pada titik ini, tim infrastruktur akan melihat ini sebagai masalah bisnis, tetapi tanpa solusi yang mudah. Pada titik ini, Anda menawarkan to benchmark solusi tambahan dengan perkiraan biaya. Karena banyak tim Anda sudah menggunakan Git, Anda harus dapat menghapus pelatihan sebagai biaya.
Semoga berhasil!
sumber
Tidak, proses Anda adalah "mimpi buruk" karena grup manajemen perubahan dan prosedur pelepasan Anda. Silakan ganti Clearcase untuk SVN atau git atau Fossil. Anda akan memiliki masalah yang sama persis . (Saya pikir mereka melakukannya dengan benar TBH, kontrol rilis yang kuat sangat penting).
Inilah yang perlu Anda fokuskan, bukan kredensial culun dari git (yang tidak relevan untuk semua kecuali dev), Anda harus fokus pada kasus bisnis untuk mengubah proses agar tidak terlalu memberatkan. Kemungkinannya adalah Anda bisa melakukan itu menggunakan Clearcase, tetapi itu memberi Anda kesempatan untuk menyelinap gagasan menggunakan git.
Jika Anda tidak melihat "gambar yang lebih besar" di sini, case terbaik Anda akan membuatnya menggunakan git dengan batasan yang sama seperti yang dibutuhkan oleh grup rilis. JIKA Anda mempertimbangkan aspek-aspek yang lebih luas dari apa yang dimaksud dengan kontrol perubahan, maka Anda akan menghargai pembatasan yang harus Anda terapkan untuk menjadikan git berguna dalam jenis proses rilis yang sangat terkontrol yang dibutuhkan org Anda.
Beberapa ide untuk Anda: Buat mereka untuk melihat masalah produktivitas dengan sistem saat ini dari sudut pandang pengembang. Lakukan ini sebagai bagian 1 dari 2. Bagian 2, pergi dan bekerja dengannya pada rilis sehingga Anda dapat melihat masalah kontrol yang perlu dipahami pengembang Anda. Perlakukan itu sebagai latihan pembelajaran bagi kedua belah pihak untuk melihat pandangan pihak lain, dan kemudian Anda harus bisa lebih baik dengan solusi yang masih memecahkan persyaratan utama yang dimiliki kedua belah pihak. Perhatikan bahwa rilis lebih penting daripada dev, jadi Anda harus menjadi orang yang siap memberikan tanah lebih dari yang Anda harapkan.
Setelah Anda memiliki pengetahuan tentang apa yang diperlukan untuk rilis, Anda harus setuju untuk menulis dokumen proses rinci (dengan langkah-langkah untuk mengikuti jenis detail) yang Anda dapat menunjukkan kepada mereka memberi mereka apa yang mereka butuhkan. Bagaimana Anda bisa memijat ini sehingga sisi dev lebih baik untuk Anda terserah Anda. Saya membayangkan mereka tidak benar-benar peduli bagaimana dev melakukan dev, asalkan sumbernya dikelola dengan benar dan rilis terorganisir dengan benar - itu berarti Anda harus menunjukkan bagaimana perubahan kode dapat dikaitkan dengan mengubah tiket, cara mengambil kode yang dibuat sebuah rilis untuk ditambal, buat dan lepaskan kembali.
sumber
Contoh spesifik akan mengesankan lebih dari sekadar keuntungan abstrak. Saya pikir Anda akan menemukan paling sukses jika Anda dapat mendokumentasikan contoh-contoh tertentu di mana (a) Clearcase menyebabkan masalah yang membutuhkan waktu untuk diselesaikan dan (b) Git memecahkan masalah tersebut. Ingatlah bahwa Anda tidak perlu masuk ke perincian teknis mengapa hal ini terjadi (kecuali diminta) cukup tunjukkan bahwa memang demikian; manajemen tidak perlu mengetahui teknisnya, itulah yang Anda bayar.
Jika Anda dapat melampirkan rentang waktu dan tanggal tertentu untuk contoh-contoh ini, jauh lebih baik. Anda juga dapat menyelesaikan ini dengan menunjukkan bahwa tugas X yang Anda lakukan banyak membutuhkan Y menit di Clearcase dan Z menit di Git.
Ingatlah bahwa waktu adalah uang, jadi jika Anda dapat menunjukkan bahwa bekerja dengan Git lebih cepat, Anda dapat menunjukkan bahwa itu juga masuk akal secara finansial.
sumber
Berikut adalah upaya bagaimana saya akan mencobanya.
Itu mungkin terdengar bodoh bagi pengembang, tetapi bagi manajemen, perubahan teknologi dipandang berisiko.
"Jika benda ajaib sudah bekerja, mengapa mengambil risiko untuk melanggarnya?"
Jadi, Anda harus membalikkan meja. Buat lebih berisiko untuk tidak beralih ke git. Bagaimanapun juga, jangan membuatnya terdengar seperti mainan baru.
Saya akan mulai dengan mengatakan bahwa git sekarang banyak digunakan. Gunakan angka, seperti itu: http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/
Untuk seorang manajer, ini menyiratkan bahwa mereka harus dapat menemukan banyak pengembang menggunakan git. Dan seluruh ekosistem alat pihak ketiga (saya mendengar bahkan Microsoft mengintegrasikan git dengan studio visual sekarang).
Juga seorang manajer tidak dapat disalahkan karena mengikuti hal-hal umum, bukan? Sebaliknya, siapa yang menggunakan $ other_cvs di sini?
Beri penekanan pada bagaimana proyek besar menggunakannya, karena itu sederhana, cepat, fleksibel, kuat ... Temukan proyek besar dengan nama besar yang melekat padanya (GNU / Linux, Google, Microsoft ...) yang menggunakan git.
Setelah menunjukkan bahwa itu bukan langkah yang buruk, Anda kemudian dapat melanjutkan bagaimana hal itu akan meningkatkan hal-hal dalam kasus Anda.
Anda ingin perusahaan tetap kompetitif, dan tidak dikalahkan oleh tim yang lebih cepat, lebih gesit, bukan? Saya akan mencoba menemukan beberapa estimasi internal (tertulis) tentang bagaimana produktivitas berubah dengan menggunakan Clearcase vs Git. Anda dapat menggunakan bantuan dari rekan pengembang di sana. Kemudian ekstrapolasi untuk seluruh perusahaan (mis. Semua pengembang perangkat lunak), dengan jumlah dan perkiraan biaya untuk tetap dengan Clearcase.
Saya akan bahkan jika pantas merangkum semuanya dalam email tertulis setelah pertemuan (termasuk orang yang tepat).
sumber
Ini adalah argumen yang tidak valid (kereta kuda telah "bekerja selama berabad-abad", tetapi Anda mungkin ingin membeli mobil saja).
Saya telah mendengar argumen yang sama tentang svn vs mercurial (saya adalah orang yang menggunakan mercurial pada sistem pengembangan saya).
Masalah ini bukan tentang mengganti yang berhasil; Jangan mencoba untuk mengatakannya seperti itu, dan jika ini adalah pertanyaan yang Anda butuhkan untuk "mengalahkan", Anda harus mulai dengan menunjukkan bahwa itu bukan masalah apa yang berhasil atau tidak - tetapi masalah apa kelebihan yang Anda miliki dengan git , ketika keduanya bekerja (dan mengapa git bekerja lebih baik).
Argumen yang bagus untuk menggunakan git:
git adalah perubahan sentris alih-alih file sentris. Ini berarti perubahan lebih mudah untuk melacak file lintas (keterlacakan melintasi proyek).
git didistribusikan bukannya terpusat; Ini berarti memeriksa barang tidak dibatasi oleh kecepatan jaringan - menghemat banyak waktu, lagi. Ini juga berarti Anda tidak memiliki satu titik kegagalan jika server ClearCase Anda turun.
karena sistem percabangannya, git meminimalkan kebutuhan untuk menggabungkan (yaitu Anda tidak menggabungkan file pada setiap check-in, tetapi pada setiap fitur yang diselesaikan). Anda beralih dari menyelesaikan konflik gabungan (jika ada) beberapa kali per hari (pada setiap komit) menjadi sekali atau dua kali per minggu (pada setiap fitur yang diselesaikan). Ini berarti lebih banyak waktu pengembangan untuk pengembang Anda (sesuatu yang manajer ingin maksimalkan).
Anda dapat menunjukkan bahwa perbedaan kualitatifnya sangat besar , sehingga pengembang di seluruh perusahaan Anda lebih suka komplikasi menginstal, mengkonfigurasi dan menggunakan git, di atas Clearcase, untuk fitur tambahan. Ini sebenarnya argumen yang kuat (jika tidak memberikan pengalaman pengguna dan fitur yang lebih baik secara keseluruhan, orang tidak akan berusaha keras untuk menggunakannya - terutama karena itu adalah sesuatu yang tidak diperlukan oleh perusahaan).
Gambarlah bagan yang menunjukkan komit dengan kedua sistem, dan perlihatkan perampingan yang diperoleh oleh pengembang yang tidak melakukan secara publik (yaitu jika Anda membuat file, bagian tim lainnya tidak diblokir dan tidak dapat dikompilasi hingga Anda memperbaikinya). Juga jelaskan kontrol kualitas tambahan yang dapat Anda lakukan ketika Anda dapat membuat komitmen perantara tanpa mempengaruhi orang lain, fakta bahwa Anda bisa mendapatkan perbedaan bersih per fitur (penting untuk ulasan kode).
sumber
Sulit untuk benar-benar menilai apa yang akan menjadi argumen yang bagus tanpa menjadi saksi adegan itu. Tetapi saya akan mencoba membantu Anda membingkai argumen Anda sehingga bisa didengar.
Saya menganggap audiens Anda memiliki tingkat pengetahuan non-pakar tentang topik tersebut, dan memiliki minat untuk tetap mengikuti kursus saat ini. Mereka memiliki keprihatinan dan tanggung jawab yang berbeda, dan mereka mungkin menderita konsekuensi serius jika terjadi kesalahan, sehingga Anda harus bekerja dari pola pikir itu. Antisipasi beberapa pertanyaan atau kekhawatiran yang mungkin mereka miliki:
Apa kemampuan baru yang akan dibawa ini? Adakah sesuatu yang saat ini tidak dapat kita lakukan, yang ingin kita lakukan, dan hal baru ini akan memungkinkan kita untuk melakukannya? Mulai dengan nada positif.
Apa dampaknya terhadap jadwal rilis? Berapa biaya mengimplementasikan perubahan ini menuju rilis segera berikutnya? Berapa biaya dan manfaat untuk rilis berikut?
Apakah ini memerlukan perubahan dalam proses? Berbeda dari jadwal rilis, apakah perubahan ini mengharuskan orang dalam proses rilis mengubah cara mereka? Apakah ini transparan bagi mereka, atau akankah mereka perlu beradaptasi? Apakah Anda perlu bekerja sama dengan departemen lain? Orang-orang tahan terhadap perubahan.
Apakah ada bahaya yang akan terjadi jika tetap menggunakan sistem saat ini? Apakah proses saat ini memiliki ketergantungan perangkat lunak atau perangkat keras yang telah hilang atau akan segera berakhir? Apakah itu bergantung pada pengetahuan khusus dari individu yang menaikkan biaya perekrutan? Apakah ada lubang keamanan potensial yang dicolokkan oleh sistem baru (poin bonus jika lubang ini dapat menyebabkan tindakan hukum)? Jangan lambaikan tangan atau 'mungkin' atau 'mungkin' ini: maknanya adalah itu bekerja dengan baik selama 20 tahun, jadi beban pembuktian ada pada pendukung perubahan.
Juga, spesifik tentang masalah dan solusi . Jika Anda tidak dapat menemukan contoh spesifik, gunakan taksiran jujur dari posisi Anda sebagai ahli. Contoh perusahaan / departemen / entitas lain yang mengadopsi perubahan seperti itu, lebih disukai dari industri Anda, dan evaluasi mereka terhadap perubahan itu, akan membantu Anda. (Jangan memilih contoh yang memiliki semacam masalah IT yang dipublikasikan beberapa tahun terakhir, atau tanggung jawab Anda adalah untuk membuktikan bahwa perubahan ini bukan penyebabnya.)
Anda dapat menemukan jawaban ini untuk Meyakinkan Perusahaan tempat saya Bekerja untuk Menerapkan Kontrol Versi? bermanfaat.
sumber