Ada proyek yang cukup lurus dan relatif dapat diprediksi, di mana alat rasional perencanaan dan pengambilan keputusan dapat diterapkan. Proyek lain yang lebih kompleks atau tidak dapat diprediksi memerlukan pendekatan yang berbeda, yang lebih bergantung pada organisasi mandiri dan inovasi.
Mayoritas proyek pengembangan perangkat lunak dianggap kompleks dan tidak dapat diprediksi karena konvergensi tiga faktor: orang, persyaratan, dan teknologi. Berbagai pendekatan yang digunakan untuk menyampaikan dan mengelola proyek dapat lebih mudah dipahami dalam konteks model kontrol proses dan kompleksitas proyek.
Proses Terdefinisi — Pendekatan Plan-Driven Tradisional
Secara tradisional, setelah proyek dimulai, paket persyaratan dibuat dan kemudian “disetujui.” Manajer proyek menganggap bahwa persetujuan ini menghasilkan set persyaratan yang tetap dan sekarang perencanaan dapat dimulai. Manajer proyek memperkirakan berapa lama yang dibutuhkan untuk menyelesaikan persyaratan dan membuat rencana proyek. Rencana memprediksi bahwa proyek akan selesai pada tanggal tertentu, dan tanggal tersebut dikomunikasikan kembali kepada pelanggan.
Kelemahan dasar dalam pendekatan ini adalah bahwa rencana, yang mendorong segalanya, didasarkan pada asumsi bahwa persyaratan tetap dan tidak akan berubah. Pengalaman telah menunjukkan bahwa hal ini tidak pernah terjadi; persyaratan tidak pernah tetap — mereka selalu berubah. Ketika persyaratan berubah, rencana terpengaruh; dan sebagai hasilnya, tanggal penyelesaian perlu berubah juga. Sayangnya, dalam banyak kasus, itu mustahil, dan tim harus menyampaikan pada tanggal yang mereka komitmenkan. Inilah saat krisis besar terjadi dan proyek mulai keluar dari kendali.
Proses Empiris — Pendekatan Agile Berbasis Nilai
Pendekatan agile berbasis nilai didasarkan pada empirisme yang mengubah seluruh pemikiran. Ia menganggap dari awal bahwa apa pun persyaratan yang ada di awal tidak tetap dan akan berubah.
Pemikiran agile juga menganggap bahwa Anda harus menyampaikan pada tanggal tertentu. Pendekatan ini memperbaiki waktu dan sumber daya dan meninggalkan persyaratan yang tidak ditentukan. Untuk kami, pendekatan ini lebih mirip dengan realitas pembuatan perangkat lunak. Sekarang seluruh konsep nilai-driven menjadi sangat masuk akal. Ketika Anda memiliki jumlah waktu tertentu di mana Anda tidak yakin apakah Anda dapat menyampaikan semua persyaratan (karena mereka akan berubah dan waktu yang dibutuhkan untuk menyelesaikannya akan berubah), reaksi alami adalah memprioritaskan persyaratan dan menyelesaikan terlebih dahulu yang memberikan nilai terbesar bagi pelanggan.
Anda mungkin berpikir, “Bagaimana dengan persyaratan yang tidak diselesaikan pada tanggal penyerahan?” Itulah alasan Anda menggunakan pendekatan berbasis nilai. Anda mengakui fakta bahwa tidak semua persyaratan akan diselesaikan pada tanggal penyerahan. Pertanyaan penting yang harus diajukan adalah apakah Anda telah menyampaikan cukup fitur untuk mendukung sistem yang memberikan nilai bagi pelanggan.
Tingkat Kegagalan Proyek Perangkat Lunak
Laporan CHAOS 2015 baru-baru ini dirilis oleh Standish Group. Laporan CHAOS telah diterbitkan setiap tahun sejak 1994 dan merupakan tinjauan tentang keadaan industri pengembangan perangkat lunak. Tahun ini laporan mempelajari 50.000 proyek di seluruh dunia, mulai dari peningkatan kecil hingga implementasi rekayasa sistem besar. Tahun ini laporan mencakup definisi keberhasilan yang diperluas dengan mempertimbangkan beberapa faktor tambahan yang ditutupi dalam survei sebelumnya.
Hasilnya menunjukkan bahwa masih ada pekerjaan yang perlu dilakukan untuk mencapai hasil sukses dari proyek pengembangan perangkat lunak. Tabel ini merangkum hasil proyek selama lima tahun terakhir menggunakan definisi baru faktor keberhasilan (tepat waktu, sesuai anggaran dengan hasil yang memuaskan).
Dengan penerapan metode pengembangan agile selama beberapa tahun terakhir, memungkinkan untuk membandingkan hasil proyek antara proyek agile dan proyek waterfall tradisional. Di semua ukuran proyek, pendekatan agile menghasilkan lebih banyak proyek yang sukses dan kurang kegagalan langsung, seperti yang ditunjukkan dalam tabel ini
Apa Masalah Pendekatan Tradisional?
Pendekatan plan-driven tradisional tidak salah secara keseluruhan; hanya saja tidak cocok untuk industri perangkat lunak saat ini. Pendekatan plan-driven awalnya didasarkan pada konsep manajemen proyek tradisional, yang berasal dari industri konstruksi. Dalam industri konstruksi, pendekatan plan-driven cocok: denah, yang merupakan persyaratan, tetap dan mungkin tidak akan berubah saat bangunan sedang dibangun. Anda dapat memperkirakan berapa lama yang dibutuhkan untuk membangun tiang baja, menuangkan beton, dan seterusnya.
Alasan mengapa pendekatan plan-driven tradisional cocok untuk industri konstruksi tetapi tidak untuk industri perangkat lunak kembali ke perbedaan dalam cara kita mengontrol sistem empiris (seperti pengembangan perangkat lunak) dan cara kita mengontrol sistem terdefinisi (seperti konstruksi atau manufaktur). Tabel di bawah menunjukkan perbedaan antara karakteristik proses terdefinisi dan proses empiris.
Setelah membaca tabel, mudah untuk melihat bahwa pengembangan perangkat lunak tentu saja merupakan proses empiris, bukan proses terdefinisi. Masalahnya adalah kita telah mendekati pengembangan perangkat lunak selama bertahun-tahun sebagai proses terdefinisi — dan pendekatan tersebut tidak berfungsi.
Referensi
- Laporan CHAOS Standish Group 2015
- Menjadi Agile di Dunia yang Tidak Sempurna — oleh Greg Smith & Ahmed Sidky
Bacaan Scrum Lainnya
- Scrum dalam 3 Menit
- Apa saja 5 Nilai Scrum?
- Apa itu Evolusi Scrum?
- Manajemen Proyek Klasik vs Manajemen Proyek Agile
- Mengapa Scrum Sulit untuk Dikuasai?
- Apa itu Velocity dalam Scrum?
- Apa itu Agile? Apa itu Scrum?
This post is also available in Deutsch, English, Español, فارسی, Français, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.