Dalam pengembangan software, dua pendekatan yang paling sering dibicarakan adalah Waterfall dan Agile. Keduanya memiliki tujuan yang sama: membantu tim menyelesaikan proyek secara terstruktur. Namun, cara keduanya menghadapi perencanaan, perubahan, pengembangan, dan kebutuhan pengguna sangat berbeda.

Sering kali muncul anggapan bahwa Agile adalah metode modern sementara Waterfall adalah metode lama yang sudah tidak relevan. Pandangan tersebut terlalu sederhana. Dalam praktiknya, tidak ada metodologi yang selalu paling baik untuk semua proyek.

Pertanyaan yang lebih tepat bukan:

"Mana yang lebih bagus, Agile atau Waterfall?"

Tetapi:

"Metode mana yang paling sesuai dengan karakter proyek yang sedang kita kerjakan?"

Mengenal Waterfall

Waterfall menggunakan pendekatan yang relatif linear. Proyek dibagi menjadi beberapa fase dan biasanya satu fase diselesaikan sebelum masuk ke fase berikutnya.

Secara sederhana alurnya dapat digambarkan sebagai:

Requirement
    ↓
Analysis
    ↓
Design
    ↓
Development
    ↓
Testing
    ↓
Deployment
    ↓
Maintenance

Pada tahap awal, tim berusaha mendefinisikan kebutuhan sistem sedetail mungkin. Setelah requirement disepakati, proses dilanjutkan ke desain, development, testing, hingga deployment.

Karena alurnya seperti air terjun yang bergerak dari atas ke bawah, pendekatan ini dikenal sebagai Waterfall.

Kelebihan Waterfall

Salah satu kekuatan Waterfall adalah struktur dan dokumentasinya yang jelas.

Sebelum development dimulai, biasanya sudah tersedia requirement, spesifikasi, desain sistem, jadwal, hingga ruang lingkup pekerjaan.

Pendekatan seperti ini memberikan beberapa keuntungan:

• scope proyek relatif jelas;
• dokumentasi lebih terstruktur;
• milestone lebih mudah ditentukan;
• kebutuhan anggaran lebih mudah diperkirakan;
• proses approval lebih mudah dikelola;
• cocok untuk lingkungan yang membutuhkan governance ketat.

Waterfall dapat bekerja dengan sangat baik ketika requirement memang sudah diketahui sejak awal dan kemungkinan perubahannya kecil.

Contohnya adalah sistem yang dibangun berdasarkan regulasi tertentu, integrasi dengan spesifikasi yang sudah baku, atau proyek dengan kontrak dan ruang lingkup yang sangat jelas.

Masalah Waterfall: Bagaimana Jika Requirement Berubah?

Software memiliki karakter yang berbeda dengan pembangunan fisik.

Ketika pengguna melihat aplikasi yang sudah berjalan, sering kali muncul pemahaman baru.

Misalnya pada awal proyek pengguna meminta:

Sistem Persetujuan Dokumen

Setelah prototype atau aplikasi mulai digunakan, muncul kebutuhan baru:

Sistem Persetujuan Dokumen
├── Multi-level approval
├── Delegasi approval
├── Notification
├── Audit trail
├── Digital signature
└── Dashboard monitoring

Masalahnya, kebutuhan tersebut mungkin baru terlihat setelah development sudah berjalan jauh.

Pada Waterfall, perubahan seperti ini dapat berdampak pada banyak hal sekaligus:

Requirement berubah
        ↓
Design berubah
        ↓
Database berubah
        ↓
Source code berubah
        ↓
Test case berubah
        ↓
Timeline berubah
        ↓
Biaya berubah

Semakin terlambat perubahan ditemukan, biasanya semakin besar biaya perubahan tersebut.

Di sinilah Agile mencoba menawarkan pendekatan berbeda.

Mengenal Agile

Agile tidak melihat pengembangan software sebagai satu perjalanan panjang dari requirement menuju deployment.

Sebaliknya, pengembangan dilakukan dalam iterasi kecil dan berulang.

Gambaran sederhananya:

Plan
 ↓
Design
 ↓
Develop
 ↓
Test
 ↓
Release
 ↓
Feedback
 └────────→ Plan berikutnya

Tim membuat sebagian kecil fitur, mengujinya, menunjukkan hasilnya kepada stakeholder atau pengguna, menerima feedback, kemudian memperbaikinya pada iterasi berikutnya.

Dalam Scrum, misalnya, periode pengembangan tersebut sering disebut Sprint.

