Sprint 3: Flashback

Tidak terasa tim kami sudah memasuki sprint terakhir dari pengembangan proyek kami pada mata kuliah PPL ini. Mari kita flashback ke awal masa pengembangan.

Project Vision

Sebelum memasuki masa pengembangan, tim kami diminta untuk membuat project vision sebagai gambaran akan seperti apa produk yang kami kerjakan. Lalu, apa saja yang perlu diperhatikan pada project vision? Menurut martin fowler, berikut ini merupakan beberapa poin yang menjadi nilai utama pada project vision:

Final Client pada produk kami tidak lain merupakan bagian yang memiliki peran pada sistem kenaikan jabatan, yaitu Fakultas, Sekretariat SDM, dan Dewan Guru Besar. 3 peran tersebut memiliki tugas masing-masing pada sistem ini. Selain itu, terdapat user non-registrar yang dapat melihat profile CYD.

Problem atau Permasalahan pada sistem yang sudah berjalan (konvensional, manual) yaitu pemantauan riwayat rekomendasi tidak praktis karena pemantauan hanya dilakukan melalui email, pembaharuan informasi status aplikasi lambat karena tidak setiap terjadi perubahan status akan dilaporkan saat itu juga sehingga terdapat celah waktu dari saat terjadi perubahan hingga dilakukan pembaharuan informasi status, dan ruang arsip berkas terbatas karena berkas masih berupa fisik (kertas) yang berarti tempat penyimpanannya yang berupa gudang atau sejenisnya pasti memiliki batas penyimpanan yang relatif tidak banyak.

Product yang kami tawarkan sebagai solusi untuk permasalahan tersebut adalah Lipsy (Lectureship Promotion System) atau Sistem Pemantauan Kenaikan Jabatan.

Product Category dari Lipsy ini berbasis web, sehingga masing-masing peran pada sistem ini cukup melakukan login dan dapat dengan mudah melakukan tugas mereka dan melakukan pemantauan. Kedua, sistem yang kami buat dapat menyimpan hasil rapat DGB pada masing-masing CYD. Ketiga, sistem kami akan memberikan notifikasi berupa email kepada peran terkait pada saat terdapat aktivitas pada suatu aplikasi.

Key-Benefits merupakan manfaat dan alasan kenapa diperlukan suatu produk sebagai solusi dari permasalahan yang ada. Sistem kami tidak menyimpan berkas CYD secara fisik, sehingga tidak membutuhkan tempat seperti gudang dan sejenisnya dan kapasitas penyimpanan akan relatif lebih besar dan lebih teratur. Berkas tidak perlu dikumpulkan secara fisik karena cukup diunggah melalui sistem kami dan pengecekan berkas cukup mengunduh dari sistem kami pula. Jika pada sistem yang sedang berjalan sekarang kecepatan notifikasi (email) tergantung dari orang yang bertanggung jawab untuk memberikan notifikasi, pada sistem kami akan otomatis mengirimkan notifikasi jika ada aktivitas pada masing-masing aplikasi.

Sebelum masa pengembangan dimulai, tentu saja kami sudah membuat mockup dan wireframe sebagai gambaran akan seperti apa sistem yang kami buat, tetapi sejak sprint 1 hingga sekarang, cukup banyak perubahan design tampilan pada sistem kami untuk menyesuaikan dengan kebutuhan yang juga mengalami perubahan dan beberapa ada yang kami anggap tidak cukup “enak dilihat” dan “enak digunakan” sehingga dilakukan perubahan.

Memasuki masa pengembangan awal, yaitu sprint 1, kami masih banyak “meraba-raba” karena banyak hal baru yang perlu kami pelajari sehingga perlu waktu adaptasi yang cukup lama. Banyak sekali hal yang baru kamu pelajari, sebut saja Django Framework, Jinja Templating, Testing, Deployment, Clean Code, dan banyak hal lainnya. Selama proses pengembangan ini, kami menggunakan GIT untuk version control.

GIT

GIT merupakan suatu version control system yang biasa digunakan pada software development process. Pada pengerjaan proyek ini, kami menerapkan GIT Flow sesuai dengan panduan yang disediakan. Saat awal memulai, hanya terdapat 1 branch yaitu Master yang dikendalikan oleh scrum master. Branch Master hanya boleh berisi user story yang sudah sesuai permintaan dan “bug free” yang berarti hanya boleh dilakukan merge ke branch master setelah disetujui product owner. Untuk melakukan pengerjaan, tim kami membuat branch Develop yang merupakan copy dari branch Master. Dari branch Develop ini barulah kemudian dibagi lagi menjadi beberapa branch user story yang diberi nama sesuai dengan user story tersebut. Setelah selesai dengan pengerjaan pada branch user story masing-masing, akan dilakukan merge ke branch Develop. Karena terdapat beberapa user story yang perlu di merge ke Develop, maka kami melakukannya secara bergantian, setiap 1 user story dilakukan merge, kami akan menggabungkan hasil merge dari Develop lagi sebelum melakukan merge user story selanjutnya.

