Scrum, dan Praktiknya dalam Dunia Nyata

Rendya Yuschak
5 min readMar 23, 2021

Baru-baru ini, pada mata kuliah PPL UI 2021, saya berkesempatan untuk melakukan pengembangan software dengan menggunakan metode Scrum. Saya dan tim saya mencoba mengikuti alur kerja Scrum dan ini adalah penjelasan dan opini saya mengenai metode tersebut.

Apa Itu Scrum?

Scrum adalah salah satu metode pengembangan software berbentuk Agile yang berfokus untuk menyelesaikan proyek secara adaptif dan efisien. Dari apa yang saya jalani, Scrum berusaha untuk membantu Scrum Team untuk berkomunikasi lancar dengan cara memastikan segala masalah yang muncul diangkat dan diselesaikan secepatnya.

Scrum Team

Scrum Team sendiri merupakan tim kecil yang terdiri atas :

  1. Product owner yang mempunyai fitur atau tugas yang dinamakan Product Backlog yang harus dikerjakan.
  2. Scrum Master yang akan menjadi pemimpin dari Dev Team dan mengatur pembagian Product Backlog yang ada.
  3. Dev Team yang akan mengerjakan product backlog.

Perlu diperhatikan bahwa scrum team tidak memiliki hierarki atau sub-team. Scrum team murni merupakan tim kecil yang berfokus menyelesaikan product backlog sehingga product goal dapat tercapai.

Scrum Events

Pada dasarnya ada 5 bagian pengerjaan dalam metodologi Scrum yaitu Sprint Planning, Sprint, Daily Scrum, Sprint Review, Sprint Retrospective. Masing-masing merupakan langkah penting dengan tujuan menyelesaikan product backlog seefisien mungkin. Saat Sprint dimulai, segala events di dalamnya sudah ditentukan waktunya dan tidak dapat diubah hingga Sprint planning berikutnya.

Sprint Planning

Photo by Headway on Unsplash

Sprint Planning adalah saat dimana tim berdiskusi mengenai product backlog yang ada. Disini tim akan mengatur, memberikan nilai dan membagi product backlog yang ingin dikerjakan, mengkonfigurasi durasi sprint, dan menjadwalkan waktu daily sprint.

Sprint

Ini merupakan bagian utama dari Scrum. Disini Dev Team akan mengerjakan Product Backlog Item (PBI) yang sudah diambil hingga selesai atau waktu sprint habis.

Dari pengalaman saya sendiri, meski PBI nanti dikerjakan sendiri-sendiri, ada kalanya suatu PBI mesti dikerjakan berbarengan. Bisa karena memang dibutuhnya kerja sama, atau mungkin karena salah satu anggota perlu bantuan oleh anggota lainnya. Yang penting, PBI bisa tercapai.

Daily Meeting

Daily Meeting merupakan bagian dimana anggota berdiskusi mengenai apa yang mereka sudah lakukan, apa hambatan yang ada, serta apa yang akan mereka lakukan selanjutnya. Biasanya Daily Meeting tidak begitu lama. kurang lebih 15 menit seharusnya cukup. Daily Meeting harus dilakukan sesering mungkin.

Dari pengalaman saya sendiri, biasanya setelah membahas hambat, kita biasanya memberikan ide atau solusi agar hambatan tersebut bisa hilang Contohnya seperti untuk mengerjakan bagian ini saya akan dipandu oleh anggota tim lain, atau saya akan memberikan referensi bagus mengenai bagian yang dikerjakan anggota lain.

Sprint Review

Sprint Review adalah bagian dimana tim melakukan review terhadap tugas yang mereka kerjakan, mulai dari PBI apa saja yang telah mereka selesaikan, PBI mana yang belum selesai dan sejauh apa progresnya, serta melihat kualitas hasil PBI yang ada.

Sprint Retrospective

Kalau tadi Sprint Review membahas mengenai hasil yang didapat, Sprint Retrospective membahas mengenai anggota tim. Disini anggota tim mengekspresikan apa saja hambatan selama sprint, dan mencari solusi untuk hambatan tersebut.

Pengalaman Saya saat Develop Aplikasi dengan Scrum

Kenalan dengan Scrum

