Anda di halaman 1dari 18

Puji Ratwiyanti, S.Kom.

,
M.MSI

Software

Process

Model
Part 2 Agility
and Process
Minggu 1 Model Proses Secara Umum

Asesmen dan Improvement


Lalu Kita 2 Model

Model Proses Perspektif :


Sudah
3 Waterfall, Prototype,
Evolutionary, Unified
Belajar
Hari ini : 1 Apa Itu Agility

Agility 2 Apa itu Agile Process

And Scrum dan Framework Agile


3 Laiinya

Process Sumber : [Pressman2016]Pressman,Rog


er;Maxim,Bruce.2016.Software
Engineering:APractitioner’sApp
roach,8thEdition
Apa itu Agility ? Agility disini dalam konteks
Rekayas/Pengembangan Perangkat Lunak

Jika Diterjemahkan secara Harfiah Agility = Ketangkasan/Kelincahan

Dalam konteks pekerjaan rekayasa perangkat lunak (Software Engineering) luasnya perubahan adalah pendorong
utama ketangkasan/Agility. Agility lebih dari sekadar respons efektif terhadap perubahan namun juga perihal :

1. mendorong struktur dan sikap tim yang membuat komunikasi (di antara anggota tim, antara ahli teknologi dan
pebisnis, dan antara insinyur perangkat lunak dan manajer mereka) lebih lancar.
2. menekankan pengiriman cepat perangkat lunak operasional dan tidak menekankan pentingnya produk kerja
menengah;
3. mengadopsi pelanggan sebagai bagian dari tim pengembangan dan bekerja untuk menghilangkan sikap "kami
dan mereka" yang terus meliputi banyak proyek perangkat lunak;

Agility mengakui bahwa perencanaan di dunia yang tidak pasti memiliki batasnya dan bahwa rencana proyek
harus fleksibel.
Apa Itu Agile Agility disini dalam konteks

Process ? Rekayas/Pengembangan Perangkat Lunak

Karakeristik utama pada agile software process adalah mengutamakan untuk menangani sejumlah asumsi/isu utama
tentang sebagian besar proyek perangkat lunak :
1. Sulit untuk memprediksi sebelumnya persyaratan perangkat lunak mana yang akan bertahan dan mana yang akan
berubah. Sama sulitnya untuk memprediksi bagaimana prioritas pelanggan akan berubah seiring dengan berjalannya
proyek.
2. Untuk banyak jenis perangkat lunak, desain dan konstruksinya berselang-seling. Artinya, kedua aktivitas tersebut
harus dilakukan secara beriringan sehingga model desain terbukti saat dibuat. Sulit untuk memprediksi berapa banyak
desain yang diperlukan sebelum konstruksi digunakan untuk membuktikan desain.
3. Analisis, desain, konstruksi, dan pengujian tidak dapat diprediksi (dari sudut pandang perencanaan) seperti yang kita
inginkan.
Apa Itu Agile

Process ? (Lanjutan)

Dari ketiga ketiga asumsi diatas, pertanyaan penting muncul: Bagaimana kita membuat proses yang dapat mengelola ketidakpastian?
Jawabannya, seperti yang telah kami catat, terletak pada kemampuan beradaptasi terhadap proses (dengan kondisi proyek dan teknis yang
berubah dengan cepat). Agile Proses, untuk bisa beradaptasi.

Tetapi adaptasi terus-menerus tanpa kemajuan ke depan tidak banyak menghasilkan apa-apa. Oleh karena itu, agile software process harus
beradaptasi secara bertahap. Untuk mencapai adaptasi tambahan, tim agile membutuhkan umpan balik pelanggan (sehingga adaptasi yang
sesuai dapat dibuat). Penghubung yang efektif untuk umpan balik pelanggan adalah prototipe operasional atau bagian dari sistem operasional.

strategi pembangunan bertahap harus dilembagakan. Peningkatan perangkat lunak (prototipe yang dapat dieksekusi atau bagian dari sistem
operasional) harus dikirimkan dalam periode waktu yang singkat sehingga adaptasi mengikuti perubahan (tidak dapat diprediksi).

Pendekatan berulang ini memungkinkan pelanggan untuk mengevaluasi peningkatan perangkat lunak secara teratur, memberikan umpan
balik yang diperlukan kepada tim perangkat lunak, dan memengaruhi adaptasi proses yang dibuat untuk mengakomodasi umpan balik
tersebut.
MDM Company June 1, 2021

Agile Methods
Scrum and Other Methods
Fun Fact : Nama SCRUM diambil dari
SCRUM aktivitas yang terjadi selama pertandingan
rugby

