The First Way: Prinsip terkait Alur Kerja
Dalam bidang IT, terutama yang berkaitan dengan pengembangan aplikasi, suatu “pekerjaan” umumnya mengalir dari kiri ke kanan, yakni dari Development hingga Operations (yang mana merupakan area fungsional antara bisnis dan pelanggan).
Maka dari itu, prinsip kerja DevOps pertama yang akan kita bahas adalah Prinsip Kerja The First Way, yakni terkait alur kerja. Prinsip ini menjelaskan bahwa kita membutuhkan alur kerja yang cepat dan lancar dalam proses pengembangan aplikasi, mulai dari penulisan kode oleh Developer (Development), penyiapan infrastruktur dan proses deploy aplikasi oleh IT Operations (Operations), hingga akhirnya sampai di gadget pengguna/pelanggan (Customer) dan terasa manfaat atau nilai dari aplikasi/fitur/pembaruan perangkat lunak tersebut.
Dalam proses pengembangan aplikasi, ada beberapa cara atau metode untuk mengoptimalkan alur kerja, yakni membuat pekerjaan kita menjadi “tampak”, membatasi work in process (tugas yang masih tahap pengerjaan dan/atau belum terselesaikan), mengurangi skala batch yang dikerjakan, memangkas jumlah handoff, serta mengidentifikasi dan memperbaiki hambatan/batasan yang ada secara kontinu.
Untuk lebih jelasnya, mari kita bahas beberapa metode di atas ini satu per satu.
Membuat Pekerjaan Menjadi Tampak
Pada submodul sebelumnya Prinsip Kerja DevOps, kita sedikit membawa topik manufaktur dan membandingkannya dengan DevOps. Kali ini, kita akan angkat bidang manufaktur lagi untuk bisa memahami apa perbedaannya dengan dunia IT, dan akhirnya pada DevOps.
Perbedaan mencolok antara IT dan manufaktur ialah bahwa pekerjaan di bidang IT sejatinya tidak tampak/terlihat secara fisik. Dalam bidang manufaktur, pekerjaan atau aktivitas produksi dapat terlihat secara gamblang sehingga kita bisa mengetahui semua alur yang ada dan mengidentifikasi dengan jelas sekiranya di bagian mana atau di mesin mana alur produksi terhambat. Meski begitu, pemindahan pekerjaan antar mesin biasanya berjalan lambat sebab produk harus dipindahkan secara fisik.
Nah, ini berbanding terbalik dengan dunia IT. Karena hampir semua aktivitas dikerjakan melalui komputer dan dieksekusi melalui perangkat lunak, pekerjaan menjadi tak tampak/terlihat secara fisik. Meski begitu, ini membuat pekerjaan bisa dipindahkan atau didelegasikan secara mudah, seperti menugaskan seseorang hanya dengan mengirim email atau menyampaikan pesan di aplikasi chatting. Sebagai contoh, pimpinan tim Developer bisa langsung mengabari pimpinan tim IT Operations melalui email bahwa aplikasi yang dikembangkan sudah siap untuk di-deploy.
Namun, di situlah letak masalahnya. Karena saking mudahnya, pekerjaan yang kita delegasikan bisa saja tak kunjung dikerjakan, entah karena orang yang dituju tidak paham dengan email atau pesan dari kita; informasi yang kita berikan tak cukup lengkap; orang/tim tersebut sedang memiliki banyak pekerjaan lain; atau mungkin memang sedang dalam tahap pengerjaan, tetapi orang/tim tersebut sedang mengalami kesulitan; dan masih banyak lagi masalah lainnya.
Ini bisa terjadi karena ketidakjelasan dalam pendelegasian tugas serta ketidakbakuan proses alur kerja yang ada. Dalam proses pengembangan aplikasi, ini problem yang tak bisa diremehkan sebab pada akhirnya perusahaan bisa terlambat dalam memberikan fitur baru kepada pelanggan atau bahkan aplikasi benar-benar gagal beroperasi di lingkungan production.
Nah, agar bisa mengidentifikasi mana pekerjaan/tugas yang punya proses pengerjaan yang baik dan mana yang sedang dalam antrean atau bahkan terhenti, kita perlu membuat alur kerja yang sejelas-jelasnya.
Salah satu metode terbaik untuk melakukan ini adalah menggunakan papan kerja visual, seperti Kanban board atau Scrum board, di mana kita dapat merepresentasikan suatu pekerjaan atau tugas pada semacam card (kartu) baik fisik maupun digital.
Suatu pekerjaan akan dimulai dari sebelah kiri (seringnya diambil dari backlog, yakni akumulasi pekerjaan yang belum selesai atau hal-hal yang perlu ditangani), kemudian dipindahkan dari satu kolom ke kolom lainnya ke arah kanan, dan dianggap selesai ketika mencapai sisi kanan Kanban board (biasanya dalam kolom berlabel “Done”, “Delivered”, atau “ In Production” bila pada IT Operations).
Gambar di atas adalah contoh Kanban board yang digunakan pada siklus DevOps secara global atau keseluruhan. Alur kerja pada gambar di atas dimulai dari kolom Ready (siap untuk dikerjakan) hingga Investigate (pengumpulan informasi, pencatatan spesifikasi, persiapan, perancangan, dll). Setelah itu, masuk tahap Development, di mana kode mulai ditulis oleh Developer sesuai dengan spesifikasi dan kebutuhan awal.
Bila sudah selesai, alur selanjutnya adalah masuk ke bagian Operations, di mana IT Operations mempersiapkan infrastruktur untuk proses deployment aplikasi. Sebelum disajikan ke publik sepenuhnya, aplikasi akan diuji terlebih dahulu untuk proses UAT (User Acceptance Testing) guna memvalidasi apakah aplikasi sudah memenuhi kebutuhan bisnis atau belum. Jika sudah sesuai harapan, aplikasi lantas di-deploy ke lingkungan production sehingga akhirnya tersaji ke seluruh pengguna (dalam hal ini berarti sudah masuk tahap “Delivered”).
Perlu Anda ketahui, dalam menggunakan Kanban board pada DevOps, suatu pekerjaan tidak bisa disebut selesai ketika hanya selesai di sisi Developer saja, melainkan saat aplikasi berjalan dengan sukses di lingkungan production, dalam kata lain telah memberikan nilai kepada pelanggan.
Semoga Anda sudah paham dengan pembahasan ini. Intinya, dengan menempatkan semua pekerjaan kita ke dalam sebuah antrean pada papan kerja visual dan membuatnya “tampak”, setiap orang (yang memiliki wewenang) dapat lebih mudah memprioritaskan pekerjaan dalam konteks tujuan umum/bersama, bukan hanya untuk masing-masing tim. Selain itu, melakukan hal ini juga memungkinkan setiap orang/tim untuk melakukan satu tugas/pekerjaan dengan prioritas tertinggi hingga benar-benar selesai yang berujung peningkatan kualitas pekerjaan.
Membatasi Work In Process (WIP)
Mari kita ambil lagi contoh dalam bidang manufaktur. Pekerjaan sehari-hari di dunia manufaktur umumnya ditentukan oleh jadwal produksi yang dibuat secara teratur (misalnya, harian atau mingguan) dan menetapkan pekerjaan mana yang harus dijalankan berdasarkan pesanan pelanggan, tanggal jatuh tempo pesanan, suku cadang yang tersedia, dan sebagainya.
Sebaliknya, dalam bidang IT, justru pekerjaan itu biasanya jauh lebih dinamis (tak menentu), terutama pada kasus shared services (layanan bersama), di mana tim (dalam hal ini, Developer dan IT Operations) harus memenuhi kebutuhan atau tuntutan banyak pihak yang berbeda seantero perusahaan. Akibatnya, pekerjaan sehari-hari mereka malah didominasi oleh permintaan-permintaan yang acapkali datang dari divisi lain dengan prioritas (seolah-olah) mendesak yang masuk melalui berbagai mekanisme komunikasi, termasuk ticketing system, email, telepon, chat, atau bahkan obrolan saat berpapasan dengan atasan dari divisi lain di lorong kantin. Ini menjadi masalah karena Developer maupun IT Operations menjadi tidak fokus terhadap tugas utama mereka. Meskipun bisa multitasking, itu bukanlah opsi yang bagus untuk diambil.
Sebagai manusia, multitasking adalah sesuatu yang harus Anda hindari dalam melakukan aktivitas. Coba pikirkan, hanya sekadar menyelesaikan tugas sederhana seperti menyortir bentuk geometris saja, waktu kita akan tersita secara signifikan saat melakukan banyak tugas secara bersamaan. Apalagi mengerjakan tugas di bidang IT yang pada dasarnya jauh lebih kompleks secara kognitif daripada sekadar menyortir bentuk geometris, imbas multitasking yang ditimbulkan pada segi waktu akan jauh lebih buruk. Bayangkan saja, tugas sehari-hari yang seharusnya bisa dikerjakan hanya dalam 30 menit bisa jadi memakan waktu hingga berminggu-minggu akibat dari multitasking (saking banyaknya tugas yang datang dari luar).
Untungnya, kita bisa membatasi multitasking ketika menggunakan Kanban board untuk mengelola pekerjaan, seperti mengodifikasi dan memberlakukan pembatasan WIP (work in process) untuk setiap kolom dengan cara menempatkan batas atas atau maksimal jumlah card yang dapat ditaruh pada kolom tersebut.
Misalnya, kita bisa menetapkan batas WIP hanya sebanyak 3 card untuk UAT. Ketika sudah ada 3 card di kolom UAT, kita tidak bisa lagi menambahkan card baru ke kolom tersebut, kecuali jika minimal satu card dipindahkan ke kolom lain, baik karena sudah selesai (digeser ke kolom Delivered) ataupun ditunda (digeser kembali ke kolom Done pada bagian Ops atau jauh hingga ke Backlog atau Ready).
Pada akhirnya, ini menyimpulkan bahwa tidak boleh ada tugas yang dikerjakan oleh tim (baik Developer maupun IT Operations) sampai seseorang (yang memberikan tugas atau dirinya sendiri) merepresentasikannya terlebih dahulu ke dalam bentuk card. Sekali lagi, ini menegaskan bahwa semua pekerjaan harus dibuat tampak/terlihat. Jadi, jika suatu waktu seorang Developer mendapatkan permintaan dari divisi lain melalui email, tetapi belum dimasukkan ke Kanban board, maka sang Developer tak boleh mengerjakan tugas tersebut.
Mengurangi Skala Batch yang Dikerjakan
Komponen penting lainnya untuk menciptakan alur kerja yang lancar dan cepat adalah melakukan pekerjaan dalam skala batch yang kecil.
Catatan: Batch atau batch production adalah metode di mana sekelompok produk identik diproduksi secara bersamaan (bukan satu per satu), sedangkan skala batch berarti jumlah unit/produk yang dieksekusi secara bersamaan dalam satu waktu selama proses produksi.
Kala itu, dalam bidang manufaktur, produksi dalam skala batch yang besar/banyak merupakan praktik yang umum, terutama untuk operasi di mana penyetelan mesin dan changeover (proses mengubah lini atau mesin dari menjalankan satu produk ke produk lainnya) memakan waktu dan mahal.
Sebagai contoh, memproduksi panel bodi mobil besar tentunya memerlukan pengaturan cetakan yang gede nan berat pada mesin stamping logam, yang mana ini adalah sebuah proses kompleks dan bisa memakan waktu berhari-hari. Ditambah lagi, proses changeover pun umumnya cukup mahal sehingga sering kali panel bodi mobil akan di-stamp/dicetak sebanyak-banyaknya dalam skala batch yang besar/banyak untuk mengurangi biaya.
Namun, ketahuilah bahwa memproduksi dalam skala batch yang besar dapat menghasilkan tingkat WIP (work in process) yang tinggi dalam alur kerja pabrik. Hasilnya adalah lead time (waktu yang diperlukan untuk membuat sebuah produk hingga akhirnya dikirim ke pelanggan) akan menjadi lama dan kualitas produk pun buruk. Jika ditemukan ada masalah atau kecacatan di salah satu panel bodi, seluruh panel bodi pada batch tersebut harus dibuang. Mubazir waktu dan anggaran, kan?
Salah satu hikmah utama yang bisa kita petik adalah bahwa untuk mempersingkat lead time dan meningkatkan kualitas, kita harus berusaha untuk terus memperkecil/mengurangi skala batch yang diproduksi. Batas minimalnya adalah “single-piece flow”, di mana setiap operasi dilakukan satu unit pada satu waktu.
Mari kita ambil contoh lain. Katakanlah sebuah pabrik memproduksi 10 brosur yang harus segera dikirim ke pelanggan. Setiap brosur memerlukan 4 langkah: Fold (melipat kertas), Insert (memasukkan kertas ke dalam amplop), Seal (menyegel amplop), dan Stamp (mencap amplop).
Apabila kita menerapkan strategi skala batch yang besar (a.k.a, “mass production”), itu artinya satu operasi akan dilakukan secara berurutan pada masing-masing 10 brosur tersebut. Dengan kata lain, pertama-tama 10 lembar kertas akan dilipat, lalu masing-masing dimasukkan ke dalam amplop, kemudian 10 amplop itu disegel, dan terakhir semuanya dicap.
Di sisi lain, dalam strategi skala batch yang kecil (a.k.a, “single-piece flow”), semua langkah yang diperlukan untuk menyelesaikan setiap brosur dilakukan secara berurutan sebelum mengeksekusi brosur berikutnya. Dengan kata lain, satu lembar kertas pertama akan dilipat, lalu dimasukkan ke dalam amplop, kemudian disegel, dan dicap. Setelah brosur pertama selesai, barulah lembar kertas berikutnya dieksekusi. Begitu seterusnya hingga kertas kesepuluh.
Perbedaan antara penggunaan skala batch yang besar dan kecil dapat menghasilkan dampak yang dramatis. Misalnya, setiap operasi (Fold, Insert, Seal, dan Stamp) memakan waktu 10 detik untuk masing-masing 10 amplop. Dengan strategi skala batch yang besar maka amplop pertama baru akan benar-benar selesai diproduksi (telah dicap) setelah 310 detik (100 detik proses Fold + 100 detik proses Insert + 100 detik proses Seal + 10 detik proses Stamp untuk amplop pertama). Sungguh lama ya hanya untuk menunggu hasil amplop pertama selesai?
Lebih buruknya lagi, apabila pada saat operasi penyegelan amplop (Seal) ternyata kita menemukan bahwa ada kesalahan pada langkah pertama (Fold). Dalam hal ini, berarti kita baru bisa menemukan kesalahan tersebut setelah 200 detik berlalu dan walhasil mengulang seluruh operasi kembali dari awal (Fold dan Insert) terhadap kesepuluh brosur tersebut.
Sebaliknya, dalam strategi skala batch yang kecil (a.k.a single-piece flow), amplop pertama bisa selesai diproduksi hanya dalam waktu 40 detik (10 detik Fold + 10 detik Insert + 10 detik Seal + 10 detik Stamp). Luar biasa, kan? Ini 8x lebih cepat ketimbang strategi skala batch yang besar. Terutama, jika pada saat operasi penyegelan amplop (Seal) ternyata kita menemukan kesalahan pada langkah pertama (Fold), kita hanya perlu mengulang satu brosur saja.
Ini membuktikan bahwa skala batch yang kecil dapat menghasilkan WIP lebih sedikit, lead time lebih cepat, deteksi kesalahan lebih awal, dan pengerjaan ulang lebih sedikit.
Oke, sudah cukup berkutat di bidang manufakturnya, mari kita masuk ke dunia IT. Dampak negatif dari skala batch yang besar juga sama relevannya dengan di bidang IT. Misalnya, suatu proyek IT menerapkan model waterfall dan memiliki jadwal tahunan untuk merilis perangkat lunak ke publik yang berarti kode yang telah dikerjakan oleh tim Developer selama satu tahun penuh akhirnya di-deploy ke lingkungan production.
Proyek IT tersebut memiliki skala batch yang besar, selain karena setiap langkah operasi (Code, Build, Test, dan Deploy di model waterfall) untuk keseluruhan aplikasi dikerjakan secara berurutan, pun kita harus menunggu lama dan baru bisa melihat hasilnya (rilis ke publik) hingga 1 tahun lamanya. Itu pun jika aplikasi berjalan dengan baik. Kalau tidak? Tentu tim harus mengerahkan seluruh pasukan dan tenaganya untuk menyelesaikan berbagai WIP dan gangguan yang melintang. Akibatnya, ini akan menghasilkan alur kerja yang tidak baik dan kualitas perangkat lunak yang buruk.
Hal ini menjelaskan bahwa makin besar ukuran unit (cakupan kode) yang di-deploy ke lingkungan production, makin sulit pula untuk mendiagnosis dan memperbaiki kesalahan tersebut, dan makin lama pula waktu yang dibutuhkan untuk memulihkannya (membuat aplikasi menjadi berjalan normal kembali saat terjadi down).
Oleh karena itu, selaras seperti yang terjadi di manufaktur, di dunia IT pun perlu diterapkan single-piece flow. Di DevOps, hal itu dapat diwujudkan dengan praktik Continuous Deployment, di mana setiap perubahan kode yang dilakukan pada version control system (seperti Git) diintegrasikan, diuji, dan di-deploy ke lingkungan production secara bertahap dan dalam unit/cakupan kode yang tidak terlalu besar. Dengan demikian, alur kerja yang ada bisa tercipta makin baik dan kualitas perangkat lunak dapat kian meningkat. Kita akan bahas lebih lanjut soal ini nanti.
Memangkas Jumlah Handoff
Sebagai permulaan, ketahui dulu bahwa yang dimaksud handoff di sini adalah penyerahan/pengiriman informasi, tanggung jawab, atau pekerjaan dari satu pihak ke pihak lain.
Dalam proses pengembangan aplikasi, contohnya adalah penyerahan kode yang sudah matang dari Developer ke IT Operations untuk di-deploy ke lingkungan production.
Tahukah Anda bahwa kerap kali siklus untuk melakukan deployment itu mengharuskan kita menunggu hingga berbulan-bulan lamanya. Ini bisa terjadi karena nyatanya ada ratusan (atau bahkan ribuan) operasi/prosedur yang diperlukan dan butuh kontribusi banyak pihak untuk memindahkan kode dari version control system (seperti Git) hingga akhirnya tiba di lingkungan production (rilis ke publik), termasuk pengujian, pembuatan environment (misal, untuk lingkungan production), administrasi server, administrasi jaringan, hingga keamanan informasi.
Selain itu, setiap kali ingin menyerahkan pekerjaan dari satu tim ke tim lainnya (handoff), kita memerlukan berbagai jenis cara komunikasi dan medium, seperti mengirim email, berkoordinasi di sebuah rapat, menugaskan di tools manajemen proyek atau ticketing system, penulisan dokumen spesifikasi teknis, dll.
Nah, setiap langkah/operasi/prosedur ini merupakan potensi yang memungkinkan terjadinya antrean pekerjaan, yang berarti kita harus menunggu sampai pekerjaan tersebut benar-benar dikerjakan dan selesai. Masalahnya, saat kita menyerahkan pekerjaan ke tim lain untuk mereka eksekusi (misal Developer menyerahkan kode ke IT Operations untuk di-deploy), belum tentu itu akan langsung dikerjakan. Apabila tim yang diminta sedang sibuk sehingga tidak ada kapasitas untuk mengeksekusi pekerjaan tersebut, bisa jadi pekerjaan yang kita kirim akan ditunda sampai mereka siap mengerjakannya. Itulah mengapa pekerjaan yang sebenarnya hanya membutuhkan waktu 30 menit, bisa jadi selesai dalam waktu berminggu-minggu. Bukan lama dalam proses pengerjaannya, tetapi lantaran menunggu pekerjaan tersebut dieksekusi.
Saking lamanya, terkadang diperlukan eskalasi konstan (contoh, mendatangi langsung dan berdiskusi dengan orang yang bertanggung jawab untuk memprioritaskan pekerjaan yang diminta) semata-mata agar pekerjaan tersebut bisa dieksekusi dan selesai dalam timeline yang dibuat.
Selain itu, ini akan berdampak semakin buruk jika jumlah handoff yang terjadi terlalu banyak. Salah satunya, beberapa atau sebagian informasi penting yang melekat pada suatu pekerjaan atau tugas bisa jadi kehilangan konteks selama proses handoff. Sebagai contoh, seorang Administrator Server mendapatkan tugas baru dari atasannya (yang mana atas permintaan dari tim bisnis) untuk membuat user accounts (akun pengguna). Namun, karena informasi yang diterima tak begitu lengkap dan tidak tersampaikan dengan baik, sang Administrator Server pun menjadi kesulitan dalam melakukan tugasnya, entah itu karena dia tak tahu akun ini untuk aplikasi yang mana, mengapa akun ini harus dibuat, apa peran atau kemampuan untuk akun ini, dan lain sebagainya.
Maka dari itu, untuk menangani masalah ini, langkah tepat yang harus dilakukan adalah memangkas jumlah handoff, baik dengan mengotomatiskan sebagian besar pekerjaan atau mereorganisasi tim (misal, tim Developer dan tim IT Operations bersatu menjadi tim DevOps) sehingga tim tersebut dapat menyelesaikan pekerjaan (misal, menyajikan fitur baru ke pengguna) dengan cepat dan lancar tanpa perlu terus-menerus bergantung pada orang/tim lain.
Hasilnya, kita dapat memperbaiki alur kerja, mengurangi waktu tunggu saat proses handoff, dan meningkatkan kualitas pekerjaan.
Mengidentifikasi dan Memperbaiki Constraint
Sebagai bagian dari langkah untuk mengurangi lead time dan meningkatkan throughput (jumlah pekerjaan yang berhasil selesai dan sukses dikirim ke pelanggan), kita perlu secara berkala mengidentifikasi apa saja constraint (kendala) yang terjadi pada alur kerja, terutama dalam proses pengembangan aplikasi.
Mengidentifikasi dan memperbaiki constraint ini menjadi poin penting sebab sebesar apa pun upaya kita untuk melakukan perbaikan terhadap alur kerja, jika kita tidak memperbaiki constraint, itu akan sia-sia.
Mari kita ambil contoh, umpamanya ada seorang IT Operations bernama Budi yang terlibat dalam Proyek A (proyek penting perusahaan). Sudah menjadi kesepakatan bersama bahwa proyek ini harus diprioritaskan ketimbang hal-hal lain karena ini adalah proyek yang akan menghasilkan keuntungan besar bagi perusahaan dalam sejarah. Akan tetapi, si Budi ini malah sibuk luar biasa lantaran diminta oleh tim Sales untuk mengerjakan tugas-tugas lain, seperti membuat akun, mereset password, dan lain-lain yang tidak berkaitan dengan Proyek A tadi.
Karena saking sibuknya, saat diminta untuk men-deploy kode (terkait Proyek A), ia tak kunjung mengeksekusinya, bahkan hingga berhari-hari lamanya. Padahal, normalnya tugas ini bisa ia eksekusi hanya dalam waktu beberapa jam saja. Alhasil, Proyek A pun menjadi terlambat dan masalah ini berpotensi untuk merugikan perusahaan.
Nah, dari contoh di atas, kita bisa identifikasi bahwa yang menjadi “constraint” atau kendala/hambatan utama pada Proyek A adalah Budi. Pasalnya, yang seharusnya ia fokus terhadap Proyek A, nyatanya malah mengerjakan hal-hal lain di luar pekerjaan utamanya. Namun, bukan berarti sepenuhnya salah Budi sebab ia pun hanya menerima tugas dari orang lain. Oleh karena itu, kita harus bisa membatasi apa saja yang perlu dikerjakan oleh Budi–tentu hanya fokus terhadap Proyek A–dan mendelegasikan tugas-tugas dari tim Sales kepada orang lain yang sekiranya sedang tidak terlalu banyak pekerjaan. Sehingga, Budi bisa lebih mengabdikan diri sepenuhnya pada Proyek A dan memberikan manfaat yang berarti dalam kontribusi pada proyek tersebut.
Budi hanyalah salah satu contoh constraint atau kendala yang terjadi pada proses pengembangan aplikasi. Tak hanya “orang” (seperti Budi), constraint pun bisa terjadi pada “proses atau praktik”. Jika Anda sering berjibaku dan andil dalam proses pengembangan aplikasi, niscaya Anda akan menemukan lebih banyak contoh-contoh constraint lainnya yang dapat menghambat alur kerja.
Misalnya, seperti pembuatan environment (seperti test atau production) dan deployment aplikasi yang bisa memakan waktu hingga berminggu-minggu. Padahal, seharusnya proses tersebut bisa diautomasi agar lebih fleksibel dan berlangsung cepat.
Oke, itu dia beberapa hal yang ada pada Prinsip Kerja The First Way: Prinsip terkait Alur Kerja. Tentu sebenarnya masih ada banyak hal lain yang bisa kita bahas, tetapi cukup itu dulu yang perlu Anda pahami untuk saat ini. Semoga dengan memahami Prinsip Kerja The First Way ini, Anda bisa menerapkannya agar proses transformasi DevOps di perusahaan pun semakin baik.
Intinya, tujuan dari Prinsip Kerja The First Way ini adalah untuk memperbaiki alur kerja sehingga proses pengembangan aplikasi bisa berlangsung cepat, tetapi tetap menjaga keandalan infrastruktur dan meningkatkan kualitas aplikasi. Dengan demikian, pada akhirnya pelanggan pun bisa merasakan fitur atau pembaruan aplikasi lebih cepat.