Analisis Tingkat Kematangan Manajemen Proyek Pengembangan Perangkat Lunak Menggunakan Scrum Maturity Model: Studi Kasus PT. XYZ

I-STATEMENT STIMIK ESQ | I-4 Volume 2 Nomor 2, Agustus 2016

ISSN : 2442-8337

Analisis Tingkat Kematangan Manajemen Proyek Pengembangan Perangkat Lunak Menggunakan Scrum Maturity Model: Studi Kasus PT. XYZ Ahlijati Nuraminah Program Studi Sistem Informasi, STIMIK ESQ Jl. TB Simatupang Kavling 1, Cilandak, Jakarta Selatan – 12560 Email: [email protected]

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 Ahlijati Nuraminah

Page 1

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.

Scrum, Scrum Maturity Model

I-STATEMENT STIMIK ESQ | I-4 Volume 2 Nomor 2, Agustus 2016 Salah satu implementasi agile methodology

Sprint

Daily Scrum

Sprint Planning

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

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

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 proyekproyek 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.

Sprint

Daily Scrum

Sprint Planning

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

Ahlijati Nuraminah

Page 2

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 pekerjaan

(%) 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 Scrum, Scrum Maturity Model

I-STATEMENT STIMIK ESQ | I-4 Volume 2 Nomor 2, Agustus 2016 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 20122014.

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 bertanggungjawab 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. 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. Ahlijati Nuraminah

Page 3

2)

3)

Sprint Backlog: daftar pekerjaan yang akan dilaksanakan pada sebuah Sprint (iterasi pengembangan) yaitu menerjemahkan bagian-bagian dari Product Backlog ke dalam produk jadi. Release Burndown Charts: Grafik yang menggambarkan kemajuan dari pelaksanaan proyek dari waktu ke waktu yang memungkinkan tim Scrum untuk Scrum, Scrum Maturity Model


4)

memiliki visi global terhadap proyek pengembangan. 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.

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.

Siklus iterasi Scrum ditampilkan pada Gambar 2.

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.

Gambar 2. Scrum Framework Sumber: Schwaber & Beedle [3]

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

Ahlijati Nuraminah

Page 4


I-STATEMENT STIMIK ESQ | I-4 Volume 2 Nomor 2, Agustus 2016 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 metodologimetodologi 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 langkahAhlijati Nuraminah

Page 5

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,


I-STATEMENT STIMIK ESQ | I-4 Volume 2 Nomor 2, Agustus 2016 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

Ahlijati Nuraminah

Page 6

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 Scrum, Scrum Maturity Model


5.

6.

7.

8.

draft daftar pertanyaan. 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. 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. 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. 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

9.

metode analisis terhadap KPA (Key Process Area). Keluaran dari tahapan ini adalah rekomendasi sasaran perbaikan. 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. 1.

2.

Nama Proyek TE

NV

Keterangan 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.

Deskripsi

Proyek pengembangan aplikasi back office dan sistem akuntansi untuk sasaran perusahaan kecil dan menengah.

Ahlijati Nuraminah

Page 7



No.

3.

4.

Nama Proyek

HMS

TR

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.

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.

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 ∑(𝑌𝑛) + ½ ∑(𝑃𝑛) ∗ 100% ∑(𝑇𝑛) − ∑(𝑁𝐴𝑛)

Presentase untuk masing-masing KPA dihitung menggunakan persamaan:

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”

Ahlijati Nuraminah

(poin pertanyaan hanya dijalankan sebagian), dan “Tidak Berlaku (N/A)” (poin pertanyaan tidak dapat diimplementasikan).

Page 8

Dimana Yn = Jumlah jawaban “Ya” Pn = Jumlah jawaban “Sebagian” Tn = Jumlah total pertanyaan NAn = Jumlah jawaban “Tidak Berlaku (N/A)”


I-STATEMENT STIMIK ESQ | I-4 Volume 2 Nomor 2, Agustus 2016 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 masingmasing tingkat kematangan, selanjutnya dilakukan identifikasi area perbaikan Sasaran perbaikan diidentifikasi melalui jawaban dari kuesioner yang bernilai “Sebagian”, “Tidak”, atau “Tidak Berlaku (N/A)”. Dari jawabanjawaban 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 2

