Mengotomatiskan pengembangan perangkat lunak dan mempercepat inovasi

Pengembangan perangkat lunak tradisional lambat. Ini hanya untuk berpikir ulang.

Hampir tiga tahun lalu Satya Nadella dari Microsoft dengan terkenal menciptakan bahwa “setiap bisnis akan menjadi bisnis perangkat lunak”. Saat ini, pasar perangkat lunak global senilai $500 miliar berada di jalur untuk berlipat ganda menjadi $1 triliun pada tahun 2030.

J.P. Morgan tercatat memiliki 40.000 insinyur perangkat lunak (lebih dari Alphabet) dalam pengarsipan terbaru mereka. Setiap perusahaan besar berlomba untuk merekrut insinyur untuk mengembangkan pesaing mereka. Masalah besarnya adalah pengembangan perangkat lunak tradisional lambat, terfragmentasi, dan boros.

Misalnya, setiap minggu insinyur perangkat lunak rata-rata akan menghabiskan 4 jam menunggu tes selesai, 3,5 jam menunggu build, dan 3 jam untuk manajemen lingkungan — lebih dari seperempat minggu kerja mereka tidak benar-benar menciptakan sesuatu yang berharga. Ketika Anda menganggap bahwa insinyur sering kali merupakan orang dengan bayaran tertinggi dalam organisasi, itu jelas merupakan masalah besar. Namun, banyak hal berubah.

Salah satu platform pengembangan terkemuka, CircleCI, bertaruh bahwa AI dan otomatisasi akan menjadi kunci untuk mempercepat inovasi perangkat lunak dan membebaskan para insinyur untuk melakukan pekerjaan penting. Pada tahun lalu, perusahaan memperkenalkan sejumlah peningkatan otomatisasi dan pembelajaran mesin yang mengurangi waktu tunggu para insinyur hingga 50%. Ini adalah salah satu dari banyak alasan mengapa lebih dari 300.000 pengembang termasuk di Facebook, Spotify, GoPro, InstaCart, dan banyak lainnya beralih ke CircleCI untuk bergerak lebih cepat.

Pemimpin perusahaan adalah Jim Rose — enam kali pendiri dengan investasi masa lalu dari Google Ventures, Foundation Capital, dan Marc Andreessen. Sejak bergabung dengan CircleCI lebih dari empat tahun yang lalu, Rose telah meningkatkan pendapatan lebih dari 450% dan mengembangkan perusahaan menjadi entitas yang benar-benar menarik.

Tertarik untuk mempelajari lebih lanjut tentang mengotomatisasi pengembangan perangkat lunak dan mempercepat inovasi, Era Informasi berbicara kepada Rose tentang masalah ini.

Bagaimana keadaan pasar perangkat lunak saat ini?

Saat ini masih banyak perusahaan dan individu yang melakukan proses yang berbeda secara manual. Ketika Anda memikirkan proses transformasi digital, ini benar-benar tentang mencoba membina tim pengembangan perangkat lunak.

Salah satunya adalah mencoba mengeluarkan perangkat lunak dari pusat data lokal dan memasukkannya ke lingkungan cloud-native, tempat Anda bisa mendapatkan akses ke komputasi secara instan.

Yang kedua adalah bahwa perangkat lunak, secara tradisional atau dalam banyak kasus, telah dilihat sebagai pedoman atau tambahan untuk bisnis utama. Sekarang Anda memiliki semua jenis bisnis mulai dari bank hingga produsen mobil hingga pengecer, semuanya menyadari bahwa perangkat lunak adalah inti dari apa yang mereka lakukan. Jadi mereka perlu mencari tahu apa yang mereka miliki dan mereka harus mengkonsolidasikan aset mereka dan mengintegrasikannya sebagai standar.

Setelah perusahaan memiliki akses instan ke komputasi dan mereka memiliki struktur di tempat pengembang dapat bekerja, apa yang ada di antaranya saat ini biasanya adalah semacam campur aduk dari berbagai platform dan proses.

Dalam kebanyakan kasus Anda memiliki proses rilis perangkat lunak air terjun yang sangat panjang yang memiliki banyak langkah manual dan kemudian mereka memiliki banyak skrip manual. Dalam beberapa kasus untuk toko yang lebih maju, mereka mungkin memiliki solusi otomatisasi generasi pertama, tetapi seiring dengan kecepatan tim, solusi tersebut mulai rusak.

