Empowering Team Work & Collaboration : Unlocking Software Development Productivity with Scrum

9 min readMar 5, 2024

“When you hand good people possibility, they do great things.” - Biz Stone

Dalam lingkungan kerja pada pengembangan perangkat lunak, kerja tim merupakan salah satu aspek penting dan fondasi yang mempengaruhi kesuksesan sebuah proyek. Di tengah lingkungan yang dinamis dengan berbagai tugas, klien, dan anggota tim yang beragam, kemampuan untuk bekerja secara efektif sebagai tim tidak hanya meningkatkan produktifitas, namun memungkinkan anggota tim untuk berkolaborasi dalam mencapai tujuan bersama. Selain itu, keberagaman pendekatan dan solusi yang muncul dari kolaborasi ini mendorong inovasi baru yang tidak mungkin tercapai secara individu.

Metodologi Scrum

Salah satu pendekatan kolaborasi dalam software development adalah dengan metodologi Scrum. Metodologi Scrum adalah pendekatan Agile yang dirancang untuk mengingkatkan produktivitas selama siklus pengembangan produk. Dalam Scrum, tim terdiri dari 3 peran utama, yaitu :

Product Owner
Product Owner bertanggung jawab stama stakeholder dalam tim Scrum. Mereka memastikan bahwa kebutuhan dan ekspektasi stakeholder diwakili dalam perencanaan dan pengembangan produk. Mereka juga perlu memastikan bahwa semua stakeholder dan anggota tim Scrum memiliki pemahaman yang jelas dan seragam tentang visi produk tersebut. Selain itu, Product Owner bertugas untuk mengelola Product Backlog, yang merupakan daftar semua fitur, fungsi, persyaratan, peningkatan, dan perbaikan yang diperlukan untuk produk.
Scrum Master
Scrum Master bertanggung jawab untuk memfasilitasi pertemuan Scrum (Sprint Planning, Daily Scrum, Sprint Review, dan Sprint Retrospective) dan memastikan bahwa proses berlangsung lancar dan efisien sesuai dengan prinsip Scrum.
Development Team
Development Team merupakan sebuah tim lintas fungsi (desain, pengembangan, QA (Quality Assurance), dan lain-lain) yang bertanggung jawab untuk merancang, mengembangkan, dan menguji produk. Tim ini bekerja secara kolaboratif untuk mengirimkan increment produk yang berpotensi dapat dirilis di akhir setiap Sprint dan mencapai tujuan yang ditetapkan pada awal setiap Sprint.

Tahapan pada metode Scrum adalah sebagai berikut :

