Agile Scrum & Git Flow
Agile Scrum & git flow dalam proses software development
Memahami Agile Scrum
Pada pengembangan mobile app scrum booster ini, kami juga menggunakan metode scrum. Jadi kita mengerjakan sebuah aplikasi untuk scrum dengan mengunakan scrum, hebat juga ya. Lalu apa sih metode scrum ini ? Scrum ini merupakan sebuah workflow atau proses dalam pengembangan suatu perangkat lunak. Scrum ini juga merupakan bagian dari Agile Software Development, dimana metode ini sangat fleksibel terhadap adanya perubahan requirements pada saat pengembangan.
Dalam metode scrum ini, terdapat 3 role yaitu Product Owner, Scrum Master, dan Scrum Team / Tim Developer. Product Owner atau kita sebut PO adalah individu yang berperan memberikan spesifikasi produk yang ingin dibuat, serta menilai apakah produk yang dinilai sudah sesuai atau belum. Pada kuliah PPL ini PO kami adalah Pak Eko dari RSE Labs. Kemudian role berikutnya adalah Scrum Master atau SM. Kak Arfi merupakan SM dari kelompok kami yang tentunya memegang peran penting dalam proses scrum yang kami jalani. SM adalah seorang individu yang sudah memiliki pengalaman tentang scrum. Tugas dari SM adalah untuk memastikan serta membantu tim agar metode scrum ini berjalan dengan baik. Yang terakhir adalah Scrum Team, yang merupakan role kami dari pengembangan software ini. Scrum Team ini berperan untuk membuat produk berdasarkan spesifikasi yang sudah diberikan oleh PO.
Dalam metode scrum terdapat ceremony/kegiatan yang dilakukan, diantaranya adalah Sprint Planning, Daily Meeting, Sprint Review, dan Sprint Retrospective. Sprint adalah proses 1 kali iterasi scrum atau sebuah batasan waktu (timebox) untuk pengembangan produk yang siap digunakan oleh pengguna. Waktu dari Sprint biasanya 2–4 minggu teragantung dari proyek pengembangan itu sendiri, Sprint dimulai dari Sprint Planning, dimana tim menentukan product backlog mana yang ingin dikerjakan oleh tim selama 1 sprint. Selama sprint berjalan ada kegiatan Daily Meeting dimana kegiatan ini melakukan meeting selama 15 menit setiap hari untuk menyampaikan progress yang sudah dikerjakan serta komunikasi antar anggota jika terjadi perubahan. Diakhir sprint terdapat kegiatan Sprint Review & Sprint Retrospective. Diakhir sprint, Scrum team akan melaporkan dan mempresentasikan produk yang sudah dibuat selama 1 sprint berjalan kepada PO, apakah produk yang dibuat sudah sesuai atau belum. Setalah sprint review selesai, tim akan melakukan sprint retrospective untuk menilai anggota satu sama lain dan melihat kelebihan yang perlu dipertahan serta kekurangan yang perlu diperbaiki dalam tim.
Selain itu, terdapat juga manefesto yaitu sebuah “kesepatan” oleh para programmer untuk membantu software development dari sisi business requirements dan teknologi itu sendiri. berikut 4 nilai dan 12 prinsip dari agile manifesto.
4 Nilai Agile Manifesto:
1. Individuals and Interactions Over Processes and Tools
Pentingnya hubungan antar individual dalam sebuah tim menentukan flow kerja dari sebuah tim tersebut, disini kuncinya adalah komunikasi, komunikasi yang baik dapat meningkatkan kinerja tim dalam sebuah software development.
2. Working Software Over Comprehensive Documentation
Dokumen yang komprehensif itu baik, namun hal ini juga memakan banyak waktu dalam sebuah software development, agile didesain agar deliverablesutama seorang developer tidak terganggu oleh pembuatan sebuah dokumentasi.
3. Customer Collaboration Over Contract Negotiation
Waterfall melibatkan kostumer hanya pada tahap requirement gathering, dan pada tahap tersebut akan dibuatkan kontrak atau MOU atas fitur2 apa saja yang akan ada dalam sebuah software, sedangkan agile melibatkan kostumer pada tahap-tahap seperti sprint review, dimana seorang kostumer terlibat langsung dalam prosesnya juga.
4. Responding to Change Over Following a Plan
Dibanding metode software development lain, agile memperbolehkan adanya perubahan, sebuah rencana pengembangan dibagi menjadi task-task kecil pada setiap sprint, maka task-task ini dapat diubah pada iterasi selanjutnya.
12 Prinsip Agile Manifesto:
1. Customer satisfaction through early and continuous software deliver
Prinsip ini dipenuhi dengan sebuah sprint review, di mana kostumer menerima MVP dari sebuah produk pada setiap iterasinya, kostumer akan merasa lebih puas jika mereka dapat melihat sebuah produk di setiap iterasi.
2. Accommodate changing requirements throughout the development process
Sediakan waktu untuk perubahan suatu requirement, agar tidak menghambat fase development.
3. Frequent delivery of working software
Selalu sediakan MVP pada setiap sprint review.
4. Collaboration between the business stakeholders and developers throughout the project
Komunikasi yang baik antara klien dan pengembang adalah kunci dari metode agile.
5. Support, trust, and motivate the people involved
Peran member tim satu sama lain juga untuk saling bantu dan menyemangati.
6. Enable face-to-face interactions
Interaksi secara langsung adalah bentuk komunikasi terbaik dala metode agile.
7. Working software is the primary measure of progress
MVP dari setiap iterasi adalah cara yang baik untuk mengukur progresssebuah pengembangan.
8. Agile processes to support a consistent development pace
Pace yang cepat dan konsisten adalah sebuah best practice.
9. Attention to technical detail and design enhances agility
Desain dan rencana yang baik dapat mendukung pace yang cepat dan konstan.
10. Simplicity
Tidak diperlukan over-develop suatu produk, cukup sesuai kesepakatan pada setiap sprint.
11. Self-organizing teams encourage great architectures, requirements, and designs
Tim yang kuat adalah tim yang dapat berkomunikasi dengan baik satu sama lain dan tim yang memiliki skill-set yang lengkap dari gabungan antar individu.
12. Regular reflections on how to become more effective
Selalu adakan evaluasi atas hal apa yang dapat ditingkatkan dari kinerja pribadi dan kinerja tim.
Berikutlah nilai-nilai dan prinsip-prinsip agile manifesto, kami sebagai sebuah tim berusaha sepenuh tenanga untuk memenuhi semua ini, sembari belajar untuk menyiapkan diri di dunia pengembangan perangkat lunak nanti, semangat PPL :)
Git Flow dalam pengembangan Scrum Booster
Dalam proses aplikasi Scrum Booster ini, kelompok kami menggunakan git untuk version contol dari software yang kami kembangkan. git flow kami mengikuti ketentuan yang sudah dirumuskan oleh Tim Dosen dan Asisten. Berikut ini adalah visualisasi git tree dari pengembangan Scrum Booster ini :
Sama seperti yang sudah dijelaskan oleh izzan dalam blog sebelumnya, dalam Pengembangan Scrum Booster terdapat 3 fase yaitu Development, Staging, dan Production.
- Development: adalah fase pengembangan awal, dimana dilakukan implementasi kode awal untuk pondasi sebuah proyek dan menggunakan data seeding yang masih bersifat dummy.
- Staging: Pada fase ini, kode yang sudah dikerjakan dalam fase Development dikumpulkan. Namun sebelum dikumpulkan harus sudah melewati proses code review oleh Scrum Master. Kode yang dikumpulkan sudah bersifat deliverables (kemungkinan produk) tetapi masih ada kemungkinan bug yang tinggi. Data seeding pada proses ini sudah mulai menyusuaikan kondisi real di lapangan
- Production: Pada fase ini, kode yang sudah melalui tahap code review oleh Product Owner, testing oleh calon pengguna, disimpan. Pada tahap ini, aplikasi yang sudah siap untuk dipasarkan dan digunakan oleh end userdihasilkan. Data seeding dalam fase ini sudah berbentuk data asli milik user.
Selanjutnya, juga ada beberapa penamaan branch (cabang) dalam pengembangan Scrum Booster. Ada beberapa branch, yaitu:
- Branch master: Branch utama yang menyimpan kode yang sudah siap di-deploy ke dalam production environment. Kode yang tersimpan dalam branch ini sudah siap digunakan oleh user.
- Branch staging: Branch yang terkait dengan proses pengembangan. Branch ini akan merupakan hasil merge dari pekerjaan dari setiap anggota. Aplikasi yang akan dipergunakan pada saat sprint review berasal dari branch ini.
- Branch user story: Branch yang digunakan untuk implementasi sebuah user story (PBI). Nantinya, akan ada beberapa cabang user story yang diberi nama sesuai dengan nama user story yang dikembangkan. Branch ini merupakan percabangan dari branch staging. Pada saat akan digabungkan, code reviewer dari branch user story adalah teman satu tim yang bukan penanggung jawab dari user story tersebut.
- Branch hotfix: Percabangan dari branch master yang dibuat apabila terdapat bug pada kode di branch master. Branch ini digunakan sebagai tempat untuk memperbaiki bug tersebut. Selanjutnya, branch ini akan kembali di-merge ke branch master.
- Branch coldfix: Branch yang dibuat untuk melakukan rollback (menghapus semua perubahan dari branch user story) apabila dalam sprint review terjadi penolakan salah satu user story oleh Product Owner. Branch ini nantinya akan ditarik dari branch staging, dan perbaikannya akan kembali di-merge ke branch staging.
Selanjutnya, ada beberapa peraturan penamaan commit message dalam Git Flow pengembangan Scrum Booster ini:
- [RED]: Commit yang bersifat menginisiasi kode unit test dari suatu aplikasi (fungsi/class kosong). Ditandai dengan silang merah pada hasil pipeline test GitLab. Contoh commit message: [RED] membuat test_login_admin
- [GREEN]: Commit yang bersifat mengimplementasikan unit test pada aplikasi. Ditandai dengan centang hijau pada hasil pipeline test GitLab. Contoh commit message: [GREEN] membuat fungsi login_for_admin
- [REFACTOR]: Commit yang bersifat mengubah susunan kode unit test pada aplikasi, dengan tidak mengubah status dari pipeline test Gitlab. (tetap sukses). Contoh commit message: [REFACTOR] restructure fungsi login_for_admin
- [CHORES]: Commit yang berisikan implementasi yang tidak berhubungan langsung dengan fungsionalitas aplikasi (ex. penambahan asset berupa image tanpa mengubah implementasi kode). Tidak ada peraturan khusus mengenai pipeline status Gitlab. Contoh commit message: [CHORES] restructure perintah pada berkas .gitlab-ci.yml
Sekian blog dari saya kali ini, sampai ketemu di blog selanjutnya!
