Cara memulai transformasi DevOps

Jika Anda tidak mengerti apa itu DevOps, maka inilah lembar contekan pendek. DevOps adalah serangkaian praktik yang mengurangi ketakutan insinyur dan mengurangi jumlah kegagalan dalam produksi perangkat lunak. Sebagai aturan, mereka juga mengurangi waktu ke pasar - periode dari ide hingga pengiriman produk akhir ke pelanggan, yang memungkinkan Anda untuk dengan cepat melakukan eksperimen bisnis .

Bagaimana cara memulai transformasi DevOps? Singkatnya: kami memilih layanan dari mana kami akan memulai proses, mengidentifikasi orang-orang yang terkait dengan layanan, membangun Value Stream Map, membuat tim sementara yang akan menangani transformasi untuk pertama kalinya dan menetapkannya sebagai tugas. Kami mengulangi siklus sebanyak yang diperlukan.


Rencana transformasi DevOps yang terperinci dengan contoh-contoh dan instruksi di bawah potongan tersebut ada dalam penguraian laporan Andrei Alexandrov , seorang insinyur di Express42, yang memberi saran tentang perkecambahan DevOps, mempercepat proses ini, karena telah membangun peta rake. Jika menurut Anda Anda tidak membutuhkan transformasi, atau jika Anda memiliki kekhususan sehingga praktik DevOps tidak cocok, gunakan laporan tersebut sebagai instruksi untuk menemukan dan menghilangkan batasan.

Jika Anda khawatir tentang masalah transformasi DevOps, maka Anda memiliki perusahaan besar, dan Anda perlu secara bertahap mengukur proses ini ke seluruh struktur. Selama ada kebutuhan untuk mengubah tim atau menghapus semacam pembatasan, algoritma di bawah ini dapat diulang.

Pilihan layanan

Kami telah menguraikan rencana, mulai dengan langkah pertama - memilih layanan. Kriteria pertama adalah seumur hidup : ada layanan lama - warisan, dan yang baru. Anda bisa mulai dengan itu dan yang lainnya.

Adalah logis untuk memilih layanan muda . Ini baru, tidak ada proses kerja yang mapan dalam tim yang berurusan dengannya. Di sekelilingnya tidak ada gunung hutang teknis, tidak perlu memperbaikinya sepanjang waktu. Kita dapat melakukan apapun yang kita inginkan dengannya.

Dalam hal layanan lama, ada masalah yang terkait dengan fakta bahwa selalu sulit untuk berubah . Sudah ada beberapa batasan serius, tetapi mungkin orang yang siap untuk mendorong semuanya melakukannya - mereka lelah dan ingin melakukan sesuatu yang berbeda, karena itu menyakitkan.

Bekerja dengan layanan lama menciptakan preseden yang kuat di perusahaan Anda - Anda dapat mengubah sesuatu. Jika Anda mengubah layanan baru, layanan akan bergulir hingga 100 kali per jam, dan semuanya baik-baik saja, maka orang di perusahaan Anda dapat mengatakan:

- Ini adalah layanan baru! Semuanya ada di sana sederhana, cobalah untuk melakukan sesuatu dengan hal-hal germo kami.

Masuk akal untuk mengambil layanan Legacy ke dalam transformasi ketika Anda melakukannya dengan seseorang, misalnya, jika Anda mengundang konsultan eksternal. Jujur saja, transformasi akan mengejutkan segala hal yang mungkin terjadi . Anda sedang bereksperimen dan tidak tahu di mana Anda akan datang, teknologi apa dan mengapa Anda akan menggunakan, di mana dan apa perangkap akan muncul dalam proses. Karenanya, perubahan baru lebih mudah.

Jika Anda melakukan semuanya sendiri, tetapi perusahaan tidak memiliki kompetensi serius, kami mengambil layanan baru. Jika Anda mengenal konsultan eksternal dan ada dana - pilih yang lama.

Ada layanan yang hanya merupakan antarmuka bagi pengguna, misalnya, situs web sederhana atau aplikasi seluler. Tetapi ada hal-hal serius dalam semangat penagihan. Jika ada yang salah dengan penagihan, akan sulit dimengerti. Di sini kita juga punya pilihan.

Kami bekerja dengan layanan kritis , tetapi sudah menderita karena itu, itu membuat batasan, atau kami bekerja dengan antarmuka . Ini adalah kriteria seleksi kedua. Demikian pula, dimungkinkan untuk menarik konsultan yang berpengalaman - kami bekerja dengan opsi yang sulit.

