Nama : Eka Puji Rahayu Lestari

NIM : 16650011
Kelas : MPL – B

The Agile Requirements Refinery: Applying SCRUM Principles

to Software Product Management

1. Pendahuluan
Manajemen produk dapat didefinisikan sebagai disiplin dan peran, yang mengatur suatu
produk (solusi atau layanan) dari awal hingga pengiriman pasar / pelanggan untuk
menghasilkan nilai sebesar mungkin bagi bisnis. Manajemen produk perangkat lunak (SPM)
adalah proses mengelola persyaratan, mendefinisikan rilis, dan mendefinisikan produk dalam
konteks di mana banyak pemangku kepentingan internal dan eksternal yang terlibat.
Karena kompleksitas produk perangkat lunak, dengan beragam kepentingan, daftar
panjang persyaratan, dan lingkungan yang berubah dengan cepat, maka Manajemen Perangkat
Lunak adalah tugas yang kompleks. Untuk mengatasi hal tersebut, dalam jurnal ini dijelaskan
cara manajemen produk perangkat lunak dapat dilakukan dalam konteks pengembangan
SCRUM yang meningkatkan kemampuan untuk menangani sejumlah besar persyaratan
kompleks dalam lingkungan agile.

2. Manajemen Produk Perangkat Lunak Agile

2.1. Metode pengembangan SCRUM
Metode yang digunakan dalam jurnal ini adalah Manajemen Produk Prangkat Lunak
agile berdasarkan SCRUM, yang meningkatkan kemampuan untuk menangani sejumlah besar
persyaratan kompleks dalam lingkungan agile. Inti dari SCRUM adalah gagasan bahwa banyak
proses selama pengembangan tidak dapat diprediksi. Karena itu, pengembangan perangkat
lunak ditangani dengan cara yang fleksibel. Backlog adalah instrumen penting dalam proses
SCRUM. Berikut peran dalam pengembangan SCRUM:
 Product Backlog (PB): PB adalah pusat dari metode SCRUM. PB berisi daftar prioritas
semua item yang relevan dengan produk tertentu. Daftar ini dapat terdiri dari bug,
peningkatan yang diminta pelanggan, fungsionalitas produk kompetitif, fungsionalitas
keunggulan kompetitif dan peningkatan teknologi. Setelah persyaratan sepenuhnya
ditentukan, dengan persetujuan pengembang, persyaratan tersebut dapat disalin dari PB
ke dalam Development Sprint Backlog.
 Pengembangan Sprint Backlog (DSB): Setiap tim yang berpartisipasi dalam proses
pengembangan perangkat lunak memelihara DSB sendiri. Semua persyaratan yang
ditugaskan ke tim pengembangan pada awal sprint dimasukkan pada DSB mereka.
Setiap persyaratan diuraikan menjadi beberapa tugas, yang kemudian ditugaskan untuk
anggota tim tertentu. Development Sprint Backlog diumpankan oleh backlog produk
dengan item yang telah ditentukan sepenuhnya.
2.2. Agile SPM
Pengembangan perangkat lunak oleh tim pengembang besar membutuhkan aliran yang
stabil dari persyaratan produk yang ditimbulkan. Tanpa aliran persyaratan yang stabil ini,
vendor perangkat lunak berisiko untuk menunda rilis perangkat lunak baru dan kode yang
buruk karena persyaratan yang tidak ditentukan dengan baik, semuanya mengakibatkan
pemborosan sumber daya dalam jumlah besar. Untuk menghindari masalah ini, diperlukan tim
manajer produk yang berfungsi, yang dapat, bekerja sama dengan tim pengembangan,
memasok persyaratan yang disetujui dan didefinisikan dengan baik. Gambar. 1 menunjukkan
aliran pengetahuan dalam proses SPM agile.

Gambar 1. Aliran pengetahuan proses SPM Agile

Gambar 2. Perbedaan antara pengembangan SCRUM dan Agile SPM.

