Please enable JavaScript.
Coggle requires JavaScript to display documents.
AGILE VS WATERFALL Methodology - Coggle Diagram
AGILE VS WATERFALL Methodology
Waterfall
Sejarah
Metode Waterfall pertama kali diperkenalkan oleh Winston W. Royce pada tahun 1970-an melalui makalahnya yang berjudul "Managing the Development of Large Software Systems". Latar belakang dibuatnya metode Waterfall berkaitan dengan kebutuhan untuk mengatasi masalah dalam pengembangan proyek-proyek besar, terutama dalam pengembangan perangkat lunak.
Prinsip-prinsip
Tahap yang Terdefinisi dengan Jelas
Dokumentasi yang Mendalam
Campur tangan pelanggan yang minimum
Kelebihan
Waterfall memberikan perkiraan biaya dan waktu yang akurat.
Evaluasi kemajuan mudah karena pendekatan yang terstruktur.
Proses dapat diulang, memudahkan anggota tim baru.
Keterlibatan pelanggan yang terbatas menghindari penambahan persyaratan baru, mencegah keterlambatan.
Kekurangan
Komunikasi terbatas dengan klien selama desain dan implementasi.
Jika satu tahap mengalami keterlambatan, semua tahap berikutnya akan terlambat.
Tidak memungkinkan proses tumpang tindih, sehingga mengurangi efisiensi.
Agile
Sejarah
Latar belakang dan sejarah metodologi Agile dapat ditelusuri kembali ke akhir tahun 1990-an dan awal 2000-an, ketika industri perangkat lunak mulai menyadari bahwa pendekatan tradisional seperti model Waterfall memiliki beberapa kelemahan dalam menangani perubahan cepat dan kompleksitas dalam pengembangan perangkat lunak.
Prinsip-prinsip
Memuaskan pelanggan atau user melalui pengiriman awal dan berkelanjutan dari pekerjaan yang berharga
Memecahkan pekerjaan besar menjadi tugas-tugas kecil yang dapat diselesaikan dengan cepat
Mengetahui bahwa karya terbaik muncul dari tim yang mengatur dirinya sendiri
Memberikan individu yang termotivasi dengan lingkungan dan dukungan yang mereka butuhkan dan percaya akan keberhasilan pekerjaan yang dilakukan
Menciptakan proses yang mempromosikan upaya berkelanjutan
Mempertahankan kecepatan konstan untuk menyelesaikan pekerjaan
Terbuka untuk mengubah persyaratan dan perubahan hingga proyek selesai
Mengumpulkan tim proyek dan pemilik bisnis setiap hari selama proyek berlangsung
Meminta tim merenungkan secara berkala tentang bagaimana menjadi lebih efektif, mengatur dan sesuaikan perilaku yang sesuai
Mengukur kemajuan dengan jumlah pekerjaan yang diselesaikan
Selalu berusaha untuk mencari keunggulan
Memanfaatkan berbagai perubahan untuk keunggulan kompetitif.
Kelebihan
Lebih fleksibel, efisien, dan sesuai dengan kebutuhan.
Prosesnya lebih singkat dan teratur.
Mampu membuat alur kerja yang lebih efisien dan lebih baik.
Lebih responsif terhadap kebutuhan klien dan kondisi.
Membuat interaksi antara klien dan developer menjadi lebih intens. Dengan komunikasi yang baik, maka miss communication juga akan bisa diminimalisir.
Kekurangan
Kurang tepat jika diimplementasikan pada tim dengan skala besar.
Para developer harus senantiasa siap siaga, lantaran perubahan dapat terjadi sewaktu-waktu.
Jangkauan kerja yang dapat berubah-ubah
Contoh
Scrum
Kanban
Extreme Programming