Tetapi bahkan dalam kasus ini, saya tidak akan menyarankan melakukannya, karena sementara tidak ada pemahaman apa yang harus bekerja dengan dan bagaimana mengubah, mengambil hal yang kritis dan mengguncang itu bukan ide yang baik. Oleh karena itu, dalam hal ini, kami lebih suka bekerja dengan antarmuka yang kegagalannya tidak kritis.

Selanjutnya, pertimbangkan perintah layanan . Dengan mereka yang terlibat dalam layanan ini, kami harus terus bekerja dan berinteraksi dalam kontak yang sangat dekat.

Orang-orang dalam tim secara kondisional dibagi menjadi dua kategori: konservatif - mereka hidup di dunia lama, atau tidak tahu apa-apa tentang DevOps, dan inovator yang melakukan semua praktik mode. Yang terakhir tidak selalu mengerti topik, tetapi setidaknya mereka siap untuk itu.

Di satu sisi, kaum konservatif adalah orang-orang yang berpengalaman: mereka telah lama bersama perusahaan, mereka memahaminya sepenuhnya, tetapi mereka tidak tahu hanya tentang praktik. Di sisi lain, ada inovator yang telah mendengar sesuatu, tetapi kemungkinan besar mereka telah bekerja untuk perusahaan belum lama ini. Mana dari mereka yang lebih baik untuk bekerja?

Bagaimanapun, Anda harus berinteraksi dengan kaum konservatif, karena ini adalah layanan mereka. Kami harus berkomunikasi dengan mereka, mencari tahu spesifik layanan, apa yang bisa dilakukan dengan cara ini dan apa yang berbeda. Kami bergantung pada saran mereka. Tentunya mereka harus mempercayakan sesuatu, karena mereka tahu layanan mereka lebih baik. Karena itu, penting bagi tim mana kita akhirnya akan memiliki kontak.

Adalah logis untuk memilih tim inovator, karena konservatif dapat menempatkan babi.

Dalam praktiknya, sering terjadi bahwa orang-orang konservatif memiliki pengalaman yang signifikan, tetapi tidak ada pemahaman tentang cara hidup. Mereka hanya takut bahwa setelah transformasi dan perubahan layanan, mereka akan diberhentikan sebagai tidak perlu. Kadang-kadang, hanya karena kurangnya pemahaman tentang apa yang terjadi, mereka menyabot pekerjaan itu.

Saya punya kasus ketika seorang pria dari tim memperbaiki apa pun, karena itu seharusnya lebih kritis daripada apa yang kita lakukan sekarang. Kami menetapkan tugas: untuk mewujudkan karya ini hari ini - tidak, ada api di sisi lain dunia, kami akan memperbaikinya. Sulit untuk bekerja dengan orang-orang seperti itu.

Orang-orang dari tim konservatif sering menyumbat tugas, atau menunda sampai yang terakhir. Dan jika, John Willis menyelamatkan Anda, Anda membuat kesalahan dan menggantungnya dengan KPI untuk jumlah tugas yang diselesaikan, dan untuk beberapa alasan beberapa dari mereka tidak termasuk dalam KPI, maka mereka tidak akan melakukan apa-apa sama sekali. Secara umum, mereka akan benar, karena mereka kehilangan bonus.

Lebih mudah dengan inovator - mereka lebih loyal . Mereka sudah mendengar sesuatu, mereka ingin pergi ke suatu tempat, sehingga mereka akan membantu. Kami membutuhkan orang-orang yang siap menderita pertama kali: jika layanan berubah, maka semua kerucut dan garu akan ditangkap oleh inovator sebagai pelopor. Inovator menginginkan yang terbaru dan paling modis, dan menderita.

Konservatif nantinya dapat dikonversi. Ketika Anda menunjukkan bahwa Anda telah mengubah karya seni dan semuanya bekerja dengan baik, kemungkinan besar mereka juga ingin mencoba dan mengadopsi agama DevOps baru.

Untuk meringkas. Jika kita melakukan semua transformasi di perusahaan kita sendiri, maka kita memilih: layanan baru, lebih disukai antarmuka yang sederhana, agar tidak banyak menderita dari kerusakannya, dan tim inovator.

