Mempercepat Inovasi: Mengotomatisasi Pengembangan Perangkat Lunak untuk Keunggulan Kompetitif

Pengembangan perangkat lunak tradisional lambat. Ini hanya perlu dipikir ulang.

Hampir tiga tahun lalu Satya Nadella dari Microsoft terkenal menyatakan bahwa "setiap bisnis akan menjadi bisnis perangkat lunak". Kini, pasar perangkat lunak global senilai 500 miliar dolar melaju untuk melipat ganda menjadi 1 triliun dolar pada tahun 2030.

J.P. Morgan tercatat memiliki 40.000 insinyur perangkat lunak (lebih banyak dari Alphabet) dalam filing terbaru mereka. Setiap perusahaan besar berlomba untuk merekrut insinyur agar dapat mengalahkan persaingan mereka. Masalah besar adalah pengembangan perangkat lunak tradisional lambat, terfragmentasi dan boros.

Misalnya, setiap minggu insinyur perangkat lunak rata-rata akan menghabiskan 4 jam menunggu pengujian selesai, 3,5 jam menunggu build, dan 3 jam pada manajemen lingkungan — lebih dari satu kuartal minggu kerja mereka tidak benar-benar menciptakan sesuatu yang bernilai. Saat Anda mempertimbangkan bahwa insinyur sering kali adalah orang-orang yang paling banyak dibayar di organisasi, ini jelas merupakan masalah besar. Namun, hal-hal sedang berubah.

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

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

Terinteresi untuk mempelajari lebih lanjut tentang mengotomatisasi pengembangan perangkat lunak dan mempercepat inovasi, Information Age berbicara dengan Rose tentang topik ini.

Bagaimana keadaan pasar perangkat lunak saat ini?

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

Salah satunya mencoba mengeluarkan perangkat lunak dari data center on-premise dan memasukkannya ke lingkungan cloud-native, tempat Anda dapat mengakses komputasi secara instan.

Kedua adalah perangkat lunak, secara tradisional atau dalam banyak kasus, telah dilihat sebagai pedoman atau pelengkap bisnis utama. Kini Anda memiliki semua jenis bisnis dari bank hingga pabrikan mobil dan ritel yang semua menyadari bahwa perangkat lunak adalah inti dari apa yang mereka lakukan. Dan 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 tempat pengembang dapat bekerja, yang ada di tengah-tengah saat ini biasanya adalah semacam campuran aduk-aduk dari berbagai platform dan proses.

Dalam sebagian besar kasus Anda memiliki proses rilis perangkat lunak waterfall yang sangat panjang yang memiliki banyak langkah manual dan kemudian mereka memiliki banyak skrip manual. Dalam beberapa kasus untuk toko yang lebih canggih, mereka mungkin memiliki solusi otomatisasi generasi pertama yang tersedia namun saat tim bercepat, itu mulai pecah.

Dan kini itulah yang kami hadapi dan membantu perusahaan menavigasi. Saat tim perangkat lunak mereka bercepat, mereka membangun lebih banyak perangkat lunak dan saat mereka mencoba melakukannya lebih cepat; agar dapat responsif terhadap peluang di pasar tetapi juga responsif terhadap perubahan negatif yang potensial. Bisnis hanya perlu memikir ulang sepenuhnya bagaimana semua bagian itu disatukan.

Apakah kecepatan yang Anda sebut adalah hambatan utama dalam pengembangan perangkat lunak?

Perusahaan dan tim pengembangan mencoba untuk bercepat seiring dengan kecepatan pasar. Mereka mencoba mencari tahu bagaimana mereka dapat bekerja dengan cepat sehingga dapat mengatasi peluang.

Satu-satunya cara untuk sampai ke sana adalah untuk benar-benar mengotomatisasi semua langkah yang tidak memerlukan intervensi manusia, karena alih-alih melakukannya selama menit, jam dan hari, Anda dapat melakukannya dalam detik.

Saat tim bercepat, dan sebagai perangkat lunak adalah toko utama Anda untuk pelanggan Anda, Anda harus memastikan bahwa tingkat kualitas tinggi; Anda harus memastikan bahwa itu tidak macet atau bahwa Anda tidak memiliki kerentanan keamanan, misalnya.

Jadi, saat Anda memikirkan agile, itu tentang mencoba menjadi lebih cepat tanggap, baik dari segi kualitas maupun dari segi kecepatan.

Di AS semuanya tentang kecepatan tetapi dalam bergerak lebih cepat, mengintegrasikan potongan yang lebih kecil dan dapat merilis perangkat lunak pada basis yang lebih konsisten, perangkat lunak Anda secara bawaan menjadi lebih baik. Semua ketakutan tentang harus me-deploy hilang saat Anda melakukannya lima, delapan, 15 kali seminggu, dan dalam beberapa kasus kami memiliki pelanggan yang melakukannya 100 kali sehari.

Deployment menjadi bukan masalah lagi.

