Hai guys!!! SEPUTAR TEKNOLOGI hari ini akan berbagi info lagi. Kali ini kita akan membahas Software Development (Pengembangan Perangkat Lunak) yuk guys langsung kita simak di bawah ini.😁😁
Agile Software Development Methodology
Untuk pembuatan atau
pengembangan suatu perangkat lunak terdapat beberapa hal yang harus di
perhatikan, mulai dari sumber daya manusia (resources) yang menangani proyek
tersebut, sampai dengan metode apa yang harus diterapkan dalam proses
pengembangan perangkat lunaknya. Terdapat banyak metode dalam proses
pengembangan perangkat lunak salah satunya yaitu metode Agile Sofware Development.
Agile Software development adalah salah satu
metodelogi dalam pengembangan sebuah perangkat lunak (software). Kata Agile
berarti bersifat cepat, ringan, bebas bergerak, waspada. Kata ini digunakan
sebagai kata yang menggambarkan konsep model proses yang berbeda dari konsep
model-model proses yang sudah ada. Konsep Agile software development dicetuskan
oleh Kent Beck dan 16 rekannya dengan menyatakan bahwa Agile Software
Development adalah cara membangun software dengan melakukannya dan membantu
orang lain membangunnya sekaligus.
Dalam Agile Software Development interaksi dan personel lebih
penting dari pada proses dan alat, software yang berfungsi lebih penting
daripada dokumentasi yang lengkap, kolaborasi dengan klient lebih penting
daripada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting
daripada mengikuti rencana. Namun demikian, sama seperti model proses yang
lain, agile software development memiliki kelebihan dan tidak cocok untuk semua
jenis proyek, produk, orang dan situasi. Agile Software Development memungkinkan
model proses yang toleransi terhadap perubahan kebutuhan sehingga perubahan
dapat cepat ditanggapi. Namun di sisi lain menyebabkan produktiitas menurun.
Salah satu cirri dari Agile Software Development adalah tim yang
tanggap terhadap perubahan. Mengapa? Karena perubahan adalah hal yang utama
dalam membangun software: perubahan kebutuhan software, perubahan anggota tim,
perubahan teknologi dll. Selain itu Agile Software Development juga melihat
pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan
businessmen, anatara developer dan managernya. Cirri lain adalah klien menjadi
bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang
diterapkan oleh Agile Alliance. Menurut Agile Alliance, 12 prinsip ini adalah bagi
mereka yang ingin berhasil dalam penerapan Agile Software Development :
–
Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan
terus menerus
–
Menerima perubahan kebutuhan, sekalipun diakhir pengembangan
–
Penyerahan hasil/software dalam hitungan waktu dua minggi sampai dua bulan
–
Bagian bisnis dan pembangun kerja sama tiap hari selama proyek berlangsung
–
Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja
dalam lingkungan yang mendukung dan yang dipercaya untuk dapat menyelesaikan
proyek.
–
Komunikasi dengan berhadapan langsung adalah komunikasi yang efektis dan
efisien
–
Software yang berfungsi adalah ukuran utama dari kemajuan proyek
–
Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk
menjaga perkembangan yang berkesinambungan.
–
Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat
agile
–
Kesederhanaan penting
–
Arsitek. Kebutuhan dan desain yang bagus muncul dari tim yang mengatur dirinya
sendiri
–
Secara periodic tim evaluasi diri dan mencari cara untuk lebih efektif dan
segera melakukannya.
Kedua belas
prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat
agile. Dengan prinsip-prinsip tersebut agile process model berusaha untuk
menyiasati 3 asumsi penting tentang proyek software pada umumnya :
–
Kebutuhann software sulit diprediksi dari awal dan selalu akan berubah. Selain
itu, prioritas klien juga sering berjalannya proyek.
–
Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh
desain yang diperlukan sebelum pembangunan
–
Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang
diinginkan.
Beberapa
jenis proses peomodelan yang termasuk kedalam metode Agile Software Development
: Extreme Programming (XP), Adaptif Software Development (ASD), Dynamic System
Development Method (DSDM), Scrum, Crystal, Feature Driven Development (FDD),
Agile Modeling (AM).
Rapid Application Development
Rapid Application Development (RAD)
adalah strategi siklus hidup yang ditujukan untuk menyediakan pengembangan yang
jauh lebih cepat dan mendapatkan hasil dengan kualitas yang lebih baik
dibandingkan dengan hasil yang dicapai melalui siklus tradisional (McLeod,
2002). RAD merupakan gabungan dari bermacam-macam teknik terstruktur
dengan teknik prototyping dan teknik
pengembangan joint application untuk
mempercepat pengembangan sistem/aplikasi (Bentley, 2004). Dari
definisi-definisi konsep RAD ini, dapat dilihat bahwa pengembangan aplikasi
dengan menggunakan metode RAD ini dapat dilakukan dalam waktu yang relatif lebih
cepat.
Pemaparan konsep yang lebih spesifik lagi dijelaskan
oleh Pressman (2005) dalam bukunya, “Software Engineering: A
Practition’s Approach”. Ia mengatakan bahwa RAD adalah proses model
perangkat lunak inkremental yang menekankan siklus pengembangan yang singkat.
Model RAD adalah sebuah adaptasi “kecepatan tinggi” dari model waterfall, di mana perkembangan pesat dicapai dengan
menggunakan pendekatan konstruksi berbasis komponen. Jika tiap-tiap kebutuhan
dan batasan ruang lingkup projek telah diketahui dengan baik, proses RAD
memungkinkan tim pengembang untuk menciptakan sebuah “sistem yang berfungsi
penuh” dalam jangka waktu yang sangat singkat. Dari penjelasan Pressman (2012)
ini, satu perhatian khusus mengenai metodologi RAD dapat diketahui, yakni implementasi
metode RAD akan berjalan maksimal jika pengembang aplikasi telah merumuskan
kebutuhan dan ruang lingkup pengembangan aplikasi dengan baik.
Sedangkan
menurut Kendall (2010), RAD adalah suatu pendekatan berorientasi objek terhadap
pengembangan sistem yang mencakup suatu metode pengembangan serta
perangkat-perangkat lunak. RAD bertujuan mempersingkat waktu yang biasanya
diperlukan dalam siklus hidup pengembangan sistem tradisional antara
perancangan dan penerapan suatu sistem informasi. Pada akhirnya, RAD sama-sama
berusaha memenuhi syarat-syarat bisnis yang berubah secara cepat.
Fase
dan Tahapan Pengembangan Aplikasi
Menurut Kendall (2010), terdapat tiga fase dalam RAD
yang melibatkan penganalisis dan pengguna dalam tahap penilaian, perancangan,
dan penerapan. Adapun ketiga fase tersebut adalah requirements planning (perencanaan
syarat-syarat), RAD design
workshop (workshop desain
RAD), dan implementation (implementasi).
Sesuai dengan metodologi RAD menurut Kendall (2010), berikut ini adalah
tahap-tahap pengembangan aplikasi dari tiap-tiap fase pengembangan aplikasi.
1) Requirements Planning (Perencanaan Syarat-Syarat)
Dalam fase ini, pengguna dan
penganalisis bertemu untuk mengidentifikasikan tujuan-tujuan aplikasi atau
sistem serta untuk megidentifikasikan syarat-syarat informasi yang ditimbulkan
dari tujuan-tujuan tersebut. Orientasi dalam fase ini adalah menyelesaikan
masalah-masalah perusahaan. Meskipun teknologi informasi dan sistem bisa
mengarahkan sebagian dari sistem yang diajukan, fokusnya akan selalu tetap pada
upaya pencapaian tujuan-tujuan perusahaan (Kendall, 2010).
2) RAD Design Workshop (Workshop Desain
RAD)
Fase
ini adalah fase untuk merancang dan memperbaiki yang bisa digambarkan
sebagai workshop. Penganalisis dan dan pemrogram dapat bekerja
membangun dan menunjukkan representasi visual desain dan pola kerja kepada
pengguna. Workshop desain ini dapat
dilakukan selama beberapa hari tergantung dari ukuran aplikasi yang akan
dikembangkan. Selama workshop desain
RAD, pengguna merespon prototipe yang ada dan penganalisis memperbaiki
modul-modul yang dirancang berdasarkan respon pengguna. Apabila sorang
pengembangnya merupakan pengembang atau pengguna yang berpengalaman, Kendall
menilai bahwa usaha kreatif ini dapat mendorong pengembangan sampai pada
tingkat terakselerasi (Kendall, 2010).
3) Implementation (Implementasi)
Pada
fase implementasi ini, penganalisis bekerja dengan para pengguna secara intens
selama workshop dan merancang aspek-aspek bisnis dan
nonteknis perusahaan. Segera setelah aspek-aspek ini disetujui dan
sistem-sistem dibangun dan disaring, sistem-sistem baru atau bagian dari sistem
diujicoba dan kemudian diperkenalkan kepada organisasi (Kendall, 2010).
Kelebihan
dan Kekurangan RAD
Metode
pengembangan sistem RAD relatif lebih sesuai dengan rencana pengembangan
aplikasi yang tidak memiliki ruang lingkup yang besar dan akan dikembangkan
oleh tim yang kecil. Namun, RAD pun memiliki kelebihan dan kekurangannya
sebagai sebuah metodoligi pengembangan aplikasi. Berikut ini adalah kelebihan
metodologi RAD menurut Marakas (2006):
1. Penghematan waktu dalam keseluruhan fase projek dapat
dicapai.
2. RAD mengurangi seluruh kebutuhan yang berkaitan
dengan biaya projek dan sumberdaya manusia.
3. RAD sangat membantu pengembangan aplikasi yang
berfokus pada waktu penyelesaian projek.
4. Perubahan desain sistem dapat lebih berpengaruh
dengan cepat dibandingkan dengan pendekatan SDLC tradisional.
5. Sudut pandang user disajikan dalam sistem akhir baik
melalui fungsi-fungsi sistem atau antarmuka pengguna.
6. RAD menciptakan rasa kepemilikan yang kuat di antara
seluruh pemangku kebijakan projek.
Sedangkan,
mengacu pada pendapat Kendall (2010), maka dapat diketahui bahwa kekurangan
penerapan metode RAD adalah sebagai berikut:
1. Dengan metode RAD, penganalisis berusaha mepercepat
projek dengan terburu-buru.
2. Kelemahan yang berkaitan dengan waktu dan perhatian
terhadap detail. Aplikasi dapat diselesaikan secara lebih cepat, tetapi tidak
mampu mengarahkan penekanan terhadap permasalahan-permasalahan perusahaan yang
seharusnya diarahkan.
3. RAD menyulitkan programmer yang
tidak berpengalaman menggunakan prangkat ini di mana programmer dan analyst dituntut
untuk menguasai kemampuan-kemampuan baru sementara pada saat yang sama mereka
harus bekerja mengembangkan sistem.
b
Dynamic System Development Model Methodology
Metode Pengembangan Sistem Dinamis (DSDM) mengasumsikan
bahwa semua langkah sebelumnya dapat ditinjau kembali sebagai bagian dari
pendekatan iteratifnya. Karena itu, langkah saat ini perlu diselesaikan
hanya cukup untuk pindah ke langkah selanjutnya, karena bisa selesai di iterasi
selanjutnya. Premis ini adalah bahwa persyaratan bisnis mungkin akan
berubah pula karena pemahaman meningkat, jadi pekerjaan lebih lanjut pasti akan
sia-sia.
Menurut pendekatan ini, waktu dianggap sebagai kendala,
yaitu waktu tetap, sumber daya tetap sementara persyaratan diizinkan untuk
berubah. Ini tidak mengikuti asumsi mendasar untuk membuat sistem yang
sempurna untuk pertama kalinya, namun memberikan 80% sistem yang diinginkan dan
berguna dalam 20% dari total waktu pengembangan. Pendekatan ini terbukti
sangat berguna dalam batasan waktu dan berbagai persyaratan.
Sekarang mari kita lihat semua
langkah DSDM secara singkat
1-Studi
Kelayakan
Selama tahap proyek ini, kelayakan proyek untuk
penggunaan DSDM diperiksa.Prasyarat untuk penggunaan DSDM ditangani dengan menjawab
pertanyaan seperti: 'Dapatkah proyek ini memenuhi kebutuhan bisnis yang
dibutuhkan?', 'Apakah proyek ini sesuai untuk penggunaan DSDM?' dan 'Apa
saja risiko terpenting yang terlibat?'. Teknik yang paling penting yang
digunakan dalam fase ini adalah Lokakarya .
Kiriman untuk
tahap ini adalah Laporan Kelayakan dan Prototipe Kelayakan yang membahas
kelayakan proyek yang sedang ditangani. Ini diperluas dengan Rencana Garis
Besar Global untuk keseluruhan proyek dan Log Risiko yang mengidentifikasi
risiko terpenting proyek.
Studi Bisnis
Studi bisnis memperluas studi kelayakan . Setelah
proyek dianggap layak untuk penggunaan DSDM, tahap ini menguji proses bisnis
yang dipengaruhi, kelompok pengguna yang terlibat dan kebutuhan dan keinginan
masing-masing. Sekali lagi lokakarya adalah salah satu teknik yang paling berharga,
lokakarya di mana berbagai pemangku kepentingan berkumpul
untuk mendiskusikan sistem yang diusulkan. Informasi dari sesi ini
digabungkan ke dalam daftar persyaratan . Properti
penting dari daftar persyaratan adalah fakta bahwa persyaratannya (dapat diprioritaskan ) . Persyaratan
ini diprioritaskan dengan menggunakan pendekatan MoSCoW . Berdasarkan prioritisasi ini, sebuah
rencana pembangunan dibangun sebagai pedoman untuk sisa proyek.
Teknik proyek penting yang digunakan dalam pengembangan
rencana ini adalah timeboxing . Teknik ini sangat
penting dalam mewujudkan tujuan DSDM, yaitu tepat waktu dan sesuai anggaran,
menjamin kualitas yang diinginkan. Arsitektur sistem adalah
bantuan lain untuk memandu pengembangan IS. Kiriman untuk tahap ini adalah
definisi area bisnis yang menggambarkan konteks proyek di dalam perusahaan,
definisi arsitektur sistem yang menyediakan arsitektur global awal IS yang
sedang dikembangkan bersama dengan rencana pengembangan yang menguraikan
langkah terpenting dalam proses pembangunan. Di dasar dua dokumen terakhir
ini ada daftar persyaratan yang diprioritaskan. Daftar ini menyatakan
semua persyaratan untuk sistem, diatur menurut prinsip MoSCoW .Dan terakhir Log Risiko diperbarui dengan
fakta-fakta yang telah diidentifikasi selama fase DSDM ini.
Iterasi Model
Fungsional
Persyaratan yang telah diidentifikasi pada tahap
sebelumnya diubah menjadi model fungsional. Model ini terdiri dari
prototipe dan model yang berfungsi. Prototyping adalah salah satu teknik
proyek utama dalam tahap ini yang membantu mewujudkan keterlibatan pengguna
yang baik selama proyek berlangsung.Prototipe yang dikembangkan ditinjau oleh
kelompok pengguna yang berbeda.Untuk memastikan kualitas, pengujian
diimplementasikan pada setiap iterasi DSDM. Bagian penting dari pengujian
direalisasikan dalam Functional Model Iteration. Model Fungsional dapat
dibagi menjadi empat sub tahap:
·
Identifikasi Prototipe Fungsional: Tentukan fungsi yang
akan diimplementasikan pada prototipe yang dihasilkan dari iterasi ini.
·
Setuju Jadwal: Setuju bagaimana dan kapan mengembangkan
fungsionalitas ini.
·
Buat Prototipe Fungsional: Kembangkan prototipenya. Selidiki,
perbaiki, dan konsolidasikan dengan gabungan prototipe Fungsional dari iterasi
sebelumnya.
·
Tinjau Prototipe: Periksa kebenaran prototipe yang
dikembangkan. Hal ini dapat dilakukan melalui pengujian oleh pengguna
akhir, kemudian menggunakan catatan uji dan masukan pengguna untuk menghasilkan
dokumen tinjauan prototip fungsional.
Kiriman untuk
tahap ini adalah Model Fungsional dan Prototipe Fungsional yang bersama-sama
mewakili fungsi yang dapat direalisasikan dalam iterasi ini, siap untuk diuji
oleh pengguna. Di samping ini, Daftar Persyaratan diperbarui, menghapus
item yang telah direalisasikan dan memikirkan ulang prioritas persyaratan yang
tersisa. Log Risiko juga diperbarui dengan analisis risiko pengembangan
lebih lanjut setelah meninjau dokumen prototyping.
Desain dan
Build Iterasi
Fokus utama iterasi DSDM ini adalah mengintegrasikan
komponen fungsional dari fase sebelumnya ke dalam satu sistem yang memenuhi
kebutuhan pengguna. Ini juga membahas persyaratan non-fungsional yang
telah ditetapkan untuk IS. Sekali lagi pengujian merupakan kegiatan berkelanjutan yang penting
dalam tahap ini.Iterasi Desain dan Bangun dapat dibagi menjadi empat sub tahap:
·
Identifikasi Prototipe Desain: Identifikasi persyaratan
fungsional dan non-fungsional yang perlu dilakukan dalam sistem yang diuji.
·
Setuju Jadwal: Setuju bagaimana dan kapan harus
mewujudkan persyaratan ini.
·
Buat Desain Prototipe: Buat sistem yang bisa dengan aman
diserahkan ke pengguna akhir untuk pemakaian sehari-hari. Mereka
menyelidiki, memperbaiki, dan mengkonsolidasikan prototipe iterasi saat ini
dalam proses prototipe juga penting di sub-tahap ini.
·
Review Design Prototype: Periksa kebenaran sistem yang
dirancang. Sekali lagi pengujian dan pengkajian adalah teknik utama yang
digunakan, karena catatan pengujian dan masukan pengguna penting untuk
menghasilkan dokumentasi pengguna.
Kiriman untuk
tahap ini adalah Prototipe Desain selama fase yang dapat diuji pengguna akhir
dan pada akhir Design and Build Iteration, Sistem yang Teruji diserahkan ke
tahap berikutnya. Pada tahap ini, sistem ini terutama dibangun dimana
disain dan fungsinya dikonsolidasikan dan diintegrasikan dalam
prototipe.Penyampaian lainnya untuk tahap ini adalah User Documentation.
Pelaksanaan
Pada tahap Implementasi, sistem yang diuji termasuk dokumentasi
pengguna disampaikan kepada pengguna dan pelatihan pengguna masa depan
terwujud.Sistem yang akan dikirim telah ditinjau untuk memasukkan persyaratan
yang telah ditetapkan pada tahap awal proyek. Tahap implementasi dapat
dibagi menjadi empat sub tahap:
·
Persetujuan dan Pedoman Pengguna: Pengguna akhir
menyetujui sistem teruji untuk implementasi dan pedoman sehubungan dengan
penerapan dan penggunaan sistem yang dibuat.
·
Pengguna Kereta Api: Latihlah pengguna akhir masa depan
dalam penggunaan sistem.
·
Terapkan: Terapkan sistem yang teruji di lokasi pengguna
akhir.
·
Tinjau Bisnis: Tinjau kembali dampak sistem yang
diterapkan pada bisnis, sebuah isu utama adalah apakah sistem tersebut memenuhi
sasaran yang ditetapkan pada awal proyek. Bergantung pada proyek ini
berlanjut ke fase berikutnya, proyek pasca atau loop kembali ke tahap
berikutnya
Peran di DSDM
Ada beberapa peran yang diperkenalkan di lingkungan DSDM. Adalah
penting bahwa anggota proyek perlu diangkat ke peran yang berbeda sebelum
mereka memulai menjalankan proyek. Setiap peran memiliki tanggung jawab
tersendiri. Perannya adalah:
·
Executive Sponsor Jadi disebut "Project
Champion". Peran penting dari organisasi pengguna yang memiliki
kemampuan dan tanggung jawab untuk melakukan dana dan sumber daya yang tepat. Peran
ini memiliki kekuatan tertinggi untuk membuat keputusan.
·
Visioner Orang yang memiliki tanggung jawab untuk
menginisiasi proyek dengan memastikan bahwa persyaratan penting ditemukan sejak
dini.Visioner memiliki persepsi yang paling akurat mengenai tujuan bisnis
sistem dan proyek. Tugas lainnya adalah mengawasi dan menjaga proses
pembangunan di jalur yang benar.
·
Duta Besar Pengguna Membawa pengetahuan tentang
komunitas pengguna ke dalam proyek, memastikan pengembang cukup menerima
masukan pengguna selama proses pengembangan.
·
Penasihat Pengguna Dapat menjadi pengguna yang
mewakili sudut pandang penting dan membawa pengetahuan sehari-hari proyek.
Extreme Programing Methodology
Extreme Programming (berikutnya akan disingkat
sebagai XP) adalah sebuah pendekatan atau model pengembangan
perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses
pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. XP bukan
hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat
lunak. XP mengambil pendekatan ‘ekstrim’ dalam iterative development.
XP Pertama kali diusulkan oleh Kent Beck dan Ward
Cunningham pada bulan Maret 1996, asal mula XP digunakan karena pada saat itu
permintaan dari customer yang sering berubah dengan cepat sehingga mengakibatkan
putaran kehidupan metode pengembangan perangkat lunak tradisional menjadi lebih
pendek dan tidak selaras dengan metode tradisional karena pada umumnya
memerlukan desain yang luas dan itu mengakibatkan perubahan desain yang terjadi
dan tentu saja memerlukan biaya yang lebih tinggi. Tujuan XP adalah
meminimalisir biaya yang diperlukan jika ada perubahan dalam pengembangan
perangkat lunak.
ASPEK
DASAR XP TERDIRI DARI BERBAGAI TEKNIK ATAU METODE YANG DITERAPKAN BECK DAN
JEFFRIES PADA C3 PROJECT. TEKNIK-TEKNIK TERSEBUT ANTARA LAIN:
·
Whole
Team
Seluruh
kontributor dalam proyek yang menggunakan pendekatan XP duduk bersama sebagai
suatu tim. Tim ini terdiri beberapa peran, antara lain programmer,
penguji,orang yang mengerti bisnis, analis, manajer, dan lain-lain. Setiap
peran yang ada tidak mutlak menjadi peran dari satu orang saja. Tim terbaik
dalam XP tidak harus memiliki pakar, hanya kontributor umum dengan keterampilan
khusus saja. Semua orang di tim XP memberikan kontribusi dengan cara apapun
yang mereka dapat lakukan.
·
Planning
game
Perencanaan
dalam XP mengemukakan dua pertanyaan kunci dalam pengembangan perangkat lunak,
yaitu memprediksi apa yang akan dicapai pada waktu tertentu, dan
menentukan apa yang harus dilakukan setelah itu. Ada dua langkah kunci dalam
perencanaan XP, yang menangani dua pertanyaan tersebut:
2.
Release
Planning yaitu praktek dimana Customer mengutarakan fitur yang diinginkannya ke
programer, dan programer memperkirakan tingkat kesulitannya. Dengan estimasi
biaya di tangan, dan dengan pengetahuan tentang pentingnya fitur yang
diinginkan, Pelanggan meletakkan satu rencana untuk proyek tersebut. Rencana
rilis awal yang selalu tepat: baik prioritas maupun perkiraan yang benar-benar
solid, dan sampai tim mulai bekerja, kita tidak akan tahu seberapa cepat mereka
akan pergi. Bahkan rencana rilis pertama cukup akurat untuk pengambilan
keputusan, namun, dan tim XP melakukan revisi terhadap rencana rilis secara
teratur.2. Iteration Planning adalah praktek di mana tim diberikan petunjuk
atau arahan setiap beberapa minggu sekali. Tim XP membangun perangkat lunak
dalam “iterasi” dua minggu, memberikan menjalankan perangkat lunak yang berguna
pada setiap akhir iterasi. Selama Iteration Planning, Customer mengutarakan
fitur yang diinginkan selama dua minggu ke depan. Para programer memecahnya ke
dalam pekerjaan yang lebih kecil, dan memperkirakan biaya yang diperlukan.
o Customer TestsSebagai bagian dari presentasi
masing-masing fitur yang diinginkan, Customer XP mendefinisikan satu atau lebih
tes penerimaan otomatis untuk menunjukkan bahwa fitur tersebut bekerja
dengan baik. Tim membangun tes ini dan menggunakannya untuk membuktikan pada
kepada Customer bahwa fitur ini telah diimplementasikan dengan benar. Tes
secara otomatis ini penting karena dalam XP hanya diberikan waktu yang singkat
sehingga tes manual tidak akan digunakan karena memakan waktu yang lama.
o Small Release
Pada
setiap Iterasi, tim mengerjakan sebuah unit atau bagian dari perangkat lunak,
melakukan tes terhadap unit perangkat lunak yang dibangun, kemudian di akhir
iterasi perangkat lunak yang dibangun diberikan kepada Customer. Oleh customer,
perangkat lunak ini bisa dijadikan bahan evaluasi maupun langsung dirilis
kepada end user. Bisa juga tim XP langsung merilis ke end user secara rutin.
o Simple Design
Tim XP
membangun perangkat lunak dengan desain yang sederhana. Dimulai dengan desain
yang sederhana, kemudian melalui pengujian program dan perbaikan desain. Desain
yang dibuat harus benar-benar cocok untuk fungsi saat ini dari sistem sehingga
tidak ada yang sia-sia dan perangkat lunak siap dikembangkan lagi selanjutnya.
Namun, pembuatan desain dalam XP tidak dilakukan hanya sekali. Tahapan desain
dalam Extreme Programming yang menghasilkan desain yang bagus dianggap sangat
penting, sehingga selama proses development banyak difokuskan ke tahapan
desain.
o Pair Programming
Semua
perangkat lunak yang dibangun dengan pendekatan XP dibangun oleh dua orang
programmer. Keduanya duduk berdampingan di satu komputer yang sama. Seorang
programmer akan membuat code dan programmer yang lainnya akan mengoreksinya.
Praktik seperti ini mungkin kelihatan tidak efisien. Namun dari segi hasil dari
pair programming, desain akan lebih baik, pengujian lebih baik, dan code yang
dihasilkan pun akan lebih baik.
o Test-Driven Development
XP
begitu terobsesi dengan umpan balik, dan dalam pengembangan perangkat lunak,
umpan balik yang baik mensyaratkan pengujian yang baik pula. Test-Driven
Development bergantung pada pengulangan siklus development yang sangat pendek.
Pertama tim XP akan menuliskan automated test case yang mendefinisikan
perbaikan yang diinginkan atau fungsi baru. Kemudian dari test case tersebut
dihasilkan jumlah minimal code yang harus dituliskan untuk lulus tes tersebut.
Setelah itu melakukan refactoring code baru agar memenuhi standar baru.
o Design Improvement
XP
berfokus pada memberikan nilai bisnis dalam setiap perulangan. Agar dapat
mencapai tujuan tersebut selama proyek berlangsung, perangkat lunak harus
dirancang dengan baik. XP menggunakan proses perbaikan desain secara terus
menerus dengan Refactoring. Proses refactoring berfokus pada penghapusan
duplikasi dari code yang telah dibuat. Disamping itu, proses refactoring
didukung dengan pengujian yang komprehensif utnuk memastikan bahwa desain yang
dibuat berkembang dan tiidak ada yang rusak.
o Continuous Integration
Beberapa
kali dalam sehari, tim XP akan menggabungkan seluruh salinan pekerjaan tim
menjadi satu dalam jaringan utama. Sehingga tim XP harus menjaga tim agar
terintegrasi setiap saat.
o Collective Code Ownership
Pada
proyek XP, setiap pasang programmer dapat meningkatkan code apapun setiap saat.
Semua code yang ada dimiliki secara kolektif oleh tim. Manfaatnya setiap code
akan mendapat perhatian dari banyak orang, sehingga dapat meningkatkan kualitas
code dan mengurangi cacat. Selain itu dapat mengurangi duplikasi code yang sama
walaupun dibuat oleh pasangan programmer yang berbeda.
o Coding Standard
Setiap
anggota tim XP harus mengikuti standar coding yang umum, sehingga semua code
dalam sistem seolah-olah tampak dibuat oleh satu orang yang sangat kompeten.
Selain itu hal ini sangat mendukung Collective Code Ownership.
o Metaphor
Tim XP
akan membuat suatu deskripsi umum bagaimana program yang mereka kembangkan
bekerja dengan benar.
o Sustainable Pace
Tim XP
akan bekerjasama dalam jangka waktu lama. Mereka bekerja keras dengan kecepatan
tertentu tanpa batas waktu. Tim XP akan bekerja lembur pada hari efektif dan
memaksimalkan produktivitas setiap minggunya. Hal ini perlu diperhatikan
dengan baik, karena akan mengurangi produktivitas atau sebaliknya menghasilkan
perangkat lunak yang berkualitas.
Scrum
Development Methodology
Scrum
adalah sebuah kerangka kerja untuk pengembangan secara inkremental dengan
menggunakan satu atau lebih tim yang cross-functional dan self-organizing yang terdiri
dari kurang lebih tujuh orang pada tiap-tiap tim. Scrum menggunakan iterasi
tetap bernama Sprint, yang dijalankan dalam waktu dua minggu atau tiga puluh
hari. Tim Scrum berusaha untuk membangun inkremen produk (perangkat lunak) yang
siap digunakan dan telah diuji pada setiap proses iterasi ini. (James, 2012)
Peran
Dalam Scrum
Menurut Michael James (2012),
dalam proses pengembangan sebuah perangkat lunak menggunakan metode Scrum,
teradapat beberapa aktor penting, di antaranya:
1. Product Owner. Orang ini bertugas untuk
menentukan Product Backlog dan menentukan prioritas fitur yang akan disajikan
pada perangkat lunak. Ia juga berhak untuk menerima atau menolak setiap hasil
yang telah dikembangkan pada tiap iterasi.
2. Tim Pengembangan Scrum. Tim yang beranggotakan
antara 7-9 orang ini bersifat cross-functional, yaitu tim yang berisi
orang-orang dengan kemampuan dan perang yang berbeda, misalnya terdiri dari
tester, developer, business analyst, domain expert, dan lain-lain. Tim ini
mendiskusikan kepada Product Owner mengenai tiap-tiap Sprint yang akan
dijalankan.
3. Scrum Master. Orang ini secara
tradisional disebut sebagai Project Mabager dan bertugas untuk mengawasi
keseluruhan proses Scrum, membantu mengatasi halangan yang dihadapi selama
proses tersebut, menciptakan suasana yang kondusif bagi tim pengembang, dan
melindungi tim dari gangguan eksternal sehingga tim dapat bekerja dengan baik
pada zonanya. Akan tetapi, Scrum Master tidak memiliki otoritas untuk mengatur
tim. Orang yang memiliki otoritas untuk mengatur tim ditentukan oleh tim
tersebut.
Perangkat-perangkat
Scrum
Penjelasan berikut ini merupakan
hasil kolaborasi antara apa yang dikemukakan Michael James (2012) dan Hamid
Shojaee (2012) mengenai beberapa perangkat yang digunakan dalam sebuah pengembangan
menggunakan metode Scrum ini, di antaranya:
1. Product Backlog. Product Backlog berisi
kumpulan User Story yang akan menentukan fitur-fitur yang akan dibuat pada
perangkat lunak. Kumpulan User Strory ini kemudian dibuat skala prioritasnya
oleh Product Owner.
2. Product Backlog Item (PBI). PBI atau secara tradisional
dikenal sebagai User Story ini secara tertulis kurang lebih berisi mengenai
“Sebagai seorang (nama peran), saya menginginkan (nama fitur), sehingga dapat
berguna untuk (keuntungan fitur)”.
3. Sprint Backlog. Sebuah Sprint berisi
beberapa PBI yang telah diprioritaskan dalam rapat antara Product Owner dan Tim
Pengembang. Sprint merupakan milestone dalam pengembangan produk yang akan
berlangsung hingga maksimal tiga puluh hari, tidak boleh lebih. Pada akhir
tiap-tiap Sprint harus menghasilkan shipped product (produk yang siap
digunakan). Oleh sebab itu, pada Sprint pertama, pastikan semua fitur dasar dan
utama yang telah diprioritaskan dimasukkan ke dalam Sprint ini. Dengan kata
lain, setelah Sprint 1, perangkat lunak / aplikasi / produk dasar telah siap
digunakan. Adapun pelengkapan fitur-fitur pelengkap atau lainnya pada produk
dengan tingkatan prioritas yang lebih rendah dapat dikembangkan pada Sprint 2
dan seterusnya.
4. Burndown Chart. Burndown chart digunakan
untuk mengawasi setiap fase perkembangan Sprint agar berjalan mulus dan tidak
melebihi tenggat waktu yang telah ditentukan. Chart ini menampilkan pengukuran
harian terhadap jumlah dan sisa pekerjaan hingga produk siap dirilis. Dengan
demikian tim dapat membuat perkiraan mengenai kapan sebuah Sprint atau sebuah shipped
product akan selesai, sehingga apabila diperkirakan akan melebihi batas waktu,
tim dapat melakukan penyesuaian dengan meningkatkan waktu/jam kerja mereka tiap
harinya.
5. Daily Scrum. Perangkat ini merupakan
sarana komunikasi yang sangat penting bagi seluruh anggota tim Scrum. Daily
Scrum juga sering disebut stand-up meeting karena akan berlangsung sangat
singkat, yaitu kurang lebih lima belas menit. Secara teknis, Daily Scrum
merupakan rapat singkat harian di mana seluruh anggota tim bertemu dan hanya mengemukakan
tiga hal utama, yaitu “apa yang telah saya lakukan kemarin”, “masalah yang saya
hadapi/telah diselesaikan”, dan “apa yang akan/sudah saya selesaikan hari ini”.
Sedangkan Scrum Master hanya akan membuka rapat, mencatat, mengawasi, dan
memfailitasi diskusi untuk menyelesaikan beberapa permasalahan yang dihadapi
tim.
6. Sprint Retrospective Meeting. Rapat
ini dilakukan oleh seluruh tim saat setiap Sprint selesai dijalankan dan
shipped product dihasilkan. Dalam rapat ini, tim akan mengevaluasi mana saja
yang telah berjalan baik dalam proses, dan mana saja yang masih membutuhkan
perubahan/perbaikan/improvement.
Demikianlah sedikit penjelasan
mengenai Scrum. Lebih lanjut dan lebih lengkap untuk mengetahui Metodologi
Scrum, dapat diakses melalui link-link yang menjadi sumber penulisan.
