Week #4 - Rekayasa Perangkat Lunak

METODE
AGILE
Week #4 - Metode Agile

Outline
• Konsep Agile
• Metode Agile
• XP
• Scrum
• Tugas
Week #4 - Metode Agile

Apa itu "Agility"

• Respon efektif (rapid dan adaptif ) terhadap perubahan
• Komunikasi efektif diantara seluruh pemangku kepentingan
• Mengelola sebuah tim sehingga semua pekerjaan terkontrol

Agile diartikan sebagai

"quickness, lightness, and ease of movement"
Week #4 - Metode Agile

Metode Pengembangan
Agile
Agile Software Development adalah sekumpulan metodologi
pengembangan PL yang berbasis pada pengembangan iteratif,
dimana persyaratan dan solusi berkembang melalui kolaborasi antar
tim yang terorganisir (Pressman, 2010)

Metode Agile merupakan metode pengembangan

inkremental yang fokus pada perkembangan yang
cepat, perangkat lunak yang dirilis bertahap dan
menghasilkan kode berkualitas tinggi, serta pada proses
perkembangan melibatkan pelanggan secara langsung
(Sommerville, 2011)
AGILE MANIFESTO - 1

Individuals and
interactions
• Contoh dalam Pengembangan Game yang
membutuhkan pengembang dari berbagai ilmu
disiplin berbeda, misalnya:

over processes ⚬ Animator

⚬ Perancang
⚬ Texture Artist

and tool ⚬ Programmers

⚬ Audio Composer

• Individu adalah aset yang terbesar

• Individual adalah sesuatu yang kreatif dan memerlukan space
• Kerja sama dan kolaborasi lebih penting daripada pemain "bintang"
AGILE MANIFESTO - 2

Working
software over
• Software pada dasarnya adalah
dokumentasi
• Dokumentasi terkadang
comprehensive menyimpang
• Dokumentasi harus jelas singkat
documentation dan dapat dicode

Martin's First Law of Documentation:

Produce no document unless its need is immediate and significant
AGILE MANIFESTO - 3

Customer
Collaboration
• Customer adalah bagian dari tim
• Manager adalah customer
• Pahami apa yang mereka butuhkan, dan
over Contract berikan apa yang mereka butuhkan
• Buat pelanggan sebagai bagian dari

Negotiation proses
• Mengandalkan umpan balik
AGILE MANIFESTO - 4

Responding
to change • Siap terhadap adanya perubahan
• Bersifat adaptif

over • Jangan takut untuk merubah

sesuatu

following a • Evaluasi perubahan dalam konteks

saat ini

plan • Pastikan ada kemajuan

Week #4 - RPL

AGILE

Individuals &
Interactions Processes &
Tools

Working
Software Comprehensive
Documentation

Customer
Collaboration Contract
Negotiation

Responding
to change Following a
plan
Prinsip Agile

Customer
Involvement

Incremental
Delivery

People not
Process
Prinsip Agile - 2

Embrace Change

Maintain
simplicity
Weel #4 - Rekayasa Perangkat Lunak

Tahapan dalam Metodologi Agile

 Weel #4 - Rekayasa Perangkat Lunak

Tahapan dalam Metodologi Agile

1 - Plan
Pada langkah ini, tim pengembang dan klien membuat
1 - Planning
rencana tentang kebutuhan dari perangkat lunak yang
(Perencanaan)
akan dibuat
2 - Design 3 - Develop
Merancang produk yang Merupakan bagian dari proses
akan
3 -dibuat
Develop dimana
4 - Testprogrammer melakukan
pengkodean perangkat lunak

4 - Test 5 - Release 6 - Feedback

Tahapan selanjutnya Setelah diuji, selanjutnya Tahap Agile melibatkan klien dalam
adalah menguji hasil sistem atau perangkat hal feedback
pengkodean lunak akan dirilis
Beberapa variasi Metodologi Agile

AGILE AGILE UNIFIED EXTREME

MODELING PROCESS (AUP) PROGRAMMING

FEATURE DRIVEN OPEN UNIFIED

DEVELOPMENT PROCESS
(FDD) (OPENUP)

SCRUM VELOCITY TRACKING

 EXTREME
PROGRAMMING
(XP)
Week #4 - RPL

Extreme Programming (XP)

• XP merupakan salah satu metode agile yang terkenal dan banyak digunakan
• XP dikenalkan oleh Beck (2000) karena pendekatannya dikembangkan dengan
mendorong praktik baik yang diakui, seperti pengembangan berulang, ke tingkat
'ekstrim'. Misalnya, di XP, beberapa versi baru dari suatu sistem dapat dikembangkan
oleh pemrogram yang berbeda, terintegrasi dan diuji dalam satu hari
Week #4 - RPL

