7
BAB II TINJAUAN PUSTAKA
2.1 Manajemen Proyek Menurut PMBOK (Project Management Book of Knowledge), manajemen proyek adalah penerapan ilmu, keterampilan, peralatan, dan teknik untuk kegiatan proyek dengan memenuhi persyaratan proyek. Manajemen proyek dibagi menjadi lima kelompok proses: initiation, planning, executing, monitoring, controlling, dan closing. Mengelola proyek termasuk mengidentifikasi kebutuhan, kepedulian, dan harapan para stakeholders. Manajemen proyek ini dirancang untuk memberikan berkelanjutan, mengintensifkan manajemen dan mengintegrasikan kegiatan yang kompleks dan untuk menarik bersama-sama kombinasi sumber daya manusia dan non manusia ke dalam organisasi sementara untuk mencapai tujuan tertentu. Whitty dan Maylor menambahkan manajemen proyek diakui sebagai key enabler dari perubahan bisnis dan kontributor penting untuk masa depan bisnis yang sukses (Project Management Institute, 2013). Untuk menentukan kesuksesan proyek secara keseluruhan ketika fase evaluasi proyek dapat diukur dari dimensi manajemen proyek yaitu : 1. Seberapa dekat proyek tersebut mencapai tujuannya sebagaimana didefinisikan dalam project charter atau project business case? 2. Apakah proyek memenuhi spesifikasi produk yang sudah ditentukan dari sisi cost, time, dan scope?
8
2.1.1 Manajemen Ruang Lingkup Proyek (Project Scope Management) Lingkup mengacu kepada seluruh pekerjaan yang terlibat dalam pembuatan produk suatu proyek dan aktivitas – aktivitas yang digunakan dalam pembuatan produk tersebut. Manajemen ruang lingkup proyek terlibat dalam pendefinisian dan pengendalian mengenai apa yang harus ada dan tidak ada dalam proyek. Manajemen ruang lingkup memastikan bahwa tim proyek dan para Stakeholder memiliki pemahaman yang sama mengenai produk yang dihasilkan oleh proyek serta aktivitas - aktivitas yang dilakukan. Aktivitas yg termasuk dalam manajemen ruang lingkup proyek adalah : 1. Inisiasi, melakukan otorisasi pada organisasi untuk memulai proyek atau beralih pada fase proyek selanjutnya. Output dari proses inisiasi adalah perjanjian kontrak yg merupakan dokumen kunci yang secara formal mengakui keberadaan dan menyediakan ulasan luas mengenai sebuah proyek. 2. Perencanaan ruang lingkup, mengembangkan dokumen yang berguna
sebagai
basis
pengambilan
keputusan
di
masa
mendatang, termasuk kriteria dalam menentukan apakah suatu proyek atau fase telah lengkap. Tim proyek akan membuat pernyataan mengenai ruang lingkup dan rencana manajemen ruang lingkup sebagai hasil aktivitas perencanaan ruang lingkup.
9
3. Definisi ruang lingkup, pembagaian deliverables (produk yang dibuat sebagai bagian dari proyek) proyek utama
menjadi
komponen – komponen yang lebih kecil dan lebih mudah dikelola. 4. Verifikasi ruang lingkup, menyusun penerimaan dari ruang lingkup proyek. Para Stakeholder kunci sebuah proyek, seperti customer dan sponsor, secara formal menerima deliverables proyek selama aktivitas ini. 5. Pengendalian
perubahan
ruang
lingkup,
mengendalikan
perubahan yang terjadi pada ruang lingkup. Perubahan ruang lingkup, tindakan koreksi, dan refleksi yang dipelajari merupakan output dari aktivitas ini.
2.1.2 Manajemen
Jadwal
Proyek
(Project
Time
Management) Tidak jarang ditemui proyek teknologi informasi yang gagal dalam menyatukan rencana mengenai ruang lingkup, waktu dan biaya. Para manajer menyebutkan bahwa
menyelesaikan proyek
tepat waktu merupakan tantangan besar bagi mereka. Para manajer juga menyebutkan isu mengenai jadwal yang merupakan alasan utama sehingga terjadi konflik dalam proyek pada keseluruhan Proses. Tim proyek sering membandingkan waktu penyelesaian yang terencana dengan yang nyata terjadi tanpa meminta persetujuan perubahan rencana proyek padahal waktu merupakan satu variable
10
yang memiliki fleksibilitas paling sedikit. Karena waktu terus berlalu tanpa memperdulikan apa yang terjadi pada proyek. Manajemen waktu proyek, meliputi aktivitas-aktivitas yang diperlukan untuk memastikan penyelesaian proyek tepat pada waktunya. Aktivitas-aktivitas utama yang merupakan bagian dari manajemen jadwal proyek adalah : 1. Pendefinisian aktivitas, mengidentifikasikan aktivitas-aktivitas secara spesifik yang harus dilakukan oleh anggota tim proyek dan para Stakeholder sehingga menghasilkan produk-produk proyek. 2. Rangkaian
aktivitas,
mengidentifikasikan
dan
mendokumentasikan hubungan antara aktivitas-aktivitas proyek. 3. Perkiraan durasi aktivitas, memperkirakan jumlah periode kerja yang dibutuhkan untuk menyelesaikan aktivitas individu atau tunggal. 4. Pengembangan
jadwal,
menganalisis
rangkaian
aktivitas,
memperkirakan durasi aktivitas, dan kebutuhankebutuhan sumber daya untuk membentuk jadwal proyek. 5. Pengendalian jadwal, mengendalikan dan mengatur perubahanperubahan pada jadwal proyek.
2.1.3 Manajemen Biaya Proyek (Project Cost Management) Seperti halnya pengaturan jadwal proyek, proyek teknologi informasi juga memiliki kesulitan dalam manajemen biaya karena proyek ini dikenal sebagai proyek yang mahal dan sering melampaui
11
batas anggaran ketika proyek berakhir. Para professional teknologi informasi paham bahwa kebanyakan perkiraan biaya awal untuk proyek dirasa rendah berdasarkan kebutuhan-kebutuhan proyek, sehingga diakhir proyek pastilah terjadi pembengkakan biaya. Perkiraan lain terjadinya pembengkakan biaya adalah kebanyakan proyek teknologi informasi menggunakan teknologi atau proses bisnis baru. Teknologi maupun proses bisnis yang masih baru kebanyakan
belum
teruji
dan
beresiko.
Untuk
mengatasi
permasalahan tersebut dibutuhkan sebuah manajemen biaya proyek yang lebih baik. Manajemen biaya proyek meliputi aktivitas-aktivitas yang dibutuhkan untuk memastikan proyek diselesaikan sesuai dengan anggaran yang disetujui. Manajer proyek harus memastikan bahwa proyek didefinisikan dengan baik, memiliki perkiraan waktu dan biaya yang akurat, memiliki biaya yang realistis pada saat persetujuan dibuat. Terdapat 4 (empat) aktivitas utama dalam manajemen biaya proyek, yaitu: 1. Perencanaan
sumber
daya,
memperkirakan
sumber
daya
(manusia, perlengkapan, atau material) serta jumlah setiap sumber daya yang harus digunakan untuk melakukan aktivitas proyek. 2. Perkiraan biaya, mengembangkan pendekatan atau perkiraan biaya sumber daya yang dibutuhkan untuk menyelesaikan proyek.
12
3. Anggaran biaya, mengalokasikan keseluruhan perkiraan biaya pada satuan kerja untuk membangun dasar (baseline) untuk mengatur performa. 4. Pengendalian biaya, mengendalikan perubahanperubahan pada anggaran proyek.
2.2 Siklus Hidup Proyek (Project Life Cycle) Tujuan merancang dan mendokumentasikan proses siklus hidup proyek secara keseluruhan untuk setiap proyek atau proyek kategori adalah untuk (Archibald, Filippo, & Filippo, 2012): 1. Memungkinkan semua orang yang bersangkutan dalam sebuah proyek dengan membuat, perencanaan dan pelaksanaan proyek-proyek untuk memahami proses yang harus diikuti sepanjang hidup proyek. 2. Capture dan mendokumentasikan pengalaman terbaik dalam organisasi sehingga proses dalam setiap fase proyek dapat terus ditingkatkan dan diterapkan di proyek serupa di masa depan. 3. Aktifkan semua peran proyek dan tanggung jawab dan perencanaan proyek, estimasi, penjadwalan, pemantauan dan pengendalian metode dan alat yang tepat terkait dengan proses manajemen siklus hidup proyek secara keseluruhan. Hal tersebut termasuk yang paling penting dalam menugaskan orang yang memenuhi syarat untuk peran sponsor eksekutif proyek dan manajer proyek pada titik-titik yang tepat dalam kehidupan proyek.
13
Gambar 2.1 Standard top level project life cycle model (Archibald et al., 2012)
Pada gambar 2.1 secara umum terdapat 4 fase dalam siklus hidup proyek, yaitu: 1. Memulai proyek (concept, authorization, initiation, identification, selection, project charter and business case, planning, scheduling). 2. Pengorganisasian dan persiapan (definition, feasibility confirmation, development, demonstration, design prototype, quantification). 3. Melakukan
pengerjaan
(execution,
implementation,
realization,
production and deployment, design/construct/ commission, installation and test). 4. Menutup proyek (handover of the project results to the user, project termination, sometimes including post-completion evaluation).
2.3 Agile Project Management Agile
Project
Management
adalah
hasil
dari
pergerakan
pengembangan perangkat lunak agile. Sedangkan asal-usul manajemen proyek agile dapat ditelusuri kembali ke ide-ide oleh Takeuchi dan Nonaka di Januari 1986 edisi Harvard Business Review, ide tersebut sebelum Jeff Sutherland dan Ken Schwaber membahas metode agile pertama untuk pengembangan perangkat lunak pada konferensi OOPSLA 1995. Sementara menganalisis proses pengembangan perangkat lunak umum, mereka
14
menemukan bahwa pendekatan pengembangan tradisional tidak cocok dengan empiris, tak terduga dan proses non-berulang. Saat ini, ada beberapa pendekatan yang berbeda untuk menerapkan metode agile tapi untuk mendasari semua berbagai gerakan agile, terdapat beberapa konsep dasar yang merubah metodologi tradisional di kepala mereka. “Manifesto for Agile Software Development” menyatakan empat prinsip utama (Frank, 2010) yaitu: 1. Interaksi antar individual daripada proses dan alat-alat. 2. Mengerjakan perangkat lunak daripada dokumentasi yang komprehensif. 3. Kolaborasi dengan user daripada negosiasi kontrak. 4. Menanggapi perubahan daripada mengikuti rencana.
Manajemen proyek agile sangat berakar dalam prinsip-prinsip tersebut namun sedikit dimodifikasi agar masuk akal dalam manajemen proyek, daripada environment pengembangan perangkat lunak. Hal ini dapat dilihat pada beberapa kualitas dari pendekatan manajemen proyek agile. Sebagai contoh, manajemen proyek agile menekankan dua konsep penting. Yang pertama adalah risiko yang diminimalkan dengan berfokus pada iterasi pendek. Yang kedua adalah bahwa komunikasi langsung dengan user dalam proses pengembangan ditekankan sebagai pengganti dari membuat dokumentasi proyek yang berlebihan. Alasan kedua konsep ini ditekankan sederhana: baik membantu tim proyek beradaptasi dengan cepat terhadap kebutuhan yang tak terduga dan perubahan yang cepat dari sebagian besar pelaksanaan pembangunan proyek (Frank, 2010).
15
2.4 Pendekatan Agile Salah
satu
argument
dari
“Manifesto
for
Agile
Software
Development” adalah pendekatan agile didasari oleh mengenali dan menggunakan feedback (Aljaž, 2013). Setelah mempertimbangkan dari berbagai sumber, dapat diketahui bahwa: 1. Dari segi istilah dan konsep dari metode agile lebih digunakan untuk mengembangkan sistem informasi dan pada umumnya untuk proyek TI. 2. Metode tersebut didapat dari keberhasilan eksekusi pengerjaan secara tradisional dan koordinasi secara terus menerus dari semua pihak. 3. Esensi dari pendekatan tersebut melibatkan pembaruan pengerjaan secara terus menerus, dan perencanaan yang detil dari iterasi yang lebih kecil untuk implementasi proyek sesuai dengan hasil yang sebenarnya, pembelajaran yang telah dipelajari, ide baru, dan lainnya. 4. Fokus dari user sangat penting sekali dan biasanya tim proyek melibatkan representative dari user yang selalu mengecek sebagian hasil dari proyek tersebut.
2.5 Traditional vs Agile Perbedaan yang mendasar dari konsep traditional dan agile adalah pada konsep traditional, solusi dan kebutuhan (requirement) sangat jelas didefinisikan di awal proyek sehingga perubahan scope yang besar sangat tidak diharapkan. Konsep traditional mengerjakan proyek secara rutin dan dapat diulang dengan menggunakan template yang sudah dibuat. Pada konsep agile solusi dan kebutuhan (requirement) sebagian diketahui dan
16
dimengerti sehingga terdapat kemungkinan fitur tambahan yang sebelumnya tidak diketahui oleh tim proyek. Konsep agile mempersiapkan tim proyek untuk perubahan scope yang besar (Aljaž, 2013).
Gambar 2.2 Traditional Project Management Life Cycle
(Deshmukh, 2015)
Manajemen proyek traditional atau biasa disebut waterfall method merupakan siklus hidup proyek yang dapat diprediksi kebutuhan (requirement) di awal proyek.
17
Gambar 2.3 Agile Project Management Life Cycle
(Deshmukh, 2015) Manajemen proyek agile sangat cocok untuk proyek yang kebutuhannya kompleks dan belum jelas sehingga tidak dapat di definisikan semua requirement di awal proyek. Keuntungan dari manajemen proyek agile dan khususnya berbasis pendekatan scrum adalah kesederhanaannya. Dalam sebuah proyek agile, peran masing-masing anggota tim sangat jelas dan tidak ada lintas peran. Fitur dapat sepenuhnya dikembangkan dan diuji di siklus iterasi yang pendek. Karena setiap anggota tim memikul tanggung jawab utama untuk bagian mereka dari proyek, kepemilikan proyek ini lebih luas. Metode manajemen proyek agile menegakkan komunikasi yang tinggi, yang membantu tim mengatur pekerjaannya lebih efektif. Manajemen proyek agile dapat menyebabkan produktivitas yang lebih tinggi untuk semua orang yang terlibat (Frank, 2010). Manajemen proyek agile adalah salah satu cara yang paling efektif untuk meningkatkan siklus pengembangan dalam proyek. Dengan berfokus
18
pada menghilangkan birokrasi yang tidak perlu, proses, dan praktek dalam mengelola proyek. Metodologi ini memungkinkan semua pihak untuk melakukan pekerjaan yang lebih produktif (Frank, 2010).
2.6 Agile Scrum Project Management Agile Scrum merupakan salah satu metode atau proses yang berasal dari konsep agile yang saat ini sangat populer digunakan oleh perusahaanperusahaan pada bidang industry pengembangan perangkat lunak atau aplikasi diseluruh dunia. Pada gambar 2.4 dapat dilihat pupularitas variasi penggunaan metodologi agile.
Gambar 2.4 Popular Agile Methodologies (Versionone.com, 2016)
Scrum diprakarsai oleh Ken Swaber pada tahun 1995. Scrum termasuk dalam metodologi agile karena berisi konsep yang sama dari agile. Scrum
adalah
sebuah
kerangka
kerja
yang
digunakan
untuk
mengembangkan suatu produk yang memiliki permasalahan kompleks yang
19
senantiasa berubah. Scrum merupakan sebuah proses iterative dan incremental untuk mengembangkan sebuah produk atau mengelola suatu pekerjaan. Scrum berkonsentrasi membangun sebuah tim yang dapat berfungsi menghasilkan suatu sistem yang fleksibel dalam suatu lingkungan yang terus berubah. Pada akhir setiap iterasi menghasilkan serangkaian fungsi atau modul aplikasi. Sebuah scrum adalah paket tim, di mana semua orang di tim bertindak bersama-sama (Mahalakshmi & Sundararajan, 2013). Dasar dari scrum adalah motivasi kerja sama tim dan sebuah reaksi agile untuk merubah orientasi pada hasil akhir. Proyek-proyek yang mempunyai requirement yang berubah dengan sangat cocok untuk penerapan metode ini. Ringkasan karakteristik dari scrum yaitu (Barrios & Zarrabeitia, 2012). 1. Pengembangan perangkat lunak dilakukan melalui iterasi, bernama sprint, yang berlangsung selama 30 hari. Hasil dari setiap sprint adalah peningkatan layaknya aplikasi yang ditunjukkan kepada klien. 2. Rapat sepanjang proyek dimana perlu dicatat bahwa tim pengembangan bertemu setiap hari dan menyisihkan waktunya hanya selama 15 menit untuk koordinasi dan integrasi. Praktek-praktek yang diterapkan oleh scrum untuk mempertahankan agile control dalam suatu proyek adalah (Barrios & Zarrabeitia, 2012): 1. Revisi iterasi. 2. Pembangunan incremental. 3. Perkembangan evolusi. 4. Pengorganisasian tim secara mandiri.
20
5. Kolaborasi. Proses scrum dapat mengubah deskripsi pekerjaan dan kebiasaan tim proyek Scrum. Sebagai contoh, manajer proyek, yaitu Scrum Master, tidak perlu lagi mengatur tim tetapi tim mengorganisasi dirinya sendiri dan membuat keputusan tentang apa yang harus dilakukan. Kebanyakan manajemen digunakan untuk mengarahkan proyek, mengatakan tim apa yang harus dilakukan dan kemudian memastikan mereka melakukannya. Scrum bergantung pada pengorganisasian mandiri, dengan tim memutuskan apa yang harus dilakukan sementara manajemen mengatasi gangguan dan menghilangkan hambatan (Barrios & Zarrabeitia, 2012).
2.7 Komparasi Tradisional (Waterfall) dengan Scrum Metode tradisional (waterfall) dan metode scrum memiliki kelebihan dan kekurangan dalam penggunaannya pada proyek pengembangan perangkat lunak. Perbedaan waterfall dan scrum dapat dilihat pada table 2.1. Tabel 2.1 Komparasi Traditional (Waterfall) dan Scrum
No 1 2 3 4 5 6 7 8
Waterfall Fokus terhadap proyek Terdiri dari beberapa fase Tidak mengharapkan perubahan dan sulit untuk menerima perubahan Lebih banyak dokumentasi Biaya proyek ditentukan pada saat perencanaan proyek Probabilitas keberhasilan rendah Fleksibilitas dan kreativitas tim terbatas Sequential
Scrum Fokus terhdap produk Terdiri dari bebrapa sprint Mengharapkan perubahan dan menerima perubahan Dokumentasi lebih sedikit Biaya proyek ditetapkan selama proyek berlangsung Probabilitas keberhasilan tinggi Fleksibilitas dan kreativitas tim tidak terbatas Overlappig
21
2.7.1 Kelebihan dan Kekurangan Waterfall Manajemen proyek waterfall merupakan model tradisional dari proses pengembangan perangkat lunak yang pada prakteknya memiliki kelebihan dan kekurangan sebagai berikut (Mahalakshmi & Sundararajan, 2013): 1. Kelebihan Waterfall Merupakan
model
sekuensial,
sehingga
mudah
untuk
diterapkan. Jumlah sumber daya yang dibutuhkan untuk melaksanakan model ini sangat minim. Dokumentasi yang tepat diikuti untuk menjaga kualitas pengerjaan proyek. 2. Kekurangan Waterfall Jika masalah pada salah satu fase tidak pernah diselesaikan sepenuhnya selama fase itu dapat menyebabkan banyak masalah yang akan terjadi. Jika klien ingin requirement berubah, hal tersebut tidak akan di implementasikan. Ruang lingkup yang tidak berubah dan terikat kontrak requiremet dengan klien.
22
2.7.2 Kelebihan dan Kekurangan Scrum Manajemen proyek scrum merupakan salah satu dari metodologi agile yang memiliki kelebihan dan kekurangan sebagai berikut (Mahalakshmi & Sundararajan, 2013): 1. Kelebihan Scrum Scrum
memberikan
kepuasan
pelanggan
dengan
mengoptimalkan waktu penyelesaian dan responsif terhadap permintaan. Meningkatkan kualitas. Menerima dan mengharapkan perubahan. Memberikan perkiraan yang lebih baik dan menghabiskan lebih sedikit waktu untuk mengembangkan perangkat lunak. Jadwal proyek lebih terkendali. Scrum sangat ideal untuk ruang lingkup yang cepat berubah, dan mengakumulasikan ruang lingkup. Lebih bermanfaat bagi pelanggan dan manajer proyek. Scrum cepat dan dapat beradaptasi perubahan dengan mudah. Mengatur ruang lingkup jika diperlukan untuk memenuhi tanggal rilis perangkat lunak. Perkiraan pekerjaan jauh lebih mudah. Menyelesaikan pekerjaan lebih logis. 2. Kekurangan Scrum Dokumentasi sangat kurang. Dedikasi anggota tim sangat diutamakan.
23
Kerjasama tim kerja sangat diutamakan Jika anggota tim tidak bekerja sama dengan baik, proyek ini akan menghadapi kegagalan
2.8 Scrum Framework Peran kunci, artefak dan event utama dalam Scrum dapat dilihat pada gambar 2.5.
Gambar 2.5 Scrum Framework
(Barrios & Zarrabeitia, 2012)
Jantung dari Scrum adalah Sprint, sebuah batasan waktu selama satu bulan atau kurang, dimana sebuah Inkremen yang “Selesai”, berfungsi, berpotensi untuk dirilis dan dikembangkan. Sprint biasanya memiliki durasi yang konsisten sepanjang proses pengembangan produk (Schwaber & Sutherland, 2014). Sprint yang baru, langsung dimulai setelah Sprint yang sebelumnya berakhir. Sprint memuat dan terdiri dari Sprint Planning, Daily
24
Scrum, pengembangan, Sprint Review dan Sprint Retrospective. Ada beberapa hal yang dilarang pada saat Sprint berjalan, yaitu: 1. Tidak boleh ada perubahan yang dapat membahayakan tercapainya Sprint Goal; 2. Kualitas dari Sprint Goal tidak boleh menurun; 3. Scope dapat diklarifikasikan dan dinegosiasikan ulang diantara Product Owner dan Tim Pengembang seiring dengan bertambahnya pengetahuan.
Setiap Sprint dapat dikatakan sebagai sebuah proyek dengan batasan waktu tidak lebih dari satu bulan. Sama halnya dengan proyek, Sprint digunakan untuk menyelesaikan sesuatu. Setiap Sprint memiliki definisi mengenai apa yang akan dikembangkan, sebuah disain dan perencanaan yang fleksibel yang akan membimbing pengembangan, pekerjaan yang akan dilakukan dan hasil dari produk. Dalam Scrum Framework terdiri dari 3 komponen utama, yaitu: 1. Artefak Scrum. 2. Tim Scrum. 3. Acara – acara Scrum.
2.8.1 Artefak Srum Artefak Scrum merepresentasikan pekerjaan atau nilai, bertujuan untuk menyediakan transparansi, dan kesempatankesempatan
untuk
didefinisikan
oleh
peninjauan Scrum
dan
secara
adaptasi. khusus
Artefak
dirancang
yang untuk
25
meningkatkan transparansi dari informasi kunci, dengan begitu semua pihak dapat memiliki pemahaman yang sama terhadap artefak (Schwaber & Sutherland, 2014).
2.8.1.1 Product Backlog Product Backlog adalah daftar terurut, dari setiap hal yang berkemungkinan dibutuhkan di dalam produk, dan juga merupakan sumber utama, dari daftar kebutuhan mengenai semua hal yang perlu dilakukan terhadap produk. Product Owner bertanggung-jawab terhadap Product Backlog, termasuk isinya, ketersediaannya, dan urutannya. Product Backlog tidak pernah selesai. Pada awal pembuatannya hanya terjabar daftar kebutuhan yang paling diketahui dan dipahami pada saat itu (Schwaber & Sutherland, 2014). Product Backlog berkembang seiring dengan berkembangnya produk dan lingkungan di mana produk tersebut digunakan. Product Backlog bersifat dinamis; senantiasa berubah agar produk dapat menjadi
layak,
kompetitif
di
pasar,
dan
bermanfaat
bagi
penggunanya. Selama produk masih eksis maka Product Backlog juga eksis. Product Backlog menjabarkan semua fitur, fungsi, kebutuhan, penyempurnaan dan perbaikan terhadap produk di rilis mendatang. Item Product Backlog memiliki atribut deskripsi, urutan, estimasi dan nilai bisnis.
26
2.8.1.2 Sprint Backlog Sprint Backlog Sprint Backlog adalah sekumpulan item Product Backlog yang telah dipilih untuk dikerjakan di Sprint, juga di dalamnya rencana untuk mengembangkan potongan tambahan produk dan merealisasikan Sprint Goal. Sprint Backlog adalah perkiraan mengenai fungsionalitas apa yang akan tersedia di Inkremen selanjutnya dan pekerjaan yang perlu dikerjakan untuk menghantarkan fungsionalitas tersebut menjadi potongan tambahan produk yang “Selesai”. Sprint
Backlog
menampilkan
semua
pekerjaan
yang
dibutuhkan untuk mencapai Sprint Goal yang dibuat oleh Tim Pengembang. Sprint Backlog adalah sebuah rencana yang cukup detail, di mana perubahan-perubahannya di tengah Sprint bisa dipahami saat Daily Scrum Meeting. Tim Pengembang memodifikasi Sprint Backlog sepanjang Sprint berlangsung, dan Sprint Backlog dapat berubah kapanpun juga sepanjang Sprint. Perubahan ini terjadi seiring dengan berkerjanya Tim Pengembang sesuai rencana pada saat itu, dan semakin meningkatnya wawasan tim untuk mencapai tujuan Sprint (Schwaber & Sutherland, 2014).
2.8.2 Tim Scrum Tim Scrum terdiri dari Product Owner, Tim Pengembang dan Scrum Master. Tim Scrum mengatur diri mereka sendiri dan berfungsi
antar-lintas.
Tim
yang
mengatur
dirinya
sendiri
27
menentukan cara terbaik untuk menyelesaikan pekerjaannya, daripada diatur oleh pihak lain yang berada di luar anggota tim. Tim yang berfungsi antar-lintas memiliki semua kompetensi yang dibutuhkan untuk menyelesaikan pekerjaan, tanpa mengandalkan pihak lain yang berada di luar anggota tim. Model tim di dalam Scrum
dirancang
sedemikian
rupa
untuk
mengotimalisasi
fleksibilitas, kreatifitas dan produktifitas. Tim Scrum menghantarkan produk secara berkala dan bertahap untuk memperbesar kesempatan mendapatkan masukan. Penghantaran secara bertahap dari sebuah produk yang “Selesai”, memastikan produk yang berpotensi dapat digunakan, selalu siap (Schwaber & Sutherland, 2014).
2.8.2.1 Product Owner Product Owner bertanggung-jawab untuk memaksimalkan nilai produk dan hasil kerja Tim Pengembang. Cara pelaksanaannya sangat bervariasi antar organisasi, Tim Scrum dan individu. Product Owner merupakan satu-satunya orang yang bertanggung-jawab untuk mengelola Product Backlog. Pengelolaan Product Backlog mencakup (Schwaber & Sutherland, 2014): 1. Mengekspresikan dengan jelas item Product Backlog. 2. Mengurutkan item di dalam Product Backlog untuk mencapai tujuan dan misi dengan cara terbaik. 3. Mengoptimalkan nilai dari hasil pekerjaan Tim Pengembang.
28
4. Memastikan Product Backlog transparan, jelas, dan dapat dilihat semua pihak, dan menunjukkan apa yang akan dikerjakan oleh Tim Scrum selanjutnya. 5. Memastikan Tim Pengembang dapat memahami item dalam Product Backlog hingga batasan yang diperlukan.
Product Owner dapat saja mengerjakan pekerjaan-pekerjaan di atas, atau menyerahkan pengerjaannya kepada Tim Pengembang, namun satu-satunya pihak yang bertanggung jawab tetaplah Product Owner. Product Owner adalah satu orang dan bukan berupa sebuah komite. Product Owner dapat mengumpulkan aspirasi dari komite ke dalam Product Backlog, jika ada yang ingin merubah prioritas item pada Product Backlog, harus melakukannya melalui Product Owner.
2.8.2.2 Tim Pengembang Tim Pengembang terdiri dari para profesional yang bekerja untuk menghasilkan tambahan potongan produk (selanjutnya disebut Inkremen) “Selesai”, yang berpotensi untuk dirilis di setiap akhir Sprint. Hanya anggota Tim Pengembang yang mengembangkan Inkremen ini (Schwaber & Sutherland, 2014). Tim Pengembang dibentuk dan didukung oleh organisasi untuk mengatur dan mengelola pekerjaannya secara mandiri. Sinergi yang ada di dalam tim akan meningkatkan efisiensi dan efektifitas
29
dari Tim Pengembang secara keseluruhan. Tim Pengembang memiliki karakteristik sebagai berikut: 1. Mereka mengatur dirinya sendiri. Tidak ada satu orang pun (bahkan Scrum Master) yang memerintah Tim Pengembang bagaimana cara merubah Product Backlog menjadi Inkremen yang berpotensi untuk dirilis. 2. Tim Pengembang berfungsi antar-lintas, sebagai sebuah tim, memiliki semua keahlian yang dibutuhkan untuk menghasilkan produk. 3. Scrum tidak mengenal adanya jabatan tertentu untuk anggota Tim Pengembang selain Pengembang, apapun pekerjaan dikerjakan
oleh
masing-masing
anggota
tim;
tidak
yang ada
pengecualian untuk aturan yang satu ini. 4. Tim
Pengembang tidak
mengenal
adanya
sub-tim
yang
dikhususkan untuk bidang tertentu seperti pengujian atau analisa bisnis; tidak ada pengecualian untuk aturan yang satu ini. 5. Anggota Tim Pengembang boleh memiliki spesialisasi keahlian dan fokus di satu area tertentu, namun akuntabilitas dari hasil dari pekerjaan secara keseluruhan adalah milik Tim Pengembang.
Jumlah anggota Tim Pengembang yang optimal adalah cukup kecil untuk dapat berkoordinasi dengan cepat, dan cukup besar untuk dapat menyelesaikan pekerjaan dalam satu Sprint. Jumlah anggota tim yang kurang dari tiga orang akan mengurangi interaksi dan akan
30
menyebabkan produktifitas yang rendah. Tim Pengembang yang kecil kemungkinan akan mengalami kekurangan keahlian tertentu pada saat Sprint berjalan, yang pada akhirnya menyebabkan Tim Pengembang tidak dapat menghasilkan Inkremen yang berpotensi untuk dirilis. Tim Pengembang dengan jumlah anggota lebih dari sembilan orang membutuhan terlalu banyak koordinasi. Tim Pengembang dengan jumlah anggota tim yang banyak, akan menimbulkan terlalu banyak kompleksitas bagi proses yang berbasiskan empirisme. Product Owner dan Scrum Master tidak termasuk dalam hitungan, kecuali mereka juga turut ikut mengerjakan pekerjaan yang ada di Sprint Backlog (Schwaber & Sutherland, 2014).
2.8.2.3 Scrum Master Scrum Master bertanggung jawab untuk memastikan Scrum telah dipahami dan dilaksanakan. Scrum Master melakukannya dengan memastikan Tim Scrum mengikuti teori, praktik, dan aturan main Scrum. Scrum Master adalah seorang pemimpin yang melayani Tim Scrum. Scrum Master membantu pihak di luar Tim Scrum, untuk memahami apakah interaksi mereka dengan Tim Scrum bermanfaat atau tidak. Scrum Master membantu setiap pihak untuk merubah interaksi-interaksi yang tidak bermanfaat sehingga bisa memaksimalkan nilai yang dihasilkan oleh Tim Scrum (Schwaber & Sutherland, 2014).
31
2.8.3 Acara-Acara Scrum Acara-acara wajib dalam Scrum dihadiri untuk menciptakan sebuah kesinambungan dan mengurangi adanya acara-acara lain yang tidak tercantum di dalam Scrum. Setiap acara di dalam Scrum memiliki batasan waktu, yang artinya selalu memiliki durasi maksimum. Pada saat Sprint dimulai, durasinya tetap dan tidak dapat diperpendek maupun diperpanjang. Scrum menyediakan empat acara formal, yang dibungkus di dalam Sprint, untuk inspeksi dan adaptasi, yaitu (Schwaber & Sutherland, 2014): 1. Sprint Planning. 2. Daily Scrum. 3. Sprint Review. 4. Sprint Retrospective.
2.8.3.1 Sprint Planning Pekerjaan
yang
akan
dilaksanakan
di
dalam
Sprint
direncanakan pada saat Sprint Planning. Perencanaan ini dibuat secara kolaboratif oleh seluruh anggota Tim Scrum. Perencanaan tersebut termasuk menentukan estimasi dalam menyelesaikan pekerjaan di dalam sprint tersebut. Sprint Planning dibatasi maksimum delapan jam untuk Sprint yang berdurasi satu bulan. Untuk Sprint yang lebih pendek, batasan waktunya biasanya lebih singkat. Scrum Master memastikan bahwa acara ini dilaksanakan
32
dan setiap hadirin memahami tujuannya. Scrum Master mengedukasi Tim Scrum untuk melaksanakannya dalam batasan waktu yang telah ditentukan (Schwaber & Sutherland, 2014). Sprint
Planning
harus
dapat
menjawab
pertanyaan-
pertanyaan berikut: 1. Apa goal dari Sprint? 2. Apa yang dapat dihantarkan di dalam Inkremen sebagai hasil dari Sprint yang sedang berjalan? 3. Apa yang perlu dilakukan untuk dapat menghantarkan Inkremen tersebut?
2.8.3.2 Daily Scrum Daily Scrum adalah kegiatan dengan batasan waktu maksimum selama 15 menit agar Tim Pengembang dapat mensinkronisasikan pekerjaan mereka dan membuat perencanaan untuk 24 jam ke depan. Hal ini dilakukan dengan meninjau pekerjaan semenjak acara Daily Scrum terakhir dan memperkirakan pekerjaan yang dapat dilakukan sebelum melakukan Daily Scrum berikutnya (Schwaber & Sutherland, 2014). Daily Scrum dilaksanakan pada waktu dan tempat yang sama setiap hari untuk mengurangi kompleksitas. Pada saat pertemuan, Tim Pengembang menjelaskan: 1. Apa yang sudah saya lakukan kemarin yang telah membantu Tim Pengembang mencapai Sprint Goal?
33
2. Apa yang akan saya lakukan hari ini untuk membantu Tim Pengembang mencapai Sprint Goal? 3. Apakah ada hambatan yang dapat menghalangi saya atau Tim Pengembang untuk mencapai Sprint Goal?
2.8.3.3 Sprint Review Sprint Review diadakan di akhir Sprint untuk meninjau Inkremen dan merubah Product Backlog bila diperlukan. Pada saat Sprint Review, Tim Scrum dan stakeholder berkolaborasi untuk membahas apa yang telah dikerjakan dalam Sprint yang baru usai. Berdasarkan hasil tersebut tersebut dan semua perubahan Product Backlog pada saat Sprint, para hadirin berkolaborasi menentukan apa yang dapat dikerjakan di Sprint berikutnya, untuk mengoptimalisasi nilai produk. Pertemuan ini bersifat informal, bukan merupakan status meeting, dan presentasi dari Inkremen diharapkan dapat mengumpulkan masukan dan menumbuhkan semangat kolaborasi (Schwaber & Sutherland, 2014). Sprint Review adalah acara dengan batasan waktu maksimum selama empat jam untuk Sprint yang berdurasi satu bulan. Untuk Sprint yang lebih pendek, batasan waktunya biasanya lebih singkat. Scrum Master memastikan bahwa acara ini dilaksanakan, dan setiap hadirin memahami tujuannya. Scrum Master mengedukasi Tim Scrum untuk melaksanakannya dalam batasan waktu yang telah ditentukan (Schwaber & Sutherland, 2014).
34
Sprint Review mencakup elemen-elemen berikut: 1. Hadirin termasuk Tim Scrum dan stakeholder kunci diundang oleh Product Owner. 2. Product Owner menjelaskan item Product Backlog apa yang sudah “Selesai” dan apa yang belum “Selesai”. 3. Tim Pengembang menjelaskan apa yang berjalan dengan baik sepanjang Sprint, masalah apa yang mereka hadapi, dan bagaimana mereka menyelesaikan masalah tersebut. 4. Tim Pengembang mendemonstrasikan pekerjaan yang sudah mereka
selesaikan
dan
menjawab
pertanyaan-pertanyaan
mengenai potongan tambahan produk. 5. Product Owner menjelaskan keadaan terakhir Product Backlog. Ia dapat memproyeksikan tanggal perkiraan selesai produk (bila dibutuhkan). 6. Seluruh hadirin berkolaborasi membahas pekerjaan selanjutnya, dengan begitu Sprint Review menyediakan masukan yang berarti bagi Sprint Planning berikutnya. 7. Ulasan mengenai keadaan pasar--atau kemungkinan potensi penggunaan produk--yang telah berubah dan hal yang paling berharga apa yang harus dikerjakan berikutnya. 8. Review timeline, budget, potensi kapabilitas dan marketplace untuk antisipasi rilis produk.
35
Hasil dari Sprint Review adalah revisi dari Product Backlog yang mendefinisikan kemungkinan item Product Backlog untuk Sprint berikutnya. Product Backlog dapat dirubah secara keseluruhan sebagai tanggapan atas peluang-peluang baru.
2.8.3.4 Sprint Retrospective Sprint Retrospective adalah sebuah kesempatan bagi Tim Scrum untuk meninjau dirinya sendiri dan membuat perencanaan mengenai peningkatan yang akan dilakukan di Sprint berikutnya. Sprint Retrospective dilangsungkan setelah Sprint Review selesai dan sebelum Sprint Planning berikutnya. Ini adalah acara dengan batasan waktu maksimum selama tiga jam untuk Sprint yang berdurasi satu bulan. Untuk Sprint yang lebih pendek, batasan waktunya biasanya lebih singkat. Scrum Master memastikan bahwa acara ini dilaksanakan dan setiap hadirin memahami tujuannya. Scrum Master mengedukasi Tim Scrum untuk melaksanakannya dalam batasan waktu yang telah ditentukan. Scrum Master berpartisipasi sebagai rekan yang bertanggungjawab terhadap proses Scrum (Schwaber & Sutherland, 2014). Tujuan dari Sprint Retrospective adalah: 1. Meninjau bagaimana Sprint yang telah selesai berlangsung, termasuk hal-hal
yang berkaitan dengan
orang-orangnya,
hubungan antara orang-orang, proses, dan perangkat kerja.
36
2. Mengidentifikasi dan mengurutkan hal-hal utama yang berjalan baik, dan hal-hal yang berpotensi untuk ditingkatkan. 3. Membuat rencana implementasi, dengan tujuan peningkatan caracara kerja Tim Scrum.
Di akhir Sprint Retrospective, Tim Scrum harus dapat mengidentifikasi
peningkatan-peningkatan
yang
akan
diimplementasikan di Sprint berikutnya. Mengimplementasikan peningkatan ini di Sprint berikutnya, merupakan salah satu bentuk adaptasi dari hasil peninjauan Tim Scrum itu sendiri.
2.9 Scrum Tools Scrum Tools merupakan alat bantu yang sangat diperlukan untuk mengadopsi metode dan proses scrum dalam sebuah proyek pengembangan aplikasi. Alat bantu tersebut digunakan untuk mengelola dan mengorganisis semua informasi yang berkaitan dengan proyek, mulai dari jadwal pelaksanaan proyek, bug tracker, status proses yang sedang berjalan, sprint, dan elemen-element lainnya yang ada pada scrum seperti redmine dan scrum planning poker.
2.9.1 Redmine Redmine adalah sebuah perkakas untuk mengelola proyek dan bug-tracking berbasis web yang bebas dan open source. Ia menyertakan sebuah kalendar dan gantt charts untuk menyokong
37
presentasi
visual
dari
proyek-proyek
dan
tenggat-waktunya
(deadlines). Disamping kemapuan penanganan proyek berganda (multiple), Redmine juga menyediakan fitur-fitur pengelola proyek terpadu, issue tracking, dan dan dukungan terhadap berbagai sistem ‘version control’. Redmine sangat mendukung pengelolaan proyek berbasis agile scrum.
2.9.2 Scrum Planning Poker Scrum planning poker merupakan suatu cara yang digunakan untuk
melakukan
menyelesaikan suatu
estimasi
waktu
yang
dibutuhkan
pekerjaan dalam sebuah sprint.
untuk Selama
perencanaan sprint di scrum, tim dapat menggunakan kartu poker sebagai satuan ukuran untuk memperkirakan ukuran keseluruhan user story dan fitur. Hal ini membantu tim menetapkan poin yang ditentukan dan membantu estimasi tim berapa lama waktu yang dibutuhkan untuk menyelesaikan setiap tugas, dan apa yang masuk ke iterasi berikutnya. Alat ini juga merupakan teknik berbasis konsensus untuk memperkirakan kesepakatan tentang beban kerja yang diproyeksikan dalam sprint backlog (Oluwole, 2013). Nilai estimasi pada planning poker terbatas, yaitu 0, ½,1,2,3,5,8,13,20,40, dan 100. Setiap nilai merepresentasikan jumlah dari story points, jumlah hari, jumlah jam atau unit lainnya untuk melakukan estimasi. Story points merupakan nilai dari
38
customer requirements dan mendeskripsikan fungsionalitas secara spesifik. Contoh planning poker cards dapat dilihat pada gambar 2.6.
Gambar 2.6 Scrum Planning Poker
Tim yang melakukan estimasi melakukan diskusi tentang fitur yang akan dibangun
dan menanyakan pertanyaan kepada
perwakilan dari customer yaitu product owner
jika diperlukan.
Setelah selesai, maka masing-masing peserta akan menunjukkan salah satu kartu yang meruapakan estimasi dari setiap orang secara bersamaan. Jika setiap peserta menunjukkan nilai yang sama, maka salah satu fitur tersebut sudah ditentukan dan disepakati bersama estimasinya. Jika tidak, maka untuk peserta yang mempunyai nilai yang berbeda dengan peserta lain akan melakukan diskusi tentang
39
alasan estimasinya. Setelah itu dilakukan estimasi ulang sampai semua menunjukan nilai yang sama pada kartu poker yang mereka tunjukkan. Proses planning poker dilakukan berulang-ulang sampai konsensus didapatkan atau semua peserta sepakat terhadap keseluruhan estimasi dalam sprint yang akan berjalan (Gandomani, Wei, & Binhamid, 2014).
40
2.10 Review Jurnal Tabel 2.2 Review Jurnal
No 1
Judul Penelitian
Author
Traditional SDLC Vs Scrum Mahalakshmi, M., Waterfall Methodology – A Comparative & Sundararajan, M. and Scrum Study (2013)
2
Suitability Analysis of Various Mishra, Apoorva & Software Development Life Dubey, Deepty Cycle Models (2013)
3
SCRUM: Application Barrios, W. G., & Experience in a Software Zarrabeitia, C. T. Development PyME in the NEA (2012)
4
Metode
The Success Factors of Rich C., L. (2012) Running Scrum: A Qualitative Perspective
Hasil Kelebihan: Menjelaskan kelebihan dan kekurangan metode waterfall dan scrum.
Kekurangan: Tidak ada contoh kasus dan pengaruh scrum terhadap kekurangan metode waterfall. Waterfall, Kelebihan: Menampilkan kelebihan dan kekurangan model XP, RAD, SDLC serta analisis berbagai model SDLC dengan Prototype, kesesuaian terhadap berbagai jenis proyek perangkat lunak Incremental, yang tergantung pada environment-nya. and Spiral Kekurangan: Tidak menampilkan model agile Scrum Kelebihan: Menunjukkan scrum tidak hanya sebagai praktek yang terisolasi dalam PyMES dan untuk pengembangan perangkat lunak saja, tetapi juga sebagai suatu tindakan dalam rencana strategis perusahaan.
Scrum
Kekurangan: Kurang menjelaskan perbandingan dengan proses existing atau model pengembangan yang lain. Kelebihan: Menjelaskan kinerja pengembangan Software dipengaruhi oleh: 1. On-Time 2. On-Budget 3. Software Functionalities
41
No
Judul Penelitian
Author
Metode
Hasil 4. Development Efficiency Software Development Agility dipengaruhi oleh: 1. Team Attitude 2. Software Team Response Extensiveness 3. Software Team Response Efficiency 4. Team Skills
5
6
Understanding agile project Frank, C. H. (2010) Scrum management methods using Scrum. International digital library. Agile Project Management – a Aljaž, S. (2013) Future Approach to the Management of Projects?
Agile
Kekurangan: Kurang menjelaskan peningkatan kinerja dengan metode scrum dibandingkan metode lainnya. Kelebihan: Memaparkan keuntungan dari manajemen proyek agile, khususnya pendekatan berbasis scrum. Kekurangan: Kurang menjelaskan perbandingan dengan metode lain. Kelebihan: Memaparkan pendekatan agile dalam menyediakan pelaksanaan yang lebih efisien dari suatu proyek. Kekurangan: Kurang menjelaskan perbandingan dengan metode lain dari segi efisiensi pelaksanaan suatu proyek.
42
