Tugas dan tiket — apa itu, sistem pelacakan dan bekerja dengan tugas

Apa itu tugas dan tiket?

Tugas (dari bahasa Inggris task) — unit kerja yang dicatat dalam sistem pelacakan. Berisi deskripsi, prioritas (Critical, High, Medium, Low), pelaksana, tenggat waktu, dan status. Dalam pengembangan mobile, tugas bisa berupa “Menambahkan layar profil dengan avatar”, “Menerapkan paginasi feed”, atau “Memperbarui versi targetSdk ke 35”. Setiap tugas terikat pada proyek, sprint, dan pengembang atau tim tertentu.

Tiket (dari bahasa Inggris ticket) — entitas yang lebih luas. Tiket bisa berupa laporan bug (“Aplikasi crash saat rotasi layar di Android 14”), permintaan fitur (“Menambahkan dukungan tema gelap”), pengaduan ke dukungan teknis (“Notifikasi push tidak datang”), atau tugas dari manajer (“Menyiapkan laporan crash rate bulanan”). Perbedaan antara tugas dan tiket kabur: di Jira kedua konsep disatukan dalam Issue. Perbedaan kunci: tugas selalu merupakan pekerjaan dengan pelaksana, tiket bisa berupa permintaan tanpa pelaksana tertentu hingga saat triase.

Dalam Scrum dan Kanban, tugas adalah elemen utama backlog. Setiap tugas harus memenuhi kriteria INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Tugas independen dapat diimplementasikan dalam urutan apa pun. Dapat diperkirakan — tim dapat memperkirakan upaya kerja. Kecil — muat dalam satu sprint. Dapat diuji — memiliki kriteria penerimaan yang jelas. Tugas besar (epik) dipecah menjadi bagian yang lebih kecil hingga semua kriteria terpenuhi.

Jenis tugas dalam pengembangan mobile

Feature — fungsionalitas baru aplikasi. Contoh: “Layar masuk melalui biometri (Face ID / Touch ID)”. Tugas Feature selalu terikat pada user story dan memiliki Kriteria Penerimaan. Perkiraan — dalam story points (1, 2, 3, 5, 8, 13). Bug — cacat yang ditemukan dalam proses pengembangan atau pengujian. Prioritas tiket bug ditentukan oleh severity (crash → Critical, UI-bug → Medium, salah ketik → Low). Dalam pengembangan mobile, crash rate di atas 0,1% adalah bug kritis dan memerlukan perbaikan segera.

Tech Debt / Chore — tugas teknis tanpa efek yang terlihat oleh pengguna: memperbarui pustaka (Dependency Bump), refactoring (Migrasi dari ViewPager ke ViewPager2), konfigurasi CI/CD, menulis tes. Tugas Tech Debt sering diremehkan, meskipun menurut data Stripe 2025, hingga 30% waktu tim mobile dihabiskan untuk pemeliharaan dan pembayaran utang teknis. Mengabaikan Tech Debt menyebabkan peningkatan jumlah bug dan perlambatan pengembangan fitur baru.

Jenis tambahan: Spike (tugas penelitian — mempelajari teknologi baru, menulis POC), Task (pekerjaan apa pun yang tidak terkait dengan kode — dokumentasi, review desain), Improvement (peningkatan fungsionalitas yang ada — optimalisasi waktu muat layar). Di Jira, jenis issues dapat dikonfigurasi per proyek. Set standar untuk tim mobile: Story, Bug, Task, Improvement, Epic. Epic — topik besar yang menyatukan beberapa cerita. Contoh: “E-commerce: keranjang dan checkout”.

Siklus hidup tugas: dari pembuatan hingga penutupan

