Kumpulan Soal Rekayasa Perangkat Lunak (RPL) Tentang Scrum, Sprint, dan User Story

Kunci Jawaban Tentang Scrum, Sprint, User Story

KakaKiky - Hai sobat semua! Pada kesempatan kali ini Kiky akan membagikan berbagai kumpulan pertanyaan lengkap dengan kunci jawaban dari mata kuliah Rekayasa Perangkat Lunak (RPL) tentang Agile, Scrum, Sprint, dan User Story. Pertanyaan-pertanyaan ini didapatkan sewaktu menempuh mata kuliah RPL Semester 3. Berikut adalah daftar pertanyaan dan jawabannya.

 

Kumpulan Pertanyaan Dan Jawaban RPL - Agile, Scrum, Sprint, dan User Story

 

1. Salah satu karakteristik metodelogi Agile adalah Fail Fast. Jelaskan apa yang dimaksud dengan fail fast.

Jawab:

Fail Fast (kegagalan cepat) merupakan pengujian ekstensif dan pengembangan tambahan untuk menentukan apakah suatu ide itu mempunya nilai atau tidak. Tujuannya adalah untuk memotong kerugian ketika pengujian dalam mengungkap sesuatu tidak berfungsi dan dengan cepat mencoba sesuatu yang lain. Tujuan pentingnya adalah untuk menghindari efek biaya hangus. Ini berusaha menghilangkan stigma dari kata kegagalan dengan menkankan pengetahuan yang diperloha dari upaya gagal untuk meningkatkan keberhasilan.

Gagal berusaha menghilangkan stigma dari kata "kegagalan" dengan menekankan bahwa pengetahuan yang diperoleh dari upaya yang gagal sebenarnya meningkatkan kemungkinan keberhasilan akhirnya. Konsep fail fast juga terkait dengan perbedaan antara metode waterfall dan pendekatan agile untuk pengembangan perangkat lunak.

 

2. Jelaskan secara umum apa itu Scrum.

Jawab:

Yang dimaksud engan Scrum adalah sebuah kerangka kerja di mana orang-orang dapat menyelesaikan permasalahan kompleks yang senantiasa berubah. Scrum lebih banyak digunakan untuk pengembangan rekaya perangkat lunak. Hal ini dikarekanan Scrum lebih ditujukan untuk pengembangan produk secara kompleks. Scrum didasari oleh empirisme yang memiliki tiga tiang yaitu transparansi, inspeksi dan adaptasi. Hal yang paling penting dari Scrum adalah Sprint, bisa dikatakan sebagai jantungnya Scrum adalah Sprint.

 

3. Jelaskan apa yang dimaksud dengan Product Backlog pada Scrum.

Jawab:

Yang dimaksud dengan Product Backlog adalah sebuah daftar terurut dari setiap hal yang berkemungkinan dibutuhkan dalam produk, serta merupakan sumber utama dari daftar kebutuhan mengenai semua hal yang perlu dilakukan terhadap produk. Yang bertanggung jawab terhadap product backlog adalah product owner. Pada awal pembuatan Product Backlog hanya terjabar daftar kebutuhan yang paling diketahui dan dipahami pada saat itu. Product Backlog juga menjabarkan semua fitur, fungsi, kebutuhan, serta penyempurnaan dan perbaikan terhadap produk di rilis mendatang. Item Product Backlog memiliki atribut deskripsi, urutan, estimasi dan nilai bisnis. Product Backlog bersifat dinamis; senantiasa berubah agar produk dapat menjadi layak.

 

4. Uraikan format User Story pada Scrum.

Jawab:

User story adalah sebuah deskripsi sederhana dan singkat dari fitur yang diceritakan dengan menggunakan perspektif orang yang menginginkan fitur terbaru. Biasanya dari pengguna ataupun costumer perangkat lunak. Ada 3 buah format untuk user story. Format tersebut diantaranya adalah: 'As a' 'I want' dan 'So that'. 'As a' ini diikuti oleh aturan dari user yang nantinya menggunakan feature dari user story tersebut. 'I Want' bermakna sebagai penjelasan mengenai fungsi atau feature yang ingin dikembangkan. Lalu untuk 'So that' maknanya adalah hasil yang akan didapatkan setelah fungsi yang diminta itu dapat dijalankan. Namun, di beberapa teori lainnya 'So that' ini disebutkan sebagai opsional (boleh tidak ada).

 

5. Berikan minimal tiga contoh User Story dari project anda.

Jawab:

Berikut ini adalah contoh user story dari project JakBloe:

