TUGAS MATA KULIAH

REKAYASA PERANGKAT LUNAK

RINGKASAN MATERI METODE AGILE

Dosen Pengampu:
Kholiq Budiman, S.Pd., M.Kom.

Oleh:
Nurul Zaatsiyah (4612418014)
Farhan Ramadhan (4612418028)
Hafid Fikri Bachtiar (4612418029)
Muhammad Lintang A H P (4612418037)
Tiffany Ovilia D L (4612418040)

PROGRAM STUDI SISTEM INFORMASI

JURUSAN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
UNIVERSITAS NEGERI SEMARANG
2020
A. INTRODUCTION TO AGILE

Agile adalah mindset yang dapat bertindak cepat, adaptif dan

fleksibel dengan berbagai macam kerangka kerja di dalamnya.

Jadi, Agile bukanlah suatu metodologi karena orang sering salah

mengartikan Agile sebagai suatu metode tertentu yang implementasinya bisa sama
dari satu company ke company lain. Padahal sebenarnya Agile adalah suatu
mindset dan principle di mana saat implementasinya setiap company atau
perusahaan memiliki perjalanannya masing-masing. PT Ekipa Indonesia adalah
salah satu konsultan Agile yang paling berpengaruh di Indonesia.

Dari sisi bisnis user ada lima poin yang menjadi alasan mengapa perlu
mengimplementasikan Agile, antara lain:

1. Time to market
Melalui Agile kita dapat merilis produk tanpa harus menunggu seluruh scope
produk selesai dikerjakan. Kita dapat mendeliver MVP atau minimum viable
product terlebih dahulu agar bisa segera dirilis ke market. Sehingga kita tidak
kehilangan momentum time to market.
2. Ability to change
Sebagai seorang bisnis user seringkali dihadapkan pada situasi harus merubah
Scope Project. Melalui Agile dapat menginspect dan adapt terhadap produk
inkremen. Sehingga bisnis user tetap dapat melakukan perubahan scope
sesuai dengan kondisi market saat ini.
3. Accelerate product delivery and veasibility
Seringkali project yang dijalankan tidak terdeliver sesuai rencana dan
cenderung telat. Hal tersebut dikarenakan perencanaan jangka panjang yang
lebih beresiko terhadap kesalahan estimasi. Dengan Agile kita menjalankan
sprint dengan durasi yang singkat, yaitu maksimal 1 bulan. Sehingga resiko
 terhadap project delay lebih kecil dibandingkan planning long term untuk
keseluruhan project.
4. Customer Satisfaction
Bisa dibayangkan jika banyak menghabiskan waktu yang digunakan untuk
membangun sesuatu yang user tidak inginkan karena memaksakan perencanaan
awal ketimbang beradaptasi terhadap perubahan bisnis.

Melalui Agile, fokus pada outcome yang memiliki value bisnis terkini
ketimbang fokus pada output sesuai scope awal yang sebenarnya tidak akan
pernah user gunakan karena sudah tidak sesuai dengan kondisi saat ini. Dengan
menghasilkan suatu produk yang dibutuhkan oleh customer, harapannya
customer akan lebih puas terhadap produk yang dihasilkan. Selain itu, customer
dapat memberikan feedback terhadap produk.

5. Bisnis Eksistensi
Jika organisasi tidak Agile, maka organisasi tersebut lebih beresiko untuk
terdisrupsi, bangkrut dan gulung tikar. Saat ini banyak perusahaan sangat yang
bisa menjadi ancaman besar bagi corporate besar jika tidak beradaptasi.
Dengan Agile diharapkan akan lebih siap dalam menghadapi perubahan
tersebut sehingga organisasi bisa tetap survive.

Dari sisi tim proyek ada tiga benefit bagi tim proyek, yaitu:

1. Collaboration IT dan Business

Agile mengedepankan kerjasama antara IT dan bisnis user. Sesuai dengan Agile
principal “business people and developers must work together”. Dengan Agile,
produk owner haruslah berasal dari bisnis user sehingga development team
mempunyai akses untuk berkomunikasi dengan bisnis user. Sehingga tidak ada
lagi istilah antara bisnis user dan tim proyek, melainkan hanya ada Agile tim
dengan gol yang sama yaitu menghasilkan produk yang berkualitas dan
mempunyai nilai bisnis yang tinggi sesuai dengan kondisi market saat ini.
 2. Removed Silo Mindset
Seringkali di internal tim proyek pun ada silo mindset, bisnis analyst, developer
dan tester berasal dari departemen yang berbeda-beda. Mereka cenderung untuk
memikirkan KPA masing-masing dari pada kesuksesan produknya. Dengan
Agile, tidak ada istilah bisnis analis, developer dan tester, mereka semua
tergabung menjadi development team yang sama-sama bertanggung jawab
terhadap kualitas produk.
3. Self -organized
Agile mengedepankan tim yang self-organized ketimbang tim yang hanya
menerima perintah dan disuruh. Environment Agile memungkinkan Agile team
bisa berkembang dan meningkatkan skill mereka. Karena mereka diberi ruang
untuk berkembang dan berani menyatakan pendapat demi terciptanya bisnis
goal.