Inisiasi (Inception/Sprint 0)
Fase inisiasi adalah periode di mana Product Owner melakukan persiapan dengan mendefinisikan dasar-dasar proyek berdasarkan kebutuhan stakeholder dan memastikan semua anggota tim memiliki pemahaman yang seragam. Setelah itu, terdapat langkah-langkah yang biasanya terlibat dalam fase inisiasi :
- Product Requirement Document (PRD) : Dokumen yang berisi panduan mengenai kebutuhan dan ekspektasi fungsi produk yang berfungsi sebagai referensi utama bagi stakeholder dan anggota tim Scrum lainnya. Panduan bagaimana cara mengisi PRD dapat diakses pada link berikut.
- Product Backlog (User Stories) : Dokumen yang berisi daftar semua hal yang perlu dilakukan dalam proyek seperti user stories, tugas teknis, penanganan bug, dan lainnya. User Stories adalah deskripsi singkat dari fitur yang ditulis dari perspektif pengguna. User stories didefinisikan menggunakan format: “As a [SUBJECT], I want to [WHAT], so I can [WHY].” Ini membantu memastikan bahwa tim memahami siapa yang akan mendapatkan manfaat dari fitur tersebut (SUBJECT), apa fitur tersebut (WHAT), dan mengapa fitur itu penting (WHY).
Sprint Planning
Sprint Planning adalah sesi perencanaan di mana tim memutuskan pekerjaan apa yang akan dilakukan selama Sprint berikutnya dan merencanakan bagaimana pekerjaan tersebut dapat dilakukan. Durasi dari Sprint biasanya 2–4 minggu sehingga semua anggota tim wajib memiliki pemahaman yang sama dan berkomitmen untuk mencapai tujuan Sprint. Pada Sprint Planning, tim Scrum perlu memastikan untuk menetapkan tujuan Sprint dan memilih user story yang seimbang dengan tujuan tersebut. Setiap user story harus memiliki estimasi story point dan harus cukup di mana jika terlalu besar, perlu dipecah menjadi user story atau task yang lebih kecil. Setiap user story harus memiliki Definition of Done dan Acceptance Criteria yang jelas. Akhirnya, tentukan prioritas dan tetapkan penanggung jawab untuk masing-masing user story. Manajemen user story dan task dapat dilakukan dengan menggunakan project management tools seperti Jira, Asana, dan lainnya.
Daily Scrum
Daily Scrum adalah pertemuan singkat setiap hari untuk menyampaikan update kemajuan pengerjaan ataupun mengidentifikasi adanya error/bug. Daily Scrum berlangsung singkat, biasanya 20 menit. Setiap anggota tim wajib menjawab tiga pertanyaan utama :
- Apa progress yang telah dikerjakan?
- Apa yang sedang atau akan dikerjakan selanjutnya?
- Apakah terdapat hambatan dalam proses pengerjaan?
Sprint Review
Sprint Review adalah pertemuan yang diadakan di akhir Sprint untuk menunjukkan pekerjaan yang telah selesai. Pada pertemuan ini, semua tim Scrum dan stakeholder akan berkumpul untuk meninjau pekerjaan yang telah diselesaikan selama Sprint, seperti dengan melakukan demonstrasi produk kepada stakeholder. Kemudian, semua anggota dapat menentukan pekerjaan yang mungkin diperlukan ke depannya.
Sprint Retrospective
Sprint Retrospective adalah sesi di mana semua anggota tim meninjau keberhasilan dan kegagalan Sprint yang baru berakhir serta merefleksikan kegagalan tersebut. Tujuannya adalah untuk mengidentifikasi apa yang sudah dikerjakan dengan baik, apa yang belum, dan bagaimana cara memperbaikinya.

Implementasi Scrum

Pada mata kuliah proyek perangkat lunak, tim saya yang beranggotakan 6 orang, dibagi menjadi 3 peran dengan komposisi sebagai berikut: Product Owner (2 orang), Scrum Master (1 orang), dan Development Team (3 orang). Untuk mata kuliah ini, Product Owner dan Scrum Master perlu melakukan development produk juga.

Tahapan Scrum dimulai dengan fase inisiasi di mana kami bertemu dengan stakeholder dari Fakultas Ilmu Keperawatan. Beliau meminta kami untuk mengembangkan sebuah permainan edukatif tentang manajemen penyakit talasemia. Tujuan dari permainan ini adalah untuk meningkatkan adaptasi dan kepatuhan terhadap terapi kelasi besi pada anak-anak dengan talasemia, khususnya yang berusia prasekolah (3–5 tahun). Setelah berdiskusi, kami menyusun PRD dan Product Backlog yang dibutuhkan berdasarkan requirements dari stakeholder. Kami menggunakan documenting tools seperti Google Docs untuk berkolaborasi dalam membuat, menyunting, dan berbagi dokumen-dokumen tersebut.

Selanjutnya, kami melakukan sesi Sprint Planning, di mana kami menetapkan fitur-fitur yang akan kami kembangkan selama Sprint berikutnya, menilai story point untuk setiap tugas, dan menugaskan tugas tersebut kepada developer yang sesuai. Untuk pengelolaan proyek, kami memilih Jira, sebuah aplikasi yang menawarkan kemudahan dalam meng-assign pekerjaan kepada anggota tim, membuat backlog yang mencakup deskripsi, story point, dan assignee-nya, serta menyediakan Scrum Board yang efektif untuk memonitor progres pekerjaan selama Sprint berlangsung.