Open (To Do) — tugas dibuat tetapi belum dimulai. Berisi deskripsi, Kriteria Penerimaan, prioritas. Dalam status ini, tugas harus melalui grooming (klarifikasi dan perkiraan) sebelum masuk ke sprint. In Progress — pengembang mulai bekerja. Dalam pengembangan mobile, penting untuk menautkan commit dan pull request ke tugas: di Jira melalui Smart Commits (APP-123 #comment perbaikan bug), di GitHub/GitLab melalui kata kunci dalam deskripsi PR (Closes APP-123).

In Review — kode dikirim untuk review. Pemeriksaan otomatis: CI (Gradle build, lint, tes unit), SonarQube (kualitas kode), Danger (changelog, tes). Pengembang tidak dapat mengambil tugas berikutnya selama tugas saat ini dalam Review — ini mencegah multitasking. QA / Testing — penguji memeriksa pada perangkat nyata (Android — berbagai versi OS dan ukuran layar, iOS — berbagai model iPhone). Jika bug ditemukan, tugas kembali ke In Progress dengan komentar.

Done (Closed) — tugas selesai: kode digabungkan ke main/master, lulus pengujian, siap dirilis. Beberapa tim menambahkan status Deployed — tugas mencapai pengguna hanya setelah build dirilis di toko. Penting untuk menutup tugas dengan komentar tentang hasil: versi apa, PR apa, metrik apa yang berubah. Menurut data Linear (2025), tim yang menutup tugas dengan deskripsi hasil 40% lebih jarang kembali ke tugas yang sama.

Siklus hidup dapat mencakup status Blocked — tugas tidak dapat diselesaikan karena ketergantungan eksternal (menunggu desain, jawaban dari backend, persetujuan manajer). Tugas yang diblokir harus memiliki komentar dengan alasan dan tanggal pemeriksaan berikutnya. Review mingguan tugas yang diblokir membantu mengidentifikasi keterlambatan sistemik dalam proses pengembangan. Pemblokir lebih dari 2 minggu memerlukan eskalasi ke tingkat manajer produk.

Sistem pelacakan tugas

Jira — standar industri untuk tim dari 10 orang. Mendukung papan Scrum dan Kanban, konfigurasi alur kerja tingkat lanjut, bidang kustom, otomatisasi, integrasi dengan Bitbucket/GitHub. Kekurangan: redundansi untuk tim kecil, antarmuka lambat, konfigurasi rumit. Untuk proyek mobile, Jira dikonfigurasi dengan: plugin Mobile-specific fields (Platform, OS version, Device model), integrasi dengan TestFlight dan Firebase Test Lab, otomatisasi pembuatan build rilis. Jira — pilihan proyek perusahaan dengan proses birokratis.

Linear — pelacak modern untuk tim produk. Antarmuka cepat, dukungan kelas satu untuk pintasan keyboard, Cycle bawaan (analog sprint), integrasi dengan GitHub dan Slack. Kelebihan: kecepatan pembuatan tugas melalui CMD+K, distribusi otomatis ke fase (Triaged → Backlog → Upcoming → Current → Completed), dokumentasi dan peta jalan bawaan. Linear dipilih oleh startup dan tim produk yang menghargai kecepatan kerja. Pada tahun 2025, 40% proyek mobile baru menggunakan Linear.

Trello — papan kanban sederhana untuk tim kecil (2-5 orang). Kartu dengan daftar periksa, label, tenggat waktu. Kekurangan: tidak ada sprint, analitik terbatas, sulit diskalakan. YouGile — padanan Trello versi Rusia dengan papan kanban, obrolan, dan panggilan video. Asana — pelacak dengan fokus pada proyek dan linimasa. Pemilihan pelacak tergantung pada ukuran tim, anggaran, dan preferensi: Jira untuk enterprise, Linear untuk tim produk, Trello/YouGile untuk startup. Penting: alat harus seragam untuk seluruh tim — desainer, pengembang, penguji, manajer bekerja dalam satu sistem.

Praktik terbaik pengelolaan tugas

Tulis Kriteria Penerimaan — kriteria penerimaan harus spesifik dan dapat diverifikasi. Buruk: “Layar masuk berfungsi”. Baik: “Pengguna memasukkan email dan kata sandi, menekan Masuk. Jika data benar — pindah ke layar utama. Jika salah — ditampilkan kesalahan “Email atau kata sandi salah””. Kriteria Penerimaan (AC) adalah kontrak antara pengembang, penguji, dan manajer produk. Tanpa AC, tugas tidak memenuhi Definition of Ready (DoR) dan tidak boleh masuk ke sprint.

Tautkan semuanya. Commit, PR, kasus uji, maket desain (Figma), diskusi di Slack — semuanya harus terhubung ke tugas. Di Jira ini dilakukan melalui tautan di komentar, di Linear — melalui penautan otomatis PR. Aturan satu klik: dari tugas ke desain/kode/tes — tidak lebih dari satu klik. Pengembang membuka tugas dan langsung melihat maket di Figma, tautan PR, dan kasus uji. Ini mempercepat orientasi anggota tim baru sebesar 30% menurut data Linear (2025).

Jangan buat tugas hantu. Tugas tanpa deskripsi, tanpa AC, dan tanpa prioritas adalah sampah. Jika dalam standup harian tidak ada yang ingat mengapa tugas dibuat — harus dihapus atau diklarifikasi. Aturan 48 jam: jika tugas berada dalam status In Progress tanpa aktivitas selama 48 jam — pengembang harus meninggalkan komentar tentang alasan keterlambatan. Menurut data Jira (2025), 60% tugas yang tidak aktif lebih dari 3 hari akhirnya ditutup tanpa penyelesaian.

Dekomposisi tugas: epik, user story, dan sub-tugas

Epic — area fungsional besar yang menyatukan beberapa cerita. Contoh: “Onboarding pengguna” mencakup “Layar selamat datang”, “Pemilihan minat”, “Unggah avatar”, “Pengaturan notifikasi”. User Story — tugas dari sudut pandang pengguna. Format: “Sebagai [peran], saya ingin [tindakan] sehingga [nilai]”. Contoh: “Sebagai pengguna, saya ingin masuk melalui biometri agar tidak perlu memasukkan kata sandi setiap kali”. User Story ditulis oleh manajer produk atau pemilik produk.

Sub-tugas (Sub-task) — dekomposisi pekerjaan teknis di dalam Story / Task. Contoh untuk Story “Layar Profil”: Sub-task 1: Membuat UI layar (XML / SwiftUI), Sub-task 2: Menghubungkan ke ViewModel, Sub-task 3: Menulis tes unit, Sub-task 4: Tes Snapshot, Sub-task 5: Tes UI (Espresso / XCUITest). Aturan dekomposisi: setiap sub-tugas selesai dalam 1-2 hari. Jika pengembang memperkirakan sub-tugas lebih lama — kita bagi lagi. Sub-tugas adalah teknik internal tim, tidak terlihat di backlog produk. Jumlah perkiraan sub-tugas belum tentu sama dengan perkiraan Story induk (sebagian pekerjaan — komunikasi, code review, pengujian).

Piramida dekomposisi: Epic (Kuartal / Setengah tahun) → Feature / Story (Sprint) → Task (1-3 hari) → Sub-task (Beberapa jam). Teknik INVEST membantu memeriksa kualitas dekomposisi. Jika tugas tidak Independent (tergantung pada yang lain) — ini menandakan dekomposisi salah. Jika tugas tidak Small (lebih dari 8 story point) — perlu dibagi lagi. Pola umum: Epic → 5-15 Stories → setiap Story → 3-8 Sub-tugas. Perkiraan akhir epik = jumlah perkiraan Stories, tetapi sprint pertama biasanya memiliki deviasi 20-30% dalam perkiraan.

Kesalahan umum saat bekerja dengan tugas

Kesalahan 1: tugas terlalu besar. Tugas 2 minggu kerja adalah epik yang perlu didekomposisi. Tugas besar tidak cocok untuk pelacakan harian, menggantung di In Progress selama berminggu-minggu. Aturan: ukuran maksimum tugas — 2-3 hari kerja. Semua yang lebih besar — dekomposisi. Efek samping: pengembang merasakan kemajuan dengan menutup 2-3 tugas per minggu, bukan satu tugas raksasa. Ini meningkatkan motivasi dan prediktabilitas tenggat waktu.

Kesalahan 2: tidak ada Kriteria Penerimaan. Pengembang membuat fitur, penguji memeriksa — semuanya ok. Manajer: “Di mana tombol edit?” — “Tidak ditulis di tugas”. Tanpa AC setiap pihak memahami tugas dengan caranya sendiri. Hasil: pengerjaan ulang, konflik, tenggat waktu yang terlewat. AC — kontrak: jika tidak ada kriteria dalam tugas — tidak siap untuk sprint. Pada grooming, pertama-tama diperiksa keberadaan AC. Jika AC tidak ada — tugas dikirim untuk perbaikan ke Manajer Produk.

Kesalahan 3: melupakan Tech Debt. Tim hanya mengerjakan tugas Feature sprint demi sprint. Setelah enam bulan: kompilasi memakan waktu 15 menit, Gradle usang 3 versi utama, tes gagal di CI karena deprecation. Solusi: cadangkan 20% waktu tim untuk Tech Debt (praktik Google SRE “SLO-based error budget”). Buat setidaknya satu tugas Tech Debt untuk setiap sprint Feature. Proporsi: untuk setiap 3 tugas Feature — 1 Tech Debt atau Bug. Ini mencegah akumulasi utang teknis dan mempertahankan kecepatan pengembangan.