---

Harus Merencanakan Seluruh Proyek Sebelum Memahaminya? Ini Mungkin Mengejutkan Anda!

Tanpa Scrum, tim kami pernah membangun dan menghasilkan produk perangkat lunak serta perangkat keras yang sepenuhnya keliru dan tidak memenuhi tuntutan klien.

Ada masa dalam kehidupan profesional kami ketika perusahaan pihak ketiga memaksakan cara membangun produk atau layanan perangkat lunak kami.

Capability Maturity Model (CMM), ISO 9001:2008 dan turunannya berusaha membantu perusahaan kami memastikan perangkat lunak yang benar dibangun dengan cara benar.

Tingkat keberhasilan mereka bukan bagian buku ini. Buku ini berfokus pada proses serta keunggulan kerangka kerja Scrum, bukan mengkritik prosedur yang hampir punah.

Namun, saya perlu menambahkan bahwa kerangka perbaikan proses sebelum kerangka rekayasa perangkat lunak Scrum menyarankan pendekatan bertahap. Mereka menyarankan pendekatan rekayasa perangkat lunak bertahap yang kami sebut Model Rekayasa Perangkat Lunak Waterfall.

Dalam Model Waterfall, setiap proyek seharusnya dimulai dengan analisis persyaratan untuk memahami kebutuhan dan keinginan klien.

Lalu kami mendesain persyaratan, mengimplementasikan, menguji (memverifikasi), dan memeliharanya dalam lingkungan produksi perangkat lunak. Akhirnya kami mencapai akhir siklus hidup rekayasa perangkat lunak.

Namun, kenyataannya tidak berjalan demikian!

Metodologi Waterfall dibandingkan Kerangka Kerja Scrum

Fase Model Pengembangan Perangkat Lunak Waterfall Klasik

Dampak buruk keterlambatan tak terduga pada satu tahap Model Rekayasa Perangkat Lunak Waterfall tidak terhindarkan bagi tahap berikutnya.

Studi menunjukkan bahwa pada lebih dari 80% proyek perangkat lunak gagal yang diteliti, penggunaan Metodologi Waterfall merupakan salah satu faktor kegagalan utama. Namun, mengapa?

Seperti terlihat di sebelah kiri, Metodologi Waterfall memiliki rangkaian tahap proyek berurutan yang ketat. Tahap sebelumnya harus selesai sebelum tahap berikutnya dimulai. Kembali ke tahap sebelumnya biasanya menyakitkan, mahal, membuat tim frustrasi, dan memakan waktu.

Jadwal proyek direncanakan sejak awal. Produk yang dapat dirilis baru disampaikan pada akhir jadwal. Jika satu tahap terlambat, semua tahap lain ikut terlambat.

Untuk menghindarinya, manajer proyek Waterfall biasanya mencoba mengantisipasi semua kemungkinan sebelumnya. Pada tahap sangat awal, mereka berusaha mendefinisikan seluruh persyaratan sedetail dan selengkap mungkin. Namun, definisi persyaratan pada awal proyek sering rumit sehingga banyak persyaratan berubah (atau seharusnya berubah) sepanjang proyek.

Studi menunjukkan bahwa pada proyek lebih besar serta kompleks, sekitar 60% persyaratan awal berubah selama proyek. Persyaratan lain diimplementasikan sesuai definisi, tetapi sebagian sebenarnya tidak diperlukan pelanggan. Implementasi tersebut menghabiskan waktu serta uang yang seharusnya dapat digunakan untuk fungsi bernilai tambah lebih tinggi bagi klien.

Pemisahan tahap proyek memaksa manajer mengestimasi setiap tahap secara terpisah. Masalahnya, sebagian besar tahap biasanya tidak terpisah. Tahap tersebut berjalan bersama dan paralel.

Misalnya, tidak masuk akal menganggap pengembangan selesai sebelum pengujian dimulai. Namun, sayangnya itulah cara Metodologi Waterfall dahulu berjalan.

Metodologi Waterfall untuk pengembangan perangkat lunak dapat digunakan bagi proyek kecil dan sederhana. Namun, bagi proyek besar serta kompleks, pendekatan ini sangat berisiko, bahkan tidak masuk akal. Pendekatan ini sering lebih mahal dan selalu kurang efisien dibandingkan kerangka pengembangan serta penyampaian perangkat lunak Scrum.

Begitulah kehidupan sebelum kerangka kerja Scrum. Mengirim perangkat lunak bolak-balik antartim tanpa panduan profesional berketerampilan Scrum, membuat pekerjaan kami birokratis, kompleks, dan tidak produktif.

Akhirnya, selain produk yang dirugikan, semangat karyawan serta komitmen terhadap misi organisasi juga sepenuhnya terganggu.