Prinsip Metode Agile yang direfleksikan oleh XP

• Pengembangan bertahap didukung melalui rilis sistem yang kecil dan sering.
• Keterlibatan pelanggan didukung melalui keterlibatan berkelanjutan pelanggan dalam
tim pengembangan.
• Orang, bukan proses, didukung melalui pemrograman berpasangan, kepemilikan
kolektif atas kode sistem, dan proses pembangunan berkelanjutan yang tidak
melibatkan jam kerja yang terlalu panjang.
• Perubahan dianut melalui rilis sistem reguler kepada pelanggan, pengembangan uji-
pertama, refactoring untuk menghindari degenerasi kode, dan integrasi berkelanjutan
dari fungsionalitas baru
• Mempertahankan kesederhanaan didukung oleh pemfaktoran ulang konstan yang
meningkatkan kualitas kode dan dengan menggunakan desain sederhana yang tidak
perlu mengantisipasi perubahan sistem di masa mendatang.
Week #4 - RPL

1 - 'Story Card'
• Merupakan bagian dari XP
yang dibangun bersama
antara tim pengembang
dan pelanggan sistem.
• Story Card bertujuan
untuk mengenkapsulasi
kebutuhan pelanggan
• Tim Pengembang
kemudian bertujuan
untuk
mengimplementasikan
skenario tersebut dalam
filis software masa depan.
Contoh Story Card - Resep Obat
Kate adalah seorang dokter yang ingin meresepkan obat
untuk pasien yang datang ke klinik. Catatan pasien
sudah ditampilkan di komputernya sehingga dia
mengklik bidang pengobatan dan dapat memilih obat
saat ini', 'obat baru' atau 'formula'.
Jika dia memilih 'obat saat ini', sistem akan memintanya
untuk memeriksa dosisnya. Jika dia ingin mengubah
dosis, dia memasukkan dosis dan kemudian
mengkonfirmasi resepnya.
Week #4 - RPL

'Story Card' - Resep Obat - lanjutan

Jika dia memilih 'formulay', sistem akan menampilkan kotak pencarian untuk formularium
yang disetujui. Dia kemudian dapat mencari obat yang dibutuhkan. Dia memilih obat dan
diminta untuk memeriksa apakah obat itu benar. Dia memasukkan dosis dan kemudian
mengkonfirmasi resepnya.

Sistem selalu memeriksa bahwa dosis berada dalam kisaran yang disetujui. Jika tidak, Kate
diminta untuk mengubah dosisnya.

Setelah Kate mengkonfirmasi resepnya, resep itu akan ditampilkan untuk diperiksa. Dia
mengklik 'OK' atau 'Ubah'. Jika dia mengklik 'OK', resep dicatat di database audit. Jika dia
mengklik 'Ubah', dia memasuki kembali proses 'Meresepkan obat'
Week #4 - RPL

2 - Skenario dibagi kedalam Task

Task 1: Mengubah dosis dari obat yang diresepkan

Task 2: Pemilihan Formula

Task 3: Pengecekan Dosis

SCRUM
Week #4 - RPL

Scrum
• Scrum merupakan salah satu proses agile yang memungkinkan kita untuk fokus pada
memberikan nilai bisnis tertinggi dalam waktu yang singkat
• Memungkinkan untuk memeriksa software secara cepat dan berulang (setiap dua kali
hingga satu bulan)

Karakteristik Scrum
• Tim yang mengatur diri sendiri
• Produk berkembang dalam serangkaian sprint
• Persyaratan ditangkap sebagai item dalam daftar "product backlog"
• Tidak ada praktik rekayasa khusus yang ditentukan
• Menggunakan aturan generatif untuk menciptakan lingkungan yang gesit untuk
mengirimkan proyek
Week #4 - RPL

Bagaimana Scrum bekerja?

Week #4 - RPL

Sprints
• Projek Scrum membuat progres dalam serangkaian "Sprints"
• Durasi target adalah satu bulan, atau kurang lebih saetu atau dua pekan, namun durasi
yang konstan akan mengarahkan pada ritme yang lebih baik
• Produk dirancang, dikode, dan diuji selama masa sprint
Week #4 - RPL

Role yang terdapat dalam Sprints:

Product Owner Scrum Master Scrum Team

Menyediakan spesifikasi Bertanggungjawab untuk Terdiri dari berbagai role, seperti
software yang akan dibuat memastikan proses scrum developer, designer, dan tester.
dalam bentuk product berjalan dengan baik, Bertanggungjawab untuk
backlog dan mengelolanya, meningkatkan produktivitas mengerjakan product backlog
serta menjadi penjembatan tim, dan membantu product yang sebelumnya sudah
antara tim bisnis dan tim owner mencapai tujuannya. ditentukan oleh product owner
pengembang. sehingga siap diberikan ke user.
Week #4 - RPL