2.3. Kilang persyaratan

Penataan alur kerja menjadi sprint dan scrum memungkinkan SPM tangkas menangani
keinginan pelanggan. Karena SCRUM sendiri tidak menyediakan pedoman untuk mengelola
sejumlah besar persyaratan granularity yang berbeda secara efektif. Dalam kilang persyaratan
agile, visi fungsi produk umumnya akan bergerak melalui tahap-tahap Visi, Tema, Konsep,
dan Definisi Persyaratan.

2.4. Deskripsi proses

Pada gambar, sisi yang dapat dikirim telah dihilangkan untuk fokus pada aspek proses.
Notasinya didasarkan pada diagram aktivitas UML. Kegiatan standar dan sub kegiatan
digambarkan dengan kotak putih, dan kegiatan terbuka ditunjukkan oleh kotak abu-abu. Panah
digunakan untuk menunjukkan aliran kontrol dari satu aktivitas ke aktivitas berikutnya. Bagian
atas diagram aktivitas, ditunjukkan oleh kotak abu-abu terang, akan berulang beberapa kali
dalam setiap sprint SPM, satu kali untuk setiap persyaratan. Gambar. 2 memvisualisasikan
proses tangkas SPM.
 Gambar 3. Visualisasi proses Agile SPM

2.5. SPM sprint

Sprint tidak boleh dilakukan secara serempak ke sprint pengembangan perangkat lunak.
Sebaliknya, mereka harus digeser kembali setengah dari durasi sprint pengembangan. Ini
memastikan bahwa DSB selalu mutakhir dan siap digunakan setelah sprint pengembangan
perangkat lunak dimulai, mengurangi waktu antara dimulainya suatu persyaratan dan
realisasinya dalam produk. Juga, informasi mengenai kemajuan implementasi dan keakuratan
ukuran dan deskripsi persyaratan dapat mengalir kembali dari tim pengembangan ke tim SPM.

3. Pendekatan penelitian studi kasus

Metode ini diuji dalam studi kasus dari lingkungan produksi di perusahaan perangkat
lunak produk di Belanda. Data telah dikumpulkan untuk menjawab pertanyaan penelitian
dengan cara wawancara dan studi dokumen.

Gambar 4. Sprint bergantian.

 Gambar 5. Contoh kutipan dari backlog sprint manajemen produk.

3.1. Perusahaan Studi Kasus: Planon

Perusahaan yang di teliti sebagagai studi kasus adalah Planon International, sebagai
salah satu perusahaan pertama yang menerapkan proses SPM agile berdasarkan prinsip-prinsip
agile pada umumnya (dan pengembangan SCRUM metode khusus). Planon adalah vendor
perangkat lunak internasional yang memproduksi perangkat lunak Manajemen Fasilitas dan
Real Estat untuk organisasi (Sistem Manajemen Tempat Kerja Terpadu).

3.2. Narasi Studi Kasus

Hingga 2004, pengembangan produk di Planon didasarkan pada metode Prince2,
setelah itu dilakukan pergantian ke SCRUM. Peralihan ke kilang persyaratan pada bulan 15
memiliki efek yang jelas pada jaminan simpanan. Yang paling menonjol adalah struktur
langsung dan kejelasan yang diciptakan oleh perubahan ini. Dengan membagi tugas yang
terkait dengan penjabaran persyaratan ke dalam daftar yang disebut definisi tema, definisi
konsep, dan penjabaran persyaratan, diperoleh gambaran umum yang lebih jelas tentang beban
kerja. Untuk setiap tugas, menjadi jelas secara instan pada fase elaborasi apa persyaratan saat
ini.

3.3. Ancaman validitas

Untuk memastikan kualitas pekerjaan, harus berusaha mematuhi empat kriteria
validitas untuk penelitian empiris. Ancaman validitas adalah ancaman konstruk, internal,
eksternal, dan keandalan.

4. Analisis splog backlog sprint