Perubahan bisnis begitu cepat dan kompleks, seringkali perencanaan yang

dilakukan tidak sesuai dengan kondisi market saat ini. Strategi dan perencanaan
diperlukan untuk memasuki dunia yang begitu kompleks. Namun juga
membutuhkan cara kerja baru yang lebih fleksibel terhadap perubahan. Tetapi
membangunnya di lingkungan yang kompleks membutuhkan pemikiran yang
lebih adaptif daripada memaksakan untuk mengikuti perencanaan awal. Cara
kerja Agile mengedepankan respon terhadap perubahan ketimbang
mengikuti perencanaan awal. Agile meminimalkan resiko dengan cara
melakukan iterasi produk dan merilisnya ke pasar sedikit demi sedikit
namun sering.

B. VALUE OF AGILE

Pada tanggal 11-13 Februari 2001 di The Lodge, Utah, Amerika Serikat,
17 orang bertemu untuk mencoba menemukan solusi permasalahan yang sering
dihadapi di bidang software development. Mereka bersimpati pada kebutuhan
kerangka kerja yang lebih fleksibel terhadap perubahan dan fokus pada delivery
software ketimbang dokumentasinya. Dari pertemuan tersebut lahirlah agile
manifesto. Agile manifesto terdiri dari 4 agile values dan 12 agile principle.

4 agile values:

1. Individuals and Interactions Over Processes and Tools

Di dalam agile bukan berarti tidak perlu ada process dan tools, hanya
saja interaksi individual lebih penting ketimbang sekedar urusan process dan
tools. Jika ada impediments, bisa saling berkomunikasi secara langsung
ketimbang sekedar berkirim email atau komen di agile tools. Agile team
biasanya bekerja secara bersama di suatu ruangan agar bisa berkomunikasi
secara face to face.

Contoh pada suatu perusahaan multinasional ketika komunikasi

individu sangat kurang, dimana komunikasi antara business user dan
development team hampir tidak pernah terjadi. Development team biasanya
hanya sekedar menerima dokumen proyek dari project manager, kemudian
berusaha memahami kebutuhan user dari dokumen tersebut atau sesekali
bertanya kepada project manager. Lalu project manager akan bertanya pada
business owner tentang hal-hal yang ditanyakan oleh development team.
Kemudian project manager akan kembali ke development team untuk
menjelaskan apa yang menjadi concern dari business owner.

Yang sering terjadi ketika hal ini dilakukan:

a. Informasi dari project manager baik dari development team ke business

user ataupun sebaliknya sering kali tidak utuh. Miss comunication ini
menyebabkan aplikasi yang dikerjakan oleh development team tidak
 sepenuhnya sesuai dengan ekspektasi dari business user sehingga sering
terjadi konflik di antara ketiganya.

b. Development team seringkali hanya dianggap sebagai mesin yang hanya

menerima dokumen perintah tanpa ikut terlibat dalam komunikasi secara
langsung dengan business user. Hal tersebut membuat mereka merasa
kurang berkembang untuk bekerja di lingkungan yang kurang
memanusiakan manusia. Sebaliknya, project manager juga merasa
dirinya terlalu terbebani karena menanggung semua isu yang ada dalam
proyek.

c. Business owner dianggap sebagai trouble makers. Kehadirannya selalu

dibayang-bayangi perubahan requirement. Hal-hal ini karena kurang
adanya komunikasi tentang benefit proyek yang mereka kerjakan.

Hal-hal semacam ini bisa dihindari dengan adanya Agile karena agile
mengedepankan komunikasi.

2. Working Software Over Comprehensive

a. Berhenti melakukan waterfall di agile

Dengan adanya agile, metodologi yang diterapkan tampaknya

mengundurkan diri dari dokumentasi sepenuhnya yang tidak benar.
Tetapi membuat halaman – halaman dokumen teknis yang tidak dibaca
oleh siapapun mengikuti waterfall bukan agile.

b. Dokumentasi dalam agile

Dokumentasi idak harus menurut definisi, beberapa tipe dalam

kasus bekerja dengan perangkat lunak melalui dokumentasi yang
komprehensif berarti bahwa memberikan perangkat lunak yang
melakukan apa yang seharusnya menjadi prioritas utma sebelum
membuat dokumentasi. Disisi lain, agile tidak mengatakan bahwa anda
 harus berhenti membuat dokumentasinya. Jadi anda perlu menganalisa