Dan sekarang itulah yang kami hadapi dan membantu perusahaan menavigasi. Saat tim perangkat lunak mereka semakin cepat, mereka membangun lebih banyak perangkat lunak dan saat mereka mencoba melakukannya lebih cepat; agar responsif terhadap peluang di pasar tetapi juga responsif terhadap potensi perubahan negatif. Bisnis hanya perlu benar-benar memikirkan kembali bagaimana semua bagian itu disatukan.

Apakah kecepatan ini yang Anda maksud sebagai rintangan utama dalam pengembangan perangkat lunak?

Perusahaan dan tim pengembangan berusaha untuk mempercepat karena pasar semakin cepat. Mereka mencoba mencari tahu bagaimana mereka dapat bekerja dengan cepat sehingga mereka dapat mengatasi peluang.

Satu-satunya cara untuk mencapainya adalah dengan mengotomatiskan semua langkah yang tidak perlu campur tangan manusia, karena alih-alih melakukannya dalam hitungan menit, jam, dan hari, Anda dapat melakukannya dalam hitungan detik.

Saat tim semakin cepat, dan karena perangkat lunak adalah etalase utama bagi pelanggan Anda, Anda harus memastikan bahwa tingkat kualitasnya tinggi; Anda harus memastikan bahwa itu tidak mogok atau Anda tidak memiliki kerentanan keamanan, misalnya.

Jadi, ketika Anda berpikir tentang gesit, ini tentang mencoba menjadi lebih gesit, baik dari perspektif kualitas maupun dari perspektif kecepatan.

Di AS, ini semua tentang kecepatan tetapi dengan berjalan lebih cepat, mengintegrasikan potongan yang lebih kecil dan mampu merilis perangkat lunak secara lebih konsisten, perangkat lunak Anda secara inheren menjadi lebih baik. Semua ketakutan tentang keharusan menerapkan itu hilang ketika Anda melakukannya lima, delapan, 15 kali seminggu, dan dalam beberapa kasus kami memiliki pelanggan yang melakukannya 100 kali sehari.

Penerapan tidak menjadi masalah.

Di sisi kualitas, salah satu masalah besar untuk pengembangan perangkat lunak di masa lalu adalah jika Anda hanya merilis sekali dalam seperempat, Anda akan mengalami kesulitan untuk memastikan bahwa semua perubahan yang Anda masukkan ke dalam aplikasi Anda benar-benar berfungsi bersama. Sering kali Anda melihat perusahaan melakukan rilis big bang dan kemudian setelah mereka melakukan rilis big bang, mereka menghabiskan 60, 90 hari berikutnya untuk mencoba memperbaiki semua hal yang mengalami kemunduran dan kerusakan. Dalam metode ini, siklus perangkat lunak Anda melambat, tetapi juga kualitas aplikasi itu sendiri menurun.

Dari sudut pandang yang gesit, itulah yang coba diatasi oleh orang-orang.

Bagaimana organisasi dapat berubah untuk mengakomodasi, mendukung, dan membina tim pengembangan perangkat lunak?

Ada beberapa cara berbeda.

Salah satunya adalah bahwa pengembang sulit untuk dipekerjakan sehingga Anda ingin memastikan bahwa semua waktu yang dihabiskan dari perspektif pengembangan didedikasikan untuk membangun perangkat lunak khusus Anda, apa pun itu; jika Anda seorang bank, membangun aplikasi perbankan yang hebat, jika Anda adalah aplikasi e-niaga, membangun aplikasi e-niaga yang sangat hebat. Saya pikir salah satu area besar yang kurang diinvestasikan orang adalah bahwa pengembang perangkat lunak secara historis membangun sesuatu. Itulah yang mereka lakukan, mereka membangun perangkat lunak. Jadi, siklus pengembangan kurang diinvestasikan dari perspektif aplikasi pihak ketiga.

Ada hal-hal seperti, misalnya, otomatisasi pengujian dan infrastruktur pengiriman berkelanjutan yang tidak harus dibangun sendiri oleh tim. Anda jauh lebih baik mendapatkannya dari orang lain yang berspesialisasi dalam bidang itu sehingga Anda dapat fokus pada hal yang Anda kuasai. Ini seperti memberi tahu seseorang bahwa mereka perlu membuat pembuat kopi dan memberi mereka seikat pipa tembaga, beberapa solder, dan beberapa katup. Anda tidak akan pernah melakukan itu. Namun secara historis, pembangunan telah diperlakukan seperti itu. Jadi, menempatkan alat dan platform yang tepat pada tempatnya benar-benar penting, mulai dari atas dan bawah, dari pusat data hingga alat perencanaan.