Aktifitas dalam Sprints:

Sprint Planning Sprint Review

Sprint Retrospective Daily Scrum Meeting

Week #4 - RPL

1 - Sprint Planning Meeting

Week #4 - RPL

Bagian dari Sprint Planning

Bagian 1:
• Membuat product backlog
• Menentukan Sprint Goal
• Partisipan: Product Owner, Scrum Master, Scrum Team

Bagian 2:
• Partisipan: Scrum Master, Scrum Team
• Membuat Sprint Backlog
Week #4 - RPL

2 - Daily Scrum
• Daily scrum merupakan kegiatan pertemuan antara scrum
master dan dev team untuk melaporkan progress apa yang
telah kita lakukan selama sehari atau beberapa hari, sebelum
daily scrum dilakukan.
• Pada daily scrum kita melaporkan pekerjaan apa yang telah
kita kerjakan dan kendala apa yang kita hadapi ketika kita
mengerjakan suatu task. Ketika task yang kita ambil belum
selesai, biasanya kita akan ditanya terkait kendala apa yang
kita alami.
Week #4 - RPL

2 - Daily Scrum
Parameter:
• Harian
• 15-menit
• Bukan untuk menyelesaikan masalah

Pertanyaan:
• Apa yang kamu lakukan kemarin?
• Apa yang akan kamu lakukan hari ini?
• Apa hambatan yang kamu alami?
Week #4 - RPL

3 - Sprint Review Meeting

• Tim memberikan apa yang telah dicapai selama sprint
• Biasanya berbentuk demo fitur baru atau arsitektur yang
mendasarinya
• Berbentuk informal
• Partisipan:
⚬ Klien/pelanggan
⚬ Manajemen
⚬ Product Owner
⚬ Teknisi lainnya
Week #4 - RPL

4 - Sprint Retrospective Meeting

• Hanya Scrum Team/Dev Team

• Pertemuan untuk memberikan
feedback
⚬ Memberikan usulan
⚬ mengomentasi pekerjaan
tim
⚬ menyampaikan keluh
kesah, dll
• Tidak boleh diskip pada 5-6
sprint pertama
Week #4 - RPL

Hal-hal dalam Sprint

Product Backlog

Sprint Backlog

Burndown Chart
Week #4 - RPL

1 - Product Backlog
• Terdiri dari seluruh pekerjaan yang diinginkan pada sebuah projek
⚬ Biasanya merupakan kombinasi dari
￭ story-based work ("biarkan klien mencari dan mengubah")
￭ task-based work
• List diprioritasikan oleh Product Owner
⚬ Biasanya seorang product manager, marketing, internal customer,
dan sebagainya
• Product Backlog merupakan bagian dari Scrum yang
mengekspresikan kebutuhan sistem
• Product Backlog dikelola dan dimiliki oleh Product Owner
• Biasanya berbentuk spreadsheet
• Biasanya dibuat selama Sprint Planning Meeting
Week #4 - RPL

Contoh
Product
Backlog
Week #4 - RPL

2 - Sprint Backlog
• Merupakan subset dari Product Backlog Items, yang menentukan
pekerjaan untuk Sprint
• Dibuat HANYA oleh Sprint Master/Dev Team
• Setiap item memiliki statusnya masing-masing
• Harus diperbaharui setiap hari
• Tidak lebih dari 300 tasks
• Jika sebuah task membutuhkan lebih dari 16 jam, maka tugas
tersebut harus dipecah
• Tim dapat menambah atau mengurangi item dari list. Namun, tidak
diperkenankan product owner untuk melakukannya
Week #4 - RPL

Contoh
Sprint
Backlog
Week #4 - RPL

3 - Sprint burndown Chart

• Diagram burn down adalah representasi grafis dari pekerjaan yang
harus dilakukan terhadap waktu. Ini sering digunakan dalam
metodologi pengembangan perangkat lunak tangkas seperti Scrum.
• Menggambarkan total jam Sprint Backlog tersisa per hari
• Memperlihatkan perkiraan jumlah waktu menuju rilis
• Membandingkan pekerjaan yang direncanakan dengan
perkembangan tim
Week #4 - RPL

Contoh
Sprint
Burndown
Chart
Week #4 - RPL

Referensi
• Kuntarto, Guson. Bahan Kuliah Rekayasa Perangkat Lunak
• Roger Pressman, “Software Engineering: A Practitioner’s Approach 7th
edition”, McGraw Hill, 2010.
• Ian Sommerville, “Software Engineering”, 9th Edition, Addison Wesley,
2010.
• Suryadi, Christine. Modul Kuliah Rekayasa Perangkat Lunak. ITB
Bandung
THANK YOU