Jika Anda tidak memahami apa itu DevOps, inilah lembar contekan singkatnya. DevOps adalah serangkaian praktik yang mengurangi ketakutan para insinyur dan mengurangi jumlah kegagalan dalam produksi perangkat lunak. Biasanya mereka sama mengurangi waktu ke pasar — periode dari ide hingga pengiriman produk akhir ke pelanggan, yang memungkinkan Anda melaksanakannya dengan cepat eksperimen bisnis.
Bagaimana cara memulai transformasi DevOps? Singkatnya: kami memilih layanan untuk memulai proses, mengidentifikasi orang-orang yang terkait dengan layanan tersebut, membangun Peta Aliran Nilai, membuat tim sementara yang akan menangani transformasi untuk pertama kalinya dan menetapkan tugas untuk itu. Kami mengulangi siklus tersebut sebanyak yang diperlukan.
Rencana transformasi DevOps terperinci dengan contoh dan instruksi di bawah potongan - dalam transkrip Andrey Alexandrov - seorang insinyur di Express42, yang memberi nasihat tentang perkecambahan DevOps, mempercepat proses ini karena dia telah membuat peta rake. Jika Anda merasa tidak memerlukan transformasi, atau spesifikasi Anda tidak sesuai dengan praktik DevOps, gunakan laporan ini sebagai petunjuk untuk menemukan dan menghilangkan batasan.
Jika Anda khawatir tentang masalah transformasi DevOps, maka Anda memiliki perusahaan besar, dan Anda perlu secara bertahap menskalakan proses ini ke seluruh struktur. Selama ada kebutuhan untuk mengubah perintah atau menghilangkan beberapa batasan, algoritma di bawah ini dapat diulang.
Memilih layanan
Kami telah menguraikan rencananya, mari kita mulai dengan langkah pertama - memilih layanan. Kriteria pertama adalah seumur hidup: ada layanan lama - lama, dan yang baru. Anda bisa mulai dengan keduanya.
Masuk akal untuk memilih layanan yang muda. Segarnya, belum ada proses kerja yang mapan dalam tim yang menanganinya. Tidak ada hutang teknis yang menggunung di sekitarnya, Anda tidak perlu memperbaikinya setiap saat. Kita bisa melakukan apapun yang kita inginkan dengannya.
Dalam kasus layanan lama, ada masalah terkait dengan itu perubahan selalu sulit. Sudah ada serangkaian pembatasan yang serius, tetapi mungkin pembatasan tersebut dilakukan oleh orang-orang yang siap untuk menyekop segalanya - mereka lelah dan ingin melakukan sesuatu yang berbeda karena kesakitan.
Bekerja dengan layanan lama memberikan preseden yang kuat di perusahaan Anda - Anda dapat mengubah sesuatu. Jika Anda mengubah layanan baru, layanan tersebut diluncurkan 100 kali dalam satu jam, dan semuanya baik-baik saja, maka orang-orang di perusahaan Anda mungkin berkata:
- Ini adalah layanan baru! Semuanya sederhana di sana, cobalah melakukan sesuatu dengan bangkai kapal kami.
Masuk akal untuk menggunakan layanan Warisan untuk transformasi ketika Anda melakukannya dengan seseorang, misalnya, jika Anda mengundang konsultan eksternal. Jujur saja, transformasi ini akan mengguncang segala kemungkinan. Anda sedang bereksperimen dan tidak tahu di mana Anda akan berakhir, teknologi apa yang akan Anda gunakan dan mengapa, di mana dan kendala apa yang akan muncul dalam proses tersebut. Oleh karena itu, lebih mudah untuk mengganti yang baru.
Jika semuanya dilakukan sendiri, dan perusahaan tidak memiliki kompetensi yang serius, kami mengambil layanan baru. Jika Anda mengenal konsultan eksternal dan punya dana, pilihlah yang lama.
Ada layanan yang hanya berupa antarmuka bagi pengguna, misalnya situs web sederhana atau aplikasi seluler. Namun ada hal serius dalam semangat penagihan. Jika ada yang salah dengan penagihan, akan sulit untuk mengetahuinya. Di sini kita juga punya pilihan.
Kami juga bekerja dengan layanan kritis, tapi kita menderita karenanya, hal itu menimbulkan pembatasan, atau kita bekerja dengan antarmuka. Ini adalah kriteria seleksi kedua. Demikian pula, dimungkinkan untuk menarik konsultan berpengalaman - kami bekerja dengan opsi yang sulit.
Tetapi bahkan dalam kasus ini, saya tidak akan merekomendasikan melakukan hal ini, karena sampai ada pemahaman tentang apa yang harus dikerjakan dan ke arah mana harus diubah, mengambil hal yang kritis dan mengubahnya bukanlah ide yang baik. Oleh karena itu, dalam hal ini, kami lebih memilih untuk bekerja dengan antarmuka yang kegagalannya tidak kritis.
Mari kita lihat lebih jauh tim layanan. Kami harus terus bekerja dan berinteraksi erat dengan mereka yang menyediakan layanan ini.
Orang-orang di tim dibagi menjadi dua kategori: konservatif — hidup di dunia lama, atau tidak tahu apa pun tentang DevOps, dan inovator, yang menyeret semua praktik modis. Yang terakhir ini tidak selalu memahami topiknya, tapi setidaknya mereka siap untuk itu.
Di satu sisi, kaum konservatif adalah orang-orang yang berpengalaman: mereka sudah lama berkecimpung di perusahaan, mereka memahaminya luar dan dalam, namun mereka tidak tahu persis tentang praktiknya. Di sisi lain, ada inovator yang pernah mendengar sesuatu, namun kemungkinan besar sudah lama tidak bekerja di perusahaan tersebut. Mana yang lebih baik untuk dikerjakan?
Bagaimanapun, Anda harus berinteraksi dengan kaum konservatif, karena ini adalah layanan mereka. Anda harus berkomunikasi dengan mereka, mencari tahu secara spesifik layanannya, apa yang bisa dilakukan dengan cara ini dan apa lagi. Kami bergantung pada saran mereka. Anda mungkin harus mempercayakan sesuatu kepada mereka, karena mereka lebih mengetahui layanan mereka. Oleh karena itu, penting dengan tim mana kita akhirnya berhubungan.
Memilih inovator untuk tim adalah hal yang logis, karena kaum konservatif dapat mengambil peran penting di dalamnya.
Dalam praktiknya, sering terjadi bahwa orang-orang konservatif memiliki banyak pengalaman, tetapi tidak memiliki pemahaman tentang bagaimana untuk hidup lebih jauh. Mereka hanya takut bahwa setelah transformasi dan desain ulang layanan, mereka akan dipecat karena tidak diperlukan. Kadang-kadang, hanya karena mereka tidak memahami apa yang sedang terjadi, mereka menyabotase pekerjaan tersebut.
Saya punya kasus di mana seorang anggota tim memperbaiki semuanya, karena hal itu dianggap lebih kritis daripada apa yang kami lakukan sekarang. Kami menetapkan tugas: untuk mengimplementasikan bagian ini hari ini - tidak, ada kebakaran di belahan dunia lain, kami akan memperbaikinya. Sulit untuk bekerja dengan orang-orang seperti itu.
Orang-orang dari tim konservatif sering kali melupakan tugas atau menundanya hingga menit terakhir. Dan jika, amit-amit John Willis, Anda melakukan kesalahan dan menetapkan KPI untuk jumlah tugas yang diselesaikan, dan karena alasan tertentu ada bagian yang tidak termasuk dalam KPI, maka mereka tidak akan melakukan apa pun. Secara umum, mereka benar, karena mereka kehilangan bonus.
Lebih mudah bagi inovator - mereka lebih setia. Mereka sudah mendengar sesuatu, mereka ingin pergi ke suatu tempat, jadi mereka akan membantu. Kita membutuhkan orang-orang yang siap menderita untuk pertama kalinya: jika layanan berubah, maka para inovator akan mengambil alih semua tantangan sebagai pionir. Para inovator menginginkan segala sesuatu yang baru dan modis, dan mereka menderita.
Kaum konservatif nantinya dapat dikonversi. Ketika Anda menunjukkan bahwa Anda telah mengubah sedikit hal dan semuanya berjalan dengan baik, kemungkinan besar mereka akan ingin mencobanya juga dan akan menganut agama DevOps yang baru.
Mari kita rangkum. Jika kami melakukan sendiri seluruh transformasi di perusahaan kami, maka kami memilih: layanan baru, sebaiknya antarmuka yang sederhana agar tidak terlalu menderita karena kerusakannya, dan tim inovator.
Jika memungkinkan untuk memanggil konsultan eksternal, alih-alih yang baru, kami menggunakan layanan lama, karena itu kami sudah menderita. Orang-orang yang telah lama terlibat dalam transformasi di perusahaan yang berbeda telah melihat kasus yang berbeda dan sudah memahami bagaimana melakukannya dengan benar, dan arah mana yang harus diambil secara umum.
Siapa yang terlibat?
Kami perlu menemukan semua orang yang memiliki setidaknya beberapa hubungan dengan layanan ini: pengembang, penguji, admin, pakar keamanan, manajer, dan, mungkin, Pemilik Produk. Meskipun Pemilik Produk bukanlah spesialis teknis, mereka terkait dengan layanan: mereka membuat keputusan, menetapkan tugas.
Setiap orang yang setidaknya mengambil beberapa keputusan dan mempengaruhi apa yang terjadi dengan layanan perlu ditemukan, ditemui, dan dikomunikasikan.
Untuk apa kita membutuhkannya? Untuk mengetahui dengan siapa harus bernegosiasi. Selama transformasi, ketika prinsip kerja layanan yang biasa berubah, hal itu akan tetap terguncang. Akan ada gangguan untuk sementara waktu saat kami menguji pendekatan baru. Masyarakat harus siap dan menyetujuinya.
Selanjutnya Anda harus membuat Peta Aliran Nilai (Value Stream Map), dan tanpa orang-orang ini Anda tidak akan dapat membangunnya, karena hanya mereka yang mengetahui gambaran lengkap tentang apa yang sedang terjadi. Seseorang tidak pernah mengetahui segala sesuatu yang terjadi dengan layanan tersebut.
Mereka akan merekomendasikan orang-orang untuk tim tersebut. Nanti kita akan membahas mengapa diperlukan tim tersendiri. Ini harus mengambil orang-orang dari departemen yang ada. Mereka yang terlibat dalam pelayanan akan dapat merekomendasikan rekan-rekan yang berpikiran sama dengan kita, yang dapat membantu kita dan kompeten dalam hal yang kita butuhkan.
Selanjutnya, kami mengumpulkan semua orang dari berbagai departemen ke dalam satu ruangan dan mulai membuat Peta Arus Nilai.
Membangun Peta Arus Nilai
Value Stream Map merupakan diagram atau peta yang menunjukkan aliran nilai ke klien. Ini adalah keseluruhan proses mulai dari munculnya ide hingga implementasinya, termasuk semua tahap peralihan dan bagaimana nilai pada akhirnya sampai ke klien kami.
Value Stream Map diperlukan untuk itu memvisualisasikan semua tahap perkembangan, melokalisasi masalah melalui pengukuran yang ada pada proses yang sedang berjalan dan mulai menghilangkan masalah tersebut, dan menetapkan tujuan awal. Di sinilah kita mulai melakukan sesuatu.
Metrik
Ada banyak metrik berbeda yang dijelaskan dalam literatur Peta Arus Nilai, namun tiga metrik saja sudah cukup untuk membantu kita memulai.
Waktu Pimpin - tunda/tunggu - saat kita sedang menunggu sesuatu. Misalnya, seorang penguji menunggu hingga tempat tes kosong, dan selama itu tidak dapat berbuat apa-apa.
Nilai Tambah Waktu - waktu kerja yang berguna - apa yang kami keluarkan pada tahap ini dan itu untuk menciptakan nilai akhir bagi pengguna. Misalnya, seorang penguji meluncurkan pengujiannya dan mulai memeriksa sesuatu. Ini adalah waktu kerja yang bermanfaat, ketika kita benar-benar melakukan sesuatu untuk produk tersebut. Inilah yang dibayar klien - perangkat lunak berkualitas.
%C/A adalah persentase pekerjaan yang diterima. Kami memiliki satu tahap - pengembangan, tahap kedua - pengujian. Berapa banyak fitur yang diterima penguji dari pengembang dalam persentase ini.
Ini kira-kira seperti apa peta kita.
Ini mungkin terlihat berbeda tergantung pada struktur organisasi, jumlah departemen, dan apa yang Anda lakukan. Namun secara umum akan ada dua tahapan pada peta: ide itu и analisis. Pada tahap ini data yang diharapkan misalnya Lead Time 2 minggu dan Value Added Time 2 hari.
Kami benar-benar mencakup semua tahapan dengan metrik.
Jaminan simpanan — berapa banyak masalah yang muncul setelah para analis mengemukakannya.
Pembangunan - berapa minggu pengembang menunggu klarifikasi tentang tugas, stand, atau peralatan - tidak masalah, tetapi mereka menunggu sesuatu. Misalnya, mereka memerlukan waktu 4 hari untuk mengimplementasikan suatu fitur. Di sinilah metrik %C/A berperan. Pengembang hanya mengambil 80% tugas dari Backlog. Mereka menilai 20% sisanya tidak memiliki spesifikasi teknis yang cukup jelas, dan mengirimkannya untuk direvisi.
Pengujian. Diagram LT diatur ke 4 hari. Misalnya, penguji sedang menunggu meja tes menjadi gratis, VA mereka sebenarnya menguji sesuatu selama 2 hari, dan %C/A = 40%. — hanya 40% kode atau fitur yang dikirim oleh pengembang dianggap memadai oleh penguji. Mereka tidak menyukai yang lainnya karena alasan tertentu.
Saya tidak akan membahas secara rinci bagaimana melakukan pengukuran ini, di akhir artikel saya akan merekomendasikan literatur yang dapat Anda pelajari tentangnya.
Satu-satunya hal yang dapat saya rekomendasikan adalah Anda tidak mempercayai orang-orang yang akan menyusun Peta Aliran Nilai bersama Anda. Mereka memberikan gambaran tentang berapa lama waktu yang dibutuhkan untuk berbagai proses, tetapi perkiraan ini tidak selalu benar, jadi sebaiknya ukur sendiri.
Kami mempunyai kasus ketika kami datang ke departemen Operasi dan menanyakan berapa lama waktu yang dibutuhkan untuk menghadirkan fitur baru ke produksi. Mereka memberi tahu kami bahwa itu akan memakan waktu 10 menit, dan kami berpikir, mengapa kami datang ke perusahaan ini? Ternyata 10 menit adalah waktu berjalannya script yang mengambil kode tersebut dan mengirimkannya ke server. Namun sebelum ini, rilis berada di server selama tiga hari dan hanya mengumpulkan debu - ada tugas di Backlog yang perlu diterapkan. Ternyata sebelum tahap deployment ada tahap menunggu, yaitu proyek tinggal diam saja. Jika kami tidak menggunakan buku catatan, tidak memperhatikan tugas di Jira, dan mulai melacaknya langkah demi langkah, kami akan mengira semuanya baik-baik saja dan tidak ada masalah.
Oleh karena itu, Anda tetap harus melakukan pengukuran sendiri, sebaiknya lebih dari satu kali, agar gambarannya mendekati kenyataan. Bergantung pada Value Stream Map, Anda akan memutuskan dari mana harus memulai dan apa yang harus diperbaiki terlebih dahulu.
Tim sementara
Banyak perusahaan yang memutuskan untuk mengimplementasikan DevOps membuat tim, namun bukan tim sementara, melainkan tim yang sudah ada selama beberapa tahun. Jika Anda membuka layanan permintaan maaf DevOps, yang menjelaskan pola berbeda untuk membangun struktur organisasi di DevOps, Anda akan memahami bahwa ini adalah anti-pola.
Ketika tim DevOps ada terus menerus selama beberapa tahun, ini adalah kesalahan besar, karena DevOps adalah tentang komunikasi antar departemen, tentang kecepatan dan efisiensi.
Jika sebuah tim ada antar departemen hanya untuk melakukan hal lain secara terpisah, dan ada untuk waktu yang lama, maka hal itu akan menciptakan penghalang yang tidak perlu. Sekarang pemrogram, alih-alih langsung menemui administrator untuk menyelesaikan masalah, harus terlebih dahulu menghubungi departemen DevOps, dan dia akan melanjutkan.
Oleh karena itu, untuk memulai, Anda perlu membuat tim sementara. Itu akan ada secara kondisional selama enam bulan, maksimal satu tahun, tergantung tugas yang ada, hanya untuk menghilangkan satu batasan yang kita pilih. Lalu dia akan mati. Jika kami memilih titik berikutnya di mana kami merasakan banyak kesakitan dan menyadari bahwa kami juga memerlukan tim terpisah untuk itu, maka kami akan menciptakannya lagi. Namun tim seperti itu tidak boleh ada “secara permanen” - karena mereka hanya mengganggu komunikasi dan umumnya mengambil tugas terpisah hanya untuk menyelesaikan sesuatu. Tugas-tugas ini mungkin tidak terkait dengan DevOps atau transformasi sama sekali. Mengapa kita tidak memberikan tugas ini kepada departemen yang ada?
Mengapa diperlukan tim sementara?
Konflik dengan proses saat ini. Transformasi DevOps bukan hanya perubahan dalam teknologi dan alat yang kita gunakan, namun perubahan dalam proses kerja, pemikiran, dan nilai-nilai. Jika tim bekerja seperti biasanya, maka tim tidak akan dapat mencoba pendekatan lain.
Orang-orang ini harus hidup dengan aturan yang berbeda: mengabaikan semua KPI di perusahaan karena mereka mencoba bekerja secara berbeda. Tim sementara tidak akan mengisi aplikasi untuk mendapatkan server, tetapi akan langsung mendatangi departemen yang mengelolanya, menuntut agar mereka diberikan apa yang mereka butuhkan terlebih dahulu, karena itu adalah prioritas dan karena mereka berusaha hidup berbeda. Tim ini sepenuhnya berkonflik dengan semua proses yang ada saat ini. Untuk memastikan bahwa praktik kerja yang ada tidak mengganggu mereka saat ini, dan tidak mengganggu orang lain, kami mengisolasi orang-orang ini ke dalam tim terpisah.
Menghindari birokrasi dalam eksperimen. Tim sementara tidak mempunyai birokrasi, mereka tidak membuat laporan waktu, mereka tidak melapor kepada manajer. Ini adalah dunia yang benar-benar terpisah di mana orang hidup dan berpikir secara berbeda serta melakukan hal yang sangat berbeda. Tidak perlu mengganggu mereka lagi.
Bekerja tanpa henti pada layanan ini. Pada poin pertama, kami memilih sesuatu yang akan kami coba. Bereksperimen dan menemukan cara untuk bekerja lebih baik adalah hal yang baik, tetapi kami juga ingin membuat fitur. Jika seluruh tim berfokus pada transformasi daripada fitur, maka kami akan mulai kehilangan pendapatan, bug akan bertahan lama - kami tidak memerlukannya. Membuat tim sementara memungkinkan Anda bereksperimen tanpa berhenti mengerjakan produk.
Jangan buang waktu untuk tugas pekerjaan. Ini tentang produk lagi. Dibutuhkan banyak waktu bagi tim untuk mencoba alat dan hal lainnya. Dibutuhkan setidaknya enam bulan bagi masyarakat untuk menguasai alat-alat tersebut, mulai menerapkannya dan menggunakannya secara normal. Jika mereka juga fokus pada produk, enam bulan akan berjalan secara kosmik. Jika orang mengerjakan suatu produk, mereka kembali mengerjakan proses lama - kita tidak memerlukannya.
Oleh karena itu, kami menugaskan orang-orang dari departemen berbeda ke tim terpisah yang akan mengubah layanan. Hasilnya, layanan ini berfungsi, terus berkembang, dan pada saat yang sama kami melakukan beberapa eksperimen terhadapnya.
Tim sementara ini didedikasikan hanya untuk transformasi DevOps - menghilangkan batasan yang kami temukan, dan tidak lebih.
Tim ini terdiri dari orang-orang yang serba bisa. Ini berarti kami tidak hanya mempekerjakan pengembang. Kami tidak datang ke pusat layanan dan mengambil separuh tim dari sana - tidak, kami mengambilnya orang-orang dari departemen yang berbeda. Beberapa saat yang lalu, kami menemukan berbagai departemen dan karyawan berbeda yang terkait dengan layanan yang diubah. Kami merekrut tim dari mereka, karena harus universal - kami akan mengubah proses pengujian, proses pengembangan, dan proses pemeliharaan layanan. Kompetensi yang berbeda diperlukan.
Biasanya kami mengajak pengembang, penguji, dan insinyur, satu per satu, dan bersama mereka kami menemukan solusi yang memungkinkan kami hidup secara berbeda.
Sangat diharapkan bahwa orang-orang ini memiliki otoritas dalam organisasi. Anda mungkin harus mengambil obat konservatif, meskipun Anda tidak mau. Jika kita mempunyai perusahaan yang besar, tidak semua orang akan mempercayai ide kita, dan ada yang mungkin akan menghalangi kita, misalnya dengan tidak memberikan pendirian. Di sinilah Anda memerlukan "otoritas" - orang terhormat dengan pengalaman luas yang telah mendapatkan sikap baik dari rekan-rekannya. Kewenangan pegawai dalam tim akan mempermudah tugas dan pekerjaan tim sementara. Orang akan berpikir:
- Ya, pria keren yang kita semua kenal dan cintai ini cocok di sana - rupanya ada sesuatu yang layak ditonton di DevOps!
Menetapkan tujuan
Kami mengumpulkan orang-orang, memilih layanan, melihat batasannya, dan menentukan orang mana yang akan kami pengaruhi. Sekarang Anda perlu menetapkan tujuan dan itu harus lurus oleh SMART - semua yang kita sukai.
Spesifik – spesifik.
Terukur – terukur. Ini adalah poin SMART yang sangat penting. Jika Anda tidak dapat mengukur sesuatu, Anda tidak dapat mengubahnya dan memahami apa dan bagaimana Anda melakukannya dengan lebih baik atau lebih buruk.
Dapat dicapai - dapat dicapai. Lakukan penyesuaian untuk memenuhi kebutuhan spesifik Anda. Jika Anda adalah perusahaan enterprise dengan sejarah panjang dan beban tanggung jawab yang besar, yang merilis versi produk setahun sekali, maka Anda tidak akan dapat merilis versi produk baru setiap jam dalam enam bulan. Ini tidak akan berhasil seperti itu. Oleh karena itu, tetapkan tujuan realistis yang dapat dicapai dalam jangka waktu yang dapat diterima.
Relevan – relevan. Kami hanya menghapus batasan-batasan yang benar-benar memenuhi tujuan kami saat ini.
Waktu Terbatas - waktu terbatas. Jika tidak ada tenggat waktu, tim akan melakukan apa pun yang mereka inginkan: mencoba 15 teknologi, bukan 3, menulis laporan besar, melakukan penelitian yang tidak berguna, memoles penerapannya hingga berhasil ketika tujuan telah tercapai.
Kami mengambil tujuan menggunakan Peta Aliran Nilai - kami mengumpulkan semua orang lagi dan menggambar mereka. Namun baru sekarang, berdasarkan Value Stream Map sebelumnya, kita menggambar apa yang ingin kita dapatkan.
Kami menyoroti satu batasan yang akan kami hilangkan saat ini - inilah yang akan dilakukan tim. Sebagai contoh, saya menunggu dari rilis selesai hingga penerapannya dalam produksi - ini adalah batasan paling umum yang membuat orang beralih ke konsultan.
Berdasarkan hal ini, kami menetapkan tugas: kami ingin waktu tunggu antara rilis selesai dan awal pertempuran maksimal satu jam.
Contoh tugas.
- Mengurangi Lead Time pengujian dari 4 hari menjadi 1 jam.
- Kurangi Waktu Nilai Tambah untuk pengujian dari 2 hari menjadi 3 jam.
- Mengurangi Lead Time penerapan dari 5 jam menjadi 10 menit.
- Meningkatkan C/A dari 50% menjadi 95%, yaitu meningkatkan jumlah fitur yang diterima penguji, dengan kata lain meningkatkan kualitas kerja pengembang.
Contoh tugas tidak diambil begitu saja dari kepala kita - tugas tersebut didasarkan pada pengukuran yang kita lakukan saat mengembangkan Peta Aliran Nilai.
Kami menetapkan tugas serupa untuk tim kami dan batas waktunya. Bergantung pada seberapa baik kinerja perusahaan Anda, Anda menetapkan tenggat waktu yang berbeda. Rata-rata, biasanya diperlukan waktu enam bulan untuk menghilangkan batasan tersebut, jika masyarakat baru pertama kali melakukan hal ini dan belum mengetahui teknologi apa dan seberapa spesifik mereka akan menyelesaikan masalah.
Perencanaan singkat
Jadi, tim kami dibuat, memiliki tujuan, orang-orang mulai bekerja. Poin penting adalah perencanaan kerja singkat: sprint satu hingga dua mingguDan tidak lagi, perbaikan yang terukur setiap minggu dan koreksi kursus.
Misalnya kita sering menggunakan pendekatan tersebut bergerak-bergerakKetika seluruh tim berkumpul di awal setiap minggu, mereka mencatat dalam sebuah file apa yang akan dilakukan setiap orang. Setelah seminggu, kami mencatat apa yang telah dilakukan dan apa yang belum, jika belum, lalu mengapa, dan kami memikirkan apa yang harus dilakukan selanjutnya.
Sprint memungkinkan Anda melakukan koreksi arah secara tepat waktu.
Selama satu atau dua minggu Anda mencoba sesuatu: teknologi, pendekatan, cara kerja, setelah itu Anda mengukur lagi dan melihat - apakah pendekatan ini menjadi lebih baik atau lebih buruk? Jika lebih buruk, itu berarti kita menuju ke arah yang salah, kita perlu memperbaiki arah: menetapkan tugas yang berbeda, menggunakan teknologi yang berbeda, atau melakukan hal lain. Sprint singkat selama 1-2 minggu memungkinkan Anda bermanuver dan menghindari keputusan buruk pada waktunya.
Berbagi kesuksesan
Tim mencapai kesuksesan, kecil atau besar - tidak masalah, selalu ada hasil. Semua orang harus mengetahui hasil ini: baik mereka yang terlibat dalam DevOps maupun departemen sekitarnya. Di dunia yang ideal, hal ini diinginkan untuk terjadi kepada semua orang di perusahaan.
Untuk apa? Jika kita ingin mengubah tidak hanya sebagian dari perusahaan, menghilangkan tidak hanya satu batasan, tapi semuanya secara umum, sehingga perusahaan menjadi fleksibel, kode cepat sampai ke klien, dan tidak ada yang rusak, kita memerlukan semua orang untuk setia pada ide tersebut. dari DevOps. Anda tidak akan bisa menerapkan pendekatan ini pada layanan dan tim yang dengan tegas menentangnya.
Agar loyalitas muncul, kami harus memberi tahu semua orang bahwa kami telah mencoba ini - kami mendapatkan hasil, cobalah juga! Hal ini akan meningkatkan minat dan loyalitas terhadap apa yang kita lakukan, orang akan mulai mencoba melakukan sesuatu sekarang juga. Seperti yang ditunjukkan oleh latihan, ketika kami memberi tahu Anda apa yang kami coba dan apa yang kami capai, tim lain mulai bertanya bagaimana dan apa yang kami lakukan. Mereka melihat implementasi, kode, dokumentasi, mengajukan pertanyaan, dan mencoba mengubah sesuatu dalam diri mereka.
Membicarakan apa yang Anda lakukan itu penting. Dengan cara ini Anda akan meyakinkan kaum konservatif yang ingin melakukan segala sesuatu dengan cara lama untuk bergabung dengan kelompok Anda dan mengubah mereka menjadi inovator.
Total
Memilih layanan, sebagai titik tolak – tempat dimana kita akan memulai perubahan dalam perusahaan. Kami mengidentifikasi semua orang yang ada hubungannya dengan layanan ini dan bersama mereka membangun Peta Aliran Nilai, kami mengukur dan melihat di mana dan apa saja batasannya.
Membuat tim sementara baru, yang akan menyelesaikan masalah. Berdasarkan pengukuran dan Value Stream Map kami menggambar peta baru, di mana kami menyoroti batasan yang akan kami selesaikan. Berdasarkan batasan ini menetapkan tugas, yang akan ditangani oleh tim. Tugasnya seharusnya tentu SMART - spesifik, terukur, relevan dengan tugas saat ini dan terbatas waktunya.
Ulangi prosesnya, sampai kami benar-benar mengubah semua layanan kami ke bentuk yang diperlukan dan menghilangkan semua batasan.
Bonusnya. Bahan yang bermanfaat
Bagi mereka yang memutuskan untuk melakukan DevOps sendiri.
Proyek Phoenix
Judul aslinya adalah “The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win.” Ini adalah novel tentang DevOps - kisah tentang bagaimana seorang karyawan diangkat menjadi kepala departemen yang selalu bersemangat. Bos baru diberi tugas:
“Anda memiliki waktu beberapa tahun untuk memperbaiki semuanya sehingga kami akhirnya dapat mengirimkan produk kami kepada pelanggan dengan cepat dan efisien.”
"Proyek Phoenix" Sebuah novel tentang bagaimana DevOps mengubah hidup menjadi lebih baik” adalah buku untuk semua manajer, karena mereka adalah orang-orang yang membuat keputusan tentang apa yang terjadi di perusahaan. Jika Anda seorang insinyur atau pemrogram dan ingin gerakan dan transformasi dimulai di perusahaan Anda, belilah buku dan berikan kepada manajemen. Novel ini menjelaskan segalanya dan cepat serta mudah dibaca.
Panduan DevOps
Buku ini lebih rumit. Buku ini diterbitkan beberapa tahun yang lalu dalam bahasa Inggris dengan judul “Buku Panduan DevOps Cara menciptakan kelincahan, keandalan, dan keamanan kelas dunia dalam organisasi Teknologi,” namun kini sudah tersedia dalam bahasa Rusia. ini nyata buku pegangan - panduan praktis: bagaimana melakukan pengukuran, apa itu Value Stream Map dan mengapa diperlukan, ke mana harus pergi, dalam urutan apa. Buku ini hanya untuk mereka yang ingin melakukan semuanya sendiri. Yang terpenting, memuat contoh pengalaman perusahaan lain.
Misalnya, ini menceritakan bagaimana sebuah perusahaan membangun Peta Aliran Nilai dan menyadari bahwa batasannya bukan pada produknya, namun pada kenyataan bahwa kasir berjalan dari toko ke kantor berikutnya untuk menggunakan produk ini. Alih-alih menyelesaikan masalah dengan program ini, mereka hanya membeli tablet untuk tenaga penjualan mereka, dan sekarang tidak ada seorang pun yang pergi ke mana pun, dan semua tindakan dilakukan di tempat kerja mereka. Kesimpulan: Value Stream Map dapat diperluas tidak hanya pada perangkat lunak, namun juga pada seluruh proses dalam organisasi.
Mempercepat
Judul lengkap: “Akselerasi: Ilmu Perangkat Lunak Lean dan DevOps: Membangun dan Meningkatkan Organisasi Teknologi Berkinerja Tinggi.” Ini adalah level selanjutnya - hardcore. Buku tersebut diterbitkan tahun lalu, sejauh ini hanya dalam bahasa Inggris dan membahas tentang penelitian. Para penulisnya—Nicole Forsgren, Jez Humble, dan Gene Kim—telah menggunakan praktik berbeda di berbagai perusahaan selama bertahun-tahun dan meneliti praktik mana yang memengaruhi apa dan bagaimana.
Bab kedua, tentang pengukuran, menyebutkan Value Stream Map, metrik yang saya sebutkan, dan banyak lainnya, serta menjelaskan proses pengukuran secara detail. Penulis mengukur menggunakan kuesioner dan tugas pelacakan mandiri. Di dalamnya dijelaskan secara rinci metrik mana yang benar untuk diukur, mana yang tidak boleh diukur, dan kesalahan manusia dalam pengukuran. Jika Anda mengalami kesulitan dalam pengukuran, lihat bab kedua buku "Accelerate". Jika tim Anda hanya memiliki banyak praktik, tetapi tidak jelas praktik mana yang harus diterapkan sekarang, mana yang nanti, mana yang benar-benar berhasil dan mana yang tidak - bacalah, buku ini menjelaskan semuanya.
Transformasi adalah masalah yang merupakan titik persimpangan antara DevOps dan manajemen. Di suatu tempat di persimpangan pengembangan, operasi, dan pengujian yang sama adalah topik yang kami coba diskusikan , integrasi yang sama diperlukan untuk menciptakan produk yang berkualitas - topik utama . Manajemen festival diserahkan - itu berarti setiap orang mempunyai ide untuk melakukan transformasi. Bergabunglah dengan kami pada tanggal 27 dan 28 Mei, kami akan berintegrasi dan bertransformasi.
Sumber: www.habr.com
