Perbandingan Manajemen Proyek Tradisional vs Agile: Perbedaan Utama & Penjelasan Segitiga Besi

Manajemen Proyek Tradisional

Pendekatan manajemen proyek tradisional (waterfall) bersifat linier, di mana semua tahap proses terjadi secara berurutan. Metode ini mengandalkan alat yang dapat diprediksi dan pengalaman yang dapat diprediksi. Setiap proyek mengikuti siklus hidup yang sama, mencakup tahap kelayakan, perencanaan, desain, pembangunan, pengujian, produksi, dan dukungan, seperti yang ditunjukkan pada gambar di bawah ini.

Perbandingan Pengembangan Perangkat Lunak Waterfall vs Agile

Seluruh proyek direncanakan terlebih dahulu tanpa ruang untuk perubahan dalam persyaratan — seperti Waterfall, PMBOK PMI, dan PRINCE2 bersifat kaku dan sangat terkendali. Mereka menggambarkan tahapan yang jelas dari awal hingga akhir dan mengasumsikan Anda sudah memiliki semua persyaratan dan informasi yang dibutuhkan.

Pendekatan ini mengasumsikan waktu dan biaya bersifat variabel, sementara persyaratan bersifat tetap — inilah sebabnya manajemen proyek tradisional sering mengalami masalah terkait anggaran dan jadwal.

Manajemen Proyek Agile

Sementara sistem tradisional sangat menekankan perencanaan awal, faktor-faktor seperti biaya, cakupan, dan waktu sangat penting. Di sisi lain, Agile menekankan kerja tim, kolaborasi dengan pelanggan, dan fleksibilitas.

Agile menolak manajemen proyek tradisional karena membosankan, terbatas, dan tidak sesuai dengan dunia modern yang dinamis. Manajemen proyek Agile bersifat iteratif, bertujuan untuk terus mengintegrasikan umpan balik pengguna dan rilis berkelanjutan dalam setiap iterasi pengembangan, seperti yang ditunjukkan di atas. Setiap hasil tugas merupakan produk yang Anda jual kepada pemangku kepentingan. Tim dan alur kerja dirancang untuk menciptakan sesuatu yang secara langsung bermanfaat bagi pelanggan.

Tradisional atau Agile – Bagaimana Memilih?

Menurut Laporan CHAOS 2011 dari Standish Group, proyek Agile tiga kali lebih sukses dibandingkan proyek Waterfall. Grafik di bawah ini menunjukkan hasil spesifik dari studi yang dilakukan antara tahun 2002 hingga 2012:

Tingkat Keberhasilan Proyek Waterfall vs Agile

Perbedaan Antara Tradisional dan Agile

Tabel di bawah ini merangkum banyak perbedaan utama antara model manajemen proyek Scrum dan tradisional.

Biaya Perubahan

Secara tradisional, perubahan pada proyek perangkat lunak dihindari karena biaya meningkat secara signifikan di akhir proyek. Pengembangan perangkat lunak Agile mengakui bahwa perubahan adalah hal yang tak terhindarkan dan bahwa menginvestasikan banyak sumber daya pada perencanaan awal adalah tidak praktis. Hal ini secara jelas dinyatakan dalam salah satu dari empat nilai dalam Manifesto Agile:

“Menanggapi perubahan kebutuhan dibanding mengikuti rencana tetap.”

Agile menantang anggapan ini dan berargumen bahwa biaya perubahan mungkin relatif datar, seperti yang ditunjukkan pada gambar di bawah ini:

Biaya Perubahan dalam Tradisional vs Agile

Agile vs Segitiga Besi Tradisional dalam Manajemen Proyek

Keberhasilan manajemen proyek secara tradisional dikaitkan dengan kemampuan mengelola kendala dalam cakupan, waktu, biaya, dan kualitas, seperti yang ditunjukkan pada gambar di bawah ini. Ini adalah metafora yang populer yang menyiratkan bahwa manajer proyek diharapkan dapat menyeimbangkan kendala-kendala ini secara wajar.

Segitiga Besi dalam Agile vs Manajemen Proyek Tradisional

Apa Masalahnya dengan Segitiga Besi Tradisional?

Sebagai contoh, suatu proyek dapat selesai lebih cepat dengan menaikkan anggaran atau mengurangi cakupan. Demikian pula, memperluas cakupan biasanya memerlukan peningkatan anggaran dan jangka waktu yang sesuai. Mengurangi anggaran tanpa menyesuaikan jangka waktu atau cakupan akan menyebabkan penurunan kualitas. Namun dalam praktiknya, pertukaran antar batasan tidak selalu memungkinkan. Sebagai contoh, menginvestasikan lebih banyak dana (dan orang) pada proyek yang sudah memiliki sumber daya yang cukup justru dapat memperlambat kemajuan. Selain itu, pada proyek yang berkinerja buruk, meningkatkan anggaran, jadwal, atau cakupan tanpa merugikan kualitas sering kali tidak mungkin dilakukan.

Dengan demikian, Segitiga Besi tradisional jelas tidak cukup sebagai model keberhasilan proyek, karena mengabaikan dimensi kunci keberhasilan, termasuk dampak terhadap pemangku kepentingan, pembelajaran, dan kepuasan pengguna.

Sigitiga Besi Agile – Perubahan Paradigma

Dalam pendekatan tradisional, segitiga biasanya tampak seperti yang ditunjukkan di sebelah kiri di bawah ini. Seperti yang Anda lihat, persyaratan produk memiliki cakupan tetap. Oleh karena itu, untuk memastikan produk menghadirkan semua fitur yang dibutuhkan, kita memerlukan fleksibilitas dalam sumber daya (dan anggaran) serta jangka waktu (batas waktu). Jika kita benar-benar perlu produk mencakup seluruh daftar fitur yang dijelaskan dalam spesifikasi persyaratan awal, kita mungkin perlu menunda tanggal rilis selama beberapa bulan atau lebih.

Dalam pengertian Agile, terdapat jangka waktu tetap (dalam Scrum, ini dicapai melaluiwaktu terbatas Sprintdan sumber daya tetap). Oleh karena itu, ketika sesuatu tidak berjalan sesuai rencana, cakupan harus dikurangi. Namun dalam Agile, kami memastikan bahwa bahkan jika kami harus mengorbankan cakupan, kami tetap menghadirkan item dengan prioritas tertinggi dariBacklog Produkuntuk memaksimalkan nilai yang dihasilkan oleh proyek.

Sigitiga Besi dalam Konteks Agile