Sasaran Umum 2.1 Basic Scrum Management

2.2 Software Requirements Engineering

3

3.1 Customer Relationship Management

3.2 Iteration Management

Sasaran Khusus

Jumlah Pertanyaan

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.1 Definisi Product Owner jelas

4

2.2.2 Manajemen Product Backlog

6

2.2.3 Sprint Planning Meeting yang sukses

6

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.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 Ahlijati Nuraminah

Page 2

Sasaran umum Basic Scrum Management memiliki empat sasaran khusus yaitu: 1) Ada Scrum, Scrum Maturity Model

I-STATEMENT STIMIK ESQ | I-4 Volume 2 Nomor 2, Agustus 2016 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 Tabel 5.

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. Rekapitulasi KPA Rating Sasaran Umum Basic Scrum Management

No.

Proyek

Sasaran Khusus

1

Ada peran-peran Scrum

2

TE

NV

HMS

TR

Rata-rata

100.00%

100.00%

100.00%

100.00%

100.00%

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%

90.36%

90.00%

100.00%

80.00%

90.09%

Rata-rata Interpretasi

Fully Achieved (Tercapai Sepenuhnya)

4.2 Penilaian Tingkat Kematangan 2 Sasaran Umum Software Requirements Engineering

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

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 Tabel 6.

Tabel 6. Rekapitulasi KPA Rating Sasaran Umum Software Requirement Engineering No.

Proyek

Sasaran Khusus

TE

NV

HMS

TR

Rata-rata

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%

84.72%

86.11%

88.89%

80.56%

85.07%


Fully Achieved (Tercapai Sepenuhnya)

4.3 Penilaian Tingkat Kematangan 3 Sasaran Umum Customer Relationship Management

Ahlijati Nuraminah

Page 2

Penilaian tingkat kematangan sasaran umum pada subbab ini akan merinci tingkat kematangan untuk sasaran umum Customer Scrum, Scrum Maturity Model

I-STATEMENT STIMIK ESQ | I-4 Volume 2 Nomor 2, Agustus 2016 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.

Proyek

Sasaran Khusus

TE

NV

HMS

TR

Rata-rata

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%

83.33%

66.67%

83.33%

66.67%

75.00%


Largerly Achieved (Sebagian Besar Dicapai)

4.4 Penilaian Tingkat Kematangan Sasaran Umum Iteration Management

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.

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

.

Tabel 8. Rekapitulasi KPA Rating Sasaran Umum Iteration Management No.

Proyek

Sasaran Khusus

TE

NV

HMS

TR

Rata-rata

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%

65.33%

59.08%

66.82%

62.95%

63.54%


Largerly Achieved (Sebagian Besar Dicapai)

4.5 Penilaian Tingkat Kematangan Sasaran Umum Standardized Project Management Sasaran umum Standardized Project Management adalah satu-satunya sasaran Ahlijati Nuraminah

Page 11

umum yang harus dicapai untuk mencapai tingkat kematangan 4. Sasaran umum Standardized Project Management hanya memiliki sebuah sasaran khusus yaitu


I-STATEMENT STIMIK ESQ | I-4 Volume 2 Nomor 2, Agustus 2016 “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

1

Manajemen proyek yang distandarisasi

Rata-rata

Proyek

Rata-rata

TE

NV

HMS

TR

50.00%

50.00%

50.00%

50.00%

50.00%

50.00%

50.00%

50.00%

50.00%

50.00%

Interpretasi

Partially Achieved (Sebagian Dicapai)

4.6 Penilaian Tingkat Kematangan Sasaran Umum Performance Management

KPA Rating dengan nilai rata-rata sebesar 45.83% sehingga dapat dikatakan sasaran umum ini Partially Achieved (Sebagian Dicapai). Proyek TE dan NV memperoleh ratarata KPA Rating yang sama sebesar 41.67%, sedangkan proyek HMS dan proyek TR samasama memperoleh KPA Rating sebesar 50.00%. Hasil rekapitulasi lengkap dapat dilihat pada

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 Tabel 10.

Tabel 10. Rekapitulasi KPA Rating Sasaran Umum Performance Management No.

Proyek

Sasaran Khusus

TE

NV

HMS

TR

Rata-rata

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%

41.67%

41.67%

50.00%

50.00%

45.83%


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 Ahlijati Nuraminah

Page 12

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. Scrum, Scrum Maturity Model

I-STATEMENT STIMIK ESQ | I-4 Volume 2 Nomor 2, Agustus 2016 Tabel 11. Hasil Interpretasi KPA Rating Proyek TE

NV

HMS

TR

Ratarata

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

Customer Relationship Management

KPA Rating

83.33%

66.67%

83.33%

66.67%

75.00%

Interpretasi

L

L

L

L

L

KPA Rating

65.33%

59.08%

66.82%

62.95%

63.54%

Interpretasi

L

L

L

L

L

KPA Rating

50.00%

50.00%

50.00%

50.00%

50.00%

Interpretasi

P

P

P

P

P

KPA Rating

41.67%

41.67%

50.00%

50.00%

45.83%

Interpretasi

P

P

P

P

P

Tingkat

Sasaran Umum

Basic Scrum Management 2

3 Iteration Management

4

Standardized Management

5

Performance Management

Project

KPA Rating/ Interpretasi

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 butirbutir 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 1.

1. Ada definisi “Selesai” Customer Relationship Management

2. Product Owner tersedia

2. 1. 2. 1.

3. Sprint Review Meeting yang sukses

Ahlijati Nuraminah

2.

Setiap proyek perlu memastikan bahwa definisi “Selesai” tercapai dalam setiap iterasi Setiap tim harus menghargai definisi ”Selesai” Setiap proyek harus memastikan bahwa Product Owner tersedia bagi tim Setiap proyek harus memastikan bahwa Product Owner dapat dihubungi dengan mudah Setiap proyek harus dapat menunjukkan hasil jadi software yang telah melalui pengujian Pada setiap Sprint Review Meeting, Product Owner dan stakeholder lainnya memberikan umpan balik

Page 13



Sasaran Umum

Sasaran Khusus


1. Pengelolaan Sprint Backlog

2. 3. 1.

Iteration Management

2. Daily Scrum yang sukses

2. 3. 1.

3. Velocity yang terukur

2. 3.

Sprint Backlog harus dibagi-bagi ke dalam pekerjaan-pekerjaan yang lebih kecil. Semua anggota tim harus ikut melakukan estimasi Sisa upaya untuk estimasi setiap pekerjaan diperbarui setiap hari Setiap proyek harus melaksanakan Daily Scrum setiap hari kerja pada tempat dan waktu yang sama. Di dalam Daily Scrum harus diidentifikasi masalah-masalah dan hambatan yang dihadapi. Setiap anggota tim dapat mengetahui apa yang sedang dikerjakan anggota lainnya. Sprint Burndown Chart dibuat dan dapat diakses oleh semua anggota tim Sprint Burndown Chart diperbarui setiap hari 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 Standardized Project Management

Sasaran Khusus 1. Manajemen Proyek yang Distandarisasi

Praktik Perbaikan 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 Performance Management

Sasaran Khusus 1. Sprint Retrospective yang Sukses

2. Indikator Positif


Sprint Retrospective Meeting harus dapat menghasilkan saran perbaikan yang konkrit

2.

Beberapa saran yang dihasilkan harus dapat diimplementasikan

3. 1.

3.

Pelajaran yang diambil dicatat Setiap proyek dapat mencapai tingkat energi dan kepuasan yang tinggi dari seluruh tim Setiap proyek dapat mencapai tingkat kepuasan yang tinggi dari stakeholder 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

2.

Ahlijati Nuraminah

Page 14



5. KESIMPULAN DAN SARAN

4)

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 praktikpraktik 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

Ahlijati Nuraminah

Page 15

5)

pelanggan dapat dimaksimalkan. Kerangka kerja Scrum dapat dikombinasikan dengan manajemen proyek lain untuk melingkupi aspekaspek proyek yang tidak dicakup oleh Scrum seperti aspek budget. 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/whatis-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.

[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.

[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, 328, 2009.

Ahlijati Nuraminah

Page 16


Analisis Tingkat Kematangan Manajemen Proyek Pengembangan Perangkat Lunak Menggunakan Scrum Maturity Model: Studi Kasus PT. XYZ

Recommend Documents