APA ITU AGILE, SCRUM, KANBAN, SPRINT. SIMAK LEBIH LANJUT!!

https://informatika.itsk-soepraoen.ac.id/

SOFTWARE DEVELOPMENT 

LIFE  CYCLE  (SDLC)

Di dunia yang semakin modern dalam perkembangan software istilah Agile, Scrum, Kanban, dan Sprint pasti tidak asing dengan istilah tersebut. Penjelasan kali ini akan dibahas lebih detail dan rinci. 

Agile adalah sebuah pendekatan untuk pengembangan perangkat lunak yang berfokus pada iterasi dan pengiriman bertahap. Metode ini dirancang untuk mengatasi masalah yang sering muncul pada pendekatan tradisional yang kaku, di mana persyaratan proyek sering berubah.

Agile berakar pada filosofi Manifesto for Agile Software Development yang memiliki empat nilai inti, yaitu:

1. Individu dan Interaksi lebih penting dari Proses dan Alat: Komunikasi dan kerja sama antar anggota tim dianggap jauh lebih penting daripada aturan, proses, atau tools yang digunakan.

2. Perangkat Lunak yang Berfungsi lebih penting Dokumentasi Komprehensif: Prioritas utama adalah menghasilkan produk yang bisa dipakai oleh pengguna, bukan sekadar membuat tumpukan dokumen yang lengkap.

3. Tim dan pelanggan bekerja sama secara erat dan terus-menerus. Hal ini lebih efektif daripada hanya berinteraksi di awal proyek untuk negosiasi.

4. Agile mengakui bahwa perubahan adalah hal yang wajar. Tim harus mampu beradaptasi dengan perubahan, bukan hanya terpaku pada rencana awal yang sudah ditetapkan.

Contoh studi kasus pada Agile adalah melalui Sistem Manajemen Pasien (Mentcare) studi kasus yang digunakan dalam buku Software Engineering karya Ian Sommerville untuk mengilustrasikan kompleksitas dalam pengembangan sistem informasi berskala besar. Sistem ini dirancang untuk mendukung operasional klinik kesehatan mental, di mana staf medis dapat mengelola data pasien, jadwal janji temu, dan riwayat pengobatan. Fokus utama dari studi kasus ini adalah pada isu persyaratan yang rumit dan manajemen proyek; karena data pasien sangat sensitif, sistem ini memiliki persyaratan keamanan dan privasi yang sangat ketat. Selain itu, kebutuhan dari para pengguna (dokter, perawat, staf administrasi) sering kali bervariasi dan bisa saling bertentangan, sehingga proses pengumpulan dan analisis persyaratan menjadi sangat menantang dan memerlukan manajemen proyek yang terstruktur dengan baik.

Scrum adalah kerangka kerja yang sangat cocok untuk tim kecil yang bekerja di bawah tekanan, karena mendorong transparansi, kolaborasi, dan respons cepat terhadap perubahan. Scrum merupakan salah satu kerangka kerja paling populer dari metodologi Agile. Scrum menyediakan pendekatan yang fleksibel untuk manajemen proyek dan pengembangan produk, terutama dalam menghadapi persyaratan yang cepat berubah. Scrum membagi pekerjaan menjadi siklus-siklus singkat yang disebut Sprint, biasanya berlangsung 2 hingga 4 minggu. Tujuannya adalah untuk menghasilkan bagian produk yang berfungsi di setiap akhir siklus. 

Tiga peran utama dalam Scrum:

1. Product Owner yang Bertanggung jawab atas daftar fitur produk (product backlog) dan memprioritaskan fitur mana yang paling penting untuk dikerjakan.

2. Scrum Master Memastikan tim mengikuti aturan Scrum. Serta membantu tim mengatasi hambatan apa pun yang menghambat pekerjaan mereka.

3. Development Team yang membangun produk. Mereka bekerja secara mandiri untuk memutuskan cara terbaik menyelesaikan pekerjaan dalam satu Sprint.

Scrum memiliki beberapa kegiatan dan artefak (hasil kerja) yang terstruktur:

• Sprint Planning atau rapat di awal sprint untuk merencanakan pekerjaan. Tim memilih item dari product backlog untuk dikerjakan dalam Sprint tersebut.
• Daily Scrum atau rapat harian singkat dalam waktu sekitar 15 menit di mana setiap anggota tim berbagi progres dan hambatan.
• Sprint Review atau demonstrasi hasil kerja di akhir sprint kepada pihak terkait atau disebut dengan stakeholder untuk mendapatkan masukan.
• Sprint Retrospective atau rapat internal tim untuk mengevaluasi proses kerja dan mencari cara untuk meningkatkannya di sprint berikutnya.

Contoh studi kasus Memungkinkan tim untuk bekerja lebih fleksibel dan efisien dengan mengirimkan produk yang berfungsi secara bertahap dalam siklus kerja pendek yang disebut sprint, alih-alih menunggu semua fitur selesai. Pendekatan ini memprioritaskan kemampuan untuk beradaptasi cepat terhadap perubahan karena masukan dari pengguna dan pihak terkait dapat langsung diakomodasi di sprint berikutnya. Selain itu, kolaborasi dan transparansi dijamin melalui pertemuan rutin seperti Daily Scrum dan Sprint Review, yang memastikan seluruh tim dan stakeholder selaras serta dapat mengatasi hambatan dengan cepat.

Kanban merupakan pendekatan yang lebih evolusioner daripada revolusioner. Sangat ideal untuk tim yang membutuhkan fleksibilitas maksimum dan ingin meningkatkan alur kerja mereka secara bertahap tanpa perubahan drastis pada proses yang sudah ada. Kanban adalah metode agile yang fokus pada visualisasi alur kerja dan membatasi pekerjaan yang sedang berjalan. Berbeda dengan scrum yang menggunakan siklus waktu tetap (sprint), kanban bersifat lebih fleksibel dan berkelanjutan. Tujuannya adalah untuk meningkatkan efisiensi dan aliran pekerjaan secara terus-menerus.

Kanban beroperasi berdasarkan beberapa prinsip sederhana seperti 

• visualisasi alur kerja, Setiap tugas atau item pekerjaan diwakili oleh sebuah kartu. Papan ini memberikan gambaran yang jelas dan transparan tentang status semua pekerjaan.
• Membatasi pekerjaan yang berjalan, untuk memastikan tim fokus pada penyelesaian satu tugas sebelum memulai yang lain, sehingga mencegah multitasking dan kemacetan (bottleneck).
• mengelola aliran, membatasi WIP, tim dapat melihat di mana pekerjaan tersendat. Ketika satu pekerjaan selesai, slot kosong tercipta, dan tim dapat menarik pekerjaan baru dari kolom sebelumnya. Proses ini disebut sistem tarik atau (pull system).
• perbaikan berkelanjutan, berperan dalam mendorong tim untuk terus menganalisis alur kerja mereka dan mencari cara untuk membuatnya lebih efisien.

Contoh studi kasus pada Stasiun cuaca di alam liar merupakan sistem yang mengumpulkan data cuaca dari lokasi terpencil dan mengirimkannya ke pusat data. Proyek ini melibatkan tim yang fokus pada pemeliharaan dan perbaikan sistem. Mereka menghadapi tantangan seperti laporan bug mendesak yang datang dari lapangan dan permintaan untuk pembaruan perangkat lunak kecil secara terus-menerus.

Tim ini mengadopsi kanban untuk mengelola alur kerja. Mereka membuat papan visual dengan kolom-kolom yang mewakili status tugas, seperti 'Tunda', 'Siap dikerjakan', 'Sedang dikerjakan', dan 'Selesai'. Setiap laporan bug atau permintaan pembaruan diwakili sebagai kartu. Dengan sistem ini, tim dapat melihat secara instan semua pekerjaan yang ada dan memprioritaskannya.

Prinsip utama kanban, yaitu membatasi pekerjaan yang sedang berjalan, diterapkan dengan ketat. Ini memastikan setiap anggota tim berfokus pada penyelesaian satu tugas penting, seperti perbaikan bug kritis, sebelum menarik tugas baru. Pendekatan ini memungkinkan tim untuk merespons masalah yang muncul dari lapangan dengan cepat dan efisien, sambil tetap mempertahankan alur kerja yang stabil dan transparan. Kanban sangat cocok untuk lingkungan seperti ini karena ia tidak memerlukan perencanaan sprint yang kaku, melainkan mengutamakan aliran kerja yang berkelanjutan dan adaptasi terhadap prioritas yang berubah.