Pada saat saya mengikuti mata kuliah PPL, kami diharap mengikuti framework scrum. Padahal saya sendiri belum pernah menggunakan metode pengembangan seperti itu. Begitu juga dengan teman se-anggota tim saya.

Namun, ketika dikenalkan dengan Scrum Master dan Product Owner, yakni Surya dan Gibran. Saya pun merasa lega karena mereka adalah teman seangkatan.

Saat bertemu pertama kali dengan klien, sejujurnya saya sendiri bingung karena apa yang diminta oleh klien berbeda dengan Product Requirement Document yang telah diberikan. Namun berkat bantuan dari Surya dan Gibran serta penjelasan dari kliennya sendiri, kami pun akhirnya dapat memulai sprint planning kami.

Berikut adalah PBI kami

Sprint Planning

Kami pun memulai Sprint Planning di discord server buatan sendiri. Disana kita diberikan task-task yang perlu dikerjakan dan memberikan bobot terhadapnya. Persis dengan apa yang saya pelajari mengenai Scrum. Salah satu hal yang menarik dari pemberian bobot adalah Surya memakai aplikasi untuk voting kira-kira seberapa besar bobot dari suatu task, kemudian dipersilahkan bagi kami dev team untuk mendiskusikan bobot yang pas untuk task tersebut.

Sprint

Setelah beberapa kali sprint, kami sadari bahwa lebih baik langsung bagi tugas mengambil task yang ada, lalu disesuaikan saat pengerjaan task. Sehingga setelah memberikan bobot saat sprint planning, kami langsung mengambil task yang kami anggap bisa dikerjakan.

Kemudian kami pun mengerjakan tasknya masing-masing, dan update status pengerjaan task pada Gitlab board.

Dengan Gitlab Board, kami bisa tahu siapa yang sudah mengerjakan apa

Daily Meet

Namun dengan melihat Gitlab Board saja tidak cukup. Kami melakukan Daily Meet tiap hari Kamis dan Minggu di Discord. Disitu kami menjelaskan apa saja yang sudah dikerjakan, hambatan yang ada, serta apa yang akan dilakukan.

Setelah beberapa kali Sprint, saya (dan mungkin anggota dev team lainnya) sadari bahwa penting untuk membantu anggota tim lainnya apabila hambatan yang dilaluinya cukup berpengaruh terhadap produktivitas kelompok. Saya sendiri, contohnya mendapatkan hambatan karena belum pernah memakai API mapbox, namun setelah memberi tahu kepada teman-teman saat Daily Meet, ada teman yang mau bantu ajarin bagaimana cara menggunakannya.

Sprint Review

Setelah menyelesaikan task-task yang ada, kami mempresentasikan hasil pekerjaan kami kepada Klien dan Dosen (untuk penilaian Mata Kuliah). Kami juga menjelaskan concern yang ada serta menjelaskan kesulitan yang ada. Tanggapan dan saran dari mereka, cukup konstruktif untuk sprint selanjutnya.

Sprint Retrospective

Setelah Sprint Review, kami pun melakukan Sprint Retrospective. Surya selaku Scrum Master menggunakan Aplikasi Metroretro.io untuk memudahkan kami melakukan retrospective, dengan menuliskan hal yang mulai harus dilakukan, harus diberhentikan, dan hal yang harus diteruskan.

Kami sadari bahwa lebih baik blak-blak an disini daripada masalah muncul kembali saat sprint selanjutnya. Sehingga meski ada sedikit bercanda saat retrospective, kami tetap menjalaninya dengan penuh perhatian.

Seperti yang saya bilang, meskipun ada sebagian yang bercanda, namun hasil retrospective tetap diperhatikan dan dilakukan

Kesimpulan

Akhir kata, Scrum merupakan metode yang lumayan efektif dalam mengembangkan software dengan tim. Saya sendiri memiliki pengalaman yang cukup menyenangkan menggunakan metode ini dalam mengembangkan aplikasi. Saya harap dengan cerita ini para pembaca tertarik untuk menggunakan scrum agar dapat melihat seberapa efektifnya dalam mengembangkan suatu proyek.

Sekian itu saja cerita saya mengenai Scrum yang bisa saya bagikan pada artikel ini. Sampai jumpa lagi pada artikel lainnya👋.

--

--

Rendya Yuschak
0 Followers

Pelajar yang sedang belajar cara refaktoring hidupnya sendiri