Masing-masing user story memiliki branch sendiri

Pada sprint 2 kemarin, kami mendapati 1 user story yang ternyata tidak sesuai dengan kebutuhannya, sehingga kami belum bisa melakukan merge ke Master. Kami perlu membuat branch Coldfix yang diambil dari branch Develop, kemudian dari Coldfix tersebut barulah dibagi lagi menjadi beberapa branch user story yang perlu “dibenahi”. Pada branch ini, selain kami membetulkan user story yang “bermasalah” itu, kami juga memanfaatkannya untuk mengubah Front End agar lebih sesuai dan lebih baik. Setelah selesai dengan masing-masing branch Coldfix, kemudian akan dilakukan merge ke Coldfix kemudian dilanjutkan merge ke Develop jika sudah sesuai. Semoga saja pada sprint 3 ini kami berhasil merge ke Master tepat waktu dan sesuai dengan kebutuhan.

Branch Coldfix yang digunakan untuk memperbaiki fitur pada branch Develop
Test Driven Development

Pada pengerjaan proyek ini, kami juga dituntut untuk menerapkan TDD. TDD ini mengharuskan kami untuk mengawali proses pengerjaan dengan membuat unit testing (setelah doa tentunya) sebelum melakukan implementasi fitur. Setelah memulai sprint 2, saya baru bisa menerapkan TDD ini dengan baik dan teratur. Menurut Martin Fowler,terdapat 3 tahap penting pada TDD:

  • Buat test untuk setiap fungsi yang akan digunakan
  • Implementasikan fungsi tersebut hingga test-nya berhasil
  • Refactor code agar lebih terstruktur dan rapi.

Jika dikaitkan dengan GIT Flow, saya sudah menerpakan TDD, yaitu saat saya melakukan push haruslah merah (failed) terlebih dahulu karena saya membuat test yang belum ada implementasinya, kemudian baru saya implementasikan fitur tersebut sesuai dengan test yang sudah dibuat, setelah dilakukan push menjadi hijau (success). Test ini sangat penting, karena apa yang saya implementasikan akan bergantung dengan test yang sudah dibuat.

Clean Code

Clean code merupakan suatu standar yang mengharuskan kita membuat code yang mudah dipahami, efisien, dan efektif. Clean code yang saya terapkan meliputi error code dan exception handling, code standarization, naming, dan layout.

Code Standarization

  • Seluruh penamaan menggunakan Bahasa inggris
  • Layout (indentation) menggunakan tab (4 spaces)
  • Penamaan class menggunakan CamelCase
  • Penamaan variable dan fungsi menggunakan snake case
Contoh penamaan class, fungsi, dan variabel
  • Penamaan file menggunakan format [role]_[verb], sedangkan nama fungsi sesuai dengan tujuan fungsi tersebut
Contoh penamaan file template (html)
Error Code

Untuk error code, kami menetapkan untuk menggunakan code dengan rentang 500–599 karena code dengan digit pertama 5 berkaitan dengan internal server error. Berikut beberapa error code yang kami gunakan

Exception handling dilakukan pada beberapa kasus yang perlu diberikan exception, misal dilakukan download berkas suatu aplikasi, mungkin saja berkas yang ditunjuk tersebut tidak ada atau corrupt sehingga perlu diberikan ObjectDoesNotExist dan akan merefer ke page bertuliskan bahwa berkas tidak tersedia. Tidak hanya pada level backend, pada frontend saya juga berusaha mengatasi hal tersebut dengan melakukan pengecekan sebelum menampilkan, jika suatu aplikasi tidak memiliki berkas, maka tombol button akan digantikan dengan tulisan “Tidak tersedia”.

Contoh exception handling untuk download berkas CYD

Pada Clean Code ini juga terdapat poin Maintain High Code Coverage yang sudah diterapkan juga oleh tim kami. Pada sprint 1 kami masih bisa mendapatkan code coverage 100%. Memasuki sprint 2 kami kehilangan 1%, walaupun sudah berkali-kali dicari tapi kami tetap tidak menemukan kekurangan 1% itu dimana. Dan pada sprint 3 kali ini kami masih bisa mendapatkan code coverage 97%, yang masih termasuk besar dibandingkan dengan batasnya yaitu 80%.

