Budaya sering diabaikan dan disalahpahami, padahal itu adalah faktor kunci yang bertanggung jawab atas kinerja perusahaan. Jika kita tidak mengelola budaya kita, pada akhirnya kita akan melakukan praktik yang salah yang pada akhirnya akan memengaruhi tujuan bisnis kita.
Memahami budaya organisasi saat ini
Budaya memberi tahu kita tentang nilai dan norma dalam suatu kelompok atau perusahaan. Ini mengidentifikasi apa yang penting serta bagaimana orang mendekati dan bekerja satu sama lain.
CULTURE = “Bagaimana hal-hal dapat dilakukan dengan cerdas untuk sukses”
Mari kita ambil contoh tim dukungan pelanggan. Budaya tim itu harus sedemikian rupa sehingga mereka pada akhirnya mencapai kepuasan pelanggan 97-98%.
Mempertimbangkan kesenangan pelanggan, pertama-tama mereka harus sopan, bahkan dalam situasi sulit mereka perlu menjadi pendengar yang baik untuk menghindari kebingungan mereka perlu memprioritaskan pekerjaan sesuai kebutuhan.
Mari kita berhenti sejenak dan mengajukan beberapa pertanyaan kepada diri kita sendiri:
- Apa budaya perusahaan saya sekarang?
- Seberapa baik budaya ini selaras dengan tujuan bisnis atau KRA saya?
- Masalah apa yang dapat saya perkirakan karena misalignment?
Untuk setiap organisasi, 4C memainkan peran penting
Sekarang, mari kita lihat budaya organisasi pengembangan perangkat lunak. Ada banyak tim yang terlibat untuk membangun dan memelihara satu unit perangkat lunak. Semua tim ini memiliki tujuan dan budaya terpisah.
Proses ini dimulai setelah persyaratan dikonfirmasi oleh klien.
Pengembang mengikuti pedoman pengkodean yang ditentukan oleh organisasi mereka dan alat pemrograman seperti kompiler, juru bahasa, debugger dll digunakan untuk menghasilkan kode. Bahasa pemrograman tingkat tinggi yang berbeda seperti C, C ++, Pascal, Java, dan PHP digunakan untuk pengkodean.
implementasi hashmap dalam contoh java
Mereka membagi paket lengkap menjadi folder-folder kecil dan kemudian mengembangkan kode-kode kecil yang sesuai.
Tahap 1 : Unit kode kecil ini kemudian dipukuli untuk membentuk unit besar. Saat mengintegrasikan chip yang lebih kecil, pengujian tingkat proyek harus dilakukan yang dikenal sebagai pengujian integrasi.
Tahap 2 : Setelah integrasi berhasil, ini akan diterapkan ke dalam sistem tiruan. Sistem dummy ini memiliki konfigurasi yang mirip dengan mesin klien atau mesin tempat proyek ini akhirnya harus diterapkan.
Tahap 3 : Terakhir, setelah menguji semua fitur dalam sistem dummy, proyek tersebut diterapkan ke server produksi atau mesin klien.
Meskipun proses ini tampaknya sangat lancar dan mudah dalam kata-kata, dalam istilah teknis sangat sulit untuk dicapai.
Mari kita lihat masalah apa yang mungkin kita hadapi:
Tahap 1 :
Klien selalu mencari perubahan untuk meningkatkan kualitas produk. Sering kali ketika iterasi pertama selesai, klien akan menyarankan beberapa perubahan. Ketika pengembang menerima perubahan, mereka mulai menggabungkannya yang berdampak pada integrasi yang mengarah ke build yang rusak.
Tahap 2:
Sering kali, penguji atau petugas operasi lainnya tidak akan mengetahui perubahan baru yang akan dibuat. Segera setelah mereka mendapatkan kode dari pengembang, mereka mulai mengujinya. Sedangkan di back-end pengembang masih melakukan perubahan.
Karena mereka tidak mendapatkan cukup waktu untuk mengimplementasikan perubahan baru, mereka akhirnya mengembangkan kode yang tidak efisien, mereka menghadapi masalah jaringan dan database lain yang sekali lagi menunda waktu pengirimannya.
Saat mereka akhirnya mengirimkan kode ke tim operasi, mereka memiliki waktu yang sangat sedikit untuk membuat dan menerapkan kasus pengujian baru. Jadi, mereka melewatkan banyak kasus uji yang kemudian mereka sadari sebagai prioritas tinggi.
Tahap 3:
Meskipun secara virtual build tersebut tampaknya siap untuk berproduksi, tetapi hasilnya sama sekali tidak terduga. Build gagal dan sejumlah bug terjadi.
Kemudian untuk setiap bug yang terjadi, mereka harus melacak mengapa itu terjadi, di mana itu terjadi, perubahan apa yang perlu dilakukan untuk mengatasinya, apakah akan ada perubahan pada kode lain agar kompatibel dengan yang sebelumnya. Terakhir, untuk semua bug ini, laporan bug harus dibuat.
Kegagalan ini karena kesalahan sistem karena ketidaktahuan pengembang database dalam efisiensi kode, ketidaktahuan penguji dalam jumlah kasus uji, dll.
Karena klien selalu memenuhi tenggat waktu yang ketat, karyawan yang terlibat dalam mencapainya hanya berkonsentrasi pada rilis akhir meskipun mereka harus mengorbankan kualitas secara keseluruhan.
Meskipun ini tampaknya menjadi masalah dalam koordinasi pekerjaan, ini sebenarnya adalah kegagalan budaya yang dianut.
Ini terjadi karena ketergantungan yang besar pada proses manual. Berlari kesana kemari dalam tim yang sama karena kurangnya pengetahuan di bidang yang berbeda kurangnya akses atau mungkin kurangnya minat meningkatkan beban dan rasa sakit kita sendiri.
Sudah saatnya kita perlu serba bisa. Mungkin sulit untuk menguasai semua proses yang terlibat dalam sebuah sistem, tetapi kita bisa menjadi jack of all, menguasai salah satunya. Maka hanya kami yang dapat mengotomatiskan sistem kami atau membuatnya cukup cerdas untuk memulihkan daripada melakukan rollback.
Sekarang, Anda mungkin berpikir mengapa?
Itu karena, yang Anda kuasai sangat bergantung pada orang lain. Jadi untuk mengetahui tentang titik ketergantungan, kita perlu memahami keseluruhan sistem.
Jadi mari pikirkan proses untuk mengubah budaya. Sebelum itu apakah Anda memiliki jawaban untuk pertanyaan di bawah ini?
- Di mana budaya Anda saat ini gagal?
- Mengapa Anda ingin mengubah prosesnya?
- Sudahkah Anda mengidentifikasi dengan jelas semua perubahan yang diperlukan?
- Sudahkah Anda memperoleh umpan balik dan dukungan dari semua pemegang saham yang terpengaruh?
- Sudahkah Anda memvalidasi ulang disiplin proses, data, dan sistem pengukuran untuk perubahan?
Jadi, sekarang ketika kita memiliki jawaban untuk semuanya, kita memikirkan sebuah revolusi ke dalam sistem kita. Bagaimana revolusi ini akan berlangsung? Itu hanya bisa dicapai jika kita membunuh kita sekarang. Banyak waktu terbuang dalam migrasi kode di antara tim. Kami harus membawa proses di mana kami dapat melakukan integrasi berkelanjutan dan penerapan berkelanjutan.
tabel dalam html tabel
Proses integrasi dan penerapan berkelanjutan ini membuatnya lebih gesit. Membawa ketangkasan ini dianggap sebagai budaya DevOps.
DevOps adalah praktik teknisi operasi dan pengembangan yang berpartisipasi bersama dalam seluruh siklus hidup layanan, mulai dari desain hingga proses pengembangan hingga dukungan produksi.
Tidaklah mudah untuk mengubah sistem kerja dari waktu ke waktu. Membuat transisi yang berhasil adalah merenovasi sistem, bukan membangun kembali.
Sekarang mari kita lihat bagaimana kita bisa mencapai ini. Ada dua cara untuk melakukan pendekatan.
1) Atas ke bawah
2) Bawah ke atas
Menyelami lebih dalam teknik ini, kami akan menyadari mana yang paling cocok untuk organisasi kami.
Dalam pendekatan top down, kita dapat pergi ke manajemen yang lebih tinggi dan meminta mereka untuk membuat perubahan di semua tim. Kalau manajemen sudah yakin, kita bisa mulai mengerjakannya.
Tetapi kemungkinan mendapatkan jawaban “TIDAK” cukup tinggi. Itu karena mengubah sistem dapat menyebabkan ketidakstabilan organisasi.
Mereka harus melihat ke dalam struktur organisasi, pendapatan, tingkat minat klien, dll. Namun faktor terpenting yang menarik mereka untuk keluar dari sistem lama adalah mereka tidak dapat melihat gambaran besar tentang apa yang dapat dicapai dan seberapa lancar hal itu dapat dicapai dengan yang lebih baru.
Dalam hal ini, kita bisa mencari pendekatan kedua untuk mendapatkan gambaran besar ini.
Pendekatan bottom up membutuhkan relawan. Di sini kita harus mengambil tim kecil dan tugas kecil dan menjalankannya dalam Model DevOps.
Melihat dari sisi teknis model ini, kami memiliki berbagai perangkat canggih yang membuat pekerjaan lebih efisien dan cepat. Namun, alat saja tidak cukup mampu untuk membuat lingkungan kolaboratif yang disebut DevOps.
Menciptakan lingkungan seperti itu mengharuskan Anda untuk berpikir di luar kotak, mis. menilai dan menyelaraskan kembali bagaimana orang berpikir tentang tim mereka, bisnis dan pelanggan.
Menyusun seperangkat alat baru lebih sederhana daripada mengubah budaya organisasi. Dengan mempromosikan pengembang master anti-sosial, memungkinkan kode yang tidak efisien untuk diintegrasikan, menerapkan kode yang tidak diuji dengan benar, saling menyalahkan, menganggap tim operasi bodoh bukanlah praktik terbaik yang kami ikuti untuk memungkinkan bisnis dan menciptakan nilai bagi pelanggan kami.
Bukan alatnya, melainkan orang yang menggunakannya yang membuat proses menjadi rumit. Mengatakan pada tingkat abstrak daripada mengumpulkan ide dan perilaku, terbuka terhadapnya membawa kita ke jalan yang cemerlang.
Mari kita mulai dengan tim yang terdiri dari 6 anggota dan cerita 3 poin. Pertama, kami harus menghancurkan tim yang kami sebut sebagai pengembang, operasi, penguji, dll. Kami menganggap semuanya sebagai satu, katakanlah 'DevOps'. Saat kami menerima persyaratan, kami perlu menganalisis zona risiko. Mengingat bagian yang lebih dalam dari laut & hellip .. Kami mulai berlayar.
Sekarang, Anda harus berpikir 'apa faktor x dari integrasi berkelanjutan dan penerapan berkelanjutan yang mengurangi kemungkinan kegagalan'.
Dengan visi dan proses yang ditingkatkan, kami dapat mendekati manajemen dengan memberikan gambaran yang jelas tentang hasil seperti seberapa lancar prosesnya, bagaimana risiko kegagalan dikurangi, bagaimana tugas diselesaikan sebelum garis waktu, dll.
Sekarang, kami dapat dengan jelas memvisualisasikan bagaimana seluruh proses dioptimalkan pada landasan teknis dan budaya dengan melakukan retrospeksi setelah setiap iterasi.
mengatur classpath java di linux
Edureka telah melakukan kurasi khusus yang membantu Anda menguasai konsep seputar Puppet, Jenkins, Ansible, SaltStack, Chef.
Ada pertanyaan untuk kami? Sebutkan mereka di bagian komentar dan kami akan menghubungi Anda kembali.
Posting terkait: