Waterfall vs Agile: Cara Memilih Sebelum Kontrak Ditandatangani

Pilihan waterfall vs agile sebaiknya ditentukan oleh satu hal: seberapa yakin Anda bahwa kebutuhan sistem tidak akan berubah selama proyek berjalan. Bila isinya sudah pasti dan bisa ditulis lengkap di awal, waterfall memberi jadwal dan biaya yang mudah dikunci. Bila Anda baru akan tahu apa yang dibutuhkan setelah pengguna mencobanya, agile lebih aman. Di bawah ini ada enam pertanyaan untuk memutuskannya, dampaknya pada kontrak dengan vendor, dan kesalahan yang paling sering kami temui di kedua cara.

Perbedaan waterfall dan agile dalam satu kalimat masing-masing

Waterfall menyelesaikan satu tahap sebelum masuk ke tahap berikutnya: kebutuhan, desain, pembuatan, pengujian, lalu serah terima. Agile memecah pekerjaan menjadi putaran pendek yang masing-masing menghasilkan bagian sistem yang bisa dicoba, lalu urutan pekerjaan berikutnya disusun ulang dari masukan putaran sebelumnya.

Makalah Winston Royce tahun 1970 sering disebut sebagai asal waterfall, padahal Royce menilai alur satu arah tanpa umpan balik itu "risky and invites failure" dan menyarankan prosesnya diulang minimal dua kali (ringkasan di Wikipedia). Jadi waterfall yang sehat pun punya titik balik.

Agile sendiri berangkat dari Manifesto Agile 2001, yang antara lain menaruh "perangkat lunak yang bekerja" di atas "dokumentasi yang menyeluruh" dan "tanggap terhadap perubahan" di atas "mengikuti rencana". Kerangka yang paling banyak dipakai, Scrum, membatasi satu sprint paling lama satu bulan, rapat harian 15 menit, dan tim 10 orang atau kurang (Scrum Guide 2020). Di proyek kecil sampai menengah, sprint dua minggu paling umum. Kanban dan Lean, yang juga sering disebut, lebih cocok untuk pekerjaan yang mengalir terus seperti perbaikan setelah rilis; kami membahasnya di artikel Lean dan Six Sigma untuk proyek teknologi.

Aspek	Waterfall	Agile
Lingkup	Dikunci di awal lewat dokumen kebutuhan	Daftar prioritas yang boleh diubah tiap sprint
Kapan Anda melihat hasil	Saat pengujian, biasanya di bulan-bulan akhir	Tiap 1 sampai 4 minggu, dalam bentuk demo
Biaya	Satu angka untuk lingkup tertentu	Per periode atau per tim; lingkup yang menyesuaikan
Perubahan di tengah jalan	Lewat permintaan perubahan dan biaya tambahan	Ditukar dengan item lain di daftar prioritas
Waktu yang Anda berikan	Banyak di awal dan di akhir	1 sampai 2 jam tiap sprint, sepanjang proyek

Enam pertanyaan untuk memilih pendekatan

Setiap jawaban "ya" condong ke waterfall.

1. Apakah alur kerjanya sudah berjalan hari ini (di kertas atau spreadsheet) dan sistem hanya memindahkannya?
2. Apakah ada format baku dari pihak luar, misalnya laporan ke regulator, kantor pusat, atau mitra bank?
3. Apakah anggaran berupa satu angka yang tidak bisa ditambah tahun ini?
4. Apakah tanggal selesai terikat peristiwa yang tidak bisa digeser, misalnya awal tahun ajaran atau tutup buku?
5. Apakah pengguna akhir sulit dihubungi selama proyek (cabang jauh, pelanggan umum)?
6. Apakah tidak ada orang di pihak Anda yang bisa meluangkan 2 jam tiap dua minggu untuk mencoba dan memutuskan?

Lima atau enam "ya": waterfall dengan dokumen kebutuhan yang rinci. Dua atau kurang: agile. Tiga atau empat adalah wilayah hybrid, dan sejujurnya di situlah sebagian besar proyek software bisnis berada.

Pertanyaan keenam paling sering diremehkan. Agile tanpa orang yang berwenang memutuskan prioritas berubah jadi waterfall yang lebih lambat. Tim menunggu jawaban.

Dua contoh: kapan masing-masing masuk akal

Contoh pertama (ilustrasi): koperasi simpan pinjam ingin memindahkan pencatatan angsuran dari spreadsheet ke sistem, lengkap dengan laporan bulanan yang formatnya sudah ditentukan pengurus. Aturan bunga, denda, dan kolom laporan bisa ditulis lengkap sebelum satu baris kode dibuat. Waterfall cocok di sini. Waktu Anda paling berguna di awal, untuk memeriksa dokumen kebutuhan baris demi baris dengan contoh angka nyata, misalnya angsuran Rp1.250.000 yang telat 9 hari.