Saya pikir bagian kedua adalah bahwa dalam model air terjun tradisional, pengembangan perangkat lunak biasanya memainkan peran penangkap, sehingga aplikasi didefinisikan jauh lebih awal dalam proses dan kemudian pada saat tim pengembangan mendapatkannya, ada sejumlah keputusan yang dibuat yang mungkin atau mungkin tidak benar-benar berfungsi dan mungkin atau tidak layak atau mudah dilakukan.

Ada gagasan tentang shift kiri, yang mencoba mendorong pengembangan lebih jauh dan lebih jauh ke siklus perencanaan sehingga kekhawatiran atau kebutuhan tim pengembangan dipertimbangkan baik dalam konstruksi aplikasi maupun dalam pengirimannya. Dan kemudian ketika Anda memikirkannya dari perspektif operasional, itu berarti Anda benar-benar harus memikirkan bagaimana aplikasi dioperasikan jauh lebih awal dalam siklus hidup juga. Misalnya, jika Anda mencoba membuat aplikasi cloud-native, Anda harus merancangnya dengan cara yang sangat khusus, yang berarti Anda harus membuat keputusan itu dan harus menjadi bagian dari proses itu lebih awal.

Ketika tim mengadopsi lebih banyak perangkat lunak, proses gesit, Anda berakhir dengan triangulasi kekhawatiran. Anda memiliki orang-orang dan pemilik bisnis serta manajer produk yang memiliki alasan mengapa Anda membangun sesuatu. Anda memiliki arsitek teknis dan pengembang perangkat lunak yang benar-benar berbicara tentang bagaimana Anda membangunnya. Dan kemudian Anda memiliki operator, yang bertanggung jawab untuk benar-benar menjalankannya, mencari tahu apa yang sebenarnya Anda jalankan di akhir seluruh proses itu. Jadi semua orang perlu terlibat. Dan itu bisa menjadi transisi yang sulit bagi beberapa perusahaan.

Bagaimana AI dan otomatisasi dapat memacu dan meningkatkan inovasi perangkat lunak?

Dengan otomatisasi Anda dapat mengotomatisasi tugas-tugas yang telah ditentukan sebelumnya, serta belajar mandiri. Contohnya adalah jika setiap kali Anda mencoba dan merilis perangkat lunak, Anda harus melakukan pengujian pihak ketiga terhadap beberapa sistem pembayaran pihak ketiga lainnya. Di masa lalu dengan tugas-tugas itu, Anda harus menyewa tim QA yang pada dasarnya akan mencoba dan memproses transaksi dan melakukan semuanya secara manual, yang sangat lambat. Ini juga sangat penuh dengan kesalahan dan komplikasi.

Ini adalah contoh sempurna dari tugas yang harus sepenuhnya otomatis dalam rangkaian pengujian Anda — semua hal ini yang Anda tahu akan Anda lakukan berulang kali, Anda harus mengotomatiskan tugas-tugas tersebut untuk membuatnya deterministik dan dapat diprediksi. Dan akhirnya cepat.

Ada peluang untuk melakukan tugas berulang yang setiap menit yang dihabiskan oleh pengembang melakukan hal-hal itu berulang-ulang adalah buang-buang waktu dan, sejujurnya, buang-buang uang.

Jadi, ketika Anda melihat AI dan perangkat lunak yang sedang dibangun, alih-alih berpikir untuk mendorong perangkat lunak deterministik prediktif, yang Anda lakukan adalah mendorong model. Dan modelnya adalah kotak pasir dari gagasan yang telah terbentuk sebelumnya tentang bagaimana sesuatu dapat bekerja dan kemudian ketika orang-orang menjalaninya, dan saat pengujian sedang dijalankan, model tersebut berubah dan berkembang saat ia belajar lebih banyak tentang bagaimana segala sesuatunya bekerja atau tidak. bekerja. Itu memberikan tekanan luar biasa pada sistem pengujian.

Ketika Anda memikirkan beberapa kesalahan langkah AI ketika Anda memiliki situasi di mana ada bias bawah sadar yang dibangun ke dalam AI, di mana jenis AI mengamuk dan mulai menghalangi orang keluar dari aplikasi tertentu, atau mematikan semuanya, itu semua adalah situasi di mana dari menguji perspektif yang menantang.

Ini menjadi semakin rumit, tetapi juga menjadi jauh lebih cepat dan lebih responsif. Jadi Anda hanya akan melihat penyertaan AI dan pembelajaran mesin dalam pengembangan perangkat lunak terus meningkat. Namun, sekarang Anda harus memiliki semua kerangka kerja yang diperlukan untuk dapat menguji semua perubahan tersebut.