{"id":247,"date":"2022-01-25T10:25:00","date_gmt":"2022-01-25T10:25:00","guid":{"rendered":"https:\/\/www.cybermedian.com\/id\/?p=247"},"modified":"2025-02-19T17:41:13","modified_gmt":"2025-02-19T09:41:13","slug":"why-scrum-defined-process-vs-empirical-process","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/id\/why-scrum-defined-process-vs-empirical-process\/","title":{"rendered":"Mengapa Scrum: Proses Terdefinisi vs Proses Empiris"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

Jenis Kontrol Proses<\/figcaption><\/figure>\n

Proses Terdefinisi\u200a\u2014\u200aPendekatan Plan-Driven Tradisional<\/strong><\/p>\n

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.<\/p>\n

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\u200a\u2014\u200amereka 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.<\/p>\n

Proses Empiris\u200a\u2014\u200aPendekatan Agile Berbasis Nilai<\/strong><\/p>\n

Pendekatan agile berbasis nilai didasarkan pada\u00a0empirisme<\/strong>\u00a0yang mengubah seluruh pemikiran. Ia menganggap dari awal bahwa apa pun persyaratan yang ada di awal tidak tetap dan akan berubah.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Tingkat Kegagalan Proyek Perangkat Lunak<\/strong><\/p>\n

Laporan\u00a0CHAOS 2015<\/a>\u00a0baru-baru ini dirilis oleh\u00a0Standish Group<\/a>. 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.<\/p>\n

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).<\/p>\n

Tingkat Kegagalan Proyek Perangkat Lunak<\/figcaption><\/figure>\n

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<\/p>\n

<\/figure>\n

Apa Masalah Pendekatan Tradisional?<\/strong><\/p>\n

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.<\/p>\n

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.<\/p>\n

Proses Terdefinisi vs Proses Empiris<\/figcaption><\/figure>\n

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\u200a\u2014\u200adan pendekatan tersebut tidak berfungsi.<\/p>\n

Referensi<\/h3>\n
    \n
  1. Laporan CHAOS Standish Group 2015<\/a><\/li>\n
  2. Menjadi Agile di Dunia yang Tidak Sempurna\u200a\u2014\u200aoleh Greg Smith & Ahmed Sidky<\/li>\n<\/ol>\n

    Bacaan Scrum Lainnya<\/h3>\n