The Importance of Team Work with Appropriate Tools Supporting It
Haloo! Gimana kabar temen-temen? Baik-baik aja kan?
Pada kesempatan kali ini, kita akan mencoba membahas tools-tools yang akan berguna banget nih untuk dipakai di dalam sebuah tim, dan untuk menjaga produktivitas dan semangat di dalam tim.
Pernah ga sih misalnya temen-temen ketemu bug nih, terus waktu lagi berusaha fix bug tersebut, ketemu 2 atau 3 bug lainnya, terus setelah beberapa hari kemudian, bug yang pertama sudah di-fix dan kini mau fix bug berikutnya. Eh pas mau mulai nge-fix, kita udah lupa bug yang kemarin ada apa aja. Mungkin hanya inget 1 atau 2 bug aja dari antara 3 bug yang ada. Kalau kayak gitu pasti bakal ngerugiin banget dong?? Waktu kita habis untuk mengingat kembali dan mencoba kembali. Selain itu, kita juga jadi tidak tenang tidur sebelum bug itu berhasil kita ingat kembali hehe. Oleh karena itu, pada kesempatan kali ini, kita akan bahas pentingnya menggunakan tools-tools yang baik dan tepat!
Yaudah kalau gitu daripada lama-lama, kita langsung coba lihat contoh-contohnya sambil kita bahas yuk!
Contoh Penerapan pada Proyek PPL
Sejauh ini, terdapat 4 tools yang kami gunakan dalam membangun software Kembara.
1. Gitlab Commits
Gitlab/Git Commits dapat dikatakan sebagai suatu hal yang paling mendasar di dalam dunia pemrograman dan software engineering. Commit merupakan suatu tindakan untuk menyimpan progress kode. Commit juga dapat dikatakan sebagai suatu catatan history terkait perubahan dan perkembangan kode pada proyek kita. Commits juga menyimpan mengenai deskripsi kita terkait perubahan kode yang sedang terjadi.
Terdapat beberapa hal yang perlu diperhatikan dalam membuat commits. Yang pertama, berikanlah nama deskripsi commit yang mudah dimengerti dan menjelaskan terkait perubahan-perubahan yang kita buat. Yang kedua, buatlah commit-commit yang kecil dan managable. Tidak apa-apa jika jumlah commitnya terasa jadi sedikit lebih banyak.
Mengapa ini penting? Misal ibaratkan kita tidak memberikan nama commit yang deskriptif, ketika suatu saat ternyata terdapat fitur kita yang ditolak oleh Product Owner ataupun fitur kita yang menyebabkan kerusakan pada fitur lain, maka kita ingin segera melakukan revert (simpelnya membatalkan commit tersebut). Dengan nama commit yang kurang deskriptif, akan sulit bagi kita untuk mencari commit tersebut. Bisa-bisa malah kita me-revert commit yang salah wkwkwk. Tak hanya itu, nama commit yang deskriptif juga membantu kita track kembali perubahan-perubahan yang telah dilakukan apabila suatu saat kita perlu melihat kembali historynya.
Sementara itu untuk ukuran commit, biasanya semakin besar ukuran masing-masing commit yang kita lakukan, semakin sulit juga kita memberikan nama commit yang singkat dan deskriptif. Sebab, commit yang besar biasanya melakukan banyak hal sekaligus, sehingga kita cenderung jadi sulit memberikan nama yang dapat mewakili semua hal tersebut. Selain itu, hal ini juga dapat mempengaruhi fleksibilitas kita dalam melakukan beberapa hal tertentu, misalnya git revert. Misal apabila kita melakukan commit berukuran besar yang mengimplementasi 2 fitur sekaligus, ketika kita ingin menghapus/me-revert salah satu fitur saja, kita akan jadi sedikit kesulitan karena kita sudah sempat melakukan commit pada 2 fitur tersebut sekaligus. Alasan lainnya ialah jika kita melakukan commit yang terlalu besar, biasanya itu tanda-tanda kalau kita jarang melakukan commit. Hal ini bisa menjadi masalah apabila misalnya komputer kita, konfigurasi kita, ataupun bahkan kode kita sendiri mengalami suatu masalah yang mengacaukan/merusak isi file-file program kita. Pasti sayang banget kalo semua kerjaan jadi hilang ga sering di commit 🥲☹️
2. Gitlab Merge Request
Biasanya, ketika kita mengerjakan suatu fitur, kita mengerjakannya dalam branch tertentu terlebih dahulu. Hal ini memungkinkan kita push commits kita tanpa menyebabkan developer lain menerima commit kita secara langsung. Nanti, apabila kita sudah selesai mengembangkan fitur tersebut, sudah mengujinya dan memastikannya berhasil, kita akan melakukan merge request (biasanya ke branch utama seperti main atau staging). Merge request merupakan sebuah permintaan untuk menggabungkan perubahan yang telah kita lakukan supaya perubahan kita dapat dirasakan oleh developer lain ataupun oleh pengguna aplikasi. Setelah semua developer setuju terhadap perubahan tersebut, maka branch tersebut akan digabungkan ke branch utama.
Dalam membuat merge request, sangat penting memberikan merge request dengan judul yang deskriptif, dan keterangan yang deskriptif. Kita juga perlu memastikan bahwa kita telah mengikuti aturan-aturan tim yang ada, misalnya format judul merge request, minimal coverage tim, policy dan syarat dalam melakukan merge, dan lain sebagainya.
Mengapa ini penting? Untuk judul yang deskriptif, keterangan yang deskriptif, dan format judul merge request, tentu supaya lebih mudah dipahami dan enak dibaca. Sedangkan untuk syarat merge, misal kita tidak mematuhi syarat merge ke staging dengan minimal persetujuan 2 developer lainnya. Apabila ternyata suatu waktu kodingan kita ternyata mengalami suatu masalah, entah itu bug ataupun poor maintainability, tentu akan merugikan dan membuat kesal anggota-anggota tim lainnya. Jika seandainya setidaknya sudah ada 2 orang yang me-review kode kita, maka peluang kode kita masih kurang maintainable ataupun mengalami bug akan diminimalisir. Sementara itu, untuk coverage, pada tim kami coverage tidak boleh berkurang dari coverage sebelumnya. Seandainya kita tidak mematuhi syarat ini, maka kita akan cenderung menjadi malas dalam mengerjakan coverage. Dengan begitu, secara perlahan-lahan akan muncul semakin banyak baris kode yang tidak ter-cover. Tentu hal ini dapat meningkatkan potensi munculnya bug yang tidak terduga.
3. Gitlab Issues
Ketika terdapat suatu issue, misalnya bug ataupun masalah UI/UX, segeralah mendaftarkannya pada Issues gitlab. Pada kelompok kami, kami mendaftarkan masalah-masalah yang ditemui, misalnya permasalahan UI/UX ataupun bug functionality pada issues gitlab. Tentu dengan format yang konsisten, dan deskripsi issues yang mudah dimengerti.
Mengapa kita perlu membuat issues pada gitlab? Terdapat beberapa hal buruk yang mungkin terjadi apabila kita tidak mendaftarkan issues pada gitlab. Yang pertama, kita jadi sulit membedakan mana issue yang sudah di-fix, dan mana yang belum. Yang kedua, terkadang terdapat beberapa issues yang terlewat/terlupakan karena tidak segera dicatat pada media tertulis. Yang ketiga, kita jadi tidak dapat memantau history issues yang sudah diselesaikan, termasuk commit bagian mana yang melakukan fix terhadap masalah tersebut. Yang keempat, kita jadi tidak memiliki tempat/forum untuk klarifikasi terkait suatu issue.
4. Trello Scrum Board
Scrum board merupakan tools di mana kita dapat track progress kita, termasuk fitur-fitur apa saja yang masih perlu dilakukan di sprint ini, fitur apa saya yang perlu dilakukan di sprint kedepannya, fitur-fitur apa saja yang sedang berjalan (beserta penanggung jawabnya), serta fitur-fitur apa saja yang sudah selesai. Pada kelompok kami, kami menggunakan Trello untuk scrum board.
Sama seperti gitlab issues, scrum board dapat membantu melacak mana saja yang ingin dikerjakan pada sprint ini, mana saja yang dikerjakan pada sprint kedepannya, dan mana saja yang sudah selesai dikerjakan. Apabila seandainya kita tidak memiliki scrum board, akan sulit untuk men-track tugas-tugas apa saja yang sudah atau belum dikerjakan. Selain itu, misal apabila terdapat suatu fitur A yang bergantung pada fitur B dan tidak ada scrum board, bisa saja terjadi kebingungan ketika developer fitur A butuh berkomunikasi dengan developer fitur B. Sebab, sangat memungkinkan apabila kita tidak hafal semua daftar fitur beserta developer yang bertanggung jawab. Oleh karena itu ketiadaan scrum board akan mempersulit proses komunikasi dan development, terlebih lagi untuk aplikasi yang besar seperti google atau semacamnya.
5. Echometerapp Sprint Retrospective
Selain keempat tools di atas, kami juga menggunakan tools echometer ketika kami melaksanakan Sprint Retrospective. Sprint Retrospective merupakan salah satu kegiatan pada akhir sprint di mana kita merefleksikan kembali hal-hal yang telah kita lalui di sprint tersebut. Kita biasanya akan refreshing, bermain semacam games pembuka, kemudian kita merefleksikan apa yang sudah bagus, apa saja tantangan yang dialami, dan apa saja hal-hal yang merugikan kita. Hal ini berguna dalam merefleksikan kembali kinerja tim, sehingga tim dapat bekerja lebih baik lagi kedepannya.
Salah satu hal mengapa kita butuh tools tersendiri dalam melaksanakan Sprint Retrospective ialah supaya kita menjadi lebih lancar dan lebih nyaman dalam menyampaikan pendapat. Kita dapat memanfaatkan UI yang nyaman untuk dengan mudah mencatat dan mengkategorikan suatu masalah. Kita jadi tidak perlu menghafalnya. Selain itu, beberapa tools sprint retrospective menyediakan game-game pembuka menarik, ataupun ice breaking menarik yang dapat meningkatkan mood positif dan keakraban, serta merendahkan ketegangan di dalam tim sebelum memasuki inti utama dari sprint retrospective. Oleh karena itu, sebuah tools Sprint Retrospective yang baik juga akan sangat membantu tim dalam melangkah lebih jauh lagi.
6. Burndown Chart
Tools lainnya yang kami gunakan pada proyek akhir PPL kami adalah Burn Down Chart. Apa itu burn down chart? Burndown chart merupakan suatu grafik yang menampilkan jumlah pekerjaan (biasanya dalam satuan story points) yang belum selesai dan masih harus dikerjakan sebagai sumbu vertikal, dan waktu dari awal sprint sampai akhir sprint sebagai sumbu horizontal.
Mengapa kita memerlukan burndown chart? Burndown chart dapat sangat membantu kita dalam merencanakan strategi untuk mencapai tujuan dengan tepat waktu. Selain itu, chart ini juga membantu kita mencari keseimbangan jam kerja sehingga jam kerja kita tidak terlalu sedikit tetapi juga tidak terlalu berlebihan.
Terdapat beberapa hal buruk yang mungkin kita alami apabila kita tidak memanfaatkan burndown chart. Yang pertama, workload kita dari hari ke hari menjadi tidak balance. Misalnya, bisa saja kita terlalu santai sehingga terburu-buru di akhir deadline, ataupun bisa saja kita terlalu terburu-buru, sehingga bisa menimbulkan kelelahan atau bahkan burnout pada anggota tim. Tentu kita tidak mau ada tim yang burnout karena hal ini dapat menimbulkan penurunan performa tim kita dan kesejahteraan tim. Yang kedua, apabila kita tidak menggunakan burndown chart, kita menjadi lebih kesulitan untuk menganalisis pola dan kebiasaan dari team, misalnya apakah development hanya cepat di awal, hanya cepat di akhir, atau stabil. Kita juga jadi sulit mengalasis penyebab progress tim lambat pada momen-momen tertentu. Apabila kita punya burndown chart, kita bisa melihat tanggal dimana progress berjalan dengan lambat, dan kemudian kita bisa mencoba mengingat apa saja hal-hal yang terjadi pada tanggal tersebut yang menyebabkan penurunan performa tersebut. Yang ketiga, apabila tidak ada burndown charts, kita menjadi lebih sulit dalam menentukan velocity dari team kita, sehingga pada sprint planning berikutnya sangat mungkin kita mengambil terlalu banyak backlog story points ataupun terlalu sedikit backlog story points. Yang keempat, tidak ada burndown charts dapat menyebabkan sebagian jenis orang menjadi mudah anxious. Sebagian orang (termasuk saya) cukup mudah untuk merasa cemas ketika mendapatkan banyak tugas dalam jangka waktu tertentu (misalnya 1 minggu). Sebenarnya kami mungkin bisa mengerjakan tugas-tugas tersebut dengan tepat waktu, tapi kami sering kali mengalami anxious dan selalu berpikir bahwa tidak sempat untuk mengerjakan hal-hal tersebut. Akhirnya, terkadang kami menjadi kurang tidur, terlalu banyak begadang, ataupun mem-push teman-teman yang lainnya untuk mengikuti pace kami. Dengan adanya burndown charts, kami menjadi bisa mengatur ekspektasi yang lebih realistis, sehingga menjadi lebih lega dan tidak mudah cemas. Empat alasan ini tentulah hanyalah beberapa alasan di antara sekian banyak alasan mengapa kita perlu menggunakan burndown charts. Oleh karena itu aku nyaranin temen-temen buat coba menggunakan burndown charts juga!
Bonus Article
Ketika membuat merge request ataupun issues pada gitlab, terkadang anggota timku memiliki format yang berbeda-beda dan tidak konsisten. Kira-kira apakah ada solusinya?
Format issues ataupun merge request yang tidak konsisten antar anggota dapat disebabkan oleh banyak faktor. Tetapi, salah satu faktor yang mungkin mendasarinya adalah ketidaktahuan, atau tidak adanya waktu/tenaga untuk mencari template tersebut dan copy paste setiap kali membuat issues/merge request baru. Untungnya, gitlab memiliki solusi atas hal ini, yakni Templates untuk issues dan merge request. Teman-teman dapat mengakses Repository settings > General > Default description template for issues untuk menambahkan template yang akan muncul setiap kali kita membuat issues baru. Untuk merge request, template ini dapat dikonfigurasi pada Repository settings > Merge Requests > Default description template for merge requests. Dengan menambahkan template, anggota tim akan dengan mudah mengetahui adanya requirement format tersebut, serta menjadi lebih hemat waktu dan tenaga tanpa perlu copy-paste secara manual.
Terkadang aku ingin melacak commit mana yang melakukan fixing terhadap suatu issues, bagaimana caranya?
Salah satu cara untuk mempermudah masalah seperti ini adalah dengan menyertakan ID issue pada commit message, ataupun dengan cara mention commit SHA ketika kita ingin menutup suatu issue. Dengan begitu, kita akan dengan lebih mudah melacak keterhubungan antara suatu issue dengan suatu commit. Untuk mention ID Issue, cukup tambahkan saja #ID_ISSUE pada commit message, misalnya pada commit message 2 baris terakhir. ID Issue dapat dilihat ketika kita mengunjungi halaman issue tersebut. Untuk commit sha, dapat dilihat di Gitlab pada bagian kiri atas, atau dapat dilihat menggunakan IDE favorit masing-masing.
Sekian dari saya, semoga semua informasi yang telah saya bagikan dapat membantu dan bermanfaat bagi temen-temen semua. Happy coding!