Satu Sprint dapat berlangsung satu hingga beberapa minggu tergantung kesepakatan tim.

Filosofi Penting Agile

Agile bukan sekadar:

"Tidak perlu dokumentasi."

Dan juga bukan:

"Requirement boleh berubah setiap hari."

Justru Agile membutuhkan disiplin yang tinggi.

Perbedaannya adalah Agile menerima kenyataan bahwa tidak semua kebutuhan dapat diketahui secara sempurna sejak hari pertama proyek.

Software berkembang bersama pemahaman pengguna terhadap masalah yang ingin diselesaikan.

Karena itu Agile mengutamakan feedback yang cepat.

Contoh Sederhana

Bayangkan sebuah perusahaan ingin membuat aplikasi Helpdesk.

Dengan pendekatan Waterfall, tim mungkin mencoba menentukan seluruh requirement terlebih dahulu:

Helpdesk System
├── Ticket Management
├── User Management
├── SLA
├── Notification
├── Escalation
├── Reporting
├── Dashboard
├── Knowledge Base
└── Integration

Setelah seluruh requirement selesai, barulah development dimulai.

Dengan Agile, pendekatannya dapat berbeda.

Sprint 1

Login
Create Ticket
Ticket List
Ticket Detail

Aplikasi kemudian diperlihatkan kepada pengguna.

Pengguna memberikan feedback:

"Kami membutuhkan kategori tiket agar tiket bisa langsung diarahkan ke tim terkait."

Maka Sprint berikutnya dapat berisi:

Sprint 2

Ticket Category
Assignment
Ticket Status
Basic Notification

Setelah digunakan kembali, muncul kebutuhan:

"Kami perlu mengetahui apakah penyelesaian tiket sudah melewati SLA."

Sprint berikutnya:

Sprint 3

SLA
Escalation
Dashboard

Dengan pola seperti ini, sistem berkembang berdasarkan kebutuhan nyata yang semakin dipahami oleh pengguna dan developer.

Perbedaan Agile dan Waterfall

Apakah Agile Berarti Bisa Mengubah Requirement Seenaknya?

Tidak.

Ini merupakan salah satu kesalahpahaman yang cukup sering terjadi.

Agile memang menerima perubahan, tetapi perubahan tetap harus dikelola.

Misalnya sebuah Sprint sedang berjalan dengan target:

Sprint 12

- Login SSO
- User Management
- Role Management
- Audit Log

Kemudian stakeholder datang di tengah Sprint dan mengatakan:

"Tambahkan modul inventory, payment gateway, chatbot AI, dan mobile application. Minggu ini juga."

Itu bukan Agile.

Itu adalah scope yang tidak terkendali.

Agile tetap membutuhkan backlog, prioritas, kapasitas tim, estimasi, dan keputusan mengenai pekerjaan mana yang harus dilakukan terlebih dahulu.

Agile Juga Bisa Gagal

Agile bukan solusi ajaib.

Implementasi Agile dapat gagal ketika organisasi hanya mengadopsi istilahnya tanpa mengadopsi cara kerjanya.

Misalnya:

Ada Sprint
Ada Daily Meeting
Ada Jira
Ada Scrum Master

Tetapi setiap hari stakeholder memasukkan pekerjaan baru dan semuanya dianggap prioritas.

Hasilnya bukan Agile.

Hasilnya adalah kekacauan yang diberi nama Agile.

Agile membutuhkan disiplin dalam menentukan prioritas dan keberanian mengatakan:

Jika pekerjaan baru masuk, kita harus menentukan pekerjaan mana yang ditunda.

Karena kapasitas tim tetap terbatas.

Waterfall Juga Tidak Selalu Buruk

Waterfall sering dianggap sebagai pendekatan kuno.

Padahal dalam kondisi tertentu, Waterfall justru masuk akal.

Misalnya ketika proyek memiliki:

• requirement yang sangat stabil;
• spesifikasi teknis yang sudah baku;
• kebutuhan compliance yang ketat;
• kontrak dengan scope yang jelas;
• proses approval formal;
• ketergantungan terhadap hardware atau infrastruktur;
• dokumentasi yang wajib tersedia sebelum implementasi.

Dalam kondisi seperti itu, melakukan perencanaan mendalam di awal dapat mengurangi risiko.

Kapan Sebaiknya Menggunakan Agile?

Agile biasanya menarik ketika:

• kebutuhan bisnis masih berkembang;
• feedback pengguna sangat penting;
• produk harus cepat masuk pasar;
• prioritas dapat berubah;
• pengembangan dilakukan secara berkelanjutan;
• sistem memiliki banyak fitur yang dapat dirilis bertahap.

