10
BAB II
LANDASAN TEORI
2.1 Pendahuluan
Ketika sebuah perusahaan pengembang software masih tergolong kecil, maka proyek di dalamnya juga relatif kecil . Dan karena proyek-proyek tersebut masih dalam skala kecil maka tim yang terlibat juga kecil. Namun ketika proyek-proyek tersebut berkembang maka tim yang terlibatpun membesar dan saat-saat itulah masalah-masalah baru dapat muncul. Proyek-proyek tersebut harus mempunyai alur kerja yang terstruktur.
Manajemen Proyek Software adalah sebuah jenis dari manajemen proyek yang memfokuskan spesifik pada menciptakan atau memperbaharui perangkat lunak (Teresa Luckey dan Joseph Philips, 2006). Dalam rangka memahami dan mendapatkan pandangan yang obyektif dari model model pengembangan software, penulis telah membaca artikel-artikel dan buku- buku terkait.
2.2 Model-model Pengembangan Software
Kita sangat perlu untuk mengetahui mengapa kita membutuhkan model pengembangan software di tahap awal. Sekitar 3 dekade yang lalu, produk
11
software relatif lebih sederhana dengan tingkat kerumitan yang rendah serta jumlah Line of Code (LOC) yang lebih sedikit. Pada masa itu kita belum membutuhkan model software yang terstruktur untuk mendapatkan software dengan tepat waktu dan kualitas yang sesuai. Namun seiring dengan perkembangan jaman, masa sekarang produk software sudah jauh lebih rumit, dan dengan jumlah LOC yang mencapai ribuan. Dan seperti juga produk produk yang lain, produk software juga berorientasi pada kepuasan konsumen sehingga proses pengembangannya perlu terstruktur dan disesuiakan dengan model pengembangan yang tepat untuk mencapai kepuasan pelanggan.
Model pengembangan software adalah suatu pengaturan dari aktivitas-aktivitas yang berbeda dalam sebuah pengembangan suatu produk software. Beberapa aktivitas tersebut dapat dikelompokkan berdasarkan tipikalnya seperti Software Elements Analysis, Scope Analysis, Specification, Architecture, Implementation, Testing dan Dokumentasi.
Secara garis besar metodologi software dapat dibedakan menjadi 2 kategori, yaitu metodologi tradisional yang terencana dan metodologi agile (modern). Contoh dari metodologi tradisional adalah waterfall model (model air terjun) dan model spiral sedang contoh dari metodologi agile adalah Extreme programming (XP) dan Scrum. Model pengembangan software tradisional lebih mengarah pada belajar terhadap proses namun model pengembangan modern lebih berfokus pada sumber daya manusia sebagai talenta kreatifnya.
Berkenaan dengan tingginya tingkat perbedaan diantara kedua model tersebut maka tidaklah mudah bagi sebuah organisasi untuk berpindah dari model tradisional ke model agile. Kita harus dapat menganalisa berbagai karakteristik
12
dari organisasi seperti struktur organisasinya, budaya dan saluran komunikasi berkenaan dengan penerapan dari system baru. Untuk lebih spesifik pada penulisan ini maka kami berfokus pada 2 contoh dari model pengembangan yang sudah diterapkan pada LAI Games yaitu waterfall dari model tradisional dan Scrum dari model agile modern.
2.2.1 Incremental Development
Sesuai dengan namanya, model ini mengembangkan software dengan metode penambahan. Pada metode ini, peningkatan suatu system ditambahkan ketika fungsi dasar atau utama dari system tersebut sudah tercapai. Metode ini juga diadopsi oleh beberapa model agile lainnya seperti XP dan Scrum.
2.2.2 XP (Extreme Programming)
XP merupakan salah satu dari model pengembangan berbasis agile yang diperkenalkan oleh Kent Back pada tahun 1996. Extreme programming saat ini telah semakin dapat diterima dan diterapkan dalam industry perangkat lunak. Pada metodologi ini, adanya perubahan memang sudah diantisipasi bakal terjadi dan timpun sudah siap mengatasi perubahan-perubahan tersebut. Ini yang menjadikan XP bersifat agile. Semua pengkodingan dan pengujian dilakukan oleh programmer.
2.2.3 Model Spiral
Ini adalah model yang berorientasi pada resiko dimana mengedepankan langkah-langkah yang diambil untuk meminimalkan resiko tersebut. Pada model spiral,
13
sebuah proyek dipecah-pecah menjadi beberapa sub bagian dimana perubahan dapat mudah untuk dilakukan pada tiap segmen-segmen tersebut. Pembagian suatu proyek ke dalam segmen-segmen kecil tersebut membantu dalam mengakses resiko-resiko dan menyelesaikannya sebelum hal tersebut kejadian di lapangan.
2.2.4 Model Waterfall
Model waterfall lebih bersentral pada proses dan dokumentasi yang berkeyakinan bahwa semua kebutuhan penting yang dibutuhkan dalam sebuah produk yang lengkap harus sudah diketahui di awal dan tidak mengharapkan adanya perubahan besar sepanjang proses pengembangan. Konsumen juga terlibat dalam menganalisa tahapan-tahapan dari proyek namun setelah itu ada lagi kewenangan dari customer di sisa proses pengembangan (I. Sommerville, 2004). Sebagian besar dalam ruang lingkup software engineering akan sependapat bahwa proses pengembangan software yang tertua dan paling banyak digunakan adalah model pengembangan Waterfall. Waterfall adalah urutan pengembangan software dimana proses pengembangan mengalir ke bawah seperti sebuah air terjun dalam berbagai tahapan yang biasanya diawali dari kebutuhan, analisa kemudian design, implementasi, testing, dan deployment maintenance (I. Sommervile, 2004).
Kebutuhan-kebutuhan berisikan beberapa pernyataan yang menjelaskan kebutuhan secara keseluruhan dari sebuah system dari customer dan/atau pemakai (user).
Dalam model waterfall, satu tahapan harus diselesaikan dahulu sebelum melanjutkan ketahapan berikutnya dan proses review diadakan di setiap akhir
14
suatu tahapan sebelum melanjutkan tahap selanjutnya. Sebagai contoh gambaran adalah ketika diawali dari analisa kebutuhan, maka kebutuhan-kebutuhan terhadap keseluruhan proyek harus dijelaskan dengan sebaik-baiknya dan ditinjau sebelum memasuki ke tahap selanjutnya yaitu design. Artinya adalah bahwa semua permintaan harus sudah jelas sebelum menyelesaikannya dan melanjutkan ke tahapan selanjutnya.
2.2.5 Scrum
Pada masa sekarang, tim-tim pengembang dihadapkan pada kesulitan dalam menghadapi perubahan yang diminta oleh customer. Selain dari perubahan kebutuhan, penerapan atau pengadopsian dari teknologi baru juga menjadi kendala jika masih menggunakan cara tradisional dari pengembangan. Tingkat kompetisi yang makin ketat dalam perkembangan pasar software yang meningkat menuntut suatu model pengembangan yang bisa mengadopsi terhadap perubahan dengan mudah. Model waterfall tidak mendukung untuk kebutuhan pasar yang demikian karena pada dasarnya model ini menjadikan kebutuhan-kebutuhan adalah sesuatu yang “beku” selama keseluruhan proses pengembangan. Dengan adanya kebutuhan pasar yang menuntut selalu adanya perubahan kebutuhan maka suatu organisasi harus memulai mengadaptasi suatu metodologi pengembangan yang dinamis, flexible terhadap perubahan yang lebih dikenal dengan proses pengembangan berbasis Agile atau Agile based development (Ken Schwaber, 2004).
Agile tidaklah membutuhkan suatu teknik yang spesifik melainkan hanyalah nama dari sebuah konsep system pengembangan software. Seperti
15
namanya yaitu Agile yaitu bergerak cepat dan tangkas, inilah ide inti dari Agile. Pendekatannya adalah untuk menghadapi perubahan kebutuhan dan permintaan pasar dan menyelesaikannya dengan efisien (Ken Schwabber, 2006).
Scrum adalah teknik pengembangan yang berbasis Agile. Kata Scrum diambil dari permainan rugby yang mana pendekatannya adalah seluruh tim berusaha untuk lari mencapai tujuan yang sama dan mengoper bola ke depan dan ke belakang akan lebih tepat menjawab kebutuhan perkembangan software jaman sekarang yang kompetitif (Ken Schwaber, 2004). Pengistilahan Scrum pertama kali dikenalkan oleh Hirotaka Takeuchi dan Ikujiro Nonaka dalam “The New Product Development Game” tahun 1986 dimana mereka mempresentasikan sebuah proses pengembangan yang cepat, adaptif dan self organizing. Kemudian Schwaber dan Beedle bekerja dan memperdalam hal tersebut dan menerbitkan kombinasi kerja mereka pada tahun 2002 dalam Scrum.
Tujuan utama Scrum adalah untuk menghasilkan suatu proses pengembangan yang fleksibel terhadap perubahan sehingga sebuah system yang efisien dapat diberikan ke konsumen tepat waktu (Ken Schwaber, 2004).
Proses pengembangan Scrum terdiri dari 3 fase,
Fase Pre Game
Fase ini melibatkan perencanaan dan sebagian besar dari design dan arsitektur dari suatu system. Daftar dari product backlog yang disajikan berisikan semua kebutuhan-kebutuhan dari proyek. Kebutuhan-kebutuhan tersebut bisa saja datang dari konsumen, departemen marketing, atau dari para tim pengembang. Kebutuhan tersebut diprioritaskan berdasarkan tingkat keurgensian dan
16
ditambahkan estimasi waktu pengerjaan dari tiap-tiap tugas dalam daftar product backlog. Daftar ini akan selalu diperbaharui di setiap akhir dari iterasi. Orang-orang yang akan terlibat dalam proyek dipilih di fase ini demikian juga dengan pemilihan tool, manajemen resiko dan pengendalian tugas-tugas telah dilakukan. Di akhir dari fase ini diadakan meeting untuk menganalisa design dan meninjaunya kembali sebelum melanjutkan ke tahapan implementasi.
Fase Development
Fase in juga dikenal dengan fase Game atau permainan. Di dalam fase ini perubahan-perubahan diharapkan muncul dan berusaha untuk mengatur semua tidak diharapkan dengan seefisien mungkin. Fase ini dilakukan dalam beberapa Sprint. Sprint dapat dipahami sebagai siklus iterasi pada kemajuan dari system yang sedang dikembangkan. Pada setiap akhir dari Sprint, harus dihasilkan sebuah system yang dapat berfungsi dengan baik.
Fase Post Game
Pada fase ini mengindikaskan sebagi titik akhir sebelum suatu system akan direlease. Dimulai ketika semua kebutuhan dalam proyek tersebut sudah diimplementasikan dan tidaka ada lagi permasalahan dalam fase ini. Tugas-tugas yang termasuk dalam fase ini adalah QA dari system, mengitegrasikan beberapa modul yang berbeda dan proses dokumentasi.
17 2.3 Peran-peran dalam Scrum
Scrum adalah sebuah proses pengembangan dari suatu produk. Tahapan dalam Scrum lebih ke arah bekerja pada keseluruhan proyek daripada merencanakan untuk membangun suatu produk dari awal. Hal in tentunya dapat dicapai dengan mengadakan kontak yang dekat dengan pelanggan. Di akhir setiap iterasi dari peningkatan produk yag telah dikerjakan akan ditinjau oleh para stakeholder. Dengan demikian maka pelanggan dapat merasakan bagaimana produk tersebut mengalami perkembangan dan dapat melakukan perubahan ataupun koreksi sepanjang proyek berlangsung. Pengujian dan proses dokumentasi diselesaikan pada tiap-tiap Sprint dan ini akan mengarahkan ke kualitas yang lebih baik pada produk akhir. Terdapat beberapa posisi atau tugas dalam Scrum yang akan dijelaskan lebih lanjut di bawah ini.
Scrum Master
Scrum Master adalah suatu peran manajerial yang bertanggung jawab untuk memfasilitasi tim pengembang dan menghilangkan semua potensi kendala yang dapat menyebabkan keterlambatan dalam pelaksanaan Sprint. Scrum Master bukanlah seorang bos melainkan hanya bertindak sebagai fasilitator antara tim proyek dan konsumen. Biasanya peran in dilakukan oleh orang yang berpengalaman di industri terkait sehingga mampu melakukan tugas –tugas dengan mulus. Scrum Master juga memainkan peran penting untuk menjaga dan memotivasi bentuk komunikasi dan kerjasama diantara anggota tim Scrum. Selain itu juga bertanggung jawab terhadap pelaksanaan aturan-aturan Scrum, contohnya dalam rapat harian Scrum anggota tim akan menyampaikan berbagai
18
permasalahan mereka yang berpotensi menghambat tugas mereka maka Scrum Master bertugas memberikan solusi terhadap permaslahan tersebut dan memfasilitasi anggota tim. Peran ini bisa disejajarkan dengan dengan seorang pemimpin dalam tim yang selalu mencari cara untuk meningkatkan performa dari anggota timnya.
Scrum Owner
Peran ini merupakan peran yang berhubungan atau berinteraksi dengan kebutuhan konsumen. Scrum owner mengurutkan prioritas dari kebutuhan konsumen dan memastikan bahwa proyek berlangsung sesuai dengan kebutuhan konsumen dan kebutuhan bisnis. Scrum Owner selalu dengan ketat mengawasi kebutuhan konsumen dan juga memastikan semua usaha yang sedang dikerjakan sudah pada jalur yang tepat. Daftar yang ada di product backlog dimaintain dan diperbaharui oleh Scrum Owner. Tidak boleh ada orang lain yang mempunyai wewenang untuk memodifikasi product backlog.
Scrum Team
Peran ini adalah peran yang sebenarnya yang bertanggung jawab terhadap aktifitas-aktifitas seperti analisa, design, implementasi dan testing. Jumlah anggota dalam satu tim dapat bervariasi dengan jumlah minimum 3 atau dapat mencapai jumlah 8 dalam satu tim.Scrum team harus bersikap mandiri dalam melaksanakan tugas sehari-hari dan sesegera menyampaikan hambatan-hambatan yang terjadi kepada Scrum Master agar tidak menyebabkan keterlambatan dalam proses pengembangan (Ken Schwaber, 2004).
19 Konsumen
Konsumen adalah orang yang sepakat terhadap tugas-tugas yang berhubungan dengan kebutuhan mereka. Mereka berhubungan erat dengan daftar dalamproduct backlog. Kepuasan konsumen adalah tujuan utama dari keseluruhan pengembangan Scrum dan mereka juga dapat berpartisipasi dalam rapat scrum dan mengambil bagian di posisi tim pengembang.
Chickens
Ini adalah istilah untuk orang yang tertarik dalam sebuah proyek tetapi mereka tidak mempunyai tanggung jawab resmi dalam Scrum. Mereka berpartisipasi dalam rapat Scrum namun tidak diperbolehkan untuk berbicara atau menginterupsi proses.
Pigs
Ini adalah istilah yang merupakan kebalikan dari chickens. Mereka adalah orang-orang yang secara resmi mempunyai tanggung jawab di dalam Scrum. Mereka adalah Scrum Master, Product Owner, atau siapapun dalam tim yang mempunyai komitmen untuk menyelesaikan pekerjaannya.
Scrum Meeting
Ada beberapa macam meeting yang dilakukan dalam Scrum untuk melaksanakan proses-prosesnya.
20 Sprint Planning Meeting
Biasanya durasi dari meeting ini dijadwalkan selam 8 jam yang dibagi menjadi 2 sesi dengan tiap sesi adalah 4 jam. Meeting ini dihadiri oleh Scrum Master, Porduct Owner, dan tim. Memungkinkan juga untuk dihadiri oleh orang-orang yang berkaitan dengan Sprint walaupun nantinya mereka tidak ambil bagian dalam pelaksanaannya. Orang-orang yang termasuk dalam istilah Chickens tidak termasuk dalam meeting ini (Ken Schwaber, 2004). Agenda pada meeting ini adalah product owner mempresentasikan product backlognya dan diadakannya sesi diskusi dan tanya jawab dengan tim yang pada akhirnya akan diputuskan bahwa product backlog sudah disepakati untuk dilaksanakan dalam Sprint. Para anggota tim menyiapkan strategi untuk mengimplementasikan item-item tersebut menjadi sesuatu yang siap kirim atau siap uji pada akhir dari Sprint nantinya (Ken Schwaber, 2004)
Daily Scrum meeting
Sesuai dengan namanya, ini adalah meeting yang dilakukan dalamproses pengembangan Scrum secara harian. Lama dari meeting ini adalah sekitar 15 menit. Meeting ini memberikan pedoman dan gambaran seberapa banyak tugas-tugas telah dicapai dan tugas selanjutnya.
Setiap peserta diharapkan untuk menjawab 3 pertanyaan dasar : 1. Seberapa banyak tugas yang telah terselesaikan kemarin? 2. Apakah target yang akan dicapai sampai besok?
3. Apakah ada hal-hal yang dapat menyebabkan keterlambatan dalam mencapai sasaran?
21
Meeting ini dibawakan oleh Scrum Master dan dilaksanakan pada pagi hari setiap hari pada waktu dan tempat yang sama.
Sprint review Meeting
Durasi dari Sprint review meeting adalah 4 jam. Meeting ini diatur untuk Product Owner dan para stakeholder untuk melihat langsung hasil dari Sprint. Mereka akan mempresentasikan secara actual dari hasil sebuah Sprint yang berfungsi dengan baik. Selam meeting, anggota tim memulai dengan item per item yang ada di Product Backlog yang sudah terselesaikan dengan baik. Juga pengalaman baik dan buruk selama proses pengembangan dapat juga dijelaskan dalam meeting. Anggota tim juga mempersilahkan pertanyaan-pertanyaan yang muncul dari Product Owner dan stakeholder.
Scrum Retrospective Meeting
Durasi dari meeting ini adalah berkisar 3 jam. Meeting ini dihadiri oleh tim, Scrum Master dan/atau Product Owner.
Beberapa pertanyaan berikut harus dijawab oleh anggota tim Apa yang telah berjalan baik pada Sprint terakhir? Apa yang perlu ditingkatkan pada Sprint selanjutnya?
Kemudian Scrum Master akan mengupulkan jawaban dari anggota Tim dan hanya mendengar jawaban dari anggota Tim.
22
2.4 Perbandingan Antara model Scrum dengan model Waterfall
Model traditional Waterfall adalah lebih berorientasi pada detail dalam kenyataannya. Sebagai contoh, semua dokumentasi harus sudah disiapkan dan memegang peran yang luar biasa penting.Semua dokumentasi ini akan digunakan dan dijaga sepanjang proses sehingga pross yang berlangsung benar-benar terencana dengan baik. Dokumen ini juga digunakan untuk implementasi yang kan datang. Para anggota tim benar-benar mengandalkan dokumen ini selama proses siklus pengembangan dan komunikasi personal mendapat prioritas rendah.
Scrum kurang begitu mengandalkan dokumen jika dibandingkan dengan model Waterfall. Scrum lebih fleksibel dan mudah beradaptasi terhadap perubahan. Pertemuan yang mempunyai frekuensi sering di antara para anggota lebih dikedepankan sebagai alternative dari semua spesifikasi dokumen. Tidak seperti kehadiran metodologi baru lainnya, Scrum sekarang ini telah diaplikasikan oleh ribuan proyek yang ada di dunia dan mereka membuktikan bahwa metode ini telah berhasil.
Pada halaman berikutnya dapat dilihat tabel 2.1 yaitu tabel perbandingan antara model Waterfall dan Scrum.
23 Tabel 2.1
Perbandingan model Waterfall dan Scrum
Waterfall (Tradisional) Ruang lingkup Scrum (Agile)
Mempunyai pengetahuan yang jelas, model ini mendorong untuk mengahsilkan artefak di hampir semua tahapan dan diselesaikan sesuai urutan
Pengetahuan Manajemen
Mempunyai pengetahuan yang cukup untuk memahami,
sebagian besar pengetahuan ada pada para programmer
Formal dan terbatas Komunikasi Informal dan sering
Daftar permintaan jelas, perubahan besar sangat tidak diharapkan, dan sistem dibangun berdasarkan perencanaan yang matang
Tipe permintaan kebutuhan
Daftar permintaan untuk keseluruhan sistem belum jelas, perubahan sangat diharapkan, perbaikan secara kontinyu dilakukan selama perancangan. Kualitas yang meningkat didapat dari feedback yang
berkelanjutan, perubahan dan testing
Proses (the life cycle model) Keterlibatan Orang ( dalam sebuah tim Scrum) Kebanyakan bersifat memerintah
dan mengontrol struktur Gaya Manajemen
Meski mempunyai seorang pemimpin yaitu Scrum Master namun lebih bersifat
kepemimpinan dan kolaborasi Karena berfokus pada proses
maka project life cycle
dihubungkan melalui daftar tugas di tiap-tiap tahapan
Project Cycle
Dibandingkan urutan dari tugas-tugas, fitur produk lebih penting dalam Scrum dan metode Agile lainnya.
Terbuka terhadap teknologi apapun tergantung dari jenis proyeknya
Teknologi Teknologi yang object oriented yang paling ideal
Peran pelanggan penting dalam setiap metodologi
pengembangan termasuk model Waterfall
Keterlibatan pelanggan
Keterlibatan pelanggan adalah yang paling penting untuk Scrum dan metodologi Agile lainnya. Scrum Owner yang akan melayani keterlibatan dan kepuasan pelanggan melalui feedback
Model Waterfall tepat digunakan pada struktur organisasi yang secara dijabarkan secara jelas dalam hirarkinya
Struktur Organisasi yang tepat
Karena sangat membutuhkan hubungan komunikasi, maka yang paling tepat adalah struktur organisasi yang fleksibel dimana mendorong dilakukannya komunikasi informal sesering mungkin