mana yang dibutuhkan dan mana yang bisa dijatuhkan. Dalam konteks
itu, ketika membuat dokumen tunggu sebentar dan cari tahu siapa yang
membutuhkan dokumen ini dan mengapa. Jika tidak menemukan jawaban
kemungkinan besar hal buruk tidak akan terjadi.

c. Teknikal dokumentasi

Waterfall menciptakan entitas, kelas, integrase, diagram interaksi

dan dokumentasi teknis lainnya sebelum memulai implementasu.
Sekarang ini dilakukan dengan cara yang berbeda. Agile mendukung
arsitektur yang muncul dan perubahan bertahap sehingga kebutuhan
merancang kelas java oleh arsitek tidak lagi wajib. Jika seorang
pengembang membutuhkan diagram untuk memvisualisasikan konsep
sebelum implementasi, itu baik-baik saja. Tetapi tidak diperlukan dalam
metodologi lagi. Mengapa harus menghindari dokumentasi teknis:

1) Sulit untuk up to date. Dokumentasi yang ketinggalan jaman lebih

buruk daripada tidak ada dokumentasi.
2) Tidak mungkin untuk membuatnya lengkap dalam jangka panjang.
Kode sumber berisi beberapa pernyataan IF. Saya tidak percaya kalua
anda bisa memasukan semuanya ke dalam surat kabar. Sama seperti
diatas dokumentasi tidak lengkap lebih buruk daripada tidak ada
dokumentasi.
3) Sastu – satunya sumber informasi teknis yang selalu terkini adalah
kode itu sendiri. Tetap pada itu. Jika anda memerlukan dokumentasi
karena sulit mendapatkan informasi dari kode, bersihkan kode
tersebut. Arsitektur yang baik mudah dimengerti dan diikuti.
4) Pengembang benci memperbarui dokumentasi teknis dan mereka
akan menghindari melakukan apa yang akan menghasilkan kertas
yang using dan tidak lengkap. Di sisi lain, memperkejakan orang
 non-teknis untuk memelihara dokumentasi teknis salah satu menurut
definisi.

d. Binis dokumentasi

20 tahun yang lalu analis bisnis menghasilkan dokumen

persyaratan bisnis (BRD) dan dokumen persyaratan fungsional (FRD)
agar perjanjian dengan klien ditulis sebelum melibatkan pengembang. Itu
seperti itu di waterfall. Agile membutuhkan tim Scrum untuk
mengerjakan cerita pengguna yang tidak menggambarkan persyaratan
fungsional tetapi kebutuhan pengguna atau masalah. Tim Scrum harus
menangani masalah pengguna murni bukan hanya mengimplementasikan
apa yang ditulis dalam FRD. Mengapa anda harus menghindari
dokumentasi bisnis:

1) Apapun yang ditulis dalam dokumentasu, itu harus dilaksanakan

karena kami berjanji kepada anda klien bahkan jika anda kemudian
menyadari bahwa klien membutuhkan sesuatu yang lain.
2) Setelah mengimplementasikan fitur, makalah tidak berguna karena
tujuannya adalah untuk memberikan persyaratan kepada
pengembang untuk implementasi

e. Dokumentasi pengguna akhir

Ketika saya memulai perjalanan saya dengan komputer saya

menggunakan Windows 95 dan saya ingat bagaimana saya benci tidak
sengaja menekan tombol F1 pada keyboard saya. Seluruh sistem
dibekukan. Setelah beberapa menit, kotak pesan muncul dengan
informasi yang membantu konten diindeks dan saya harus menunggu.
Kemudian saya akhirnya bisa mematikan proses dan kembali ke apa yang
saya lakukan. Saya tidak ingat menggunakan bantuan bawaan dalam
 program. Ketika saya tidak tahu bagaimana melakukan sesuatu, saya
menggunakan mesin pencari internet untuk menemukan jawaban.

Jika Anda kesulitan menulis manual pengguna, pikirkan tentang

membuat komunitas pengguna, sebuah forum di mana mereka dapat
bertukar informasi cara menggunakan perangkat lunak Anda secara
efektif. Saya tahu, ini mudah dilakukan untuk program yang digunakan
oleh jutaan pengguna, tetapi bahkan untuk aplikasi yang didedikasikan
untuk sekelompok kecil orang, itu bisa dilakukan. Ini akan membutuhkan
keterlibatan Anda untuk menjawab pertanyaan pengguna dan untuk
membuat komunitas tetap aktif, tetapi saya yakin itu pekerjaan yang lebih
menarik yang menulis dokumen dan jelas lebih baik bagi pengguna.

Mengapa harus menghindari dokumentasi pengguna akhir:

1) Pengguna tidak suka membaca manual. Pengguna mahir lebih suka