Contohnya:

SaaS
E-Commerce
Mobile Application
Startup Product
Internal Business Application
AI Application
Customer Portal

Produk seperti ini biasanya terus berkembang setelah versi pertama dirilis.

Kapan Waterfall Lebih Masuk Akal?

Waterfall dapat menjadi pilihan ketika:

• requirement sudah jelas;
• perubahan relatif kecil;
• regulasi sangat ketat;
• proyek membutuhkan dokumentasi formal;
• kontrak menentukan scope secara detail;
• pekerjaan memiliki dependency yang sulit diubah.

Namun, bahkan pada proyek seperti ini, bukan berarti seluruh proses harus 100% Waterfall.

Bagaimana dengan Hybrid?

Dalam dunia nyata, banyak organisasi sebenarnya tidak menggunakan Agile atau Waterfall secara murni.

Mereka menggunakan pendekatan Hybrid.

Misalnya:

Project Planning
        ↓
High Level Requirement
        ↓
Architecture
        ↓
Security Standard
        ↓
─────────────────────────
        ↓
    Agile Sprint
        ↓
Develop → Test → Review
        ↑             ↓
        └── Feedback ─┘
        ↓
─────────────────────────
        ↓
UAT
        ↓
Production

Arsitektur utama, standar keamanan, compliance, anggaran, dan ruang lingkup besar dapat ditentukan sejak awal.

Namun pengembangan fitur dilakukan secara Agile.

Pendekatan ini sering lebih realistis untuk organisasi besar.

Agile Bukan Berarti Tanpa Arsitektur

Ada risiko lain ketika Agile diterjemahkan sebagai:

"Coding dulu, nanti dipikirkan."

Pendekatan seperti ini dapat menghasilkan technical debt yang sangat besar.

Walaupun menggunakan Agile, tim tetap perlu memikirkan:

Architecture
Security
Database Design
API Standard
Logging
Monitoring
Backup
Scalability
Testing
CI/CD
Documentation

Agile memberikan fleksibilitas terhadap perubahan produk, bukan alasan untuk mengabaikan engineering discipline.

Memilih Metodologi Berdasarkan Risiko

Daripada memperdebatkan Agile versus Waterfall, pendekatan yang lebih berguna adalah melihat karakter proyek.

Tanyakan beberapa pertanyaan berikut:

Apakah requirement sudah jelas?
        ↓
Apakah kemungkinan berubah besar?
        ↓
Seberapa cepat pengguna harus melihat hasil?
        ↓
Apakah ada regulasi atau compliance?
        ↓
Seberapa besar risiko perubahan arsitektur?
        ↓
Seberapa sering stakeholder dapat memberikan feedback?

Jawaban dari pertanyaan tersebut akan membantu menentukan pendekatan yang paling sesuai.

Jangan Agile Hanya Karena Sedang Tren

Banyak organisasi ingin menggunakan Agile karena dianggap lebih modern.

Namun mengganti nama:

Project Manager → Scrum Master
Task List       → Backlog
Meeting         → Daily Scrum
Tahapan         → Sprint

tidak otomatis membuat organisasi menjadi Agile.

Transformasi Agile sebenarnya lebih banyak berkaitan dengan cara mengambil keputusan, kolaborasi, feedback, prioritas, dan kemampuan organisasi menerima perubahan.

Tools hanyalah pendukung.

Menggunakan Jira tidak otomatis membuat sebuah tim Agile.

Sama seperti menggunakan Git tidak otomatis membuat seseorang menjadi software engineer yang baik.

Kesimpulan

Agile dan Waterfall bukan dua kubu yang harus selalu dipertentangkan.

Waterfall menawarkan prediktabilitas, struktur, dan perencanaan, sedangkan Agile menawarkan adaptabilitas, feedback cepat, dan pengembangan iteratif.

Waterfall dapat menjadi pilihan yang baik ketika tujuan dan requirement sudah jelas.

Agile dapat menjadi pilihan yang baik ketika produk masih berkembang dan membutuhkan feedback terus-menerus.

Dan untuk banyak proyek enterprise, pendekatan Hybrid justru dapat menjadi pilihan yang lebih realistis.

Pada akhirnya, metodologi hanyalah alat.

Metodologi yang baik bukan metodologi yang paling populer, tetapi metodologi yang membantu tim menghasilkan software yang tepat, aman, dapat dipelihara, dan benar-benar menyelesaikan masalah pengguna.