Scrum adalah metode pengembangan perangkat lunak Agile yang sangat populer yang digagas oleh Jeff Sutherland dan tim
pengembangannya pada awal 1990-an. Pengembangan lebih lanjut pada metode Scrum dilakukan oleh Schwaber dan Beedle.

Prinsip scrum konsisten dengan manifesto agile dan digunakan untuk memandu aktivitas pengembangan dalam proses yang
menggabungkan aktivitas kerangka kerja berikut: persyaratan, analisis, desain, evolusi, dan penyampaian.

Dalam setiap aktivitas kerangka kerja, tugas kerja berlangsung dalam 4 periode waktu yang relatif singkat yang disebut sprint. Pekerjaan yang
dilakukan dalam sprint (jumlah sprint yang dibutuhkan untuk setiap aktivitas framework akan bervariasi tergantung pada ukuran produk dan
kompleksitasnya) disesuaikan dengan masalah yang dihadapi dan ditentukan dan sering dimodifikasi secara real time oleh tim Scrum.

Alur Keseluruhan proses Scrum dapa disimak pada Gambar


SCRUM (Lanjutan)
SCRUM (Lanjutan)

Secara singkat, langkah scrum dapat dijelaskan sebagai berikut :

1. Pemilik produk membuat daftar keinginan yang diprioritaskan yang disebut backlog produk.
2. Selama perencanaan sprint, tim memilih salah satu item dari urutan teratas daftar keinginan tersebut dan memutuskan bagaimana
mereka akan menjalankan potongan tersebut.
3. Tim memiliki sejumlah waktu, yang disebut dengan istilah sprint (biasanya dua sampai empat minggu) untuk menyelesaikan pekerjaannya,
namun setiap harinya akan ada pengecekan untuk melihat progress pekerjaan (Scrum harian).
4. Sepanjang jalan, Scrum Master membuat tim tetap fokus pada tujuannya.
5. Di akhir sprint, pekerjaan harus berpotensi untuk dikirim: siap untuk diserahkan kepada pelanggan, diletakkan di rak toko, atau ditunjukkan
kepada Pemangku kepentingan.
6. Sprint diakhiri dengan review sprint dan retrospektif.
7. Seiring sprint berikutnya dimulai, tim memilih item lain lagi dari backlog produk dan mulai bekerja lagi.
8. Hal ini berlangsung sampai proyek dianggap selesai, baik karena deadline dan budget atau dengan melengkapi seluruh daftar item yang
sudah ditentukan di awal.
Other Agile Methods

Selain Scrum beberapa metode agile yang dikenal adalah :


1. The XP Framework
2. Kanban
3. DevOps
The XP Framework mencakup seperangkat
aturan dan praktik yang terjadi dalam konteks
The XP
empat aktivitas kerangka kerja: perencanaan,
Framework desain, pengkodean, dan pengujian,
sebagaimana terlihat pada gambar
The XP
(Lanjutan)
Framework

1. Planning/Perencanaan. Aktivitas perencanaan (juga disebut permainan perencanaan) dimulai dengan aktivitas persyaratan yang disebut
mendengarkan. Mendengarkan mengarah pada pembuatan sekumpulan "cerita" (juga disebut cerita pengguna) yang menggambarkan
keluaran, fitur, dan fungsionalitas yang diperlukan untuk perangkat lunak yang akan dibangun.
2. Design/Rancangan. Desain XP secara ketat mengikuti prinsip KIS (Keep In Simple). Desain fungsionalitas tambahan (karena pengembang
menganggapnya akan dibutuhkan nanti) tidak disarankan
3. Codding/Pengodean. Setelah cerita pengguna dikembangkan dan pekerjaan desain awal selesai, tim tidak berpindah ke kode, tetapi
mengembangkan serangkaian tes unit yang akan melatih setiap cerita yang akan disertakan dalam rilis saat ini (peningkatan perangkat
lunak). Setelah pengujian unit dibuat, pengembang dapat lebih fokus pada apa yang harus diterapkan agar lulus pengujian. Setelah kode
selesai, kode dapat segera diuji unit, sehingga memberikan umpan balik instan kepada pengembang.
4. Testing/Pengujian. Pengujian unit yang dibuat harus diimplementasikan menggunakan kerangka kerja yang memungkinkannya
diotomatiskan (karenanya, dapat dijalankan dengan mudah dan berulang kali). Hal ini mendorong penerapan strategi pengujian regresi
setiap kali kode dimodifikasi (yang sering kali diberikan filosofi pemfaktoran ulang XP). Tes penerimaan XP, juga disebut tes pelanggan,
ditentukan oleh pelanggan dan berfokus pada keseluruhan fitur dan fungsionalitas sistem yang terlihat dan dapat ditinjau oleh pelanggan.
Mereka berasal dari cerita pengguna yang telah diimplementasikan sebagai bagian dari rilis perangkat lunak.
Metode Kanban menjelaskan metode untuk
meningkatkan proses atau alur kerja apa pun.
Kanban Kanban difokuskan pada manajemen
perubahan dan pemberian layanan.
Kanban (Lanjutan)