Sprint sama seperti 'denyut nadi' Scrum yang mendorong tim untuk bekerja dalam siklus pendek yang fokus, terukur, dan menghasilkan produk secara bertahap. Sprint merupakan inti dari kerangka kerja Scrum. Sprint adalah siklus kerja singkat dan berulang yang memiliki durasi tetap, biasanya antara 2 hingga 4 minggu. Bertujuan untuk menghasilkan bagian perangkat lunak yang berfungsi dan dapat dikirimkan di setiap akhir siklus.

Setiap Sprint dimulai dengan Sprint Planning untuk menetapkan tujuan yang jelas dan memilih tugas dari Product Backlog yang akan dikerjakan. Selama Sprint, tim dilindungi dari perubahan atau gangguan, sehingga mereka bisa fokus penuh untuk menyelesaikan tugas yang sudah disepakati, dengan tujuan menghasilkan increment atau versi produk yang berfungsi. Di akhir setiap Sprint, tim melakukan Sprint Review untuk mendemonstrasikan hasil kerja dan Sprint Retrospective untuk mengevaluasi dan memperbaiki proses kerja mereka secara berkelanjutan.

Contoh studi kasus pada pengembangan fitur "Dark Mode" untuk Aplikasi "NotesPro". Tim ini bekerja menggunakan kerangka kerja scrum dan memutuskan untuk menyelesaikan fitur ini dalam satu Sprint berdurasi dua minggu.

1. Perencanaan Sprint (Sprint Planning)

Pada hari pertama Sprint, tim mengadakan rapat sprint planning. Mereka meninjau product backlog yang berisi banyak ide fitur dan memilih satu tugas utama: "Mengimplementasikan mode gelap yang berfungsi di seluruh aplikasi". Tim kemudian memecah tugas besar ini menjadi tugas-tugas kecil yang bisa dikerjakan dalam dua minggu, seperti:

• Mendesain palet warna baru untuk mode gelap.

• Mengubah tampilan setiap layar aplikasi (halaman utama, editor, pengaturan) agar sesuai dengan mode gelap.

• Memastikan fitur dark mode bisa diaktifkan dan dinonaktifkan oleh pengguna.

2. Eksekusi Sprint

Selama dua minggu, tim bekerja dengan fokus penuh. Mereka mengadakan rapat harian singkat (Daily Scrum) setiap pagi untuk saling memberi tahu kemajuan dan hambatan. Misalnya, seorang pengembang frontend melaporkan kesulitan dalam mengintegrasikan dark mode dengan pop-up notifikasi. Scrum master segera membantu pengembang tersebut agar tidak ada penundaan. Selama periode ini, tim tidak menerima permintaan tugas baru dari pihak lain, seperti "Tolong tambahkan fitur font baru sekarang". Permintaan ini akan menunggu hingga sprint berikutnya.

3. Tinjauan Sprint (Sprint Review)

Di akhir dua minggu, tim mengadakan rapat sprint review. Mereka mendemonstrasikan fitur dark mode yang sudah berfungsi penuh di aplikasi "NotesPro" kepada product owner dan stakeholder lainnya. Mereka bisa menunjukkan bagaimana tampilan aplikasi berubah ketika fitur diaktifkan, dan memastikan tidak ada elemen yang rusak atau tidak berfungsi. Fitur yang telah selesai dan berfungsi ini disebut increment.

4. Retrospeksi Sprint (Sprint Retrospective)

Setelah Sprint Review, tim mengadakan rapat internal. Mereka membahas apa yang berjalan dengan baik (misalnya, kolaborasi antara desainer dan pengembang) dan apa yang bisa diperbaiki (misalnya, proses persetujuan desain yang memakan waktu). Pembelajaran ini digunakan untuk meningkatkan efisiensi mereka di Sprint-Sprint berikutnya.

bersumber dari buku berjudul Software Engineering karya Ian Sommerville.