Jika dimungkinkan untuk memanggil konsultan eksternal, alih-alih yang baru, kami menggunakan layanan lama, karena itu kami sudah menderita. Orang-orang yang telah terlibat dalam transformasi untuk beberapa waktu di berbagai perusahaan telah melihat berbagai kasus dan sudah memahami bagaimana melakukannya dengan benar dan ke mana harus pergi secara umum.

Siapa yang terlibat?

Kita perlu menemukan secara umum setiap orang yang setidaknya memiliki hubungan dengan layanan: pengembang, penguji, admin, penjaga keamanan, manajer, dan mungkin juga Pemilik Produk. Terlepas dari kenyataan bahwa Pemilik Produk bukan teknisi, mereka terkait dengan layanan: membuat keputusan, menetapkan tugas.

Setiap orang yang membuat setidaknya beberapa keputusan dan memengaruhi apa yang terjadi dengan layanan perlu menemukan, bertemu, dan mengobrol.

Apa itu untuk kita? Untuk mengetahui siapa yang harus dinegosiasikan . Selama transformasi, ketika prinsip biasa bekerja dengan layanan berubah, itu akan bergetar pula. Akan ada gangguan untuk sementara waktu sementara kami menguji pendekatan baru. Orang harus siap untuk ini dan setuju dengannya.

Maka Anda harus membangun Value Stream Map dan tanpa orang-orang ini Anda tidak dapat membangunnya, karena hanya mereka yang bersama-sama yang mengetahui gambaran lengkap tentang apa yang terjadi. Satu orang tidak pernah tahu semua yang terjadi dengan layanan ini.

Mereka akan memberi saran kepada orang-orang di tim. Nanti kita akan membahas mengapa tim terpisah diperlukan. Itu harus mengambil orang dari departemen yang ada. Mereka yang terkait dengan layanan akan dapat merekomendasikan kolega yang berpikir ke arah kita, yang dapat membantu kita dan memiliki kompetensi dalam apa yang kita butuhkan.

Lalu kami mengumpulkan semua orang ini dari berbagai departemen ke dalam satu ruangan dan mulai membangun Value Stream Map.

Membangun Peta Stream Nilai

Value Stream Map adalah diagram atau peta yang menunjukkan aliran nilai ke klien . Ini adalah keseluruhan proses dari menciptakan ide hingga implementasinya, termasuk semua tahap peralihan dan bagaimana nilai akhirnya mencapai pelanggan kami.

Value Stream Map diperlukan untuk memvisualisasikan semua tahap pengembangan , untuk melokalisasi masalah melalui pengukuran yang ada dalam proses saat ini, dan untuk mulai menghilangkan masalah ini dan menetapkan tujuan awal . Ini adalah tempat di mana kita akan mulai melakukan sesuatu.

Metrik

Ada banyak metrik yang berbeda yang dijelaskan dalam literatur Value Stream Map, tetapi sebagai permulaan, kita hanya perlu tiga.

Lead Time - delay / wait - waktu ketika kita menunggu sesuatu. Sebagai contoh, tester menunggu sampai dudukan tes dibebaskan dan tidak dapat melakukan apa pun saat ini.

Nilai Tambah Waktu - waktu kerja yang bermanfaat - yang kami habiskan pada tahap ini dan itu untuk menciptakan nilai akhir bagi pengguna. Sebagai contoh, seorang tester menjalankan tesnya dan mulai menguji sesuatu. Ini adalah waktu kerja yang bermanfaat ketika kita benar-benar melakukan sesuatu untuk produk tersebut. Inilah yang pelanggan bayar - untuk perangkat lunak berkualitas.

% C / A - persentase pekerjaan yang diterima. Kami memiliki satu tahap - pengembangan, tahap kedua - pengujian. Berapa banyak fitur yang diambil penguji dari pengembang, dan ada persentase ini.

Seperti inilah peta kita.



Mungkin terlihat berbeda tergantung pada struktur organisasi, jumlah departemen dan apa yang Anda lakukan. Namun dalam kasus umum, peta akan memiliki dua tahap: ide dan analitik . Pada titik ini, data diharapkan, misalnya, Waktu Pimpin 2 minggu dan Nilai Tambah Waktu 2 hari.

Metrik mencakup sepenuhnya semua tahapan.

Backlog - berapa banyak tugas yang diletakkan setelah analis mengatasinya.