Kanban difokuskan pada manajemen perubahan dan pemberian layanan. Manajemen perubahan mendefinisikan proses di mana
perubahan yang diminta diintegrasikan ke dalam sistem berbasis perangkat lunak. Penyampaian layanan didorong dengan berfokus
pada pemahaman kebutuhan dan harapan pelanggan. Anggota tim mengelola pekerjaan dan diberi kebebasan untuk mengatur diri
mereka sendiri untuk menyelesaikannya. Kebijakan berkembang sesuai kebutuhan untuk meningkatkan hasil. kanban terdiri dari 6
praktik utama :

1. Memvisualisasikan alur kerja menggunakan papan Kanban (contohnya ditunjukkan pada Gambar 3.4). Papan Kanban diatur ke
dalam kolom yang mewakili tahap pengembangan untuk setiap elemen fungsionalitas perangkat lunak. Kartu di papan mungkin
berisi cerita pengguna tunggal atau cacat yang ditemukan baru-baru ini pada catatan tempel dan tim akan memajukannya dari
"harus dilakukan", menjadi "melakukan", dan "selesai" seiring kemajuan proyek.
2. Membatasi jumlah Work In Progress (WIP) pada waktu tertentu. Pengembang didorong untuk menyelesaikan tugas mereka saat
ini sebelum memulai yang lain. Hal ini mengurangi waktu tunggu, meningkatkan kualitas kerja, dan meningkatkan kemampuan tim
untuk sering memberikan fungsionalitas perangkat lunak kepada pemangku kepentingan mereka.
Kanban (Lanjutan)

3. Mengelola alur kerja untuk mengurangi pemborosan dengan memahami aliran nilai saat ini, menganalisis
tempat-tempat di mana aliran tersebut terhenti, menentukan perubahan, dan kemudian menerapkan perubahan
tersebut.
4. Membuat kebijakan proses eksplisit (misalnya, tuliskan alasan Anda memilih item untuk dikerjakan dan kriteria
yang digunakan untuk mendefinisikan "selesai").
5. Berfokus pada perbaikan berkelanjutan dengan membuat putaran umpan balik di mana perubahan
diperkenalkan berdasarkan data proses dan efek perubahan pada proses diukur setelah perubahan dilakukan.
6. Lakukan perubahan proses secara kolaboratif dan libatkan semua anggota tim dan pemangku kepentingan
lainnya sesuai kebutuhan.
DevOps dibuat oleh Patrick DeBois [Kim16a]
untuk menggabungkan Pengembangan dan
DevOps Operasi. DevOps mencoba menerapkan prinsip
pengembangan yang gesit dan ramping di
seluruh rantai pasokan perangkat lunak
DevOps (Lanjutan)

Pendekatan DevOps melibatkan beberapa tahap yang terus berputar hingga produk yang diinginkan yaitu :

Pengembangan berkelanjutan. Hasil perangkat lunak dipecah dan dikembangkan dalam beberapa sprint dengan peningkatan yang
dikirimkan ke jaminan kualitas 14 anggota tim pengembangan untuk pengujian
Pengujian berkelanjutan. Alat pengujian otomatis 15 digunakan untuk membantu anggota tim menguji beberapa peningkatan kode
secara bersamaan untuk memastikan mereka bebas dari cacat sebelum integrasi. •
Integrasi berkelanjutan. Potongan kode dengan fungsionalitas baru ditambahkan ke kode yang ada dan ke lingkungan run-time
dan kemudian diperiksa untuk memastikan tidak ada kesalahan setelah penerapan.
Penerapan berkelanjutan. Pada tahap ini kode terintegrasi disebarkan (diinstal) ke lingkungan produksi, yang mungkin mencakup
beberapa situs secara global yang perlu disiapkan untuk menerima fungsionalitas baru. •
Pemantauan terus menerus. Staf operasi yang merupakan anggota tim pengembangan membantu meningkatkan kualitas
perangkat lunak dengan memantau kinerjanya di lingkungan produksi dan secara proaktif mencari kemungkinan masalah sebelum
pengguna menemukannya.

Anda mungkin juga menyukai