1. Jira Backlog

Pada Jira, Backlog adalah kumpulan semua tugas, fitur, perbaikan bug, dan pekerjaan lainnya yang diperlukan untuk menyelesaikan sebuah proyek dalam proses pengembangan.

Contoh Backlog pada Jira — Dokumentasi Pribadi

Kita juga dapat membuat Issue, yaitu informasi mendetail tentang tugas, termasuk deskripsi, prioritas, penugasan, dan status dari tugas tersebut.

Contoh Issues pada Jira — Dokumentasi Pribadi

2. Jira Scrum Board

Jira Scrum Board berfungsi untuk membagi pekerjaan menjadi beberapa kolom yang mewakili tahapan pekerjaan, seperti “To Do,” “In Progress,” dan “Done.” Tujuannya adalah agar semua anggota tim dapat melihat secara visual tugas apa yang sedang dikerjakan, siapa yang bertanggung jawab atas tugas tersebut, dan apa yang telah selesai.

Contoh Scrum Board pada Jira — Dokumentasi Pribadi

Selama Sprint berlangsung, kami menggunakan version control systems, salah satunya adalah Github untuk mengatur dan memudahkan manajemen kode dari semua anggota tim dalam satu tempat. Pada Github, kami dapat dengan mudah melakukan software development dengan fitur-fitur yang menunjang pekerjaan seperti merge request dan commit message.

2. GitHub Pull Request

Pull request atau seringkali dikenal sebagai merge request adalah fitur yang memungkinkan developer untuk mengajukan perubahan kode yang telah mereka buat ke dalam cabang (branch) kode utama / production maupun cabang sementara / staging. Tujuannya adalah untuk memfasilitasi code review oleh anggota tim lainnya sebelum perubahan tersebut digabungkan sehingga tim dapat memastikan bahwa kode yang diintegrasikan memenuhi standar kualitas yang telah ditetapkan dan dapat bekerja sesuai rencana. Selain itu, pull request dapat mengurangi kemungkinan konflik kode sehingga proses pengembangan lebih aman.
Panduan pull request pada GitHub dapat dilihat pada link berikut.

Contoh Pull Request — Dokumentasi Pribadi

3. GitHub Commit Message

Commit message adalah deskripsi singkat dari perubahan yang dilakukan pada repositori kode. Anggota tim harus memberikan pesan commit yang efektif sehingga anggota tim lainnya dapat memahami apa yang telah diubah tanpa harus menelusuri kode secara detail. Kami juga menerapkan metodologi Test-Driven Development (TDD) sehingga perlu menerapkan commit message dengan prinsip red-green-refactor. [RED] digunakan untuk kode testing, [GREEN] digunakan untuk implementasi kode dari testing yang telah berhasil, dan [REFACTOR] digunakan untuk perbaikan implementasi kode dengan refactoring.

Contoh Commit Message — Dokumentasi Pribadi

4. Remote Communication Tool (Discord)

Kami juga melakukan Daily Scrum yang dilakukan setiap minggu secara asinkronus maupun sinkronus. Jika asinkronus, kami menggunakan tools seperti Discord untuk membantu tim dalam melaksanakan Daily Scrum secara virtual seperti dengan menggunakan fitur chat, streaming, dan video call. Selain itu, kami mengintegrasikan Github dengan Discord Webhook sehingga setiap kali ada perubahan dalam repository Githup, notifikasi akan secara otomatis terkirim ke channel Discord secara real-time.

Contoh Daily Scrum — Dokumentasi Pribadi

5. FigJam Sprint Retrospective

Pada akhir Sprint, tim Scrum akan melakukan Sprint Review bersama stakeholder dan dilanjut dengan Sprint Retrospective, untuk merefleksikan kembali apa yang telah dicapai selama sprint tersebut, mulai dari hambatan yang dihadapi dan pencapaian yang didapat. Dalam pelaksanaannya, kami menggunakan Figma dengan template retrospective yang dapat diakses di link berikut. Template tersebut menyediakan struktur yang terorganisir dengan kerangka kerja “Start, Stop, Continue”, yang membantu tim mengidentifikasi tindakan baru yang dapat dimulai, tindakan yang perlu dihentikan, dan tindakan yang perlu dipertahankan untuk meningkatkan kinerja tim di masa depan.