Pengembangan - berapa minggu pengembang telah menunggu klarifikasi tentang tugas, berdiri atau peralatan - itu tidak masalah, tetapi mereka sedang menunggu sesuatu. Misalnya, mereka menerapkan fitur selama 4 hari. Metrik% C / A muncul di sini. Pengembang hanya mengambil 80% tugas dari Backlog. Mereka percaya bahwa 20% sisanya tidak memiliki TK yang jelas, dan mengirim mereka untuk direvisi.

Pengujian . Pada skema LT, 4 hari ditetapkan. Misalnya, penguji menunggu bangku tes akan dirilis, VA selama 2 hari mereka benar-benar menguji sesuatu, dan% C / A = 40%. - hanya 40% dari kode atau fitur yang dikirim pengembang dianggap cukup oleh penguji. Mereka tidak suka yang lain karena suatu alasan.

Saya tidak akan membahas cara melakukan pengukuran-pengukuran ini, di akhir artikel saya akan merekomendasikan literatur yang dapat Anda pelajari tentangnya.

Satu-satunya hal yang saya sarankan adalah jangan percaya orang-orang yang akan menyusun Value Stream Map bersama Anda. Mereka mewakili berapa banyak waktu proses yang berbeda, tetapi perkiraan ini tidak selalu benar, oleh karena itu lebih baik untuk mengukur diri sendiri.

Kami memiliki kasus ketika kami datang ke departemen Operasi dan bertanya berapa lama untuk mengirimkan fitur baru ke produksi. Mereka menjawab 10 menit, dan kami berpikir, mengapa kami datang ke perusahaan ini? Ternyata 10 menit adalah waktu berjalan skrip, yang mengambil kode dan mengirimkannya ke server. Tetapi sebelum ini, rilis terletak tiga hari di server dan hanya mengumpulkan debu - di Backlog terletak tugas yang perlu dikerahkan. Ternyata sebelum tahap penempatan ada tahap menunggu ketika proyek hanya terletak. Jika kita tidak pergi dengan buku catatan, tidak memperhatikan tugas di Jira, dan tidak mulai melacaknya secara bertahap, kita akan menganggap bahwa semuanya indah dan tidak ada masalah.

Oleh karena itu, pengukuran masih harus dilakukan sendiri, lebih disukai lebih dari sekali, agar memiliki representasi yang mendekati kenyataan. Bergantung pada Value Stream Map, Anda akan memutuskan di mana untuk memulai dan apa yang harus diperbaiki terlebih dahulu.

Tim sementara

Banyak perusahaan yang telah memutuskan untuk memperkenalkan DevOps membuat tim, tidak hanya sementara, tetapi sudah ada selama beberapa tahun. Jika Anda pergi ke layanan permintaan maaf DevOps, yang menggambarkan berbagai pola untuk membangun struktur organisasi di DevOps, maka Anda akan memahami bahwa ini adalah antipemutakhir.

Ketika tim DevOps telah 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 di antara departemen, hanya untuk melakukan sesuatu yang terpisah, dan ada untuk waktu yang lama, maka itu menciptakan penghalang tambahan. Sekarang, alih-alih langsung ke administrator, programmer harus terlebih dahulu menghubungi departemen DevOps, dan dia akan melangkah lebih jauh.

Karena itu, untuk memulai, Anda perlu membuat tim sementara . Itu akan ada untuk periode enam bulan ditangguhkan, maksimum satu tahun, tergantung pada tugas, hanya untuk menghilangkan satu batasan yang telah kita pilih. Maka dia akan mati. Jika kita memilih titik berikutnya di mana itu sangat menyakitkan dan memahami bahwa kita juga membutuhkan tim terpisah untuk itu, maka kita akan membuatnya lagi. Tetapi tim seperti itu seharusnya tidak ada pada "dasar permanen" - maka mereka hanya mengganggu komunikasi dan mengambil tugas terpisah secara umum, hanya untuk melakukan sesuatu. Tugas-tugas ini mungkin tidak terkait dengan DevOps atau transformasi sama sekali. Mengapa kita tidak memberikan tugas ini ke departemen yang ada?

Mengapa Anda membutuhkan tim sementara

Konflik dengan proses saat ini . Transformasi DevOps adalah perubahan tidak hanya dari teknologi dan alat yang kami gunakan, tetapi juga perubahan dalam proses kerja, pemikiran, dan nilai-nilai. Jika tim bekerja seperti biasanya, ia tidak akan dapat mencoba pendekatan lain.

