ISSN : 2442-8337
Analisis Tingkat Kematangan Manajemen Proyek
Pengembangan Perangkat Lunak Menggunakan Scrum
Maturity Model: Studi Kasus PT. XYZ
Ahlijati NuraminahProgram Studi Sistem Informasi, STIMIK ESQ
Jl. TB Simatupang Kavling 1, Cilandak, Jakarta Selatan – 12560 Email: ahlijati.nuraminah@esqbs.ac.id
Abstract: Scrum is an agile framework designed for simplicity to produce software incrementally and iteratively involving collaboration between a team of developers and consumers. PT. XYZ has implemented Scrum since 2012, but there are problems in the implementation that projects don't achieve the time target of software development timeline. This research examines the maturity level of project management of software development that implement Scrum frameworks with quantitative research methodology using Scrum Maturity Model. Data were collected through questionnaires to the Scrum Master on software development projects that have implemented Scrum work. The conclusion from this research is PT. XYZ reached maturity level 2 Scrum Maturity Model. Recommendations for improvement are given to improve processes to achieve maturity level 3, 4, and 5.
Keywords: Maturity Level, Project Management, Scrum, Scrum Maturity Model.
Abstrak: Scrum adalah kerangka tangkas dirancang untuk kesederhanaan untuk menghasilkan
perangkat lunak secara bertahap dan iteratif yang melibatkan kolaborasi antara tim pengembang dan konsumen. PT. XYZ telah menerapkan Scrum sejak 2012, tetapi ada masalah dalam pelaksanaan, dimana proyek-proyek tidak mencapai target waktu dari timeline pengembangan perangkat lunak. Penelitian ini menguji tingkat kematangan manajemen proyek pengembangan perangkat lunak yang menerapkan kerangka kerja Scrum dengan metodologi penelitian kuantitatif dengan menggunakan Scrum Maturity Model. Data dikumpulkan melalui kuesioner kepada Scrum Master di proyek-proyek pengembangan perangkat lunak yang telah menerapkan Scrum kerja. Kesimpulan dari penelitian ini adalah PT. XYZ mencapai tingkat kematangan 2 dari Scrum Maturity Model. Rekomendasi perbaikan diberikan untuk meningkatkan proses untuk mencapai kematangan level 3, 4, dan 5.
Kata kunci: Maturity Level, Project Management, Scrum, Scrum Maturity Model.
1. PENDAHULUAN
Di era perkembangan teknologi informasi saat ini, peranan perangkat lunak semakin penting sehingga dikatakan sebagai business enabler bagi organisasi [1]. Dalam mengembangkan perangkat lunak dikenal beberapa metodologi pengembangan, diantaranya Waterfall, Spiral, dan Agile. Metodologi agile adalah metodologi
yang berbasis kolaborasi antara semua pihak yang berkepentingan dalam proses
pengembangan dengan menerapkan
kesederhanaan dalam mengadaptasi
perubahan kebutuhan produk perangkat lunak dan menerapkan strategi bertahap dalam merilis produk.
Salah satu implementasi agile methodology
adalah Scrum. Scrum adalah sebuah kerangka kerja bersifat agile yang didesain secara sederhana dimana orang-orang yang terlibat dalam pengembangan produk perangkat lunak akan bekerja bersama secara kolaboratif untuk menyelesaikan masalah-masalah kompleks yang terjadi sehingga bisa mengembangkan produk dengan nilai setinggi mungkin secara produktif dan kreatif [2]. Prinsip kerja Scrum adalah bekerja secara iteratif dan bertahap hingga mencapai waktu yang telah ditentukan sehingga produk perangkat lunak yang dikembangkan dapat memenuhi kebutuhan yang diinginkan oleh konsumen.
PT. XYZ adalah sebuah perusahaan penyedia layanan Teknologi Informasi dengan fokus utama pada aplikasi bisnis, solusi mobile dan infrastruktur jaringan. Sejak tahun 2012 PT. XYZ mulai menerapkan Scrum pada proyek-proyek pengembangan perangkat lunak. Hasil evaluasi tahunan pada akhir 2013 diperoleh data adanya ketidakefektifan penerapan kerangka kerja Scrum dilihat dari rata-rata sisa pekerjaan pada Sprint yang selalu tidak tuntas.
Tabel 1 menampilkan data jumlah pelaksanaan Daily Scrum, Sprint Planning Meeting, Sprint Review, dan Sprint Retrospective pada proyek pengembangan perangkat lunak berbasis Scrum yang dikumpulkan pada kurun waktu 1– 31 Januari 2013 yang dilakukan pada tiga proyek di PT. XYZ yaitu Proyek A, B, dan C.
Tabel 1. Data Scrum Events pada PT. XYZ Pada Tabel 2 disajikan data total jumlah Sprint Backlog yang direncakan untuk dikerjakan, jumlah Sprint Backlog yang selesai dikerjakan, dan sisa Sprint Backlog yang tidak selesai dikerjakan.
Tabel 2. Data Capaian Sprint pada PT. XYZ Jumlah target backlog Jumlah backlog yang selesai Sisa pekerja-an (%) Capaian Sprint Proyek A 196 122 74 62.24% Proyek B 154 121 33 78.57% Proyek C 401 243 158 60.59
Rata-rata capaian pada Sprint masih di bawah 70% sementara harapan pencapaian Sprint ditargetkan di atas 80%. Untuk mencari sumber masalah dari rendahnya pencapaian Sprint dilakukan analisis dengan menggunakan diagram Ishikawa yang disajikan pada Gambar 1.
Gambar 1. Diagram Ishikawa Analisis Akar Masalah
Diagram Ishikawa pada Gambar 1 membagi akar masalah menjadi empat, yaitu manusia, metode, material, dan proses. Akar-akar permasalahan yang mungkin menjadi
Sprint Daily Scrum Sprint Plann-ing Sprin t Revie w Sprint Retrospe ctive Proyek A 17 2 17 17 4 Proyek B 9 5 9 9 9 Proyek C 13 2 13 13 13 Sprint Daily Scrum Sprint Plann-ing Sprin t Revie w Sprint Retrospe ctive Proyek A 17 2 17 17 4 Proyek B 9 5 9 9 9 Proyek C 13 2 13 13 13
penyebab diidentifikasi dari keempat domain. Dari akar-akar masalah yang berhasil diidentifikasi seperti pada Gambar 1 maka penelitian difokuskan untuk mengetahui tingkat kematangan manajemen proyek pengembangan perangkat lunak menggunakan Scrum. Atas dasar hal ini, penulis menetapkan pertanyaan penelitian berikut ini: Berapakah
tingkat kematangan manajemen proyek pengembangan perangkat lunak yang menerapkan kerangka kerja Scrum di PT. XYZ dan apa saja rekomendasi yang diperlukan untuk memperbaiki tingkat kematangan?
Tujuan penelitian ini adalah untuk melakukan analisis tingkat kematangan manajemen proyek pengembangan perangkat lunak yang menerapkan Scrum pada PT. XYZ dan memberikan rekomendasi perbaikan untuk memperbaiki tingkat kematangan pada proyek pengembangan perangkat lunak yang menerapkan kerangka kerja Scrum pada PT. XYZ.
Sementara itu manfaat yang diharapkan dari penelitian ini adalah sebagai bahan evaluasi bagi PT. XYZ mengenai tingkat kematangan manajemen proyek pengembangan perangkat lunak yang menerapkan kerangka kerja Scrum dan sebagai acuan perbaikan bagi pelaksanaan proyek-proyek TI berikutnya yang akan dikembangkan oleh PT. XYZ, serta sebagai kajian akademik terhadap Agile Project Management khususnya pada kerangka kerja Scrum. Ruang lingkup penelitian ditetapkan pada proyek TI yang dikerjakan oleh PT. XYZ dibatasi pada proyek yang telah menerapkan metode Scrum pada kurun waktu tahun 2012-2014.
2. TINJAUAN TEORITIS
Scrum adalah sebagai sebuah metodologi agile untuk mengelola proyek melalui metode incremental dan iterative [3]. Scrum Framework terdiri atas tim Scrum beserta peran-perannya, pertemuan-pertemuan, artefak-artefak, dan sekumpulan aturan main. Setiap komponen pada kerangka kerja Scrum memiliki tujuan tertentu dan sangat penting bagi keberhasilan dan penggunaan Scrum.
Aturan-aturan pada Scrum mengatur hubungan dan interaksi diantara events, roles, dan artifact [4].
Roles dalam Scrum adalah peran-peran yang dimainkan dalam proses pengembangan perangkat lunak. Tiga peran utama pada Scrum yaitu:
1) Product Owner, pihak yang
bertanggung-jawab terhadap suksesnya
pengembangan produk, biasanya adalah representasi dari konsumen.
2) Scrum Master, fasilitator untuk melayani tim, tidak bertindak sebagai manajer proyek
3) Tim Pengembang, sekelompok orang
yang bertanggung jawab untuk menghasilkan produk perangkat lunak. Pada proyek pengembangan menggunakan Scrum, peran manajer proyek berubah dari fungsi memimpin dan mengontrol perjalanan proyek dalam mencapai tujuan proyek, menjadi memfasilitasi kolaborasi tim dan menyingkirkan penghalang bagi kesuksesan tim. Karena tim pada Scrum bersifat dapat mengelola diri sendiri, maka proses pengambilan keputusan terjadi di tingkat tim pengembang. Oleh sebab itu fungsi pengendalian proyek bergeser dari manajer proyek ke tim pengembang. Scrum Master bertugas memastikan bahwa setiap anggota tim berkolaborasi secara efektif dengan Produt Owner [2].
Scrum juga mengidentifikasikan empat objek artefak yang dioperasikan oleh tim Scrum selama siklus pengembangan, yaitu:
1) Product Backlog: daftar fitur prioritas untuk produk akhir perangkat lunak. 2) Sprint Backlog: daftar pekerjaan yang
akan dilaksanakan pada sebuah Sprint
(iterasi pengembangan) yaitu
menerjemahkan bagian-bagian dari Product Backlog ke dalam produk jadi. 3) Release Burndown Charts: Grafik yang
menggambarkan kemajuan dari
pelaksanaan proyek dari waktu ke waktu yang memungkinkan tim Scrum untuk
memiliki visi global terhadap proyek pengembangan.
4) Sprint Burndown Charts: Grafik yang menggambarkan progres Sprint dari waktu ke waktu yang berguna bagi tim pengembang untuk melihat kemajuan Sprint.
Interaksi antara peran-peran menggunakan objek artefak di atas menggunakan beberapa jenis pertemuan pada Scrum, yaitu:
1) Sprint, kerangka waktu iterasi dengan durasi maksimal satu bulan untuk mengembangkan produk.
2) Sprint Planning Meeting, rapat perencanaan Sprint yang dilakukan di awal untuk memilih fitur-fitur apa saja yang akan dikerjakan.
3) Sprint Review, pertemuan evaluasi pelaksanaan Sprint yang dilakukan di akhir Sprint. Pada pertemuan ini produk perangkat lunak akan didemonstrasikan kepada Product Owner.
4) Daily Scrum, pertemuan harian bagi tim pengembang.
5) Sprint Retrospective, pertemuan yang dilakukan setelah Sprint Review dan sebelum Sprint Planning berikutnya untuk kilas balik Sprint yang bertujuan mencari hal-hal yang dapat ditingkatkan pada Sprint berikutnya.
Siklus iterasi Scrum ditampilkan pada Gambar 2.
Gambar 2. Scrum Framework Sumber: Schwaber & Beedle [3]
Scrum memperkenalkan konsep Sprint yang merepresentasikan sebuah iterasi dari siklus pengembangan berbasis waktu dengan durasi selama dua minggu sampai satu bulan. Inti dari Scrum terdiri dari satu set sprint-sprint yang menghasilkan perangkat lunak jadi pada setiap akhir Sprint. Sprint adalah kerangka waktu iterasi dengan durasi maksimal satu bulan untuk menghasilkan produk dengan definisi “Done” atau “Selesai”, dapat digunakan, dan berpotensi untuk dirilis.
Green [5] memaparkan metode yang digunakan oleh Adobe Systems untuk mengukur dampak penerapan Scrum terhadap proses pengembangan perangkat lunak. Ada tiga macam area pengukuran yang diprediksikan oleh Adobe System sebagai faktor yang dapat memberikan indikator yang baik dari pengaruh Scrum terhadap proyek yaitu: 1) Rating subyektif dari anggota tim Scrum tentang bagaimana proses Scrum telah mempengaruhi proyek dan bagaimana cara tim melakukan Scrum. 2) Data tentang defect produk, seperti defect counts, deferral rates, cycle-to-cycle curve information, dan 3) Net Promoter Scores, yaitu skor yang mengukur tingkat kepuasan customer sebelum dan sesudah adopsi Scrum. Dari ketiga area pengukuran, dapat disimpulkan bahwa adopsi Scrum dapat dibuktikan telah memberikan dampak yang positif dalam proyek pengembangan perangkat lunak.
V. Mahnic, N. Zabkar [6] memberikan gambaran tentang sebuah perangkat pengukuran yang memberikan wawasan berkelanjutan bagi pihak manajemen TI tentang proses pengembangan perangkat lunak berbasis Scrum. Data yang dijadikan basis pengukuran adalah velocity proyek, Release Burndown Chart, Sprint Burndown Chart dan Earned Value Management menggunakan Schedule Performance Index (SPI) dan Cost Performance Index (SPI). Kesimpulan yang diperoleh dari penelitian ini adalah bahwa
setiap pengukuran yang diajukan
mengindikasikan aspek yang penting dalam mengukur kemajuan proyek pengembangan perangkat lunak berbasis Scrum. Kemajuan
proyek diperlukan oleh pihak manajemen untuk mengambil keputusan terkait proyek. Lee (2012) menggali faktor-faktor apa saja yang mempengaruhi kesuksesan dalam penerapan metodologi Scrum melalui penelitian kualitatif. Hal yang melatarbelakangi penelitian ini adalah bahwa tidak mudah untuk melakukan generalisasi teori tentang kemudahan dan kepraktisan dalam penerapan metodologi Scrum. Kesimpulan dari penelitian ini adalah kombinasi faktor-faktor yang mempengaruhi kesuksesan penerapan Scrum methodology yaitu kinerja pengembangan software, karakteristik tim pengembang, kompetensi tim, ketangkasan pengembangan software. Bustard, Wilkie, & Greer [7] melakukan penelitian untuk memahami kemajuan tingkat kematangan pengembangan perangkat lunak yang menggunakan metode agile melalui survei pada industri perangkat lunak. Survei ini memberikan dua wawasan baru dalam penerapan metodologi agile yaitu 1) Metodologi agile menggantikan Waterfall sebagai pendekatan standar dalam pengembangan perangkat lunak dan 2) penerapan metode agile telah dapat diterima dengan baik oleh perusahaan pengembang perangkat lunak namun definisi metode agile
yang lebih jelas lagi masih dibutuhkan untuk peningkatan proses dan manfaat.
Untuk memecahkan masalah pada penelitian ini, dilakukan kajian terhadap metodologi-metodologi yang relevan yaitu Project Management Maturity Model (PMMM), Portfolio, Programme and Project Management Maturity Model (P3M3), Capability Maturity Model Integration (CMMI), Agile Maturity Model (AMM), dan Scrum Maturity Model.
Project Management Maturity Model (PMMM) adalah sebuah perangkat formal yang dikembangkan oleh PM Solutions [8] dan digunakan untuk mengukur kematangan manajemen proyek organisasi. Setelah tingkat kematangan manajemen proyek diidentifikasi, PMMM menyediakan roadmap dan
langkah-langkah yang dibutuhkan untuk memperbaiki tingkat kematangan. PMMM mengukur tingkat kematangam melalui sepuluh knowledge area di dalam Project Management Body of Knowledge [9].
Portfolio, Programme & Project Management Maturity Model (P3M3) adalah versi pengembangan dari Project Management Maturity Model [10]. P3M3 bertujuan untuk menyediakan penilaian dan pengukuran skor terhadap portfolio, programme dan aktivitas terkait proyek di dalam proses area yang memberikan kontribusi untuk mencapai kesuksesan proyek. PMMM dan P3M3 sesuai digunakan untuk pengukuran tingkat kematangan manajemen proyek yang menggunakan knowledge area dari PMBOK Project Management Body of Knowledge [9]. Untuk penelitian ini PMMM kurang relevan karena proyek-proyek yang diteliti tidak menggunakan PMBOK.
Capability Maturity Model Integration (CMMI) diperkenalkan pada tahun 2002 oleh Software Engineering Institute yang mendeskripsikan prinsip-prinsip dan praktik-praktik yang mendasari kematangan proses pengembangan perangkat lunak. Tingkat kematangan (maturity level) ditandai dengan satu rangkaian proses area yang telah ditetapkan. Tingkat kematangan dievaluasi dari specific goal dan generic goal yang juga berlaku bagi berbagai area lainnya [11]. Ada lima tingkat kematangan pada staged representation yaitu Initial, Managed, Defined, Quantitatively Managed dan Optimizing. Namun model CMMI belum cukup komprehensif untuk menilai tingkat kematangan manajemen proyek Scrum. Agile Maturity Model (AMM) dikemukakan oleh Patel & Ramachandran [12] yang
menghubungkan praktik-praktik
pengembangan perangkat lunak dengan metode agile dengan konsep tingkat kematangan pada CMMI. AMM dirancang berdasarkan agile values, agile principles, dan agile practices. Ada lima tingkat kematangan pada AMM yaitu Initial, Explored, Defined,
Improved, dan Mature. AMM cukup relevan untuk menilai kematangan proyek yang menerapkan metode agile. Namun, untuk menilai tingkat kematangan proyek yang menerapkan kerangka kerja Scrum AMM dinilai masih terlalu umum.
Kerangka Agile Maturity Model yang dikembangkan oleh Patel & Ramachandran [12] kemudian dilanjutkan oleh Yin, Figueiredo, & Miguel [13] yang memperkenalkan konsep Scrum Maturity Model untuk menilai tingkat kematangan Scrum. Scrum Maturity Model juga terinspirasi dari process area di dalam CMMI dan dibuat pemetaan antara proces area dengan praktik-praktik Scrum. SMM memiliki lima tingkat kematangan yaitu Initial. Managed, Defined, Quantively Managed dan Optimizing. Scrum Maturity Model sudah cukup relevan untuk menilai kematangan proyek Scrum sehingga dipilih sebagai rujukan utama dalam menilai tingkat kematangan manajemen proyek yang menerapkan kerangka kerja Scrum.
Dari berbagai topik yang telah dibahas, dirancang kerangka teoritis penelitian seperti diagram pemikiran sistem yang ditunjukkan pada Gambar 3.
Gambar 3. Kerangka Teoritis
3. METODE PENELITIAN
Penelitian ini adalah penelitian kuantitatif dengan langkah penelitian yang dirancang sesuai dengan diagram yang disajikan pada
Gambar 4.
Gambar 4. Kerangka Penelitian Gambar 4 menggambarkan alur desain penelitian. Berikut penjabaran tahapan penelitian yang dilakukan:
1. Identifikasi Permasalahan. Bertujuan untuk mendefiniskan latar belakang permasalahan yang mendasari penelitian yang dilakukan dengan metode studi dokumen menggunakan masukan dari dokumen jadwal pengembangan proyek yang menerapkan Scrum di PT. XYZ. Keluaran dari tahapan ini adalah permasalahan utama penelitian.
2. Pendalaman Masalah. Pemetaan akar masalah dengan menggunakan metode analisis Fishbone. Keluaran dari proses ini berupa pertanyaan penelitian.
3. Studi Literatur. Pelaksanaan tinjauan pustaka dilakukan untuk mencari teori, penelitian, serta metodologi yang relevan dengan pertanyaan penelitian yang telah didefinisikan pada tahapan sebelumnya yang besumber dari buku teks, makalah dan jurnal internasional sehingga menghasilkan keluaran berupa kerangka teoritis yang mendasari penelitian.
4. Penyusunan Kuesioner. Pembuatan instrumen penelitian berupa proses penyusunan kuesioner yang diadaptasi dari pertanyaan pada Scrum Maturity Model. Keluaran dari proses ini berupa
draft daftar pertanyaan.
5. Uji Keterbacaan Kuesioner. Sebelum disusun dalam bentuk final, daftar pertanyaan awal harus diuji coba kepada calon responden yang dinilai mempunyai karakteristik yang relatif sama dengan responden sesungguhnya. Kuesioner akan diperbaiki berdasarkan input balik dari calon responden. Jika daftar final kuesioner sudah dianggap layak untuk disebarkan, maka dilanjutkan ke tahap berikutnya yaitu penyebaran kuesioner. 6. Penyebaran Kuesioner. Pengumpulan
data dilakukan dengan menyebarkan kuesioner yang telah tersusun pada tahap sebelumnya melalui surat elektronik kepada responden. Keluaran dari proses ini adalah kuesioner yang telah terisi.
7. Analisis Kuesioner. Setelah kuesioner terkumpul kembali kemudian dilakukan
analisis terhadap kuesioner
menggunakan metode statistik. Keluaran dari proses ini adalah tingkat kematangan proyek pengembangan perangkat lunak yang menerapkan Scrum.
8. Identifikasi Sasaran Perbaikan. Dari tingkat kematangan yang diperoleh kemudian dilakukan identifikasi sasaran perbaikan untuk mencapai tingkat kematangan yang lebih tinggi. Tahapan ini dilakukan dengan menggunakan
metode analisis terhadap KPA (Key Process Area). Keluaran dari tahapan ini adalah rekomendasi sasaran perbaikan. 9. Penyusunan Kesimpulan dan Saran.
Langkah terakhir adalah pembuatan kesimpulan dan saran berdasarkan hasil dan analisis dari tahapan sebelumnya. Ada dua jenis yaitu data primer dan data sekunder. Data primer didapatkan dari observasi, penyebaran kuesioner dan wawancara terhadap obyek penelitian. Data sekunder didapatkan dari studi dokumentasi proyek pengembangan perangkat lunak pada PT. XYZ.
Berdasarkan pertimbangan jenis data yang dibutuhkan maka subyek penelitian yang ditetapkan adalah individu yang berperan Scrum Master pada proyek pengembangan perangkat lunak yang sudah menerapkan Scrum. Ada empat proyek akan diteliti yaitu Proyek TE, Proyek NV, Proyek HMS, dan Proyek TR. Deskripsi dari keempat proyek dapat dilihat pada Tabel 3.
Tabel 3. Deskripsi Proyek
No. Nama
Proyek Keterangan
1. TE
Deskripsi Proyek pengembangan aplikasi sistem back office untuk perusahaan
travel agent.
Tipe Proyek Proyek
Client PT. AB
Platform Teknologi Desktop Application (Microsoft WPF, SQL Server)
Durasi Proyek Juni 2012 – Desember 2012 Tim Pengembang Delapan orang.
Scrum Master Satu orang. Berlatar belakang programmer. 2. NV
Deskripsi Proyek pengembangan aplikasi back office dan sistem akuntansi untuk sasaran perusahaan kecil dan menengah.
No. Nama
Proyek Keterangan
Tipe Proyek Produk internal PT. XYZ
Client Internal perusahaan
Platform Teknologi Cloud Application (Microsoft ASP.NET, SQL Server, Windows Azure)
Durasi Proyek Maret 2013 – Februari 2014 Tim Pengembang Tujuh orang
Scrum Master Satu orang. Berlatar belakang programmer. Pengalaman sebagai Scrum Master satu kali pada proyek TE.
3. HMS Deskripsi Proyek pengembangan aplikasi pengelolaan hotel. Tipe Proyek Proyek
Client PT. AB
Platform Teknologi Cloud Application (Microsoft ASP.NET, SQL Server, Windows Azure)
Durasi Proyek Mei 2013 – Februari 2014 Jumlah Anggota Tim
Pengembang
Lima belas orang yang dibagi-bagi menjadi tiga tim kecil terdiri atas masing-masing lima orang
Scrum Master Dua orang. Satu orang berlatar belakang programmer dan satu orang
berlatar belakang system analyst. 4. TR
Deskripsi Proyek pengembangan portal dan aplikasi document management
system
Tipe Proyek Proyek
Client PT. TR
Platform Teknologi Web Application (Microsoft Sharepoint)
Durasi Proyek Agustus 2014 – Desember 2014 Jumlah Anggota Tim
Pengembang Empat orang
Scrum Master
Dua orang. Satu orang berlatar belakang programmer dan satu orang berlatar belakang system analyst. Pengalaman masing-masing satu kali sebagai Scrum Master.
Untuk melakukan analisis data digunakan pendekatan statistik yang diadaptasi dari untuk
keperluan analisis data dilakukan penilaian kuesioner menggunakan pendekatan metode Agile Maturity Model (AMM) [12].
Respon pada kuesioner adalah “Ya” (poin pertanyaan dijalankan/ada seluruhnya),
“Tidak” (poin pertanyaan tidak
dijalankan/tidak ada seluruhnya), “Sebagian”
(poin pertanyaan hanya dijalankan sebagian), dan “Tidak Berlaku (N/A)” (poin pertanyaan tidak dapat diimplementasikan).
Presentase untuk masing-masing KPA dihitung menggunakan persamaan:
Dimana Yn = Jumlah jawaban “Ya”
Pn = Jumlah jawaban “Sebagian”
Tn = Jumlah total pertanyaan
NAn = Jumlah jawaban “Tidak Berlaku
(N/A)”
∑(𝑌𝑛) + ½ ∑(𝑃𝑛)
Dari nilai persentase KPA Rating yang diperoleh, maka dilakukan penafsiran penilaian ke dalam kategori berikut :
Fully Achieved (Tercapai Sepenuhnya): 86% sampai 100%
Largerly Achieved (Sebagian Besar Dicapai): 51% sampai 85%
Partially Achieved (Sebagian Dicapai): 16% sampai 50%
Not Achieved (Tidak Tercapai): 0% sampai 15%
Tingkat kematangan proses pengembangan perangkat lunak yang dinilai akan berada pada level dimana seluruh KPA-nya tercapai sepenuhnya (Nilai KPA Rating ≥ 86% untuk setiap KPA).
Setelah dilakukan penilaian pada masing-masing tingkat kematangan, selanjutnya dilakukan identifikasi area perbaikan Sasaran perbaikan diidentifikasi melalui jawaban dari kuesioner yang bernilai “Sebagian”, “Tidak”, atau “Tidak Berlaku (N/A)”. Dari jawaban-jawaban tersebut dipetakan praktik-praktik yang seharusnya dilakukan.
4. HASIL PENELITIAN
Penyusunan kuesioner dilakukan dengan mengacu kepada Scrum Maturity Model [13]. Rincian jumlah pertanyaan untuk setiap tingkat kematangan pada masing-masing sasaran umum untuk Scrum Maturity Model dapat dilihat pada
Tabel 4.
Tabel 4. Rincian Jumlah Pertanyaan pada Scrum Maturity Model
Tingkat Sasaran Umum Sasaran Khusus Jumlah
Pertanyaan 2 2.1 Basic Scrum Management 2.1.1 Ada peran-peran Scrum 3
2.1.2 Ada artefak-artefak Scrum 9 2.1.3 Ada pertemuan-pertemuan Scrum 5 2.1.4 Sprint dilaksanakan dengan benar 2 2.2 Software Requirements
Engineering
2.2.1 Definisi Product Owner jelas 4 2.2.2 Manajemen Product Backlog 6 2.2.3 Sprint Planning Meeting yang sukses 6 3 3.1 Customer Relationship
Management
3.1.1 Ada definisi “Selesai” 2 3.1.2 Product Owner tersedia 1 3.1.3 Sprint Review Meeting yang sukses 2 3.2 Iteration Management 3.2.1 Pengelolaan Sprint Backlog 7
3.2.2 Iterasi direncanakan 4
3.2.3 Daily Scrum yang sukses 6
3.2.4 Velocity yang terukur 5
4 4.1 Standardized Project
Management
4.1.1 Manajemen proyek yang distandarisasi 1 5 5.1 Performance Management 5.1.1 Sprint Retrospective yang sukses 3
5.1.2 Indikator positif 3
4.1 Penilaian Tingkat Kematangan 2 Sasaran Umum Basic Scrum Management
Sasaran umum Basic Scrum Management memiliki empat sasaran khusus yaitu: 1) Ada
peran-peran Scrum; 2) Ada artefak-artefak Scrum; 3) Ada pertemuan-pertemuan Scrum; dan 4) Sprint dilaksanakan dengan benar. Berdasarkan hasil penilaian tingkat kematangan untuk setiap sasaran khusus yang ada di dalam sasaran umum Basic Scrum Management diperoleh hasil rekapitulasi KPA
Rating dengan nilai rata-rata sebesar 90.09% sehingga dapat dikatakan sasaran umum ini Fully Achieved (Tercapai Sepenuhnya). Rekapitulasi penilaian KPA Rating untuk sasaran umum Basic Scrum Management dapat dilihat pada
Tabel 5.
Tabel 5. Rekapitulasi KPA Rating Sasaran Umum Basic Scrum Management
No. Sasaran Khusus Proyek Rata-rata
TE NV HMS TR
1 Ada peran-peran Scrum 100.00% 100.00% 100.00% 100.00% 100.00% 2 Ada artefak-artefak Scrum 71.43% 80.00% 100.00% 80.00% 82.86% 3 Ada pertemuan-pertemuan Scrum 90.00% 80.00% 100.00% 70.00% 85.00% 4 Sprint dilaksanakan dengan benar 100.00% 100.00% 100.00% 70.00% 92.50%
Rata-rata 90.36% 90.00% 100.00% 80.00% 90.09%
Interpretasi Fully Achieved (Tercapai Sepenuhnya)
4.2 Penilaian Tingkat Kematangan 2 Sasaran Umum Software Requirements Engineering
Pada dasarnya proses penilaian tingkat kematangan untuk sasaran umum Software Requirement Engineering sama dengan proses pada subbab sebelumnya. Sasaran umum Software Requirement Engineering memiliki tiga sasaran khusus yaitu: 1) Definisi Product
Owner jelas; 2) Manajemen Product Backlog; dan 3) Sprint Planning Meeting yang sukses. Hasil rekapitulasi menunjukkan bahwa nilai rata-rata KPA Rating untuk sasaran umum Software Requirement Engineering adalah sebesar 85.07% dengan interpretasi Fully Achieved (Tercapai Sepenuhnya). Rata-rata KPA Rating untuk setiap proyek dapat dilihat pada
Tabel 6.
Tabel 6. Rekapitulasi KPA Rating Sasaran Umum Software Requirement Engineering
No. Sasaran Khusus Proyek Rata-rata
TE NV HMS TR
1 Definisi Product Owner jelas 87.50% 83.33% 83.33% 75.00% 82.29% 2 Manajemen Product Backlog 91.67% 91.67% 91.67% 91.67% 91.67%
3 Sprint Planning Meeting yang sukses 75.00% 83.33% 91.67% 75.00% 81.25%
Rata-rata 84.72% 86.11% 88.89% 80.56% 85.07%
Interpretasi Fully Achieved (Tercapai Sepenuhnya)
4.3 Penilaian Tingkat Kematangan 3 Sasaran Umum Customer Relationship Management
Penilaian tingkat kematangan sasaran umum pada subbab ini akan merinci tingkat kematangan untuk sasaran umum Customer
Relationship Management yang memiliki tiga sasaran khusus yaitu: 1) Ada Definisi Selesai/ Done; 2) Product Owner Tersedia; dan 3) Sprint Review Meeting yang Sukses. Dari ketiga sasaran khusus yang terdapat pada sasaran umum Customer Relationship Management, diperoleh hasil rekapitulasi KPA Rating dengan
nilai rata-rata sebesar 75.00% sehingga dapat dikatakan sasaran umum ini Largerly Achieved (Sebagian Besar Dicapai). Hasil rekapitulasi secara lengkap untuk sasaran umum Customer Relationship Management dapat dilihat pada Tabel 7.
Tabel 7. Rekapitulasi KPA Rating Sasaran Umum Customer Relationship Management
No. Sasaran Khusus Proyek Rata-rata
TE NV HMS TR
1 Ada definisi “Selesai” 75.00% 75.00% 75.00% 75.00% 75.00%
2 Product Owner tersedia 100.00% 50.00% 100.00% 50.00% 75.00%
3 Sprint Review Meeting yang sukses 75.00% 75.00% 75.00% 75.00% 75.00%
Rata-rata 83.33% 66.67% 83.33% 66.67% 75.00%
Interpretasi Largerly Achieved (Sebagian Besar Dicapai)
4.4 Penilaian Tingkat Kematangan Sasaran Umum Iteration Management
Proses penilaian tingkat kematangan subbab ini pada dasarnya sama dengan subbab-subbab sebelumnya. Sasaran khusus yang dinilai adalah 1) Pengelolaan Sprint Backlog; 2) Iterasi direncanakan; dan 3) Velocity yang terukur; dan 4) Daily Scrum yang sukses. Hasil
rekapitulasi KPA Rating adalah rata-rata sebesar 63.54% sehingga dapat dikatakan sasaran umum ini Largerly Achieved (Sebagian Besar Dicapai). Rata-rata KPA Rating untuk keempat proyek cukup bervariasi yang dapat dilihat pada Tabel 8.
.
Tabel 8. Rekapitulasi KPA Rating Sasaran Umum Iteration Management
No. Sasaran Khusus Proyek Rata-rata
TE NV HMS TR
1 Pengelolaan Sprint Backlog 57.14% 57.14% 71.43% 64.29% 62.50% 2 Iterasi direncanakan 87.50% 87.50% 87.50% 87.50% 87.50%
3 Velocity yang terukur 50.00% 33.33% 33.33% 33.33% 37.50%
4 Daily Scrum yang sukses 66.67% 58.33% 75.00% 66.67% 66.67%
Rata-rata 65.33% 59.08% 66.82% 62.95% 63.54%
Interpretasi Largerly Achieved (Sebagian Besar Dicapai)
4.5 Penilaian Tingkat Kematangan Sasaran Umum Standardized Project Management
Sasaran umum Standardized Project Management adalah satu-satunya sasaran
umum yang harus dicapai untuk mencapai tingkat kematangan 4. Sasaran umum Standardized Project Management hanya memiliki sebuah sasaran khusus yaitu
“Manajemen proyek yang distandarisasi”. Hasil rekapitulasi menunjukkan bahwa nilai rata-rata yang diperoleh keempat proyek adalah sebesar 50.00% sehingga dapat dikatakan sasaran
umum ini Partially Achieved (Sebagian Dicapai). Hasil rekapitulasi lengkap dapat dilihat pada Tabel 9.
Tabel 9. Rekapitulasi KPA Rating Sasaran Umum Standarized Project Management
No. Sasaran Khusus Proyek Rata-rata
TE NV HMS TR
1 Manajemen proyek yang distandarisasi 50.00% 50.00% 50.00% 50.00% 50.00%
Rata-rata 50.00% 50.00% 50.00% 50.00% 50.00%
Interpretasi Partially Achieved (Sebagian Dicapai)
4.6 Penilaian Tingkat Kematangan Sasaran Umum Performance Management
Penilaian tingkat kematangan untuk sasaran umum Performance Management dilakukan dengan melakukan penilaian pada dua sasaran khusus yaitu 1) Sprint Retrospective yang sukses dan 2) Indikator positif. Dari keempat proyek yang diteliti, diperoleh hasil rekapitulasi
KPA Rating dengan nilai rata-rata sebesar 45.83% sehingga dapat dikatakan sasaran umum ini Partially Achieved (Sebagian Dicapai). Proyek TE dan NV memperoleh rata-rata KPA Rating yang sama sebesar 41.67%, sedangkan proyek HMS dan proyek TR sama-sama memperoleh KPA Rating sebesar 50.00%. Hasil rekapitulasi lengkap dapat dilihat pada Tabel 10.
Tabel 10. Rekapitulasi KPA Rating Sasaran Umum Performance Management
No. Sasaran Khusus Proyek Rata-rata
TE NV HMS TR
1 Sprint Retrospective yang sukses 50.00% 50.00% 66.67% 50.00% 54.17%
2 Indikator positif 33.33% 33.33% 33.33% 50.00% 37.50%
Rata-rata 41.67% 41.67% 50.00% 50.00% 45.83%
Interpretasi Partially Achieved (Sebagian Dicapai)
Dari hasil penilaian tingkat kematangan untuk masing-masing sasaran umum, kemudian dilakukan rekapitulasi terhadap perolehan KPA Rating untuk menetapkan tingkat kematangan secara keseluruhan. Perolehan KPA Rating pada setiap sasaran umum akan diinterpretasi untuk menentukan apakah sebuah sasaran umum berada pada posisi Fully Achieved (Tercapai Sepenuhnya), Largerly Achieved (Sebagian Besar Dicapai), Partially Achieved (Sebagian Dicapai), atau Not Achieved (Tidak Tercapai). Tingkat kematangan secara
keseluruhan akan berada pada tingkat dimana seluruh KPA dari sasaran umum tercapai sepenuhnya (Nilai KPA Rating ≥ 86% untuk setiap KPA).
Berdasarkan hasil rekapitulasi KPA Rating dari seluruh sasaran umum yang telah dinilai pada semua tingkat, diperoleh hasil bahwa manajemen proyek PT. XYZ berada pada tingkat kematangan 2. Rekapitulasi perolehan KPA Rating lengkap dapat dilihat pada Tabel 11.
Tabel 11. Hasil Interpretasi KPA Rating
Tingkat Sasaran Umum KPA Rating/ Interpretasi
Proyek
Rata-rata
TE NV HMS TR
2
Basic Scrum Management KPA Rating 90.36% 90.00% 100.00% 82.50% 90.71%
Interpretasi F F F L F Software Requirements Engineering KPA Rating 84.72% 86.11% 88.89% 80.56% 85.07% Interpretasi L F F L F 3 Customer Relationship Management KPA Rating 83.33% 66.67% 83.33% 66.67% 75.00% Interpretasi L L L L L
Iteration Management KPA Rating 65.33% 59.08% 66.82% 62.95% 63.54%
Interpretasi L L L L L 4 Standardized Project Management KPA Rating 50.00% 50.00% 50.00% 50.00% 50.00% Interpretasi P P P P P 5 Performance Management KPA Rating 41.67% 41.67% 50.00% 50.00% 45.83% Interpretasi P P P P P
Keterangan: N: Not Achieved L: Largerly Achieved P: Partially Achieved F: Fully Achieved
Hasil pengukuran tingkat kematangan diperoleh hasil bahwa PT. XYZ masih berada pada tingkat kematangan 2. Untuk mencapai tingkat kematangan yang lebih tinggi diperlukan perbaikan-perbaikan pada proses pengembangan perangkat lunak. Sasaran perbaikan untuk mencapai tingkat di atas 2 diperoleh dengan melakukan identifikasi praktik-praktik yang harus dilakukan pada sasaran umum-sasaran umum untuk setiap tingkat dimana KPA Rating belum tercapai
sepenuhnya. Pemilihan praktik didasarkan pada hasil penilaian kuesioner terhadap butir-butir pertanyaan yang bernilai “Tidak”, “Sebagian”, dan “Tidak Berlaku”.
4.7 Rekomendasi Sasaran Perbaikan untuk Tingkat Kematangan 3
Hasil pemetaan rekomendasi sasaran perbaikan untuk tingkat kematangan 3 ditunjukkan pada Tabel 12.
Tabel 12. Rekomendasi Sasaran Perbaikan Tingkat 3
Sasaran Umum Sasaran Khusus Praktik Perbaikan
Customer Relationship Management
1. Ada definisi “Selesai”
1. Setiap proyek perlu memastikan bahwa definisi “Selesai” tercapai dalam setiap iterasi
2. Setiap tim harus menghargai definisi ”Selesai” 2. Product Owner
tersedia
1. Setiap proyek harus memastikan bahwa Product Owner tersedia bagi tim
2. Setiap proyek harus memastikan bahwa Product Owner dapat dihubungi dengan mudah
3. Sprint Review
Meeting yang sukses
1. Setiap proyek harus dapat menunjukkan hasil jadi software yang telah melalui pengujian
2. Pada setiap Sprint Review Meeting, Product Owner dan stakeholder lainnya memberikan umpan balik
Sasaran Umum Sasaran Khusus Praktik Perbaikan
Iteration Management
1. Pengelolaan Sprint
Backlog
1. Sprint Backlog harus dibagi-bagi ke dalam pekerjaan-pekerjaan yang
lebih kecil.
2. Semua anggota tim harus ikut melakukan estimasi
3. Sisa upaya untuk estimasi setiap pekerjaan diperbarui setiap hari
2. Daily Scrum yang sukses
1. Setiap proyek harus melaksanakan Daily Scrum setiap hari kerja pada tempat dan waktu yang sama.
2. Di dalam Daily Scrum harus diidentifikasi masalah-masalah dan hambatan yang dihadapi.
3. Setiap anggota tim dapat mengetahui apa yang sedang dikerjakan anggota lainnya.
3. Velocity yang terukur
1. Sprint Burndown Chart dibuat dan dapat diakses oleh semua anggota
tim
2. Sprint Burndown Chart diperbarui setiap hari
3. Scrum Master melakukan analisis rutin terhadap progres Sprint
4.8 Rekomendasi Sasaran Perbaikan untuk
Tingkat Kematangan 4 Hasil pemetaan sasaran perbaikan untuk tingkat kematangan 4 ditunjukkan pada Tabel 13.
Tabel 13. Rekomendasi Sasaran Perbaikan Tingkat 4
Sasaran Umum Sasaran Khusus Praktik Perbaikan Standardized
Project Management
1. Manajemen Proyek yang Distandarisasi
Semua proyek harus dikelola dengan kesesuaian pada seluruh tujuan, sasaran, dan praktik-praktik dari tingkat 2 dan 3 pada Scrum Maturity
Model.
4.9 Rekomendasi Sasaran Perbaikan untuk Tingkat Kematangan 5
Sasaran perbaikan untuk tingkat kematangan 5 ditunjukkan pada Tabel 14.
Tabel 14. Rekomendasi Sasaran Perbaikan Tingkat 5
Sasaran Umum Sasaran Khusus Praktik Perbaikan Performance
Management
1. Sprint Retrospective yang Sukses
1. Sprint Retrospective Meeting harus dapat menghasilkan saran
perbaikan yang konkrit
2. Beberapa saran yang dihasilkan harus dapat diimplementasikan 3. Pelajaran yang diambil dicatat
2. Indikator Positif 1. Setiap proyek dapat mencapai tingkat energi dan kepuasan yang tinggi dari seluruh tim
2. Setiap proyek dapat mencapai tingkat kepuasan yang tinggi dari
stakeholder
3. Jam kerja tambahan langka, jika terjadi, dilakukan secara sukarela 4. Diskusi dan kritik yang membangun terjadi pada proyek
5. Eksperimen dan perbaikan proses Scrum dapat dilakukan pada setiap proyek
5. KESIMPULAN DAN SARAN
Berdasarkan hasil dan analisis yang telah dilakukan, berikut uraian kesimpulan penelitian:
1) PT. XYZ telah mencapai tingkat kematangan 2 pada Scrum Maturity Model.
2) Untuk tingkat kematangan 3, PT. XYZ berada pada posisi Largerly Achieved (Sebagian Besar Tercapai)
3) Untuk tingkat kematangan 4, PT. XYZ berada pada posisi Partially Achieved (Sebagian Tercapai)
4) Untuk tingkat kematangan level 5, PT. XYZ berada pada posisi Partially Achieved (Sebagian Tercapai)
5) Rekomendasi perbaikan yang disarankan ditetapkan untuk masing-masing tingkat kematangan. Untuk tingkat kematangan 3 disarankan untuk memperbaiki praktik-praktik pada sasaran khusus yang terkait dengan manajemen hubungan dengan pelanggan dan manajemen iterasi. 6) Rekomendasi perbaikan untuk tingkat
kematangan 4 disarankan untuk memperbaiki sebuah praktik pada sasaran khusus yang terkait standarisasi manajemen proyek.
7) Rekomendasi perbaikan untuk tingkat kematangan 5 disarankan untuk memperbaiki praktik-praktik pada sasaran khusus yang terkait manajemen kinerja proyek.
Berikut saran bagi PT. XYZ sebagai subyek penelitian:
1) Pemahaman tentang kerangka kerja Scrum beserta seluruh praktik, cara kerja dan aturan-aturannya harus diketahui dan dipahami oleh seluruh anggota tim. 2) Penerapan kerangka kerja Scrum dapat
memberikan hasil yang maksimal jika diterapkan secara konsisten di semua proyek.
3) Product Owner harus diberikan pelatihan dan pemahaman yang memadai tentang tugas dan perannya selama proyek berlangsung, sehingga hubungan dengan
pelanggan dapat dimaksimalkan.
4) Kerangka kerja Scrum dapat
dikombinasikan dengan manajemen proyek lain untuk melingkupi aspek-aspek proyek yang tidak dicakup oleh Scrum seperti aspek budget.
5) Dalam kerangka kerja Scrum, pengujian yang dilakukan sebelum demonstrasi produk masih harus ditambahkan dengan pengujian intensif misalnya system integration testing.
Dari sisi akademis, berikut saran-saran yang dapat diberikan:
1) Penelitian dapat melibatkan lebih banyak proyek untuk menilai tingkat kematangan yang lebih baik.
2) Penelitian ini perlu dilanjutkan dengan mengkombinasikan metode kualitatif untuk menghasilkan strategi perbaikan yang lebih sistematis dan komprehensif.
DAFTAR REFERENSI
[1] L. Applegate, R. D. Austin dan D. L. Soule, Corporate Information Strategy and Management, New York: McGraw-Hill, 2009.
[2] K. Schwaber, Agile project management with Scrum, Redmond, WA: Microsoft Press, 2004.
[3] K. Schwaber dan M. Beedle, Agile Software Development with Scrum, Series in Agile Software Development, Prentice Hall, 2002.
[4] K. Schwaber dan J. Sutherland, “The Scrum Guide,” October 2011. [Online]. Available: www.scrum.org. [Diakses 20 March 2014]. [5] P. Green, “Measuring the Impact of Scrum on Product Development at Adobe Systems,” dalam Proceedings of the 44th Hawaii International Conference on System Sciences, Hawaai, 2011.
[6] V. Mahni dan N. Zabkar, “Measuring Progress of Scrum-based Software
Projects,” ELEKTRONIKA IR
ELEKTROTECHNIKA, pp. ISSN 1392-1215, VOL. 18, NO. 8, 2012.
[7] D. Bustard, G. Wilkie dan D. Greer, “The
Maturation of Agile Software
Development Principles and Practice Observations on Successive Industrial Studies in 2010 and 2012,” dalam 20th Annual IEEE International Conference and Workshops on the Engineering of Computer Based Systems (ECBS), 2013. [8] PM Solutions, “Project Management Maturity
Model,” 2013. [Online]. Available: www.pmsolutions.com/resources/view/what-is-the-project-management-maturity-model/. [9] Project Management Institute, A Guide to
the Project Management Body of Knowledge (PMBOK Guide), Fifth Edition, Sylva, North Carolina: PMI Publishing Division, 2009.
[10] Office of Government Commerce, Portfolio, Programme & Project Management Maturity Model (P3M3), Office of Government Commerce, 2006. [11] M. Paulk, C. Weber, S. Garcia, M. Chirssis
dan M. Bush, Capability Maturity Model for Software, Version 1.2, Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2010.
[12] C. Patel dan M. Ramachandran, “Agile maturity model (amm): A software process improvement framework for agile software development practices,” International Journal of Software, pp. 2, 3-28, 2009.
[13] A. Yin, S. Figueiredo dan M. d. S. Miguel , “Scrum Maturity Model, Validation for IT organizations’ roadmap to develop software centered on the client role,” dalam International Conference on Software Engineering Advances(ICSEA), Barcelona, 2011.
[14] O. Salo dan P. Abrahamsson, “Agile methods in European embedded software development organisations: A survey on the actual use and usefulness of Extreme Programming and Scrum,” IET Software, pp. 58-64, 2008.
[15] K. Beck, M. Beedle, A. v. Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor, K. Schwaber, J. Sutherland dan D. Thomas,
“Manifesto for agile software
development,” 2001. [Online]. Available: http://www.agilemanifesto.org. [Diakses 20 March 2014].
[16] M. B. Chrissis, M. Konrad dan S. Shrum, CMMI Guidlines for Process Integration and Product Improvement, Inc. Boston, MA, USA: Addison-Wesley Longman Publishing Co., 2003.
![Gambar 2. Scrum Framework Sumber: Schwaber & Beedle [3]](https://thumb-ap.123doks.com/thumbv2/123dok/2310050.2733752/4.893.139.430.842.1095/gambar-scrum-framework-sumber-schwaber-beedle.webp)