Contoh Sprint Retrospective — Dokumentasi Pribadi

Manfaat & Dampak Penggunaan Team Tools

Setelah mengakhiri Sprint, saya dan anggota kelompok lainnya merasakan kemudahan dan efisiensi pada proses kolaborasi dan pengembangan perangkat lunak. Tools seperti Github, Jira, Figma, Discord, Google Docs, dan masih banyak lainnya bermanfaat dalam memfasilitasi komunikasi yang lebih baik dan kolaborasi yang lebih baik antar anggota tim. Selain itu, penggunaaan Discord WebHook yang diintegrasikan dengan GitHub berguna agar kami dapat mengidentifikasi dan mengatasi masalah yang terjadi saat commit, memudahkan anggota lainnya untuk meng-approve suatu pull request, dan mengidentifikasi apakah CI/CD suatu commit berjalan hingga sukses. Manfaat dari penggunaan alat-alat ini, saat dibandingkan dengan pengalaman dari proyek-proyek lain yang tidak menggunakan alat-alat tersebut tentu sangat berbanding terbalik. Dengan mengintegrasikan metodologi Scrum dan tools-tools penunjangnya dalam rutinitas kerja tim, kelompok kami dapat mencapai hasil pengembangan yang lebih baik.

Bonus : Isu-Isu Penerapan Tools

Q1 : Pesan Pull Request maupun Commit Message tidak konsisten

Untuk menangani permasalahan ini, tim saya sedari awal melakukan perjanjian mengenai konten apa yang seharusnya ditulis pada pull request. Berikut tips yang kami gunakan:

Judul PR harus ringkas dan jelas pada tugas yang dikerjakan pada PR tersebut.
Isi dari PR harus menjelaskan mengenai hal-hal berikut :

Description : menjelaskan deskripsi singkat seperti fitur apa yang ditambahkan, mengapa, dan bagaimana fitur tersebut bekerja.
Code Coverage : tangkapan layar code coverage menggunakan flutter coverage ataupun SonarQube.
Attachment : tangkapan layar berupa video atau foto berupa tampilan layar ataupun demonstrasi singkat dari pengerjaan.

Berikut contoh PR yang baik dan jelas :

Kemudian, untuk commit message, kami menggunakan Test-Driven Development sehingga kami menggunakan Red, Green, Refactor dalam awalan commit message.

[RED] : menulis test untuk fungsionalitas yang akan diimplementasikan.
[GREEN] : menulis kode implementasi yang diperlukan untuk membuat test tersebut berhasil
[REFACTOR] : memperbaiki struktur kode yang sudah ada agar lebih efisien, mudah dibaca, dan mudah dipelihara, tanpa mengubah requirements dari kode tersebut.

Tips : Awali dengan Red, Green, Refactor yang sesuai, kemudian pesan yang menjelaskan apa pekerjaan yang dilakukan pada commit tersebut secara singkat, jelas, dan padat.

Berikut contoh commit message :

Q2 : Ingin mengetahui bagian code dikerjakan oleh siapa

Semisal, Anda ingin mencoba melakukan perbaikan pada sebuah kode yang membuat bug, namun anda tidak tahu siapa yang mengerjakan commit tersebut. Salah satu solusinya adalah dengan menelusuri file tersebut pada repository GitHub dan melihat commit history-nya. Namun, ada cara lain yang lebih praktis, yaitu dengan meng-install extension GitLens pada Visual Studio Code.

Dengan GitLens, kita dapat melihat perubahan kode dan memahami sejarah fungsi atau metode tertentu. Fitur ini memberikan informasi berguna tentang riwayat modifikasi langsung di atas setiap blok kode.