A(je)gile
H̶a̶l̶o̶ ̶s̶o̶b̶a̶t̶ ̶m̶i̶l̶e̶n̶i̶a̶l̶s̶
Ehem. Jadi saya membuka postingan ini dengan kata millenials karena ingin menjelaskan dulu arti kata dari Agile. Ada satu cocoklogi yang bisa saya buat diantara kata Agile dengan sifat millenials. Karena millenial itu sukanya yang instan, cepat; umpamanya kalau makan cabe harus langsung kerasa pedesnya. Agile merupakan kata sifat yang bisa menggambarkan millenials yang cepat, instan, adaptif. Kata Agile pada kamus Merriam-Webster berarti:
`a-jəl` — 1. marked by ready ability to move with quick easy grace; 2. having a quick resourceful and adaptable character
Arti yang pertama menjelaskan kata sifat yang berhubungan dengan elastisitas dan kecekatan otot tubuh manusia, sementara yang kita ingin fokus dalam tulisan ini adalah arti Agile yang kedua. Tapi ga mungkin kan kita jadi belajar bahasa inggris di sini? I mean, this is a software developer’s blog after all. It has to relate in software engineering right?
Dalam industri software engineering, Agile selalu dikenal sebagai singkatan dari Agile Software Development, yang menjadi metodologi fondasi software development process mainstream di industri ini dan dalam dekade ini. Ya, Agile merupakan sebuah metodologi, sebuah ilmu tentang metode. Metodologi dapat melahirkan sebuah metode karena memiliki prinsip dan nilai-nilai yang khas dan harus dipatuhi.
Sebelum mengulik lebih dalam tentang Agile Software Development, kita pahami sebentar apa yang dimaksud dengan software development. Software development adalah penyingkatan dari “Software Development Process” dengan alias lain seperti “Software Life Cycle”. Definisi sebuah proses adalah rangkaian langkah-langkah yang terdiri dari: kegiatan, tindakan, dan tugas yang dilaksanakan agar tercipta produktifitas. Sementara definisi software development process adalah kerangka kegiatan, tindakan, dan tugas yang diperlukan untuk membangun software yang berkualitas tinggi [Pressman, 2010].
Oke kembali lagi ke Agile, tadi saya sebutkan bahwa metodologi lazim memilki prinsip dan nilai yang harus diikuti. Prinsip dan nilai-nilai dari Agile dituangkan dalam sebuah manifesto bernama Manifesto for Agile Software Development yang disusun oleh 17 orang developer di dalam sebuah resort ski. Dalam manifest tersebut, Kent Beck dkk. memiliki asa untuk mentransfer nilai-nilai yang harus dimiliki setiap developer yang ingin menjalankan kegiatan pengembangan software yang lebih baik lagi dari metodologi yang sudah-sudah. Misalnya Prescriptive software development cycle yang dilabel menjadi software process yang tradisional dan konvensional.
Nilai yang ingin mereka ajukan ditulis seperti sebuah sajak dengan format “____ over ____”. Frasa di sebelah kanan adalah hal-hal atau kegiatan yang mereka rasa terlalu bertele-tele dan mubazir selama mereka bekerja dibawah payung nilai dan prinsip software life cycle konvensional. Sementara frasa di sebelah kiri tiap kalimat adalah hal-hal baru yang ingin mereka tonjolkan dalam mindset Agile. Ya, Agile adalah sebuah mindset, Agile Software Development adalah metodologinya. Mindset yang ingin mereka ubah dalam seorang developer ada empat:
Individuals and interactions over processes and tools
Sure, more tools mean more productivity. Tetapi 17 nabi ini merasa buat apa punya software life cycle yang terancang dan sumber daya (tools) yang mumpuni namun manusia nya tidak dilatih dan dibiasakan untuk bekerja dalam tim. Satu hal yang membedakan Agile dengan paradigma pengembangan software lain adalah fokus kepada individu pekerja dan bagaimana mereka bekerja sama. Agile percaya bahwa solusi akan berevolusi melalui kolaborasi antara anggota tim yang multi-fungsi. Pada metodologi sebelumnya, para developer sibuk memikirkan isi life cycle yang akan menjadi patokan pengembangan software sampai manager lupa bahwa yang menjalankan life cycle itu adalah pekerja mereka, seorang manusia.
Inilah mengapa setiap life cycle framework yang diturunkan dari metodologi Agile selalu memiliki sebuah kegiatan evaluasi dalam kurun waktu tertentu. Evaluasi dilakukan bukan hanya untuk menilai perkembangan software, namun juga relasi antar tim.
Working software over comprehensive documentation
Jadi perlu kamu ketahui bahwa pada paradigma software development sebelum Agile, dokumentasi software adalah nomor satu. Tujuannya adalah agar klien entah itu korporat atau komersil bisa mempelajari isi dari software dan cara mengutilisasinya. Selama software sedang dikembangkan, developer harus selalu mencatat fitur-fitur isi software ke dalam sebuah dokumentasi. Aktifitas ini memakan waktu yang bisa digunakan untuk men-deliver produk asli yang benar-benar akan dipakai oleh pengguna; bukan buku tebal yang hanya akan masuk ke dalam lemari perusahaan.
Inilah mengapa pada tiap life cycle framework turunan Agile, hasil dari setiap kegiatan iterasi harus menghasilkan sebuah produk, sebuah software yang siap pakai. Para nabi merasa bahwa selama mereka menjalani hidup sebagai developer, mereka tidak merasa adanya relevansi dari sebuah dokumentasi. Maka dari itu mereka ingin menurunkan prioritas tersebut, bukan menghapus dokumentasi secara keseluruhan dari pengembangan software. Biasanya menulis dokumentasi dilakukan setelah proyek dinyatakan berhenti atau semua iterasi telah selesai.
Customer collaboration over contract negotiation
Pada metodologi software development konvensional, selalu ada tahap/tugas yang dinamakan Communication atau diskusi dengan stakeholder yang membutuhkan software yang ingin dibangun. Dalam tahap ini seringkali (menurut pengalaman pribadi) para stakeholder dan developer tidak memiliki pace dan kompetensi yang sama tentang software. Makanya seringkali developer mendapat requirement yang ‘gila’, di luar kemampuan tim. Actually, requirement yang gila bukanlah momok terbesar, tapi begitu pengembangan (coding) sudah mulai tapi stakeholder tidak bisa dihubungi sama sekali untuk menanyakan requirement yang mungkin masa rancu. Kesalahan klasik pada stakeholder adalah dimana dia enggan untuk mengikuti proses pengembangan software padahal ia juga bertaruh pada software itu. Stakeholder berpikir peran mereka adalah cukup urusan finansial dan legal agar developer mau bekerja.
Responding to change over following a plan
Kembali pada tahap Communication seperti di atas, tim developer akan menerima requirement dari stakeholder lalu memecah permintaan tersebut menjadi beberapa tugas atau aktifitas pada tahap Planning. Pada metodologi konvensional, setelah melewati tahap planning, tidak boleh ada lagi mengubah tugas atau sub-tugas. Intinya, pada metodologi lama, melewati satu tahap berarti harus menyelesaikan satu iterasi dulu baru boleh mengulang dari tahap awal. Tim development harus menunggu satu iterasi pengembangan selesai baru boleh mengubah tasks. Di sini kata kuncinya adalah ‘mengubah’, artinya jika pada planning tim membuat tugas dan sub-tugas berdasarkan requirement, tugas itu tidak boleh berubah jika requirementnya berubah.
Requirement memang jarang berubah di tengah jalan namun yang lebih sering terjadi adalah salah penafsiran sebuah requirement sehingga tugas yang dipecah menjadi kurang tepat. Bayangkan kalau menurut peraturan metodologi lama, tugas & sub-tugas tidak boleh diganti. Ngoding harus tetap jalan walaupun kamu TAHU bahwa nantinya software pada iterasi ini tidak akan diterima stakeholder dan di iterasi berikutnya implementasi kamu ini akan langsung dihapus. Tak cuma tugas-tugas, ada juga tahap Modeling dimana developer menentukan software requirement untuk menyelesaikan iterasi. Jika saat implementasi ternyata software yang digunakan tidak tepat untuk iterasi, developer tidak diperbolehkan mengubah rencana skema infrastruktur yang sudah dibangun pada tahap modeling sebelumnya.
Seperti millenial, Agile sangat terbuka pada perubahan, biarpun terjadi di awal atau tengah implementasi. Pada framework turunan Agile, perubahan sangat didekap sehingga pembagian tugas per anggota sangat dinamis. Tiap framework juga biasa memiliki kegiatan pasca-evaluasi satu iterasi dimana stakeholder melihat kembali perencaan bisnis mereka sejauh ini dengan software yang dibuat. Sehingga tak jarang muncullah requirement baru untuk mengembangkan bisnis. Ya, menerapkan Agile berarti menghidupi software development cycle yang abadi sampai proyek itu dinyatakan berhenti.
Panjang ya? Padahal core valuenya cuma ada 4. Namun penjelasan panjang lebar di atas didasari oleh prinsip-prinsip Agile mindset yang berjumlah 12. Pada link ini tertulis semua pernyataan prinsip-prinsip Agile. Saya juga selalu membandingkan Agile dengan software development process yang tradisional karena sejarah Agile diciptakan adalah dorongan 17 orang software engineer yang ingin keluar dari life cycle yang mereka rasa tidak bagus/outdated/kurang efisien.
Nilai kunci seperti kolaborasi pelanggan diminati banyak kelompok pengembang software karena mereka sekarang bisa lebih engage ke client dan menaikkan akurasi relevansi fitur per requirement. Di lain sisi, nilai lain seperti responding to change disukai oleh para stakeholder karena stakeholder rentan plin-plan dalam menentukan requirement software karena bisnis jaman now sangat dinamis. Stakeholder tidak perlu takut untuk merevisi requirement karena dia tahu para developer juga fleksibel terhadap perubahan tugas.
Cepat, adaptif, kolaboratif. Kurang millenial apalagi coba. Pantesan Agile laris di startup abad ke-21.
Benny William Pardede
Koneg Liquid DevOps