Contoh kedua (ilustrasi): jaringan laundry dengan 4 outlet ingin aplikasi pemesanan antar-jemput untuk pelanggan. Belum ada yang tahu apakah pelanggan lebih suka memilih jam jemput atau cukup menekan "jemput sekarang", atau apakah notifikasi WhatsApp lebih dipakai daripada notifikasi aplikasi. Mengunci semua itu di dokumen awal berarti menebak. Agile cocok: rilis versi sederhana di satu outlet, amati dua sampai tiga sprint, lalu putuskan fitur berikutnya.

Metode menentukan bentuk kontrak dan pembayaran

Bagi pemilik bisnis yang memesan software ke vendor, pilihan metode langsung terasa di kontrak. Kontrak harga tetap dengan lingkup tetap hanya adil bila lingkupnya memang bisa ditulis lengkap. Bila dipaksakan pada proyek yang kebutuhannya masih bergerak, setiap perubahan kecil menjadi negosiasi, dan vendor akan menaikkan harga awal untuk menutup risiko yang belum terlihat.

Untuk waterfall, termin pembayaran biasanya mengikuti tahap: misalnya setelah dokumen kebutuhan disetujui, setelah desain disetujui, setelah UAT (uji penerimaan pengguna), dan setelah serah terima. Lampirkan dokumen kebutuhan yang sudah disetujui ke kontrak. File yang hanya tersimpan di email akan sulit dijadikan pegangan saat terjadi beda tafsir di bulan ketiga.

Untuk agile, yang dikunci adalah anggaran dan durasi, misalnya 6 sprint dua minggu, sementara isi tiap sprint ditentukan bersama. Minta tiga hal tertulis: definisi "selesai" untuk setiap fitur, demo di akhir tiap sprint, dan hak Anda menghentikan proyek setelah sprint mana pun dengan tetap memegang kode yang sudah dibayar.

Hybrid: bentuk yang paling sering kami pakai

Pola hybrid yang paling praktis adalah lingkup dan harga dikunci per tahap, tetapi pembuatan dijalankan per dua minggu dengan demo. Fondasi yang mahal diubah belakangan (struktur data, peran pengguna, integrasi pembayaran, format laporan wajib) diputuskan di awal secara waterfall. Tampilan, urutan layar, dan fitur pelengkap dikerjakan bertahap.

Kontraknya memuat klausul tukar fitur: Anda boleh menambah fitur baru selama fitur lain dengan bobot setara dikeluarkan. Tanpa klausul ini, hybrid mudah tergelincir menjadi harga tetap dengan lingkup yang terus membengkak.

Dari sisi pembuat sistem, kami melihat satu hal berulang. Perubahan yang benar-benar mahal hampir selalu menyangkut data, misalnya satu pelanggan ternyata bisa punya banyak alamat, atau satu karyawan bisa berada di dua cabang. Ubahan tampilan jarang sampai mengguncang jadwal. Karena itu, sebelum memilih metode, luangkan satu pertemuan khusus untuk membahas "satu X bisa punya berapa Y" pada data inti Anda.

Kesalahan yang sering terjadi di kedua cara

Di proyek waterfall, kesalahan terbesar adalah menyetujui dokumen kebutuhan setebal 40 halaman tanpa membacanya bersama orang yang akan memakai sistem. Kasir, admin gudang, atau staf TU sekolah biasanya langsung menemukan kasus yang terlewat, seperti retur sebagian atau siswa pindahan di tengah semester. Kesalahan kedua adalah pengujian yang dijadwalkan dua minggu terakhir tanpa cadangan waktu.

Di proyek agile, kesalahan yang paling umum adalah demo yang dihadiri orang tanpa wewenang. Tim mendapat masukan, tetapi keputusan baru keluar tiga minggu kemudian. Kesalahan lainnya adalah daftar prioritas yang tidak pernah dipangkas, sehingga sprint ke-10 masih mengerjakan permintaan dari sprint ke-2 yang sudah tidak relevan.

Satu kesalahan muncul di keduanya: tidak ada yang memutuskan fitur mana yang boleh ditunda ke versi berikutnya. Tanpa daftar "nanti saja" yang tertulis, proyek waterfall menumpuk permintaan perubahan dan proyek agile tidak pernah merasa selesai.

Cara Zonaku menentukan pendekatan proyek

Saat membangun aplikasi kustom, kami mulai dari pertanyaan yang sama dengan daftar di atas, lalu mengusulkan pendekatan beserta bentuk termin yang sesuai. Untuk sebagian besar proyek, hasilnya adalah hybrid: kebutuhan dan data inti dikunci di awal, pembuatan berjalan dengan demo rutin, dan dukungan setelah rilis mencakup perbaikan, pembaruan, dan pengembangan tambahan. Urutan tahapnya kami jelaskan lebih rinci di tahapan pengembangan aplikasi atau website.

Langkah berikutnya yang konkret: isi enam pertanyaan di atas bersama satu orang yang akan memakai sistemnya setiap hari, lalu bawa jawabannya ke diskusi dengan vendor. Bila ingin membahasnya dengan kami, hubungi tim Zonaku.