Orang-orang ini harus hidup dengan aturan yang berbeda: abaikan semua KPI di perusahaan, karena mereka mencoba bekerja secara berbeda. Tim sementara tidak akan mengisi aplikasi untuk mendapatkan server, tetapi akan langsung pergi ke departemen yang mengelola mereka, menuntut mereka menjadi yang pertama memberikan apa yang mereka butuhkan, karena ini adalah tugas prioritas dan karena mereka mencoba untuk hidup secara berbeda. Tim memiliki konflik penuh dengan semua proses saat ini. Agar metode kerja yang ada tidak mengganggu mereka sekarang, dan mereka tidak mengganggu yang lain, kami mengisolasi orang-orang ini dengan memilih mereka sebagai tim yang terpisah.

Menghindari birokrasi dalam eksperimen . Tidak ada birokrasi di tim sementara, mereka tidak mengisi laporan jam kerja, mereka tidak melapor kepada manajer. Ini adalah dunia yang sepenuhnya terpisah di mana orang hidup dan berpikir secara berbeda, dan melakukan hal-hal yang sama sekali berbeda. Jangan ganggu mereka sekali lagi.

Pekerjaan tanpa henti pada layanan ini . Di paragraf pertama, kami telah memilih sesuatu untuk diuji. Bereksperimen dan menemukan cara untuk bekerja lebih baik itu baik, tetapi kami juga ingin melakukan fitur. Jika seluruh tim melakukan transformasi alih-alih fitur, maka kami akan mulai kehilangan pendapatan, bug akan menggantung dalam waktu yang lama - kami tidak membutuhkan ini. Membuat tim sementara memungkinkan Anda untuk bereksperimen tanpa menghentikan pekerjaan pada produk.

Jangan buang waktu untuk tugas kerja . Ini lagi tentang produk. Butuh banyak waktu bagi tim untuk mencoba alat dan barang lain. Agar orang menguasai alat, mulai menerapkannya dan menggunakannya secara normal, itu akan memakan waktu setidaknya enam bulan. Jika mereka juga akan berurusan dengan produk - enam bulan meregang secara kosmik. Jika orang terlibat dalam suatu produk, mereka kembali bekerja dengan proses lama - kita tidak membutuhkan ini.

Oleh karena itu, kami memisahkan orang-orang dari departemen yang berbeda menjadi tim terpisah yang akan menangani transformasi layanan. Hasilnya, layanan ini bekerja, terus berkembang, dan pada saat yang sama, kami melakukan beberapa percobaan.

Tim sementara hanya terlibat dalam transformasi DevOps - menghilangkan batasan yang kami temukan, dan tidak lebih.

Tim ini terdiri dari orang-orang universal . Ini berarti bahwa kami mengambil tidak hanya pengembang. Kami tidak datang ke layanan dan tidak mengambil setengah tim dari sana - tidak, kami membawa orang dari departemen yang berbeda . Beberapa poin yang lalu, kami menemukan berbagai departemen dan karyawan yang terkait dengan layanan transformasi. Dari jumlah tersebut, kami merekrut tim, karena harus bersifat universal - kami akan mengubah proses pengujian, proses pengembangan, dan proses servis layanan. Kompetensi yang berbeda diperlukan.

Biasanya, kami mengambil pengembang, penguji, dan insinyur secara bersyarat - masing-masing pada satu waktu, dan bersama dengan mereka kami memberikan solusi yang memungkinkan Anda untuk hidup secara berbeda.

Sangat diharapkan bahwa orang-orang ini memiliki wewenang dalam organisasi . Anda mungkin harus mengambil satu konservatif, walaupun Anda tidak mau. Jika kita memiliki perusahaan besar, tidak semua orang akan percaya pada usaha kita, dan seseorang dapat meletakkan tongkat di atas roda, misalnya, tidak menyoroti penyangga. Di sini Anda akan membutuhkan "otoritas" - orang yang dihormati dengan pengalaman luas, yang pantas menerima sikap baik dari rekan kerja. Otoritas karyawan dalam tim akan menyederhanakan tugas dan pekerjaan tim sementara. Orang akan berpikir:

- Ya, pria keren ini yang kita semua kenal dan cintai, cocok di sana - rupanya, DevOps memiliki sesuatu yang layak untuk dilihat!