4.1. Standar Item backlog
Dari PMSB, beberapa item backlog berulang standar dapat diidentifikasi. Item standar,
sebagai lawan dari tugas-tugas insidentil, membentuk struktur dasar tugas berulang, sebagian
besar dengan jumlah jam yang sama dialokasikan setiap sprint. Tugas-tugas ini dapat
digunakan untuk membuat bentuk ritme dalam tim.
 Gambar 6. Item backlog standar pada PMSB.

4.2. Peran dan tugas

menganalisis tugas-tugas non-standar per sprint, sebesar rata-rata 85,7% dari total
waktu yang dialokasikan per bulan. Dalam melakukan ini, kami mengidentifikasi serangkaian
peran dalam tim Manajemen Produk yang gesit, masing-masing berfokus pada serangkaian
tugas tertentu. Meskipun tidak ada peran khusus yang ditemukan, yaitu orang yang hanya
menangani satu atau dua jenis tugas, masing-masing peran memiliki kombinasi karakteristik
dari tugas yang ditugaskan padanya.

Gambar 7. Distribusi tugas (non-standar) ke tim manajemen produk.

Gambar 8. Distribusi orang dalam tugas manajemen produk.

4.3. Ilustrasi: perencanaan pemeliharaan
Untuk mengilustrasikan cara kerja tema, konsep, dan persyaratan khusus dalam PMSB,
tema perencanaan pemeliharaan diikuti sepanjang pengembangannya. Tema ini diperkenalkan
pada 2008, ketika perusahaan kasing memilih untuk mencapai redefinisi dari solusi manajemen
pemeliharaan yang ada. Tema ini menjelaskan fungsionalitas yang terkait dengan pemeliharaan
fasilitas, dan pada awalnya diperkenalkan pada PB pada bulan ke 14 analisis. Seluruh siklus
hidup SPM tema berlangsung 7 bulan.

4.4. Ilustrasi: Planon lite

Seperti yang ditunjukkan pada bagian sebelumnya, pengenalan tema, konsep dan
persyaratan pada PB tidak berarti bahwa semua ide yang dibawa dalam perusahaan mengikuti
jalur yang sama dan lengkap melalui semua fase. Meskipun disarankan untuk melakukannya
dengan tema besar dan rumit, bagian sebelumnya telah menunjukkan bahwa mungkin dan
mungkin lebih efisien untuk mengambil “jalan pintas” dalam pembuatannya

5. Pelajaran yang dipetik

Selama upayanya menerapkan metode SPM agile, perusahaan studi kasus telah
memperoleh pengalaman berharga di bidang ini. Pengalaman-pengalaman ini sebagai
serangkaian pelajaran yang harus diperhitungkan ketika menerapkan SPM tangkas bersama
metode pengembangan perangkat lunak tangkas, yaitu : Siklus sprint alternatif untuk SPM dan
pengembangan, Persyaratan kompleks perlu detail terstruktur, Rapat SCRUM harian sangat
penting, Administrasi backlog membutuhkan disiplin, dan Kolaborasi awal mempromosikan
penggunaan kembali dan integrasi.

6. Kesimpulan
Hasil dari penelitian pada jurnal ini berdasarkan struktur terbukti dari metode
pengembangan agile diadopsi dengan baik di perusahaan perangkat lunak. Metode
pengembangan SCRUM telah menunjukkan bahwa proses pengembangan agile terdapat
lingkungan yang dinamis dan yang terus beradaptasi, baik secara terkendali, dan juga efektif.
Peralihan ke persyaratan agile memiliki efek yang jelas adalah struktur langsung dan kejelasan
yang diciptakan. Dengan membagi tugas yang terkait dengan penjabaran persyaratan ke dalam
daftar yang disebut definisi tema, definisi konsep, dan penjabaran persyaratan, sehingga
diperoleh gambaran umum yang lebih jelas tentang beban kerja dan juga untuk setiap tugas
menjadi jelas secara instan.