Dari sisi kualitas, salah satu masalah besar untuk pengembangan perangkat lunak di masa lalu adalah jika Anda hanya merilis sekali per kuartal, Anda akan mengalami kesulitan besar untuk memastikan bahwa semua perubahan yang Anda perkenalkan ke dalam aplikasi Anda benar-benar bekerja bersama. Seringkali Anda melihat perusahaan melakukan rilis big bang dan kemudian setelah mereka melakukan rilis big bang, mereka menghabiskan 60, 90 hari berikutnya untuk memperbaiki semua hal yang regresi dan rusak. Dengan metode ini, siklus perangkat lunak Anda melambat, tetapi juga kualitas aplikasi itu sendiri menurun.

Dari perspektif agile itulah yang orang coba atasi.

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

Ada beberapa cara berbeda.

Salah satunya adalah pengembang sulit direkrut dan jadi Anda ingin memastikan bahwa semua waktu yang dihabiskan dari perspektif pengembangan didedikasikan untuk membangun perangkat lunak khusus Anda, apapun itu; jika Anda adalah bank, membangun aplikasi perbankan yang hebat, jika Anda adalah aplikasi e-commerce, membangun aplikasi e-commerce yang benar-benar hebat. Saya pikir salah satu area besar yang orang kurang berinvestasi adalah bahwa pengembang perangkat lunak secara historis membangun hal-hal. Itulah yang mereka lakukan, mereka membangun perangkat lunak. Jadi siklus pengembangan telah kurang berinvestasi dari perspektif aplikasi pihak ketiga.

Ada hal-hal seperti, misalnya, otomatisasi pengujian dan infrastruktur continuous delivery yang tidak harus dibangun tim sendiri. Anda jauh lebih baik memperolehnya dari orang lain yang spesialis di area tersebut sehingga Anda dapat fokus pada hal yang Anda kuasai. Ini akan seperti mengatakan kepada seseorang bahwa mereka perlu membangun pembuat kopi dan memberikan kepada mereka sejumlah pipa tembaga, beberapa solder dan beberapa katup. Anda tidak akan pernah melakukan itu. Namun secara historis, pengembangan diperlakukan dengan cara itu. Jadi pasti menempatkan alat dan platform yang tepat adalah sangat krusial, dari bawah hingga atas tumpukan, dari data center hingga alat perencanaan.

Saya pikir bagian kedua adalah bahwa dalam model waterfall tradisional, pengembangan perangkat lunak biasanya memerankan peran catcher, jadi aplikasi didefinisikan jauh lebih awal dalam proses dan kemudian pada saat tim pengembangan mendapatkannya, telah sejumlah keputusan dibuat yang mungkin atau mungkin tidak benar-benar bekerja dan mungkin atau mungkin tidak layak atau mudah dilakukan.

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

Saat tim mengadopsi proses agile yang lebih software-first, Anda akhirnya mendapatkan triangulasi kekhawatiran. Anda memiliki orang-orang dan pemilik bisnis serta manajer produk yang memiliki mengapa Anda membangun sesuatu. Anda memiliki arsitek teknis dan pengembang perangkat lunak yang benar-benar membicarakan bagaimana Anda membangun itu. Dan kemudian Anda memiliki operator, mereka yang bertanggung jawab untuk sebenarnya 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 untuk beberapa perusahaan.

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

Dengan otomatisasi Anda dapat mengotomatiskan tugas yang baik ditentukan sebelumnya, serta yang dapat belajar sendiri. Contohnya mungkin jika setiap kali Anda mencoba merilis sebuah perangkat lunak Anda harus melakukan pengujian pihak ketiga terhadap sistem pembayaran pihak ketiga lainnya. Di masa lalu dengan tugas-tugas itu, Anda akan merekrut tim QA yang pada dasarnya akan mencoba memproses transaksi dan melakukannya secara manual, yang sangat lambat. Itu juga sangat rawan kesalahan dan komplikasi.

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

Ada peluang untuk mengambil tugas-tugas berulang yang setiap menit yang dihabiskan pengembang melakukan hal-hal itu berulang kali adalah pemborosan waktu dan, jujur, pemborosan uang.

Jadi saat Anda melihat AI dan perangkat lunak yang sedang dibangun, alih-alih memikirkan mendorong perangkat lunak deterministik prediktif, apa yang Anda lakukan adalah mendorong sebuah model. Dan model adalah kotak pasir dari gagasan yang telah dikonsepsikan sebelumnya tentang bagaimana sesuatu mungkin bekerja dan kemudian saat orang-orang melewatinya, dan saat pengujian dilakukan, model berubah dan berevolusi saat ia belajar lebih banyak tentang bagaimana hal-hal bekerja atau tidak bekerja. Itu menekan sistem pengujian dengan sangat kuat.

Saat Anda memikirkan beberapa langkah salah AI saat Anda memiliki situasi di mana ada bias sadar tidak tertanam dalam AI, di mana AI jenis berjalan liar dan mulai memblokir orang dari aplikasi tertentu, atau mematikan hal-hal, itu semua merupakan situasi yang dari perspektif pengujian adalah menantang.

Itu semakin rumit, tetapi juga semakin cepat dan responsif. Jadi Anda hanya akan melihat inklusi AI dan pembelajaran mesin dalam pengembangan perangkat lunak terus meningkat. Namun, kini Anda perlu memiliki semua kerangka kerja yang diperlukan agar dapat menguji semua perubahan tersebut.