Code coverage tim kami mencapai 97%
Software Environment: Staging server, SIT, dan UAT

Staging server merupakan server yang digunakan untuk menjalankan website kami. Pada proyek ini, kami menggunakan staging server dengan ip address http://139.59.231.183. Staging server kami atur agar menggunakan environment seperti dengan local yaitu docker.

Pada branch develop, kami menerapkan continuous integration dan continuous delivery, sehingga setiap ada perubahan pada branch develop akan diteruskan ke staging server.

UAT atau User Acceptance Test merupakan testing yang dilakukan oleh user secara langsung. Test ini dilakukan dengan mengikuti flow pada sistem kami. Apakah setiap fitur bekerja sebagaimana semestinya. Untuk saat ini, UAT dijalankan saat demo di sprint review dengan product owner.

Penerapan Agile Manifesto Value

Sejak awal pengerjaan hingga saat ini memasuki sprint ke-3, tentu saja tim kami menemukan beberapa kendala dalam prosesnya. Tetapi, setiap kendala yang kami temui sejauh ini selalu dapat kami atasi bersama. Karena dari sebelum proyek ini dimulai, kami membangun tim berdasarkan individu masing-masing anggota tim. Kami sudah cukup mengenal dan berteman baik satu sama lain, kami juga mengetahui dan percaya akan kemampuan satu sama lain. Tiap individu pada tim kami memiliki potensi yang baik dan dapat berinteraksi dengan baik. Kami sering melakukan sharing pengetahuan yang kami miliki masing-masing. Misal seperti pada awal sprint saya belum bisa membuat unit testing dan Tsesar sudah cukup menguasainya, oleh karena itu Tsesar membantu saya mempelajari bagaimana cara membuat unit testing yang baik. Hal ini berkaitan dengan nilai Individuals and interactions over processess and tools.

Kemudian, pada akhir sprint 2 kemarin terdapat 1 backlog yang tidak sesuai dengan permintaan. Kekeliruan ini terjadi karena terdapat perbedaan pemahaman antara kami dengan yang dimaksud oleh product owner. Berdasarkan nilai Responding to change over following a plan, walaupun kami sudah membuat backlog tersebut, tetapi karena memang belum sesuai maka kami melakukan perubahan dari rencana awal kami dan kami perbaiki pada sprint ke-3 ini. Walaupun kita sudah memiliki rencana awal, tetapi jika memang dibutuhkan, maka perlu dilakukan perubahan.

Penerapan Agile Manifesto Principles

Dari 12 Agile Manifesto Principle yang pernah saya bahas sebelumnya, saya akan menjabarkan contoh principles yang sudah kami terapkan selama proses pengembangan hingga sprint ke-3 ini.

Business people and developers must work together daily throughout the project. Sebelum memasuki masa pengembangan, pak Heru selaku product owner ikut berperan pada proyek ini untuk mendeskripsikan kebutuhan untuk proyek ini. Selama masa pengembangan pun beliau tidak lepas tangan dari proses pengerjaan kami. Seperti pada sprint kemarin, kami memiliki beberapa inisiatif diluar requirement awal, kami mendiskusikannya dengan beliau dan mendapat persetujuan untuk mengimplementasikannya. Kemudian, pada sprint kemarin saat terjadi kekeliruan pada sebuah backlog, kami mendiskusikannya lagi dengan beliau bagaimana seharusnya backlog tersebut. Kemudian setelah menemukan permasalahannya, kami mulai memperbaikinya pada sprint ini.

Breaking big work down into smaller components that can be completed quickly. Dalam proyek ini, kami mendapati beberapa task yang masih cukup besar dan dapat dibagi menjadi task yang lebih kecil.

Sebagai admin fakultas, saya dapat memantau perkembangan aplikasi CYD. Task ini kami bagi lagi menjadi 4 bagian, yaitu fakultas memantau aplikasi yang sedang diproses, disetujui, dikembalikan (revisi), dan dibatalkan.

Sebagai DGB, saya dapat memproses pengajuan Dosen sehingga saya dapat menyetujui, menolak, atau meminta revisi tehadap pengajuan. Task ini juga masih dapat dibagi menjadi 2 task yang lebih kecil, yaitu DGB melihat daftar aplikasi yang sedang aktif dan memproses pengajuan aplikasi tersebut.

Referensi: