Quality management

& Agile development

Oleh kelompok 4
Metode Agile

 dalam rekayasa perangkat lunak fokus pada pengembangan kode. Mereka meminimalkan
dokumentasi dan proses yang tidak berkaitan secara langsung dengan pengembangan kode
dan menekankan pentingnya komunikasi informal di antara anggota tim daripada
komunikasi berdasarkan dokumen proyek. Kualitas, dalam agile development, berarti
kualitas kode dan praktik seperti refactoring, dan test-driven development digunakan untuk
memastikan bahwa kode berkualitas tinggi dihasilkan.
 Manajemen kualitas dalam agile development lebih bersifat informal daripada berbasis
dokumen. Itu bergantung pada pembentukan quality culture, di mana semua anggota tim
memiliki tanggung jawab atas kualitas perangkat lunak dan mengambil tindakan untuk
memastikan bahwa kualitas dapat dipertahankan. The agile community pada dasarnya
menentang overhead birokrasi dari pendekatan berbasis standar dan proses kualitas seperti
yang diwujudkan dalam ISO 9001. Perusahaan yang menggunakan metode agile
development jarang memperhatikan sertifikasi ISO 9001.
Dalam agile development, manajemen kualitas didasarkan pada shared good practice daripada dokumentasi formal.
Beberapa contoh praktik yang baik ini adalah:

 1. Check before check-in, Programmers bertanggung jawab untuk mengatur reviews kode mereka sendiri dengan anggota
tim lain sebelum kode diperiksa ke sistem.
 2. Never break the build, Anggota tim tidak boleh memeriksa kode yang menyebabkan sistem secara keseluruhan gagal.
Oleh karena itu, individu harus menguji perubahan kode mereka terhadap seluruh sistem dan yakin bahwa kode ini
berfungsi seperti yang diharapkan. Jika sistem rusak, orang yang bertanggung jawab diharapkan memberikan prioritas
utama untuk memperbaiki masalah.
 3. Fix problems when you see them, Kode sistem adalah milik tim, bukan milik individu. Oleh karena itu, jika seorang
programmer menemukan masalah atau ketidakjelasan dalam kode yang dikembangkan oleh orang lain, dia dapat
memperbaiki masalah ini secara langsung daripada merujuknya kembali ke pengembang asli.
 Agile processes jarang menggunakan proses inspeksi atau peninjauan formal. Dalam Scrum, tim pengembangan
bertemu setelah setiap iterasi untuk membahas isu dan masalah kualitas. Tim dapat memutuskan perubahan cara
mereka bekerja untuk menghindari masalah kualitas yang muncul. Keputusan kolektif dapat dibuat untuk fokus
pada refactoring dan peningkatan kualitas selama sprint daripada penambahan fungsionalitas sistem baru.

 Review kode mungkin menjadi tanggung jawab individu (check before check-in) atau mungkin mengandalkan
penggunaan pair programming. Pair programming adalah pendekatan di mana dua orang bertanggung jawab
untuk pengembangan kode dan bekerja sama untuk mencapainya. Oleh karena itu, kode yang dikembangkan oleh
seorang individu terus-menerus diperiksa dan ditinjau oleh anggota tim lainnya. Dua orang melihat setiap baris
kode dan memeriksanya sebelum diterima.
Pair Programming

 mengarah pada pengetahuan yang mendalam tentang suatu program, sebagai kedua
programmer harus memahami program secara detail untuk melanjutkan pengembangan.
Kedalaman pengetahuan ini terkadang sulit dicapai dalam proses inspeksi lainnya,
sehingga pair programming dapat menemukan bug yang terkadang tidak akan ditemukan
dalam inspeksi formal. Namun, dua orang yang terlibat tidak bisa seobjektif tim inspeksi
eksternal karena mereka memeriksa pekerjaan mereka sendiri.
 Masalah potensial adalah:

 1. Mutual misunderstandings,Kedua anggota pasangan dapat membuat

kesalahan yang sama dalam memahami persyaratan sistem. Diskusi dapat
memperkuat kesalahan ini.
 2. Pair reputation,Pairs mungkin enggan mencari kesalahan karena tidak
ingin memperlambat kemajuan proyek.
 3. Working relationships,pasangan untuk menemukan cacat cenderung
dikompromikan oleh hubungan kerja dekat mereka yang sering
menyebabkan keengganan untuk mengkritik mitra kerja.
 Pendekatan informal
Untuk manajemen kualitas yang diadopsi dalam metode aggile sangat efektif untuk pengembangan produk perangkat lunak di mana
perusahaan yang mengembangkan perangkat lunak juga mengontrol spesifikasinya. Tidak perlu menyampaikan laporan kualitas kepada
pelanggan eksternal, juga tidak perlu berintegrasi dengan tim manajemen kualitas lainnya. Namun, ketika sistem besar sedang
dikembangkan untuk pelanggan eksternal, pendekatan aggile untuk manajemen kualitas dengan dokumentasi minimal mungkin tidak
praktis:
 1. Jika pelanggan adalah perusahaan besar, mungkin memiliki kualitas proses manajemen sendiri dan mungkin mengharapkan
perusahaan pengembang perangkat lunak untuk melaporkan kemajuan dengan cara yang kompatibel dengan proses ini. Oleh karena
itu, tim pengembangan mungkin harus membuat rencana kualitas formal dan laporan kualitas seperti yang diminta oleh pelanggan.
 2. Jika beberapa tim yang tersebar secara geografis terlibat dalam pengembangan, mungkin dari perusahaan yang berbeda, maka
komunikasi informal mungkin tidak praktis. Perusahaan yang berbeda mungkin memiliki pendekatan yang berbeda terhadap
manajemen mutu, dan anda mungkin harus setuju untuk membuat beberapa dokumentasi formal.
 3. Untuk sistem yang berumur panjang, tim yang terlibat dalam pengembangan akan berubah seiring waktu. Jika tidak ada
dokumentasi, anggota tim baru mungkin merasa tidak mungkin untuk memahami mengapa keputusan pengembangan telah dibuat.
Akibatnya, pendekatan informal untuk manajemen mutu dalam metode aggile mungkin harus disesuaikan sehingga beberapa
dokumentasi dan proses kualitas diperkenalkan. Umumnya, pendekatan ini terintegrasi dengan proses pengembangan berulang. Alih-
alih mengembangkan perangkat lunak, salah satu sprint atau iterasi harus fokus pada pembuatan dokumentasi perangkat lunak yang
penting.
Sekian dan terima
kasih