Ada lelucon lama yang berbunyi, “Jika ada rambut palsu yang bagus, saya belum pernah melihatnya.” Sebuah rahasia umum di Hollywood: aktor terkemuka seperti Ted Danson dan Burt Reynolds memakai rambut palsu. Tapi bukan permadani rakun - permadani yang sangat mahal dan dibuat dengan indah sehingga tidak ada yang bisa membedakannya dari bulu alami.
Agile memiliki kualitas yang sama: jika bagus, Anda tidak menyadarinya. Faktanya, manifesto Agile yang asli menegaskan hal ini dalam prinsipnya: “Lebih mengutamakan manusia daripada proses.” Namun sering kali, organisasi membengkokkan proses Agile untuk menghindari perubahan dinamika internal yang sulit. Hal ini mengarah pada apa yang disebut oleh penandatangan manifesto Agile, Kent Beck, sebagai 'Scrum But', misalnya, “Kami berlatih Scrum, *tapi*…” (Scrum — dibahas nanti — sangat erat kaitannya dengan Agile sehingga sering digunakan secara bergantian).
Perangkat lunak tidak memiliki batasan fisik, dan akibatnya, proyek perangkat lunak apa pun dapat dengan cepat menjadi rumit seperti imajinasi terliar para pesertanya. Kadang-kadang hal ini menghasilkan produk-produk baru yang luar biasa, namun sering kali, hal ini menyebabkan pengalaman yang membengkak, rusak, terlambat dari jadwal dan melebihi anggaran, serta membuat anggota tim kelelahan. Agile memberikan metode alternatif untuk melakukan triase terhadap sumber daya waktu anggota tim yang langka. Ini dapat diringkas dengan sangat sederhana:
Berikan fitur terpenting sesegera mungkin.
Sederhana, bukan? Tentu saja, sederhana itu tidak mudah! Orang sering kali memperumit Agile karena, seperti rambut palsu yang bagus, mereka belum pernah melihatnya dilakukan dengan benar.
Cara paling komprehensif bagi saya untuk menunjukkan kepada Anda cara yang tepat untuk melakukan Agile sederhana adalah dengan meminta Anda bergabung dengan sebuah proyek di awal, dan “ikut serta” saat kita menjalani langkah-langkahnya. Karena hal itu tidak mungkin dilakukan dalam sebuah artikel, saya harus menjelaskan prosesnya. Dalam semangat Agile, saya akan melakukannya sesederhana mungkin, tetapi karena sederhana itu tidak mudah, maka itu tidak akan singkat. Mari kita bagi menjadi tiga bagian:
1. Prinsip dasar
2. Praktek sehari-hari
3. Poin cerita: memperkirakan pengembangan perangkat lunak
Prinsip dasar
Dalam pembuatan jam, apa pun kecuali jarum jam dan menit — misalnya, kronometer, atau tanggal — disebut komplikasi. Hal ini membuat mekanisme tersebut lebih sulit untuk diterapkan. Namun hal ini tidak membuat jam tangan yang hanya memiliki jam dan menit menjadi sederhana! Operasi itu cukup rumit, tanpa komplikasi tambahan.
Sederhana dan kompleks bukanlah hal yang berlawanan. Sederhana adalah kebalikan dari rumit; rumit berarti menjadi lebih kompleks dari yang diperlukan.
Agile berupaya menghadirkan fitur sesegera mungkin dengan menjaga proses seminimal mungkin. Namun ada batas minimumnya, yang di bawahnya terdapat kegagalan. Salah satu komponen minimum tersebut adalah pengujian.
Apa saja fitur terpenting proyek Anda? Ada pepatah yang digunakan beberapa olahragawan: “Tempat kedua hanyalah ‘pecundang pertama’.” Agak sentimen kasar, tapi Agile membutuhkan penentuan prioritas yang kejam. Jika fitur terpenting Anda tidak berfungsi, apakah hal lain dalam proyek Anda memiliki nilai?
Anda mungkin berpikir tentang 'saus spesial' yang membuat aplikasi Anda luar biasa. Tapi itu tidak ada gunanya jika pengguna Anda tidak bisa mengaksesnya. Jadi fitur seperti “log in” dan sebelumnya “buat akun” sebenarnya lebih penting.
Fitur terpenting dalam semua proyek perangkat lunak adalah “hal itu perlu dijalankan”. Jika situs web atau aplikasi atau perpustakaan tidak dapat dikompilasi dan dijalankan, tidak ada fitur lain yang penting.
Proyek tangkas memerlukan pengujian otomatis, titik. Jika Anda tidak menguji, Anda bukan Agile. Saat kami menambahkan lebih banyak fitur, fitur-fitur yang dikirimkan sebelumnya — menurut definisi lebih penting daripada fitur-fitur berikutnya — harus tetap berfungsi. Jika fitur yang kurang penting/lebih baru merusak fitur yang lebih penting/sebelumnya, kami telah melanggar prioritas kami.
Pengujian manual dapat berhasil pada awalnya, namun seiring berkembangnya proyek, pengujian tersebut menjadi tidak efisien. Selain itu, praktik terbaik selama puluhan tahun telah menunjukkan bahwa kode yang ditulis agar mudah diuji memiliki keuntungan besar: bug yang jauh lebih sedikit, dukungan yang lebih besar untuk fitur tambahan, dan banyak lagi. Menulis kode yang dapat diuji awalnya sangat sulit, namun akhirnya menjadi lebih mudah. Tidak melakukannya dari awal bukanlah suatu pilihan, kecuali Anda menginginkan “pengembangan neraka” di akhir proyek, ketika mengubah salah satu bagian kode menyebabkan masalah di bagian lain.
Mulailah dengan apa yang disebut “tes asap”. Nama ini berasal dari perangkat keras elektronik: jika Anda menyalakan sirkuit dan sambungan solder mulai berasap, ada sesuatu yang mendasar yang salah. Tes asap hanya menyatakan bahwa halaman dimuat, atau ada objek, atau beberapa kriteria super mendasar lainnya. Ini juga menegaskan bahwa pengaturan pengujian berfungsi! Seiring berkembangnya proyek untuk mendukung fitur-fitur yang lebih kompleks, pengujian asap masih memiliki keuntungan: ketika banyak pengujian fitur gagal pada saat yang sama, status pengujian asap membantu menentukan dengan cepat apakah masalah memengaruhi keseluruhan sistem atau tidak.
Kiat profesional: tes yang tampak sederhana tetap bisa memberikan manfaat besar. Jangan menilai tes dari cakupannya :)
Hal lain yang tampak menggoda untuk memotong proses sebenarnya secara halus menghubungkan tim pengembangan dan bisnis: peralihan dari desain ke pengembangan. Pendatang baru dalam proses Agile sering menyarankan bahwa alih-alih meminta pemangku kepentingan bisnis menulis kriteria penerimaan, pengembang sebaiknya mengerjakan gambar mockup yang berasal dari tim desain. Tampaknya ini merupakan cara mudah untuk menghemat waktu, namun menimbulkan banyak risiko.
“Sebuah gambar bernilai ribuan kata” memang benar; namun nilai dari ribuan kata tersebut adalah tentang bagaimana seharusnya desain tersebut terlihat. Saat Anda memberikan gambaran kepada pengembang dan meminta mereka menemukan bagaimana seharusnya perangkat lunak berperilaku, Anda meminta mereka untuk membuat keputusan bisnis. Pengembang harus mengetahui cara memprogram — meminta mereka bekerja jauh di luar wilayah mereka tidaklah efisien.
Beberapa pengembang sangat pandai dalam memahami bisnis, menafsirkan persyaratan bisnis ke dalam desain UI, dan lain sebagainya. Jika Anda memiliki seseorang seperti itu, anggaplah Anda beruntung, namun Anda mungkin masih rentan terhadap ancaman yang lebih besar.
“Pengoptimalan Dini” adalah jargon perangkat lunak yang berarti “memecahkan masalah yang belum Anda hadapi.” Pengembang terkenal memikirkan semua persyaratan yang mungkin dimiliki perangkat lunak. Terkadang mereka fokus pada kinerja, menghitung waktu muat berdasarkan perkiraan jumlah pengguna di masa depan; terkadang ini tentang fitur, membuat setiap elemen aplikasi dapat dikonfigurasi tanpa batas “untuk berjaga-jaga”.
Pengembang dapat membuang banyak waktu untuk pengoptimalan prematur, dan komplikasi yang ditambahkan ke basis kode dapat dengan cepat menghentikan kemajuan pada fitur yang valid. Namun mereka terpaku pada poin-poin ini karena mereka pernah mengalami kegagalan di masa lalu. Kriteria penerimaan berfungsi sebagai jaminan dan pedoman bagi pengembang, sebuah rencana yang dapat mereka patuhi dengan percaya diri.
Prinsip dasarnya adalah membuat proses sesederhana mungkin, namun tidak lebih sederhana. Lain kali kita akan membahas tentang cara melakukan ini setiap hari.