menggunakan mesin pencari dan forum internet untuk menemukan
jawaban dan tip. Pengguna pemula akan berharap bahwa aplikasi ini
intuitif dan tidak akan membaca manual.
2) Tidak ada yang mau menulis manual. Maka akan membecimu jika
kamu meminta mereka melakukannya.

3. Customer Collaboration Over Contract Negotiation

Negosiasi adalah periode di mana pelanggan dan manajer produk

mengerjakan rincian pengiriman, dengan poin-poin di mana rincian dapat
dinegosiasikan ulang. Kolaborasi adalah makhluk yang sama sekali berbeda.
Dengan model pengembangan seperti Waterfall, pelanggan menegosiasikan
persyaratan untuk produk, seringkali dengan sangat rinci, sebelum pekerjaan
dimulai. Ini berarti pelanggan terlibat dalam proses pengembangan sebelum
pengembangan dimulai dan setelah selesai, tetapi tidak selama proses.
 Agile Manifesto menggambarkan pelanggan yang terlibat dan
berkolaborasi sepanjang proses pengembangan, pembuatan. Ini membuat
pengembangan lebih mudah untuk memenuhi kebutuhan pelanggan mereka.
Metode lincah dapat mencakup pelanggan pada interval untuk demo berkala,
tetapi proyek dapat dengan mudah memiliki pengguna akhir sebagai bagian
sehari-hari tim dan menghadiri semua rapat, memastikan produk memenuhi
kebutuhan bisnis pelanggan.

Tidak diragukan lagi, negosiasi adalah penting karena terjadi dalam

situasi ketika klien dan manajer produk bekerja sama dengan semua
perinciannya tetapi beberapa hal belum diselesaikan. Masih ada kemungkinan
negosiasi ulang, tetapi begitu negosiasi selesai, diskusi selesai. Namun, Agile
Manifesto sangat berbeda karena mendukung kolaborasi pelanggan daripada
negosiasi kontrak.

Dalam Agile Manifesto, kolaborasi pelanggan menggambarkan klien

yang menggabungkan semua melalui prosedur pengembangan. Agile
memungkinkan diskusi tanpa batas antara klien dan pengembang Agile, dan
komunikasi bersifat terbuka.

Sekali waktu, kontrak adalah raja. Anda akan membuat kontrak

dengan pelanggan Anda yang kemudian akan merinci produk jadi. Akibatnya,
seringkali ada perbedaan antara apa yang dikatakan kontrak, apa yang
dilakukan produk, dan apa yang sebenarnya dibutuhkan pelanggan.

Menurut Agile Manifesto, fokusnya harus pada pengembangan

berkelanjutan. Anda perlu membangun lingkaran umpan balik dengan
pelanggan Anda sehingga Anda dapat terus-menerus memastikan bahwa
produk Anda berfungsi untuk mereka. Ini memungkinkan tim terkoordinasi
untuk menyelaraskan lebih baik sesuai kebutuhan pelanggan. Salah satu
pendekatan untuk mencapai ini adalah melalui pemilik produk yang
 berkomitmen yang dapat membantu tim secara real-time dalam
mengklarifikasi hal-hal dan menyesuaikan pekerjaan sesuai kebutuhan klien.

4. Responding to Change Over Following a Plan

Cara berpikir standar adalah bahwa perkembangannya mahal dan kita
harus menghindari perubahan apa pun yang terjadi. Itulah hal yang tidak perlu
difokuskan pada dokumentasi dan rencana terperinci untuk disampaikan
dengan tetap mengikuti rincian produk dan jadwal. Sedangkan Agile
memungkinkan kita melakukan perubahan karena tidak terlalu mahal.
Bahkan, umpan balik selalu menyambut yang membantu proyek untuk
tumbuh. Itu tidak bisa dihindari tetapi itu menambah nilai. Seperti yang
ditunjukkan oleh Agile, kerenyahan penekanan berarti preferensi dapat
digeser dari iterasi ke iterasi dan fitur yang berbeda dapat dimasukkan dalam
iterasi berikutnya. Perubahan memperbaiki proyek dan memberi nilai
tambahan. Agile juga merencanakan, namun itu juga mengikuti pendekatan
"tepat waktu" di mana perubahan dilakukan kapan pun diperlukan saat sprint
berlangsung. pendekatan manajemen proyek tradisional mencoba untuk
menggulingkan monster perubahan ke tanah dan menjabarkannya sehingga
keluar untuk hitungan. Prosedur manajemen perubahan yang ketat dan
struktur anggaran yang tidak dapat mengakomodasi persyaratan produk baru
membuat perubahan menjadi sulit. Tim proyek tradisional seringkali
mendapati diri mereka secara membabi buta mengikuti suatu rencana,
kehilangan kesempatan untuk menciptakan produk yang lebih bernilai.
Seiring waktu - dan pengetahuan tentang produk Anda - meningkat,
kemampuan untuk melakukan perubahan berkurang, dan biaya lebih banyak.