Kami menetapkan tujuan

Kami mengumpulkan orang, memilih layanan, melihat batasan, menentukan orang yang akan kami pengaruhi. Sekarang Anda perlu menetapkan tujuan dan itu harus benar di SMART - hanya itu yang kami sukai.

Spesifik - spesifik .

Terukur - terukur . Ini adalah poin yang sangat penting dari SMART. Jika Anda tidak dapat mengukur sesuatu, maka Anda tidak dapat mengubahnya dan memahami apa dan bagaimana Anda telah melakukan lebih baik atau lebih buruk.

Dapat dicapai dapat dicapai . Sesuaikan untuk spesifik Anda. Jika Anda adalah perusahaan perusahaan dengan sejarah panjang dan beban tanggung jawab besar, yang merilis versi produk setahun sekali, Anda tidak akan dapat mencapai rilis versi produk baru setiap jam dalam enam bulan. Itu tidak akan berhasil seperti itu. Oleh karena itu, tetapkan tujuan nyata yang dapat dicapai dalam periode yang dapat diterima.

Relevan - Relevan. Kami hanya menghilangkan batasan yang benar-benar mengejar tujuan kami saat ini.

Waktu Terbatas - waktu terbatas . Jika tidak ada tenggat waktu, tim akan melakukan apa saja: coba 15 teknologi, bukan 3, tulis laporan besar, lakukan penelitian tidak berguna, jilat implementasinya hingga bersinar ketika tujuan sudah tercapai.

Kami mengambil sasaran dengan bantuan Value Stream Map - lagi-lagi kami mengumpulkan semua orang dan menggambar. Tetapi hanya sekarang, berdasarkan Value Stream Map sebelumnya, kami menggambar apa yang ingin kami dapatkan.



Kami menetapkan satu batasan yang akan kami hilangkan saat ini - inilah yang akan dilakukan tim. Sebagai contoh, saya mengambil ekspektasi dari rilis yang telah selesai ke penyebarannya dalam produksi - ini adalah batasan paling umum yang orang beralih ke konsultan.

Berdasarkan hal ini, kami menetapkan tugas: kami ingin menunggu antara rilis siap dan beraksi menjadi maksimum satu jam.

Contoh tugas.

• Kurangi pengujian Lead Time dari 4 hari menjadi 1 jam.
• Kurangi Waktu Nilai Tambah untuk pengujian dari 2 hari menjadi 3 jam.
• Kurangi penyebaran Lead Time dari 5 jam menjadi 10 menit.
• Tingkatkan C / A dari 50% menjadi 95%, yaitu, meningkatkan jumlah fitur yang diterima penguji, dengan kata lain, meningkatkan kualitas pengembang.

Contoh tugas tidak diambil dari kepala - mereka didasarkan pada pengukuran yang kami lakukan saat mengembangkan Value Stream Map.

Kami menetapkan tugas yang serupa dengan tim kami dan batas waktu. , , . , , , .

, , , . — : - , , .

, moving-moving , , , . : , , , , , .

.

- : , , , — ? , , : , - . 1-2 .

- , — , - . : , DevOps, . , .

Mengapa , , , , , , , DevOps. , .

, , — , ! , , - . , , , , . , , , - .

, — . , - .

, — , . , - Value Stream Map , , .

, . Value Stream Map , , . , . SMART — , , .

, .

.

, DevOps .

«»

— «The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win». DevOps — , , . :

— , , .

« “”. , DevOps » — , , . , — . , .

DevOps

. «The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations», . handbook — : , Value Stream Map , , . , . , .

, , Value Stream Map , , , , . , , , , . : Value Stream Map , .

Accelerate

: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». — . , . — Nicole Forsgren, Jez Humble Gene Kim — , , .

, , Value Stream Map, , , , . . , , , . , «Accelerate». , , , , , — , .

Transformasi adalah persimpangan antara DevOps dan manajemen. Di suatu tempat di area yang sama dengan persimpangan pengembangan, operasi dan pengujian adalah topik yang kami coba diskusikan di DevOpsConf , integrasi yang sama diperlukan untuk menciptakan produk yang berkualitas - tema utama QaulityConf . Manajemen di festival RIT ++ disajikan oleh Whale Rider - yang berarti ide untuk transformasi semua yang ada di sana. Bergabung pada 27 dan 28 Mei, kami akan berintegrasi dan bertransformasi.