• Sebagai seorang pedagang, saya ingin dapat membeli barang dengan murah, agar saya dapat menghemat biaya pengeluaran untuk membeli stok barang.
• Sebagai seorang supplier, saya ingin mendapatkan lebih banyak pesanan dari pedagang, agar meningkatkan penghasilan saya.
• Sebagai seorang pedagang, saya ingin mendapatkan stok barang berkualitas, sehingga saya bisa meningkatkan jumlah pembeli.
• Sebagai seorang developer, saya akan membuat fitur posting ajakan membeli stok barang, agar pedagang dapat menemukan stok barang yang dicari.
• Sebagai seorang developer, saya akan membuat fitur kategori postingan, agar postingan lebih teratur.

 

6. Untuk merealisasikan User Story, komponen teknis apa saja yang harus diperlukan?

Jawab:

Menurut saya untuk merealisasikan User Story dibutuhkan beberapa komponen teknis. Komponen teknis tersebut diantaranya adalah Halaman atau tampilan X sebagai halaman horizontal. Kemudian Halaman atau tampilan Y sebagai halaman vertikal. Lalu juga dibutuhkan sebuah tabel Z. Kemudian kita juga memerlukan pengubahan tabel A dengan cara menambakan field B, lalu koordinasikan dengan tim infrastruktu tentanc C. Setelah itu kita akan melakukan unit test untuk D. Realisasi User Story diakhiri dengan melakukan integration test. Singkatnya alur untuk merealisasikan User Story adalah sebagai berikut:

• Halaman / tampilan X
• Halaman / tampilan Y
• Perlu buat table Z
• Perlu ubah table A dengan menambah field B
• Koordinasi dengan tim infrastruktur tentang C
• Unit test untuk D
• Integration test

 

7. Jelaskan langkah-langkah untuk melakukan estimasi waktu pada satu user story!

Jawab:

Dalam membuat User Story juga diperlukan adanya estimasi waktu. Untuk melakukan estimasi waktu juga tidak boleh asal-asalan, ada beberapa hal yang harus diperhatikan. Hal-hal yang harus diperhatikan dalam estimasi waktu pada satu user story yaitu, pertama masing masing dari internal harus diestimasikan dan jangan di share. Kemudian pakai sistem bilangan fibonaci yaitu: 1, 2, 3, 5, 8, 13, 21, 34, 55, dst. Setelah selesai, maka dilanjutkan dengan voting dan dan dikabarkan secara serentak (bukan diskusi). Mengapa tidak boleh diskusi? Karena kalau dengan diskusi nanti ada yang bakalan sok pinter dan sok tahu, jadi akan mendominasi yang menyebabkan hasilnya jadi tidak seragam. Kemudian tanyakan kepada masing-masing anggota kenapa memilih itu, kemudian voting lagi. Jika masih mendapatkan hasil tidak seragam, maka diambil saja rata-ratanya kemudian di catat dalam Card. Terakhir totalkan per sprint.

Secara singkat alurnya adalah sebagai berikut:

• Masing-masing internal estimasikan
• Jangan di share
• Pakai bilangan Fibonanci:
• 1, 2, 3, 5, 8, 13, 21, 34, 55, dst
• Setelah selesai → Voting → Serentak kabarkan
• Harus serentak BUKAN diskusi
• Kalau diskusi → yang pinter / sok tahu akan dominasi
• Jika tidak seragam
• Tanya masing-masing kenapa pilih itu
• Voting diulangi
• Juga tidak seragam → Ambil rata-rata
• Catat di card
• Totalkan per Sprint

 

8. Jelaskan langkah-langkah untuk melakukan estimasi kapasitas tim!

Jawab:

Untuk melakukan estimasi kapasitas tim, ada beberapa langkah yang harus dilakukan. Langkah untuk estimasi kapasitas tim yang pertama adalah menyepakati lamanya sprint, contohnya bisa 2 minggu - 10 hari kerja. Kemudian alokasikan waktu per anggota dan ingat kembali referensi 1 unit, masing-masing dalam 2 minggu bisa sanggup sampai berapa. Dilanjutkan dengan mengalikan alokasi dalam project. Contohnya Anggota 1 → 50 unit → 100% → 100% x 50 unit → 50 unit. Setelah itu baru kapasitas tim dijumlahkan semua, contohnya ada 104 unit. dan di akhir langkah sprint ini di evaluasi apakah bisa naik atau bisa turun, lama kelamaan akan menuju titik ekuilibrium.

 

9. Jelaskan apa yang dimaksud dengan Sprint Backlog!

Jawab:

Dalam Scrum juga dikenal dengan yang namanya Sprint Backlog. Yang dimaksud dengan Sprint Backlog adalah sekumpulan item Product Backlog yang telah dipilih untuk nantinya dikerjakan di dalam sprint. Di dalamnya juga terdapat rencana untuk mengembangkan potongan tambahan produk dan merealisasikan Sprint Goal. Sprint Backlog juga dapat menampilkan semua pekerjaan yang dibutuhkan, untuk dapat mencapai Sprint Goal yang telah dibuat oleh para tim Developer. Sprint Backlog ini merupakan sebuah rencana yang cukup detail, sehingga perubahan-perubahannya di tengah Sprint dapat dipahami saat Daily Scrum Meeting. Tim Pengembang memodifikasi Sprint Backlog sepanjang Sprint berlangsung. Sprint Backlog dapat berubah kapanpun juga sepanjang Sprint. Perubahan ini terjadi seiring dengan berkerjanya Tim Developer sesuai rencana pada saat itu, dan semakin meningkatnya wawasan tim untuk mencapai tujuan Sprint.

 

10. Jelaskan apa yang dimaksud dengan Sprint.

Jawab:

Sprint termasuk ke dalam salah satu acara yang ada dalam Scrum. Sprint merupakan sebuah susunan pengembangan dalam siklus kerja yang ada dalam Scrum. Sprint juga bisa dikatakan sebagai jantungnya dari Scrum. Sprint memiliki limit waktu yang akan berakhir walaupun pekerjaan yang dilakukan itu belum selesai. Dalam Sprint tidak boleh adanya perubahan yang dapat membahayakan dari tercapainya Sprint Goal. Selain itu kualitas dari Sprint Goal juga tidak boleh menurun. Setiap Sprint yang ada bisa dikatakan sebagai sebuah proyek dengan batasan waktu yang tidak lebih dari satu bulan. Jika jangka waktu Sprintnya terlalu panjang, maka definisi mengenai apa yang nantinya akan dibangun bisa saja berubah.

 

11. Jelaskan apa yang dimaksud dengan aspek desentralisasi dari Sprint

Jawab:

Aspek desentralisasi dari sprint adalah sebuah penyerahan kekuasaan kepada anggota (sadar diri) untuk melakukan sesuatu tanpa harus adanya komando. Dalam Scrum, goal-nya adalah mendesentralisasikan akuntabilitas dan kepemimpinan. Hal ini menyebabkan terbentuknya banyak orang dengan mental seorang pemimpin dalam sebuah project. Dalam Scrum, seluruh anggota Scrum Team akuntabel terhadap kesuksesan proyek, konsepnya adalah whole team accountability. Bahkan dalam Scrum peran seperti Technical Leader dianggap redundan dan cuma menambah overhead. Kontrol dari dalam dan desentralisasi akuntabilitas yang menyebabkan setiap anggota Scrum Team memiliki rasa kepemilikan yang tinggi terhadap produk yang dikembangkan.

 

12. Jelaskan apa yang dimaksud dengan Stadup Meeting pada Scrum.

Jawab:

Dalam Scrum juga dikenal dengan adanya Standup Meeting. Standup Meeting ini merupakan sebuah pertemuan di mana peserta biasanya berpartisipasi dalam pertemuan sambil berdiri. Ketidaknyamanan berdiri untuk waktu yang lama dimaksudkan untuk membuat pertemuan menjadi singkat. Biasanya Standup Meeting ini hanya berdurasi sekitar 15 menit saja. Dalam Standup Meeting ada 3 hal penting yang harus dilaporkan diantaranya adalah yang pertama apa saja yang telah dilakukan serta dicapai semenjak meeting terakhir hingga saat ini? Kedua adlaah apa saja yang akan dilakukan dan dicapai sebelum meeting selanjutnya? Dan terakhir adalah adakah rintangan yang menjadi hambatan dalam menyelesaikan pekerjaan? Standup Meeting juga sering disebut dengan Daily Standup Meeting.

 

13. Jelaskan kriteri untuk menentukan suatu User Story itu telah benar-benar selesai.

Jawab:

Acceptance merupakan salah satu kriteria bahwa suatu user story itu telah benar-benar selesai dilakukan. Acceptance Criteria menjelaskan ruang lingkup dari sebuah user story yang berupa daftar kriteria yang mengindikasikan sebuah story sudah diselesaikan. Acceptance Criteria nantinya akan menjad isebuah panduan bagi si end user dalam melakukan User Acceptance Test. Dengan acceptance test, masalah komunikasi antara development team dan klien bisa diminimalisirkan. Acceptance test akan menangkap ekspektasi dari klien lalu menyampaikan ekspektasi tersebut ke developer. Contoh Acceptance yang dibuat dari user story adalah: Sebagai peserta, saya ingin dapat mendaftar secara online, sehingga saya dapat mendaftar dengan cepat dan mengurangi dokumen. Selain itu kriteria lainnya yaitu:

• Checklist selesai
• Testing selesai
• Unit Test
• Integration Test
• Code review selesai

 

Nah sobat, itulah pembahasan soal mata kuliah Rekayasa Perangkat Lunak (RPL) tentang Agile, Scrum, Sprint, dan User Story. Semoga postingan ini dapat bermanfaat bagi kalian semua. Baca juga kumpulan soal RPL tentang naming convetion. Cukup sekian, wassalamu’alaikum and Be Prepared!